This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Fix simple template names and template params with scope qualifiers
ClosedPublic

Authored by aeubanks on Nov 7 2022, 1:22 PM.

Details

Summary

Followup to D134378.

With PrintingPolicy::SuppressScope, we'd also not print the scope in template params. The intention was only to skip the scope for the class because we expect template params to be fully qualified when comparing them for simple template names.

Instead, use NamedDecl::getNameForDiagnostic if we're dealing with a tag, which is what we actually use when emitting debug info in clang. That already has an option to suppress the scope on the base name.

Diff Detail

Event Timeline

aeubanks created this revision.Nov 7 2022, 1:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 7 2022, 1:22 PM
aeubanks requested review of this revision.Nov 7 2022, 1:22 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptNov 7 2022, 1:22 PM

@aaron.ballman does this seem OK? (this was based on my suggestion in the related review linked in the description)

It probably needs tests in clang too - not sure if there's an opportunity to use a unit test to simplify access to the printing policy & exercise this?

...we expect template params to be fully qualified when comparing them for simple template names

So lldb is not inspecting the AST, they're doing reflection (of a sort) on the pretty printed names? Or am I misunderstanding something?

clang/include/clang/AST/PrettyPrinter.h
134

I think this should be expressed in the positive rather than in the negative (SuppressTemplateParamScope) so it's consistent with the rest of the options.

...we expect template params to be fully qualified when comparing them for simple template names

So lldb is not inspecting the AST, they're doing reflection (of a sort) on the pretty printed names? Or am I misunderstanding something?

Not reflection as such - but building names for the user, but partly from the AST - basically LLDB wants to be able to produce the same name that CGDebugInfo produces - so, maybe it should produce it the same way as CGDebugInfo, which isn't to use the pretty printer from scratch.

@aeubanks would this work for lldb's use case? https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CGDebugInfo.cpp#L5229 it'd be identical to the original debug info generation, and looks like it doesn't require a printing policy change/feature. Sorry I didn't think of that earlier. I guess since Qualified would be false for lldb's use case, you could go down into the implementation and just call the unqualified side directly: NamedDecl::printName(OS, Policy); should print it unqualified for this name, but respect the qualified printing policy flag for any nested names, parameters, etc.

...we expect template params to be fully qualified when comparing them for simple template names

So lldb is not inspecting the AST, they're doing reflection (of a sort) on the pretty printed names? Or am I misunderstanding something?

Not reflection as such - but building names for the user, but partly from the AST - basically LLDB wants to be able to produce the same name that CGDebugInfo produces - so, maybe it should produce it the same way as CGDebugInfo, which isn't to use the pretty printer from scratch.

Ah thank you for the clarification, that makes more sense to me.

@aeubanks would this work for lldb's use case? https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CGDebugInfo.cpp#L5229 it'd be identical to the original debug info generation, and looks like it doesn't require a printing policy change/feature. Sorry I didn't think of that earlier. I guess since Qualified would be false for lldb's use case, you could go down into the implementation and just call the unqualified side directly: NamedDecl::printName(OS, Policy); should print it unqualified for this name, but respect the qualified printing policy flag for any nested names, parameters, etc.

I agree that it seems pretty sensible for the debugger to use the same mechanisms as debug info in terms of what names to display for users.

aeubanks updated this revision to Diff 474848.Nov 11 2022, 1:32 PM

use getNameForDiagnostics

aeubanks edited the summary of this revision. (Show Details)Nov 11 2022, 1:36 PM
aeubanks edited the summary of this revision. (Show Details)
aeubanks updated this revision to Diff 474850.Nov 11 2022, 1:39 PM

add comment

...we expect template params to be fully qualified when comparing them for simple template names

So lldb is not inspecting the AST, they're doing reflection (of a sort) on the pretty printed names? Or am I misunderstanding something?

Not reflection as such - but building names for the user, but partly from the AST - basically LLDB wants to be able to produce the same name that CGDebugInfo produces - so, maybe it should produce it the same way as CGDebugInfo, which isn't to use the pretty printer from scratch.

@aeubanks would this work for lldb's use case? https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CGDebugInfo.cpp#L5229 it'd be identical to the original debug info generation, and looks like it doesn't require a printing policy change/feature. Sorry I didn't think of that earlier. I guess since Qualified would be false for lldb's use case, you could go down into the implementation and just call the unqualified side directly: NamedDecl::printName(OS, Policy); should print it unqualified for this name, but respect the qualified printing policy flag for any nested names, parameters, etc.

much better, thanks!

dblaikie accepted this revision.Nov 15 2022, 2:51 PM

Awesome!

This revision is now accepted and ready to land.Nov 15 2022, 2:51 PM