This is an archive of the discontinued LLVM Phabricator instance.

[clang] Improve Dumping of APValues
AbandonedPublic

Authored by Tyker on Aug 3 2020, 10:54 AM.

Details

Reviewers
rsmith
riccibruno
Summary

this is required for proper testing of D63640

Diff Detail

Event Timeline

Tyker created this revision.Aug 3 2020, 10:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 3 2020, 10:54 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
Tyker requested review of this revision.Aug 3 2020, 10:54 AM
Tyker updated this revision to Diff 282687.Aug 3 2020, 11:14 AM

remove unintended code.

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
// CHECK-NEXT: value: MemberPointer &S.

You can use utils/make-ast-dump-check.sh + some manual editing to generate the test.

riccibruno added inline comments.Aug 3 2020, 11:59 AM
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.

riccibruno added inline comments.Aug 7 2020, 7:34 AM
clang/include/clang/AST/PrettyPrinter.h
222 ↗(On Diff #282687)

My bad. It is inferred from the language mode.

Tyker updated this revision to Diff 283984.EditedAug 7 2020, 12:18 PM
Tyker marked an inline comment as done.

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.

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.

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?

Tyker updated this revision to Diff 285747.Aug 14 2020, 1:19 PM

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.

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.

Tyker abandoned this revision.Aug 21 2022, 10:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 21 2022, 10:39 AM
clang/test/AST/ast-dump-APValue-MemPtr.cpp