[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

kimgr added a comment. From a purely personal perspective, I'd prefer if this landed after the branch for llvm-15. We try to co-release IWYU shortly after LLVM/Clang are released, to get a public API-compatible release out there. So it would be really nice if we didn't have to spend time worki

[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

kimgr added a comment. In D112374#3657640 , @mizvekov wrote: > In D112374#3657472 , @kimgr wrote: > >> I'm coming at this from pretty far away, so there's very likely lots of >> details that I'm overlooking. But

[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

kimgr added a comment. > It's the difference in knowing the type was written without any tag or > nested-name specifier, and having a type that you are not sure how it was > written. > > When we are dealing with a type which we are not sure, we would like to print > it fully qualified, with a s

[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

kimgr added a comment. It's a little confusing, because it now looks like _every_ `Type` in the AST is wrapped in an `ElaboratedTypeLoc` + `ElaboratedType`. IWYU's debug AST dump shows this (excerpt): tests/cxx/sizeof_reference.cc:51:8: (1) [ VarDecl ] size_t s2

[Lldb-commits] [PATCH] D112374: [clang] Implement ElaboratedType sugaring for types written bare

kimgr added a comment. This patch also broke IWYU, not exactly sure how or why yet. We run around the AST quite a bit, so structural changes like this often bite us. Can you expand on what happened here? Before/after kind-of thing? Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE L