These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures.
Relands #129502. Previously when the framework encountered unsupported values (such as enum classes), they were always treated as equal when comparing with `==`, regardless of their actual values being different. Now the two sides are only equal if there's a Value assigned to them. Added handling for the special case of `nullptr == nullptr`, to preserve the behavior of untyped `nullptr` having no value.
Reverts llvm/llvm-project#129502 seeing new crashes around https://github.com/google/crubit/blob/859520eca82d60a169fb85cdbf648c57d0a14a99/nullability/test/smart_pointers_diagnosis.cc#L57 Would like some time to investigate.
Previously when the framework encountered unsupported values (such as enum classes), they were always treated as equal when comparing with `==`, regardless of their actual values being different. Now the two sides are only equal if there's a Value assigned to them. Added a Value assignment for `nullptr`, to handle the special case of `nullptr == nullptr`.
This was missing a call to `ignoreCFGOmittedNodes()`. As a result, the function would erroneously conclude that a block did not contain an expression consumed in a different block if the expression in question was surrounded by a `ParenExpr` in the consuming block. The patch adds a test that triggers this scenario (and fails without the fix). To prevent this kind of bug in the future, the patch also adds a new method `blockForStmt()` to `AdornedCFG` that calls `ignoreCFGOmittedNodes()` and is preferred over accessing `getStmtToBlock()` directly.
We definitely know that these operations change the value of their operand, so clear out any value associated with it. We don't create a new value, instead leaving it to the analysis to do this if desired.
To avoid generating unnecessary values, we don't create a new value but instead leave it to the specific analysis to do this if desired.
To avoid generating unnecessary values, we don't create a new value but instead leave it to the specific analysis to do this if desired.
- Instead of comparing the identity of the `PointerValue`s, compare the underlying `StorageLocation`s. - If the `StorageLocation`s are the same, return a definite "true" as the result of the comparison. Before, if the `PointerValue`s were different, we would return an atom, even if the storage locations themselves were the same. - If the `StorageLocation`s are different, return an atom (as before). Pointers that have different storage locations may still alias, so we can't return a definite "false" in this case. The application-level gains from this are relatively modest. For the Crubit nullability check running on an internal codebase, this change reduces the number of functions on which the SAT solver times out from 223 to 221; the number of "pointer expression not modeled" errors reduces from 3815 to 3778. Still, it seems that the gain in precision is generally worthwhile. @Xazax-hun inspired me to think about this with his [comments](https://github.com/llvm/llvm-project/pull/73860#pullrequestreview-1761484615) on a different PR.
The existing code was full of comments about how we assume this is always the case, but it's not mandated by the standard, and there is code out there that returns a different type. So check that the result type is in fact the same as the destination type before attempting to copy to the result. To make sure that we don't bail out in more cases than intended, I've extended existing tests to verify that in the common case, we do return the destination object (by reference or value, as the case may be).