sethp wrote:
Ah, sorry: my specific question is whether the APValue::LValuePathEntry ought
to grow an understanding of vector types rather than re-using the array
machinery, as here. It sounds like arrays express a couple of properties
vectors don't, so there's potential for the evaluator to want to distinguish an
LValuePath that ends in an array element from one that references a vector
component.
That said, I don't have a strong sense of whether it's worth doing. "Sema won't
build an AST that the evaluator would need to reject" is a fair way to avoid
telling the two apart, but seems much harder to me to demonstrate: "none of the
ways we tried to get the evaluator to mistreat a vector as an array" is only
the same property if we've managed to test exhaustively. For what my non-expert
opinion is worth, something like this seems more robust to me:
```diff
void addVectorUnchecked(QualType EltTy, uint64_t Size, uint64_t Idx) {
- Entries.push_back(PathEntry::ArrayIndex(Idx));
+ Entries.push_back(PathEntry::VectorElement(Idx));
- // This is technically a most-derived object, though in practice this
- // is unlikely to matter.
MostDerivedType = EltTy;
- MostDerivedIsArrayElement = true;
- MostDerivedArraySize = Size;
```
(assuming that's coherent, it's been a few months)
https://github.com/llvm/llvm-project/pull/72607
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
