rsmith added a comment. Ideally we should be tree-dumping the `LValue` representation rather than pretty-printing it (and similarly for member pointers and label address differences). The problem with doing so is that we can't interpret the `LValuePathEntry`s without knowing the type of the lvalue base. However, we could fix that: `LValuePathEntry` has spare bits. As a result of PR8256, we require the size *in bits* of an array type to fit into 64 bits, so the maximum possible array index is 2^61 (and the pointer representation is a `Decl*`, which has 3 spare low-order bits). So we could track which kind of path entry it is with no additional storage cost, which would remove the need to have an `ASTContext` and a `QualType` in order to be able to correctly dump an `APValue` in `LValue` form.
Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85144/new/ https://reviews.llvm.org/D85144 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
