[clang] [clang][dataflow] Model assignment to derived class from base. (PR #85064)

[via cfe-commits]

================
@@ -14,18 +14,52 @@
 
 #define DEBUG_TYPE "dataflow"
 
-void clang::dataflow::copyRecord(RecordStorageLocation &Src,
-                                 RecordStorageLocation &Dst, Environment &Env) {
+namespace clang::dataflow {
+
+static void copyField(const ValueDecl *Field, StorageLocation *SrcFieldLoc,
----------------
martinboehme wrote:

> Could `SrcFieldLoc` be a ptr to const? (Same below).

I think what you want to express is that the source field location is only ever read from, while the destination field location is written to?

This isn't really how we use `StorageLocation` constness in the framework today. (Maybe we should -- that's a separate discussion -- though I'm not convinced about how much this would buy us.) Grepping for `const StorageLocation` yields only a few hits in the whole framework[^1], and I think that's for good reason: A `StorageLocation` is essentially immutable anyway; all of its method are const, as are almost all of the methods in the derived class `RecordStorageLocation`, with the exception of `setChild()` (which is a bit of a special case). It's similar in this respect to a [flyweight](https://en.wikipedia.org/wiki/Flyweight_pattern). So the distinction between `const StorageLocation *` and `StorageLocation *` doesn't mean much in practice, and I guess we've gravitated to the less verbose `StorageLocation`.

We _could_ consider using `StorageLocation` constness to encode "can this storage location be written to" (which I think is your intent?), which would entail changing the storage location parameter of `setValue(const StorageLocation &, Value &)` to be non-const, but that would be a pretty far-reaching change because I think we'd need to add const in a lot of places in the framework.

[^1]: Notably, `setValue(const StorageLocation &, Value &)` is one of them, so passing a const storage location does not prevent us from writing to that storage location.

https://github.com/llvm/llvm-project/pull/85064