ymandel added a comment. I'm a little confused by one of the points in the description:
> `setValueStrict()`: The RFC proposes that this should always create the same > StorageLocation for a given Value, but, in fact, the transfer functions that > exist today don't guarantee this; almost all transfer functions > unconditionally create a new `StorageLocation` when associating an expression > with a `Value`. Since values are immutable, we (intentionally) share them between different storage locations. So, it makes sense that a single value could be associated with multiple storage locations. Now, there's a bug in that values aren't really immutable since you can update the fields, so we have a false sharing bug in the framework, but maybe that only applies to glvalues? ================ Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h:273 /// + /// This function is deprecated; prefer `setStorageLocationStrict()`. + /// For details, see https://discourse.llvm.org/t/70086. ---------------- Use LLVM_DEPRECATED? here and below. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D150653/new/ https://reviews.llvm.org/D150653 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
