[PATCH 7/7] [clang] improve NestedNameSpecifier: LLDB changes

[mizvekov]

Patch series starting at #147835

[llvmbot]

@llvm/pr-subscribers-clang

@llvm/pr-subscribers-lldb

Author: Matheus Izvekov (mizvekov)

Changes

Test run of the LLDB CI, just checking if anything needs to be updated there.

---

Full diff: https://github.com/llvm/llvm-project/pull/149949.diff

1 Files Affected:

• (added) lldb/DELETE.ME ()

diff --git a/lldb/DELETE.ME b/lldb/DELETE.ME
new file mode 100644
index 0000000000000..e69de29bb2d1d

[github-actions]

✅ With the latest revision this PR passed the Python code formatter.

[Michael137]

Hmmmm yea I don't think we want to be losing the scope qualifiers for the typenames. What does LLDB have to do to retain those?

[mizvekov]

Hmmmm yea I don't think we want to be losing the scope qualifiers for the typenames. What does LLDB have to do to retain those?

The answer to that depends on what LLDB wants and can do here.

The status quo is, the types produced in the places changed here are not valid as-written types, as they lacked an ElaboratedType. Clang will currently print types lacking an ElaboratedType as if they were fully qualified, with a synthesized name qualifier.

This is used to distinguish canonical from non-canonical types, and the motivation is that we find it more appropriate to print canonical types as fully qualified when they appear in diagnostics and such.

Now with this patch series, we retain the ability to distinguish canonical RecordTypes and EnumTypes, and still print those as fully qualified. But a mis-feature of the status quo is removed: the same would work for TypedefTypes, if they lacked an ElaboratedType on top, then we would fully qualify them when printing.

But this was not an intentional feature, and it lacks motivation, as TypedefTypes never appear in canonical types.
This patch does not create an AST representation for such a TypedefType, beyond what you can do synthesizing a name qualifier yourself.

Now, does LLDB want to keep fully qualified names here, or does it want these to be printed as-written?

Changing this back to the status quo is more straight-forward, we just need to synthesize fully qualified types.

This is taking me a while because it's currently very difficulty for me to get a functional LLDB workflow on MacOS, so
I am currently relying only on the CI job to test and debug this.

To change this to as-written, we would need to figure out if we have a source for this information first, if we store and can retrieve those from all of the Debug info formats we support.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.