this is required for proper testing of D63640
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for finishing this.
I don't see why you are adding dumpPretty; the point of the dump function I added is to dump the APValue as the tree-like structure it is. But your dumpPretty doesn't do that at all. Instead it is just an alias for printPretty. So dump does one thing and dumpPretty does another completely different thing.
clang/include/clang/AST/PrettyPrinter.h | ||
---|---|---|
222 ↗ | (On Diff #282687) | This seems to be unrelated. And anyway shouldn't this be inferred from the language mode? |
clang/lib/AST/APValue.cpp | ||
433–434 | What I would do here is continue to take a const ASTContext & here, but in the LValue case in TextNodeDumper just print <ASTContext required> if the context is null (which should only happens when debugging since the parameter-less version of dump() is not used in the code-base). Trying to do without the context here can result in confusing output. I think it is better to just give-up and tell the user to please pass the ASTContext (which again, should only happens in a debugger). Additionally since the context will always be present outside of debugging, the code-path without the context will not be tested. | |
630 | What's up with this inconsistency? One time OS and the other time Out... | |
clang/test/AST/ast-dump-APValue-MemPtr.cpp | ||
5 | Can you add a TODO to remember to add the serialization part when the serialization of APValue is fixed? Also can you match full lines? Here the test would still pass if you had written You can use utils/make-ast-dump-check.sh + some manual editing to generate the test. |
clang/lib/AST/APValue.cpp | ||
---|---|---|
542 | And also I don't think that this change is safe since ASTContext::getAsArrayType applies qualifiers from the array type to the element type. |
clang/include/clang/AST/PrettyPrinter.h | ||
---|---|---|
222 ↗ | (On Diff #282687) | My bad. It is inferred from the language mode. |
this a patch i had to improve dumping before your improvement to dumping.
I think there is benefits to being able to dump APValues like LValues without an ASTContext even if the output will not be as good. but i agree that now that the dumper has an ASTContext during ast-dump it is hard to test.
the intent was to reuse the same printing code that is already used for diagnostics (printPretty) since it can print Member pointers and LValues. it isn't being used for printing anything that isn't a leaf(as in no child APValues) when used in AST dump. where you planning for LValues or Membre pointer to have children and not being leaf nodes ?
So dump does one thing and dumpPretty does another completely different thing.
i removed dumpPretty and instead added a new overload to printPretty.
I agree with you that it's fine to use printPretty for leaves (and additionally it would be annoying to duplicate the LValue case); that's what I was planning to do anyway.
What I am not sure I agree with is the additional complexity to handle the (debugger-only and easy to avoid) case where no context is given.
clang/lib/AST/APValue.cpp | ||
---|---|---|
542 | This works because we only use ElemTy to distinguish between the array case and the base-or-member case right? |
i don't have a strong opinion on this.
it adds complexity, isn't testable and in many situation where the ASTContext is missing the QualType is missing too anyway.
soo i removed that code path.
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 LValuePathEntrys 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.
What I would do here is continue to take a const ASTContext & here, but in the LValue case in TextNodeDumper just print <ASTContext required> if the context is null (which should only happens when debugging since the parameter-less version of dump() is not used in the code-base).
Trying to do without the context here can result in confusing output. I think it is better to just give-up and tell the user to please pass the ASTContext (which again, should only happens in a debugger).
Additionally since the context will always be present outside of debugging, the code-path without the context will not be tested.