subject:"\[clang\] \[clang\-tools\-extra\] \[clang\] Improve nested name specifier AST representation \(PR #147835\)"

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-10-18 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

Yeah, all except one user of `getLocalSourceRange` expected the behavior to be 
what it is now.

I propose adding a note about this in the documentation, add a new helper which 
does what `getLocalSourceRange` used to do, and migrate the single existing 
user to use that.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-10-18 Thread Haojian Wu via cfe-commits


hokein wrote:

>  I think the documentation is right and matches what's happening.
It's just that what's considered local has changed in the case of a 
NestedNameSpecifier which is a Type.
The type was previously split-up, each chunk being its own nested name 
specifier.
Now a Type is always a NestedNameSpecifier component by itself.

Just my two cents. 

I think the term "local" is ambiguous, and my mental model has always been that 
it refers to the last specifier in a qualified name. This seems to have been 
the behavior, and the public API 
[doc](https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/NestedNameSpecifierBase.h#L364-L366)
 implies it.

This recent change seems to break that model and introduces behavior that feels 
inconsistent:

-  For namespace specifier `ns1::ns2::`, `getLocalSourceRange` returns the 
range of "ns2::";
-  For type specifier `ns1::C1::`, `getLocalSourceRange` returns the range of 
"ns1::C1::";

This difference is confusing. While I understand the reasoning behind the 
internal implementation, API users aren't likely to be aware of it, and the 
"last piece" model seems more intuitive.

If this new behavior is intended, could we update the comments for 
`getLocalSourceRange()` to clarify these new rules and provide examples for 
each case? or even would it make sense to preserve the old behavior for the 
sake of API consistency?


https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-09-12 Thread Alexander Kornienko via cfe-commits


alexfh wrote:

For convenience copying the code and clang stdout here:
```
class A;
using T = __attribute__((swiftasynccall)) void(
__attribute__((swift_async_context)) A *);
T R;
class A;
__attribute__((swiftasynccall)) void
fa(__attribute__((swift_async_context))
  A *) {
  R == fa;
}
```

```
clang++: /root/llvm-project/llvm/tools/clang/lib/AST/ASTContext.cpp:14198: 
clang::QualType getCommonNonSugarTypeNode(const clang::ASTContext&, const 
clang::Type*, clang::Qualifiers&, const clang::Type*, clang::Qualifiers&): 
Assertion `EPIX.ExtParameterInfos == EPIY.ExtParameterInfos' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and 
include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.  Program arguments: 
/opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -g -o /app/output.s 
-mllvm --x86-asm-syntax=intel -fno-verbose-asm -S 
--gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics 
-fno-crash-diagnostics -std=gnu++20 
1.  :9:10: current parser token ';'
2.  :8:40: parsing function body 'fa'
3.  :8:40: in compound statement ('{}')
 #0 0x04083a38 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4083a38)
 #1 0x04080e64 llvm::sys::CleanupOnSignal(unsigned long) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x4080e64)
 #2 0x03fc51e8 CrashRecoverySignalHandler(int) 
CrashRecoveryContext.cpp:0:0
 #3 0x7af017a42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #4 0x7af017a969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
 #5 0x7af017a42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
 #6 0x7af017a287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
 #7 0x7af017a2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
 #8 0x7af017a39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
 #9 0x076059d8 getCommonNonSugarTypeNode(clang::ASTContext const&, 
clang::Type const*, clang::Qualifiers&, clang::Type const*, clang::Qualifiers&) 
ASTContext.cpp:0:0
#10 0x07605f3b clang::ASTContext::getCommonSugaredType(clang::QualType, 
clang::QualType, bool) const 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x7605f3b)
#11 0x06d4390d 
clang::Sema::FindCompositePointerType(clang::SourceLocation, clang::Expr*&, 
clang::Expr*&, bool) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6d4390d)
#12 0x06c38cd1 convertPointersToCompositeType(clang::Sema&, 
clang::SourceLocation, clang::ActionResult&, 
clang::ActionResult&) SemaExpr.cpp:0:0
#13 0x06c6c125 
clang::Sema::CheckCompareOperands(clang::ActionResult&, 
clang::ActionResult&, clang::SourceLocation, 
clang::BinaryOperatorKind) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6c6c125)
#14 0x06c7454d clang::Sema::CreateBuiltinBinOp(clang::SourceLocation, 
clang::BinaryOperatorKind, clang::Expr*, clang::Expr*, bool) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6c7454d)
#15 0x06c75f98 clang::Sema::BuildBinOp(clang::Scope*, 
clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*, 
bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6c75f98)
#16 0x06c76606 clang::Sema::ActOnBinOp(clang::Scope*, 
clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6c76606)
#17 0x067af1da 
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67af1da)
#18 0x067b27f9 
clang::Parser::ParseExpression(clang::TypoCorrectionTypeBehavior) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x67b27f9)
#19 0x068363f9 
clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x68363f9)
#20 0x0682d784 
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, 
clang::ParsedAttributes&, clang::ParsedAttributes&, clang::LabelDecl*) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x682d784)
#21 0x0682e5f9 
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, 
clang::LabelDecl*) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x682e5f9)
#22 0x06836b0e clang::Parser::ParseCompoundStatementBody(bool) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x6836b0e)
#23 0x0683732a clang::Parser::ParseFunctionStatementBody(clang::Decl*, 
clang::Parser::ParseScope&) 
(/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x683732a)
#24 0x0673e82b 
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, 
cla

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-09-12 Thread Alexander Kornienko via cfe-commits


alexfh wrote:

And a bit cleaned up (https://godbolt.org/z/q9fGPj54d):
```
class A;
using T = void(__attribute__((swift_async_context)) A *);
T R;
class A;
void fa(__attribute__((swift_async_context)) A *);

bool f() {
  return R == fa;
}
```

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-09-12 Thread via cfe-commits


joanahalili wrote:

@mizvekov there is one more instance of a clang crash that we are encountering 
during our testing at google. Here is the reproducer 
https://godbolt.org/z/7PczGMeYc. Please take a look.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-09-12 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

@joanahalili @alexfh that's fixed in 
https://github.com/llvm/llvm-project/pull/157925

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-09-05 Thread Daniel M. Katz via cfe-commits


katzdm wrote:

"And on that day, every maintainer of a nontrivial clang fork cried out to the 
sky in unison."

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-09-03 Thread Shafik Yaghmour via cfe-commits


shafik wrote:

This feels like a regression, unless you think the bug is elsewhere and the 
assert just catches it now: 
https://github.com/llvm/llvm-project/issues/156458#issuecomment-3246453958

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-28 Thread Nico Weber via cfe-commits


nico wrote:

FWIW, clang has a warning like that too, it's `-Wmismatched-tags` (part of 
`-Wmost`, which is part of `-Wall`).

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-28 Thread Andrey Ali Khan Bolshakov via cfe-commits


bolshakov-a wrote:

Yeah, the not-to-break-ABI consideration is obviously the only reason why they 
haven't fix it so far. But this makes dangerous to mix declarations with 
different tag kinds despite it is allowed by the standard, and hence MSVC has a 
warning on that as @kimgr has noticed. So probably, there isn't much sense for 
strict correspondence in that case because it might be said that this is user's 
code problem... Anyway, it is fixed now.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-27 Thread Kim Gräsman via cfe-commits


kimgr wrote:

> > We don't want bug-for-bug conformance, but we do want to be ABI compatible.
> 
> It really looks like an MSVC bug. If its mangling depends on whether the 
> first (forward-)declaration of a class in a translation unit uses `class` or 
> `struct` class-key, the TUs cannot be linked together in general.

I guess this is why MSVC has this warning: https://stackoverflow.com/q/468486

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-27 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

The MSVC mangling issue is resolved here: 
https://github.com/llvm/llvm-project/pull/155662

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-27 Thread Andrey Ali Khan Bolshakov via cfe-commits


bolshakov-a wrote:

> We don't want bug-for-bug conformance, but we do want to be ABI compatible.

It really looks like an MSVC bug. If its mangling depends on whether the first 
(forward-)declaration of a class in a translation unit uses `class` or `struct` 
class-key, the TUs cannot be linked together in general.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-27 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

> (I think this was covered by tests even, right?) 
No, this patch didn't change any existing mangling tests at all, the behavior 
in question here was untested.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-27 Thread Nico Weber via cfe-commits

nico wrote:

> Sounds like if we want strict MSVC bug-for-bug conformance, we should change 
> that to use the first declaration then.

We don't want bug-for-bug conformance, but we do want to be ABI compatible. So 
we do have to undo the regression in behavior here. (I think this was covered 
by tests even, right?) So we'd appreciate a fix 🙂

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-26 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

@aeubanks 

I see, so that's unfortunate MSVC mangles the struct / class difference.
This is a different problem than I had in mind.

So MSVC mangles according to the tag kind of the first declaration, clang after 
this changes now mangles it according to thedeclaration found by lookup at 
the point of use.

Sounds like if we want strict MSVC bug-for-bug conformance, we should change 
that to use the first declaration then.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-26 Thread Arthur Eubanks via cfe-commits


aeubanks wrote:

```
$ cat /tmp/a.cc
class A;
struct A;
void f(A*) {}
$ clang-old++ -S -o - /tmp/a.cc -O2 -target x86_64-msvc-windows-pc
...
"?f@@YAXPEAVA@@@Z"
...
$ clang-new++ -S -o - /tmp/a.cc -O2 -target x86_64-msvc-windows-pc
...
"?f@@YAXPEAUA@@@Z"
...
```

notice the `V` -> `U`

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-25 Thread Matheus Izvekov via cfe-commits



@@ -5254,153 +5253,297 @@ 
ASTContext::getPredefinedSugarType(PredefinedSugarType::Kind KD) const {
   return QualType(New, 0);
 }
 
-#ifndef NDEBUG
-static bool NeedsInjectedClassNameType(const RecordDecl *D) {
-  if (!isa(D)) return false;
-  const auto *RD = cast(D);
-  if (isa(RD))
-return true;
-  if (RD->getDescribedClassTemplate() &&
-  !isa(RD))
-return true;
-  return false;
-}
-#endif
+QualType ASTContext::getTypeDeclType(ElaboratedTypeKeyword Keyword,
+ NestedNameSpecifier Qualifier,
+ const TypeDecl *Decl) const {
+  if (auto *Tag = dyn_cast(Decl))
+return getTagType(Keyword, Qualifier, Tag,
+  /*OwnsTag=*/false);
+  if (auto *Typedef = dyn_cast(Decl))
+return getTypedefType(Keyword, Qualifier, Typedef);
+  if (auto *UD = dyn_cast(Decl))
+return getUnresolvedUsingType(Keyword, Qualifier, UD);
 
-/// getInjectedClassNameType - Return the unique reference to the
-/// injected class name type for the specified templated declaration.
-QualType ASTContext::getInjectedClassNameType(CXXRecordDecl *Decl,
-  QualType TST) const {
-  assert(NeedsInjectedClassNameType(Decl));
-  if (Decl->TypeForDecl) {
-assert(isa(Decl->TypeForDecl));
-  } else if (CXXRecordDecl *PrevDecl = Decl->getPreviousDecl()) {
-assert(PrevDecl->TypeForDecl && "previous declaration has no type");
-Decl->TypeForDecl = PrevDecl->TypeForDecl;
-assert(isa(Decl->TypeForDecl));
-  } else {
-Type *newType = new (*this, alignof(InjectedClassNameType))
-InjectedClassNameType(Decl, TST);
-Decl->TypeForDecl = newType;
-Types.push_back(newType);
-  }
+  assert(Keyword == ElaboratedTypeKeyword::None);
+  assert(!Qualifier);
   return QualType(Decl->TypeForDecl, 0);
 }
 
-/// getTypeDeclType - Return the unique reference to the type for the
-/// specified type declaration.
-QualType ASTContext::getTypeDeclTypeSlow(const TypeDecl *Decl) const {
-  assert(Decl && "Passed null for Decl param");
-  assert(!Decl->TypeForDecl && "TypeForDecl present in slow case");
-
-  if (const auto *Typedef = dyn_cast(Decl))
-return getTypedefType(Typedef);
-
-  assert(!isa(Decl) &&
- "Template type parameter types are always available.");
-
-  if (const auto *Record = dyn_cast(Decl)) {
-assert(Record->isFirstDecl() && "struct/union has previous declaration");
-assert(!NeedsInjectedClassNameType(Record));
-return getRecordType(Record);
-  } else if (const auto *Enum = dyn_cast(Decl)) {
-assert(Enum->isFirstDecl() && "enum has previous declaration");
-return getEnumType(Enum);
-  } else if (const auto *Using = dyn_cast(Decl)) {
-return getUnresolvedUsingType(Using);
-  } else
-llvm_unreachable("TypeDecl without a type?");
-
+CanQualType ASTContext::getCanonicalTypeDeclType(const TypeDecl *TD) const {
+  if (auto *Tag = dyn_cast(TD))
+return getCanonicalTagType(Tag);
+  if (auto *TN = dyn_cast(TD))
+return getCanonicalType(TN->getUnderlyingType());
+  if (const auto *UD = dyn_cast(TD))
+return getCanonicalUnresolvedUsingType(UD);
+  assert(TD->TypeForDecl);
+  return TD->TypeForDecl->getCanonicalTypeUnqualified();
+}
+
+QualType ASTContext::getTypeDeclType(const TypeDecl *Decl) const {
+  if (const auto *TD = dyn_cast(Decl))
+return getCanonicalTagType(TD);
+  if (const auto *TD = dyn_cast(Decl);
+  isa_and_nonnull(TD))
+return getTypedefType(ElaboratedTypeKeyword::None,
+  /*Qualifier=*/std::nullopt, TD);
+  if (const auto *Using = dyn_cast(Decl))
+return getCanonicalUnresolvedUsingType(Using);
+
+  assert(Decl->TypeForDecl);
   return QualType(Decl->TypeForDecl, 0);
 }
 
 /// getTypedefType - Return the unique reference to the type for the
 /// specified typedef name decl.
-QualType ASTContext::getTypedefType(const TypedefNameDecl *Decl,
-QualType Underlying) const {
-  if (!Decl->TypeForDecl) {
-if (Underlying.isNull())
-  Underlying = Decl->getUnderlyingType();
-auto *NewType = new (*this, alignof(TypedefType)) TypedefType(
-Type::Typedef, Decl, Underlying, /*HasTypeDifferentFromDecl=*/false);
-Decl->TypeForDecl = NewType;
+QualType
+ASTContext::getTypedefType(ElaboratedTypeKeyword Keyword,
+   NestedNameSpecifier Qualifier,
+   const TypedefNameDecl *Decl, QualType 
UnderlyingType,
+   std::optional TypeMatchesDeclOrNone) const {
+  if (!TypeMatchesDeclOrNone) {
+QualType DeclUnderlyingType = Decl->getUnderlyingType();
+assert(!DeclUnderlyingType.isNull());
+if (UnderlyingType.isNull())
+  UnderlyingType = DeclUnderlyingType;
+else
+  assert(hasSameType(UnderlyingType, DeclUnderlyingType));
+TypeMatchesDeclOrNone = UnderlyingType == DeclUnderlyingType;
+  } else {
+// FIXME: This is a workaround for a

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-25 Thread Matheus Izvekov via cfe-commits



@@ -5254,153 +5253,297 @@ 
ASTContext::getPredefinedSugarType(PredefinedSugarType::Kind KD) const {
   return QualType(New, 0);
 }
 
-#ifndef NDEBUG
-static bool NeedsInjectedClassNameType(const RecordDecl *D) {
-  if (!isa(D)) return false;
-  const auto *RD = cast(D);
-  if (isa(RD))
-return true;
-  if (RD->getDescribedClassTemplate() &&
-  !isa(RD))
-return true;
-  return false;
-}
-#endif
+QualType ASTContext::getTypeDeclType(ElaboratedTypeKeyword Keyword,
+ NestedNameSpecifier Qualifier,
+ const TypeDecl *Decl) const {
+  if (auto *Tag = dyn_cast(Decl))
+return getTagType(Keyword, Qualifier, Tag,
+  /*OwnsTag=*/false);
+  if (auto *Typedef = dyn_cast(Decl))
+return getTypedefType(Keyword, Qualifier, Typedef);
+  if (auto *UD = dyn_cast(Decl))
+return getUnresolvedUsingType(Keyword, Qualifier, UD);
 
-/// getInjectedClassNameType - Return the unique reference to the
-/// injected class name type for the specified templated declaration.
-QualType ASTContext::getInjectedClassNameType(CXXRecordDecl *Decl,
-  QualType TST) const {
-  assert(NeedsInjectedClassNameType(Decl));
-  if (Decl->TypeForDecl) {
-assert(isa(Decl->TypeForDecl));
-  } else if (CXXRecordDecl *PrevDecl = Decl->getPreviousDecl()) {
-assert(PrevDecl->TypeForDecl && "previous declaration has no type");
-Decl->TypeForDecl = PrevDecl->TypeForDecl;
-assert(isa(Decl->TypeForDecl));
-  } else {
-Type *newType = new (*this, alignof(InjectedClassNameType))
-InjectedClassNameType(Decl, TST);
-Decl->TypeForDecl = newType;
-Types.push_back(newType);
-  }
+  assert(Keyword == ElaboratedTypeKeyword::None);
+  assert(!Qualifier);
   return QualType(Decl->TypeForDecl, 0);
 }
 
-/// getTypeDeclType - Return the unique reference to the type for the
-/// specified type declaration.
-QualType ASTContext::getTypeDeclTypeSlow(const TypeDecl *Decl) const {
-  assert(Decl && "Passed null for Decl param");
-  assert(!Decl->TypeForDecl && "TypeForDecl present in slow case");
-
-  if (const auto *Typedef = dyn_cast(Decl))
-return getTypedefType(Typedef);
-
-  assert(!isa(Decl) &&
- "Template type parameter types are always available.");
-
-  if (const auto *Record = dyn_cast(Decl)) {
-assert(Record->isFirstDecl() && "struct/union has previous declaration");
-assert(!NeedsInjectedClassNameType(Record));
-return getRecordType(Record);
-  } else if (const auto *Enum = dyn_cast(Decl)) {
-assert(Enum->isFirstDecl() && "enum has previous declaration");
-return getEnumType(Enum);
-  } else if (const auto *Using = dyn_cast(Decl)) {
-return getUnresolvedUsingType(Using);
-  } else
-llvm_unreachable("TypeDecl without a type?");
-
+CanQualType ASTContext::getCanonicalTypeDeclType(const TypeDecl *TD) const {
+  if (auto *Tag = dyn_cast(TD))
+return getCanonicalTagType(Tag);
+  if (auto *TN = dyn_cast(TD))
+return getCanonicalType(TN->getUnderlyingType());
+  if (const auto *UD = dyn_cast(TD))
+return getCanonicalUnresolvedUsingType(UD);
+  assert(TD->TypeForDecl);
+  return TD->TypeForDecl->getCanonicalTypeUnqualified();
+}
+
+QualType ASTContext::getTypeDeclType(const TypeDecl *Decl) const {
+  if (const auto *TD = dyn_cast(Decl))
+return getCanonicalTagType(TD);
+  if (const auto *TD = dyn_cast(Decl);
+  isa_and_nonnull(TD))
+return getTypedefType(ElaboratedTypeKeyword::None,
+  /*Qualifier=*/std::nullopt, TD);
+  if (const auto *Using = dyn_cast(Decl))
+return getCanonicalUnresolvedUsingType(Using);
+
+  assert(Decl->TypeForDecl);
   return QualType(Decl->TypeForDecl, 0);
 }
 
 /// getTypedefType - Return the unique reference to the type for the
 /// specified typedef name decl.
-QualType ASTContext::getTypedefType(const TypedefNameDecl *Decl,
-QualType Underlying) const {
-  if (!Decl->TypeForDecl) {
-if (Underlying.isNull())
-  Underlying = Decl->getUnderlyingType();
-auto *NewType = new (*this, alignof(TypedefType)) TypedefType(
-Type::Typedef, Decl, Underlying, /*HasTypeDifferentFromDecl=*/false);
-Decl->TypeForDecl = NewType;
+QualType
+ASTContext::getTypedefType(ElaboratedTypeKeyword Keyword,
+   NestedNameSpecifier Qualifier,
+   const TypedefNameDecl *Decl, QualType 
UnderlyingType,
+   std::optional TypeMatchesDeclOrNone) const {
+  if (!TypeMatchesDeclOrNone) {
+QualType DeclUnderlyingType = Decl->getUnderlyingType();
+assert(!DeclUnderlyingType.isNull());
+if (UnderlyingType.isNull())
+  UnderlyingType = DeclUnderlyingType;
+else
+  assert(hasSameType(UnderlyingType, DeclUnderlyingType));
+TypeMatchesDeclOrNone = UnderlyingType == DeclUnderlyingType;
+  } else {
+// FIXME: This is a workaround for a

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-25 Thread Matheus Izvekov via cfe-commits

mizvekov wrote:

@michaelrj-google 
> ```
>::sapi::v::IntBase v_type__(type__);
> ```
> 
> which clang errors on.

And that enum type, is that created by Sema, or is that synthesized by code 
from within your project?

If you are creating that type as a canonical type, or that type is being 
canonicalized for some reason, then the placement of the enum keyword is 
controlled by the `SuppressTagKeyword` printing policy.

If you are creating that type yourself within your project, you should use the 
new TagType ASTContext constructor which takes an ElaboratedKeyword as a 
parameter. Looks like in that case, you should set it to  
`ElaboratedKeyword::None`.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-25 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

@aeubanks can you get us a reproducer?


https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-25 Thread Brad King via cfe-commits



@@ -5254,153 +5253,297 @@ 
ASTContext::getPredefinedSugarType(PredefinedSugarType::Kind KD) const {
   return QualType(New, 0);
 }
 
-#ifndef NDEBUG
-static bool NeedsInjectedClassNameType(const RecordDecl *D) {
-  if (!isa(D)) return false;
-  const auto *RD = cast(D);
-  if (isa(RD))
-return true;
-  if (RD->getDescribedClassTemplate() &&
-  !isa(RD))
-return true;
-  return false;
-}
-#endif
+QualType ASTContext::getTypeDeclType(ElaboratedTypeKeyword Keyword,
+ NestedNameSpecifier Qualifier,
+ const TypeDecl *Decl) const {
+  if (auto *Tag = dyn_cast(Decl))
+return getTagType(Keyword, Qualifier, Tag,
+  /*OwnsTag=*/false);
+  if (auto *Typedef = dyn_cast(Decl))
+return getTypedefType(Keyword, Qualifier, Typedef);
+  if (auto *UD = dyn_cast(Decl))
+return getUnresolvedUsingType(Keyword, Qualifier, UD);
 
-/// getInjectedClassNameType - Return the unique reference to the
-/// injected class name type for the specified templated declaration.
-QualType ASTContext::getInjectedClassNameType(CXXRecordDecl *Decl,
-  QualType TST) const {
-  assert(NeedsInjectedClassNameType(Decl));
-  if (Decl->TypeForDecl) {
-assert(isa(Decl->TypeForDecl));
-  } else if (CXXRecordDecl *PrevDecl = Decl->getPreviousDecl()) {
-assert(PrevDecl->TypeForDecl && "previous declaration has no type");
-Decl->TypeForDecl = PrevDecl->TypeForDecl;
-assert(isa(Decl->TypeForDecl));
-  } else {
-Type *newType = new (*this, alignof(InjectedClassNameType))
-InjectedClassNameType(Decl, TST);
-Decl->TypeForDecl = newType;
-Types.push_back(newType);
-  }
+  assert(Keyword == ElaboratedTypeKeyword::None);
+  assert(!Qualifier);
   return QualType(Decl->TypeForDecl, 0);
 }
 
-/// getTypeDeclType - Return the unique reference to the type for the
-/// specified type declaration.
-QualType ASTContext::getTypeDeclTypeSlow(const TypeDecl *Decl) const {
-  assert(Decl && "Passed null for Decl param");
-  assert(!Decl->TypeForDecl && "TypeForDecl present in slow case");
-
-  if (const auto *Typedef = dyn_cast(Decl))
-return getTypedefType(Typedef);
-
-  assert(!isa(Decl) &&
- "Template type parameter types are always available.");
-
-  if (const auto *Record = dyn_cast(Decl)) {
-assert(Record->isFirstDecl() && "struct/union has previous declaration");
-assert(!NeedsInjectedClassNameType(Record));
-return getRecordType(Record);
-  } else if (const auto *Enum = dyn_cast(Decl)) {
-assert(Enum->isFirstDecl() && "enum has previous declaration");
-return getEnumType(Enum);
-  } else if (const auto *Using = dyn_cast(Decl)) {
-return getUnresolvedUsingType(Using);
-  } else
-llvm_unreachable("TypeDecl without a type?");
-
+CanQualType ASTContext::getCanonicalTypeDeclType(const TypeDecl *TD) const {
+  if (auto *Tag = dyn_cast(TD))
+return getCanonicalTagType(Tag);
+  if (auto *TN = dyn_cast(TD))
+return getCanonicalType(TN->getUnderlyingType());
+  if (const auto *UD = dyn_cast(TD))
+return getCanonicalUnresolvedUsingType(UD);
+  assert(TD->TypeForDecl);
+  return TD->TypeForDecl->getCanonicalTypeUnqualified();
+}
+
+QualType ASTContext::getTypeDeclType(const TypeDecl *Decl) const {
+  if (const auto *TD = dyn_cast(Decl))
+return getCanonicalTagType(TD);
+  if (const auto *TD = dyn_cast(Decl);
+  isa_and_nonnull(TD))
+return getTypedefType(ElaboratedTypeKeyword::None,
+  /*Qualifier=*/std::nullopt, TD);
+  if (const auto *Using = dyn_cast(Decl))
+return getCanonicalUnresolvedUsingType(Using);
+
+  assert(Decl->TypeForDecl);
   return QualType(Decl->TypeForDecl, 0);
 }
 
 /// getTypedefType - Return the unique reference to the type for the
 /// specified typedef name decl.
-QualType ASTContext::getTypedefType(const TypedefNameDecl *Decl,
-QualType Underlying) const {
-  if (!Decl->TypeForDecl) {
-if (Underlying.isNull())
-  Underlying = Decl->getUnderlyingType();
-auto *NewType = new (*this, alignof(TypedefType)) TypedefType(
-Type::Typedef, Decl, Underlying, /*HasTypeDifferentFromDecl=*/false);
-Decl->TypeForDecl = NewType;
+QualType
+ASTContext::getTypedefType(ElaboratedTypeKeyword Keyword,
+   NestedNameSpecifier Qualifier,
+   const TypedefNameDecl *Decl, QualType 
UnderlyingType,
+   std::optional TypeMatchesDeclOrNone) const {
+  if (!TypeMatchesDeclOrNone) {
+QualType DeclUnderlyingType = Decl->getUnderlyingType();
+assert(!DeclUnderlyingType.isNull());
+if (UnderlyingType.isNull())
+  UnderlyingType = DeclUnderlyingType;
+else
+  assert(hasSameType(UnderlyingType, DeclUnderlyingType));
+TypeMatchesDeclOrNone = UnderlyingType == DeclUnderlyingType;
+  } else {
+// FIXME: This is a workaround for a

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-25 Thread Michael Jones via cfe-commits

michaelrj-google wrote:

> > Related, I think the change to [`void TypePrinter::printUsingBefore(const 
> > UsingType *T, raw_ostream 
> > &OS)`](https://github.com/llvm/llvm-project/blame/d439c9ea4a19bf783120d8efee5e67131550/clang/lib/AST/TypePrinter.cpp#L1227)
> >  might be causing similar issues. The `getKeywordName` is causing `enum` to 
> > get printed when the type is listed for template instantiation, which is 
> > causing errors.
> 
> Can you give me an example of that? We shouldn't be printing a keyword unless 
> the type was written / created with a keyword.

The exact code is internal so I'm not sure exactly how much I can share, that 
being said, the relevant piece is this:

```
   ::sapi::v::IntBase v_type__(type__);
```
This line shows up in a regenerated function, and after the change it's being 
generated as
```
   ::sapi::v::IntBase v_type__(type__);
```
which clang errors on.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-25 Thread Arthur Eubanks via cfe-commits


aeubanks wrote:

fyi this uncovered some mismatching struct/class declarations, which affects 
mangling in the MSVC C++ ABI, leading to linker undefined symbol errors. unsure 
why we weren't seeing this before this change

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-25 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

> The previous revision compiles the reduced successfully. Can you please take 
> a look?

Fixed in https://github.com/llvm/llvm-project/pull/155272

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-25 Thread via cfe-commits


bgra8 wrote:

After further testing (at google) we're seeing *lots* of other crashes caused 
by this revision: https://godbolt.org/z/Y3adj3PY1

The previous revision compiles the reduced successfully. Can you please take a 
look?

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-23 Thread Andrey Ali Khan Bolshakov via cfe-commits


bolshakov-a wrote:

Ah, sorry. I tested on IWYU and get confused because it transforms a 
declaration to the definition later.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-23 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

> Seems like `getOriginalDecl()` always returns the full definition for 
> enumerations (and not an opaque declaration for enums with fixed underlying 
> type), at least in the C language mode. Is it guaranteed?

I don't see that happening. Example: https://compiler-explorer.com/z/z9cMxPWva

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-23 Thread Andrey Ali Khan Bolshakov via cfe-commits


bolshakov-a wrote:

Seems like `getOriginalDecl()` always returns the full definition for 
enumerations (and not an opaque declaration for enums with fixed underlying 
type). Is it guaranteed?

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-23 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

> Related, I think the change to [`void TypePrinter::printUsingBefore(const 
> UsingType *T, raw_ostream 
> &OS)`](https://github.com/llvm/llvm-project/blame/d439c9ea4a19bf783120d8efee5e67131550/clang/lib/AST/TypePrinter.cpp#L1227)
>  might be causing similar issues. The `getKeywordName` is causing `enum` to 
> get printed when the type is listed for template instantiation, which is 
> causing errors.

Can you give me an example of that? We shouldn't be printing a keyword unless 
the type was written / created with a keyword.



https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-22 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

> Hi, I'm helping fix some clang-as-a-library users and I'm running into some 
> issues with the TypePrinter after this commit. Specifically the clang 
> generator in sandboxed-api is broken 
> (https://github.com/google/sandboxed-api/tree/main). After doing the trivial 
> fixes (`getDecl` -> `getOriginalDecl`) some of the tests are failing 
> (https://github.com/google/sandboxed-api/blob/main/sandboxed_api/tools/clang_generator/emitter_test.cc).

The NestedAnonymousStruct case seems to be missing a `IncludeTagDefinition` 
PrintingPolicy set to true.


https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-22 Thread Matheus Izvekov via cfe-commits



@@ -2586,8 +2561,9 @@ bool 
CXXNameMangler::mangleUnresolvedTypeOrSimpleId(QualType Ty,
   }
 
   case Type::InjectedClassName:
-mangleSourceNameWithAbiTags(
-cast(Ty)->getDecl());
+mangleSourceNameWithAbiTags(cast(Ty)
+->getOriginalDecl()
+->getDefinitionOrSelf());

mizvekov wrote:

This will be fixed here: https://github.com/llvm/llvm-project/pull/155028

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-21 Thread Jordan Rupprecht via cfe-commits

rupprecht wrote:

> > I'm trying to reduce a crash that only reproduces w/ in module builds. Does 
> > this sound familiar?
> 
> Haven't seen this one yet. That may have something to do with demoted 
> definitions, a repro would be helpful.

I'm trying to reduce it now, but because it's a modules issue/involves multiple 
files, it's much harder. I created #154840 to track this.

If you have any theories you want me to try out, e.g. places to add an assert 
or calls to dump(), I can patch it in and see what happens. But that's 
obviously a very inefficient way to debug this, so hopefully I have luck w/ 
reducing this.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-21 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

> I'm trying to reduce a crash that only reproduces w/ in module builds. Does 
> this sound familiar?
> 
> ```
> assertion failed at clang/lib/AST/RecordLayoutBuilder.cpp:3380 in const 
> ASTRecordLayout &clang::ASTContext::getASTRecordLayout(const RecordDecl *) 
> const: D && "Cannot get layout of forward declarations!"
> *** Check failure stack trace: ***
> @ 0x557b3889784f  clang::ASTContext::getASTRecordLayout()
> @ 0x557b3823cd68  clang::ASTContext::getTypeInfoImpl()
> @ 0x557b3823e25c  clang::ASTContext::getTypeInfo()
> @ 0x557b3823d855  clang::ASTContext::getPreferredTypeAlign()
> @ 0x557b3823bf01  clang::ASTContext::getDeclAlign()
> @ 0x557b366c6a06  clang::CodeGen::CodeGenFunction::EmitAutoVarAlloca()
> @ 0x557b366c165c  clang::CodeGen::CodeGenFunction::EmitVarDecl()
> @ 0x557b366c1120  clang::CodeGen::CodeGenFunction::EmitDecl()
> @ 0x557b36760580  clang::CodeGen::CodeGenFunction::EmitDeclStmt()
> @ 0x557b36754d50  clang::CodeGen::CodeGenFunction::EmitSimpleStmt()
> @ 0x557b3675403e  clang::CodeGen::CodeGenFunction::EmitStmt()
> @ 0x557b36761891  
> clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope()
> @ 0x557b368c47d5  clang::CodeGen::CodeGenFunction::GenerateCode()
> @ 0x557b368ef9f6  
> clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition()
> @ 0x557b368e6bc8  
> clang::CodeGen::CodeGenModule::EmitGlobalDefinition()
> @ 0x557b368d7786  clang::CodeGen::CodeGenModule::EmitDeferred()
> @ 0x557b368d77a2  clang::CodeGen::CodeGenModule::EmitDeferred()
> ...
> @ 0x557b368d77a2  clang::CodeGen::CodeGenModule::EmitDeferred()
> @ 0x557b368d77a2  clang::CodeGen::CodeGenModule::EmitDeferred()
> @ 0x557b368d41ae  clang::CodeGen::CodeGenModule::Release()
> @ 0x557b36a1e14e  (anonymous 
> namespace)::CodeGeneratorImpl::HandleTranslationUnit()
> ```

Haven't seen this one yet. That may have something to do with demoted 
definitions, a repro would be helpful.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-19 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

> Okay, if this is just a temporary oddity, that's fine. My big concern is that 
> "original" implies "first" and that doesn't match the comment on what's 
> returned. Because temporary measures have a tendency to ossify sometimes, it 
> might make sense to add some more comments to clarify the situation. WDYT?

> After this commit, the comment in `clang/include/clang/AST/Decl.h` for 
> `clang::TypeDecl::getTypeForDecl`,
> isn't accurate any more, there's no more `ASTContext::getRecordType`.

These are fixed by: https://github.com/llvm/llvm-project/pull/154395

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-19 Thread Shafik Yaghmour via cfe-commits


shafik wrote:

Git bisect also blame this PR for: 
https://github.com/llvm/llvm-project/issues/154270

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-19 Thread Carlos Galvez via cfe-commits


carlosgalvezp wrote:

FYI bisecting https://github.com/llvm/llvm-project/issues/153770 leads to this 
patch

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-19 Thread Aaron Ballman via cfe-commits


AaronBallman wrote:

> > The comments in this area are confusing me, FWIW:
> > ```
> >   /// Stores the TagDecl associated with this type. The decl may point to 
> > any
> >   /// TagDecl that declares the entity.
> >   TagDecl *decl;
> > 
> >   ...
> > 
> >   TagDecl *getOriginalDecl() const { return decl; }
> > ```
> > 
> > 
> > 
> >   
> > 
> > 
> >   
> > 
> > 
> > 
> >   
> > The function is called "get original decl" which implies you get the first 
> > declaration seen in the TU, but the data member it returns has a comment 
> > saying it may point to any declaration in the redeclaration chain. One of 
> > these is wrong, correct?
> 
> Yeah, that is describing what is valid from the point of view of the AST Node.
> 
> As a user of TagType, you can certainly create one which points to any 
> declaration of an entity, and all of these nodes which point to a declaration 
> of the same entity are the same type.
> 
> From the point of view of Sema, there are further rules on how these types 
> are created, in normal day-to-day source code parsing, the declaration 
> pointed to by a non-canonical TagType will be the one found by lookup at that 
> point in the program.
> 
> FWIW the name `getOriginalDecl` was picked to temporarily disambiguate from 
> the behavior of the original `getDecl` that existed before the patch.
> 
> The difference in behavior is such that `getDecl` would always return the 
> definition if that existed, otherwise it would return the very first 
> declaration ever found by typename lookup when parsing a program, as there 
> only existed one TagType per entity.
> 
> The problem with keeping the name is that the behavior change meant that 
> whenever I would rebase the patch, new users of getDecl would have popped up 
> and it would be hard to make sure all uses of it were correct. By changing 
> the name, I get a compilation error which would allow me to inspect and make 
> the necessary changes.

Yeah, I think the plan is a reasonable one.

> As I stated before, once this patch is settled and everyone has had a nice 
> window to rebase their upstream, my plan is to submit another patch renaming 
> getOriginalDecl back to getDecl.

Okay, if this is just a temporary oddity, that's fine. My big concern is that 
"original" implies "first" and that doesn't match the comment on what's 
returned. Because temporary measures have a tendency to ossify sometimes, it 
might make sense to add some more comments to clarify the situation. WDYT?

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-18 Thread Jordan Rupprecht via cfe-commits


rupprecht wrote:

Filed #154270 w/ another crash, which looks different from #153933 / #153996.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-18 Thread Matheus Izvekov via cfe-commits

mizvekov wrote:

> The comments in this area are confusing me, FWIW:
> 
> ```
>   /// Stores the TagDecl associated with this type. The decl may point to any
>   /// TagDecl that declares the entity.
>   TagDecl *decl;
> 
>   ...
> 
>   TagDecl *getOriginalDecl() const { return decl; }
> ```
> 
> The function is called "get original decl" which implies you get the first 
> declaration seen in the TU, but the data member it returns has a comment 
> saying it may point to any declaration in the redeclaration chain. One of 
> these is wrong, correct?

Yeah, that is describing what is valid from the point of view of the AST Node.

As a user of TagType, you can certainly create one which points to any 
declaration of an entity, and all of these nodes which point to a declaration 
of the same entity are the same type.

>From the point of view of Sema, there are further rules on how these types are 
>created, in normal day-to-day source code parsing, the declaration pointed to 
>by a non-canonical TagType will be the one found by lookup at that point in 
>the program.

FWIW the name `getOriginalDecl` was picked to temporarily disambiguate from the 
behavior of the original `getDecl` that existed before the patch.

The difference in behavior is such that `getDecl` would always return the 
definition if that existed, otherwise it would return the very first 
declaration ever found by typename lookup when parsing a program, as there only 
existed one TagType per entity.

The problem with keeping the name is that the behavior change meant that 
whenever I would rebase the patch, new users of getDecl would have popped up 
and it would be hard to make sure all uses of it were correct. By changing the 
name, I get a compilation error which would allow me to inspect and make the 
necessary changes.

As I stated before, once this patch is settled and everyone has had a nice 
window to rebase their upstream, my plan is to submit another patch renaming 
getOriginalDecl back to getDecl.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-18 Thread Aaron Ballman via cfe-commits

AaronBallman wrote:

> > Thanks! However, for the following piece of code
> > `getOriginalDecl()` called on the pointed-to type gives the 
> > forward-declaration from the 3rd line, and the forward-declaration from the 
> > 1st line for its canonical type.
> 
> Yes that is correct.
> 
> The 3rd line is what declaration was found by type lookup at that point, and 
> the canonical declaration has long been established in clang as the first 
> declaration.

The comments in this area are confusing me, FWIW:
```
  /// Stores the TagDecl associated with this type. The decl may point to any
  /// TagDecl that declares the entity.
  TagDecl *decl;

  ...

  TagDecl *getOriginalDecl() const { return decl; }
```
The function is called "get original decl" which implies you get the first 
declaration seen in the TU, but the data member it returns has a comment saying 
it may point to any declaration in the redeclaration chain. One of these is 
wrong, correct?

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-17 Thread Andrey Ali Khan Bolshakov via cfe-commits



@@ -2586,8 +2561,9 @@ bool 
CXXNameMangler::mangleUnresolvedTypeOrSimpleId(QualType Ty,
   }
 
   case Type::InjectedClassName:
-mangleSourceNameWithAbiTags(
-cast(Ty)->getDecl());
+mangleSourceNameWithAbiTags(cast(Ty)
+->getOriginalDecl()
+->getDefinitionOrSelf());

bolshakov-a wrote:

Btw, it is a drawback of templates that you can easily overlook a 
specialization.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-17 Thread Matheus Izvekov via cfe-commits



@@ -2586,8 +2561,9 @@ bool 
CXXNameMangler::mangleUnresolvedTypeOrSimpleId(QualType Ty,
   }
 
   case Type::InjectedClassName:
-mangleSourceNameWithAbiTags(
-cast(Ty)->getDecl());
+mangleSourceNameWithAbiTags(cast(Ty)
+->getOriginalDecl()
+->getDefinitionOrSelf());

mizvekov wrote:

That looks like it needs to change, we probably don't want to do that for 
sugared leaf types.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-17 Thread Matheus Izvekov via cfe-commits



@@ -2586,8 +2561,9 @@ bool 
CXXNameMangler::mangleUnresolvedTypeOrSimpleId(QualType Ty,
   }
 
   case Type::InjectedClassName:
-mangleSourceNameWithAbiTags(
-cast(Ty)->getDecl());
+mangleSourceNameWithAbiTags(cast(Ty)
+->getOriginalDecl()
+->getDefinitionOrSelf());

mizvekov wrote:

Ah ok, interesting.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-17 Thread Andrey Ali Khan Bolshakov via cfe-commits



@@ -2586,8 +2561,9 @@ bool 
CXXNameMangler::mangleUnresolvedTypeOrSimpleId(QualType Ty,
   }
 
   case Type::InjectedClassName:
-mangleSourceNameWithAbiTags(
-cast(Ty)->getDecl());
+mangleSourceNameWithAbiTags(cast(Ty)
+->getOriginalDecl()
+->getDefinitionOrSelf());

bolshakov-a wrote:

I've understood: there are specializations of `getAs` for the leaf non-sugar 
types:

https://github.com/llvm/llvm-project/blob/71925a90c8b713d8fccbfae496e10c68f80b932b/clang/include/clang/AST/Type.h#L3138-L3140

If you call `getAs()` on a `Type` which is already 
`InjectedClassNameType`, you get its canonical type.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-16 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

> We started to see a CI failure around the time this PR landed in 
> https://green.lab.llvm.org/job/llvm.org/job/clang-stage2-Rthinlto/1079/
> Any ideas what might be going on here?

@Xazax-hun this could be the same as 
https://github.com/llvm/llvm-project/issues/153933

Could you confirm if the hang is limited to assertions enabled llvm builds, and 
if https://github.com/llvm/llvm-project/pull/153996 is sufficient to fix the 
problem?

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-16 Thread Matheus Izvekov via cfe-commits



@@ -2586,8 +2561,9 @@ bool 
CXXNameMangler::mangleUnresolvedTypeOrSimpleId(QualType Ty,
   }
 
   case Type::InjectedClassName:
-mangleSourceNameWithAbiTags(
-cast(Ty)->getDecl());
+mangleSourceNameWithAbiTags(cast(Ty)
+->getOriginalDecl()
+->getDefinitionOrSelf());

mizvekov wrote:

getAs only desugars. This could happen with a TemplateSpecializationType which 
its canonical type is an InjectedClassNameType, since in that case desugar just 
returns the canonical type, but that is not the case for that constructor, 
since its using an InjectedClassNameType as written in source code.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-16 Thread Andrey Ali Khan Bolshakov via cfe-commits



@@ -2586,8 +2561,9 @@ bool 
CXXNameMangler::mangleUnresolvedTypeOrSimpleId(QualType Ty,
   }
 
   case Type::InjectedClassName:
-mangleSourceNameWithAbiTags(
-cast(Ty)->getDecl());
+mangleSourceNameWithAbiTags(cast(Ty)
+->getOriginalDecl()
+->getDefinitionOrSelf());

bolshakov-a wrote:

Heh, interesting. `getAs` function actually returns the canonical type.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-16 Thread Matheus Izvekov via cfe-commits



@@ -2586,8 +2561,9 @@ bool 
CXXNameMangler::mangleUnresolvedTypeOrSimpleId(QualType Ty,
   }
 
   case Type::InjectedClassName:
-mangleSourceNameWithAbiTags(
-cast(Ty)->getDecl());
+mangleSourceNameWithAbiTags(cast(Ty)
+->getOriginalDecl()
+->getDefinitionOrSelf());

mizvekov wrote:

Are you sure it's not just its canonical type which refers to the first two 
lines?

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-16 Thread Andrey Ali Khan Bolshakov via cfe-commits



@@ -2586,8 +2561,9 @@ bool 
CXXNameMangler::mangleUnresolvedTypeOrSimpleId(QualType Ty,
   }
 
   case Type::InjectedClassName:
-mangleSourceNameWithAbiTags(
-cast(Ty)->getDecl());
+mangleSourceNameWithAbiTags(cast(Ty)
+->getOriginalDecl()
+->getDefinitionOrSelf());

bolshakov-a wrote:

I've caught an example:
```cpp
template 
struct Tpl;

template 
struct Tpl {
  Tpl(const Tpl&) {}
};
```
The injected name from the copy ctor prototype refers to the 
forward-declaration from the first two lines. Looks a little strange but Ok.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-16 Thread Matheus Izvekov via cfe-commits



@@ -2586,8 +2561,9 @@ bool 
CXXNameMangler::mangleUnresolvedTypeOrSimpleId(QualType Ty,
   }
 
   case Type::InjectedClassName:
-mangleSourceNameWithAbiTags(
-cast(Ty)->getDecl());
+mangleSourceNameWithAbiTags(cast(Ty)
+->getOriginalDecl()
+->getDefinitionOrSelf());

mizvekov wrote:

Not always.

I mean you could certainly attempt to define an `InjectedClassNameType` whose 
declaration necessarily is the definition.

This would cause many annoyances, most of them surmountable, as you wouldn't be 
able to form a type to an arbitrary declaration (which we do offhandedly in 
error recovery and printing diagnostics), and the type would play by different 
rules than other tag types.

Though I think at the end, you would come to the problem of demoted 
definitions, which come up for example when merging definitions from the GMF of 
different modules. You would have to throw away the ability to represent an 
InjectedClassNameType pointing to a demoted definition.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-16 Thread Andrey Ali Khan Bolshakov via cfe-commits



@@ -2586,8 +2561,9 @@ bool 
CXXNameMangler::mangleUnresolvedTypeOrSimpleId(QualType Ty,
   }
 
   case Type::InjectedClassName:
-mangleSourceNameWithAbiTags(
-cast(Ty)->getDecl());
+mangleSourceNameWithAbiTags(cast(Ty)
+->getOriginalDecl()
+->getDefinitionOrSelf());

bolshakov-a wrote:

Is this `getDefinitionOrSelf()` call necessary here? Shouldn't 
`InjectedClassNameType` always refer to the definition where the class name is 
injected to?

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-15 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

> Hi! We are seeing regression in `clang-tidy` in `modernize-type-traits` check 
> #153649. I confirmed locally that on 
> [91cdd35](https://github.com/llvm/llvm-project/commit/91cdd35008e9ab32dffb7e401cdd7313b3461892)
>  it is bugged and commit before it is not 
> [fc44a4f](https://github.com/llvm/llvm-project/commit/fc44a4fcd3c54be927c15ddd9211aca1501633e7)

Thanks for reporting. This has been fixed by 
https://github.com/llvm/llvm-project/pull/153923

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-15 Thread Baranov Victor via cfe-commits


vbvictor wrote:

Hi!
We are seeing regression in `clang-tidy` in `modernize-type-traits` check 
https://github.com/llvm/llvm-project/issues/153649. I confirmed locally that on 
91cdd35008e9ab32dffb7e401cdd7313b3461892 it is bugged and commit before it is 
not fc44a4fcd3c54be927c15ddd9211aca1501633e7


https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-15 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

> I don't know if this is the same as the other crash report, but we're also 
> seeing assert failures when building chromium. I've minimized the repro to 
> the following program:

Thanks, this is going to be fixed by 
https://github.com/llvm/llvm-project/pull/153862

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-15 Thread Matheus Izvekov via cfe-commits

mizvekov wrote:

> Thanks! However, for the following piece of code
> `getOriginalDecl()` called on the pointed-to type gives the 
> forward-declaration from the 3rd line, and the forward-declaration from the 
> 1st line for its canonical type.

Yes that is correct.

The 3rd line is what declaration was found by type lookup at that point, and 
the canonical declaration has long been established in clang as the first 
declaration.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-15 Thread Devon Loehr via cfe-commits


DKLoehr wrote:

I don't know if this is the same as the other crash report, but we're also 
seeing assert failures when building chromium. I've minimized the repro to the 
following program:
```
template  struct S {
  using typename T::Ty;
  static Ty Val;
};
template 
S::Ty S::Val;
```

This fails when running `clang++ -c repro.cc` when clang is built with asserts 
(`-std=c++20` silences a warning but isn't necessary). The crash looks like 
this:
```
llvm-project/clang/include/clang/AST/TypeLoc.h:79: T clang::TypeLoc::castAs() 
const [T = clang::DependentNameTypeLoc]: Assertion `T::isKind(*this)' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and 
include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.  Program arguments: clang++ -c repro.cc
1.  p.cc:6:19: current parser token ';'

clang++: error: clang frontend command failed with exit code 134 (use -v to see 
invocation)
clang version 22.0.0git (https://github.com/llvm/llvm-project.git 
91cdd35008e9ab32dffb7e401cdd7313b3461892)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Build config: +assertions
```

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-15 Thread Andrey Ali Khan Bolshakov via cfe-commits


bolshakov-a wrote:

Out of curiosity. The old `getDecl()` methods returned the tag type definition 
(if present), whereas the new `getOriginalDecl()` returns just some of 
redeclarations (and not necessarily the first one). What is the reason of such 
change?

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-15 Thread Gábor Horváth via cfe-commits


Xazax-hun wrote:

We started to see a CI failure around the time this PR landed in 
https://green.lab.llvm.org/job/llvm.org/job/clang-stage2-Rthinlto/1079/

The build hangs in this step (using a stage 2 compiler):
```
12:39:17  [384/5387] : && 
DYLD_LIBRARY_PATH=/Users/ec2-user/jenkins/workspace/llvm.org/clang-stage2-Rthinlto/host-compiler/lib/
 
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool"
 -static -no_warning_for_no_symbols -o lib/libbenchmark_main.a  
third-party/benchmark/src/CMakeFiles/benchmark_main.dir/benchmark_main.cc.o && :
```

This is where the compiler seems to hang:
```
Analysis of sampling clang++ (pid 12682) every 1 millisecond
Process: clang-22 [12682]
Path:/Users/*/clang-22
Load Address:0x1054d1000
Identifier:  clang-22
Version: 22.0.0git (0)
Code Type:   X86-64
Platform:macOS
Parent Process:  ninja [12327]

Date/Time:   2025-08-12 17:39:29.604 +
Launch Time: 2025-08-12 04:30:26.246 +
OS Version:  macOS 15.1.1 (24B91)
Report Version:  7
Analysis Tool:   /usr/bin/sample

Physical footprint: 83.4M
Physical footprint (peak):  83.4M
Idle exit:  untracked


Call graph:
120 Thread_240531   DispatchQueue_1: com.apple.main-thread  (serial)
  120 start  (in dyld) + 1805  [0x7ff804e212cd]
120 main  (in clang-22) + 128  [0x1054e1670]
  120 clang_main(int, char**, llvm::ToolContext const&)  (in clang-22) 
+ 5620  [0x1054d4254]
120 
clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, 
llvm::SmallVectorImpl>&)  (in 
clang-22) + 352  [0x108d26fa0]
  120 
clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, 
llvm::SmallVectorImpl>&, bool) 
const  (in clang-22) + 143  [0x108d0cc5f]
120 
clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, 
clang::driver::Command const*&, bool) const  (in clang-22) + 524  [0x108d0ca5c]
  120 
clang::driver::CC1Command::Execute(llvm::ArrayRef>,
 std::basic_string*, bool*) const  (in clang-22) + 297  [0x108d433a9]
120 
llvm::CrashRecoveryContext::RunSafely(llvm::function_ref)  (in 
clang-22) + 130  [0x10b389442]
  120 llvm::function_ref::callback_fn>,
 std::basic_string*, bool*) const::$_0>(long)  (in clang-22) + 30  
[0x108d43ace]
120 ExecuteCC1Tool(llvm::SmallVectorImpl&, 
llvm::ToolContext const&)  (in clang-22) + 395  [0x1054d49db]
  120 cc1_main(llvm::ArrayRef, char 
const*, void*)  (in clang-22) + 4289  [0x1054d77e1]
120 
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)  (in clang-22) + 632 
 [0x106d7c3e8]
  120 
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)  (in clang-22) + 
941  [0x108bfc91d]
120 clang::FrontendAction::Execute()  (in 
clang-22) + 42  [0x108c7a14a]
  120 clang::ParseAST(clang::Sema&, bool, bool) 
 (in clang-22) + 782  [0x108ec538e]
120 
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, 
clang::Sema::ModuleImportState&)  (in clang-22) + 1528  [0x108f9c968]
  120 
clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, 
clang::ParsedAttributes&, clang::ParsingDeclSpec*)  (in clang-22) + 1391  
[0x108f9e33f]
120 
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, 
clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier)  (in 
clang-22) + 625  [0x108f9f8e1]
  120 
clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, 
clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier)  (in 
clang-22) + 1314  [0x108fa00a2]
120 
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, 
clang::DeclaratorContext, clang::ParsedAttributes&, 
clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, 
clang::Parser::ForRangeInit*)  (in clang-22) + 4893  [0x108ed9a1d]
  120 
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, 
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*)  
(in clang-22) + 2342  [0x108fa0b86]
120 
clang::Sema::ActOnDefaultCtorInitializers(clang::Decl*)  (in clang-22) + 101  
[0x1093acc95]
  120 
clang::Sema::SetCtorInitializers(clang::CXXConstructorDecl*, bool, 
llvm::ArrayRef)  (in clang-22) + 3444  [0x1093a8f84]
120 
CollectFieldInitializer(clang::Sema&, (anonymous namespace)::BaseAndFieldInfo&, 
clang::FieldDecl*, clang::Indir

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-13 Thread Andrey Ali Khan Bolshakov via cfe-commits


bolshakov-a wrote:

@kimgr, what do you think?

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-13 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

It would be hard for us to document this as an intended interface, but leave 
that assert in the way, even if you found yourself a way to avoid it. This 
wouldn't look very polished.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-13 Thread Andrey Ali Khan Bolshakov via cfe-commits


bolshakov-a wrote:

The assert doesn't hurt us, as I've said. I just asked if it is a "documented 
way" of working with the new visitor interface. If it not to be avoided, then 
we will probably just proceed with the `TraverseQualifier` manipulation.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-13 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

We can make it work, we could move the assert elsewhere.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-13 Thread Andrey Ali Khan Bolshakov via cfe-commits


bolshakov-a wrote:

They should be avoided not always but in certain circumstances, so there should 
be a new flag field in the visitor class. Not many new code, TBH, but using 
`TraverseQualifier` was so tempting...

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-13 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

If you want to avoid traversal of NNSes, why don't you just override 
TraverseNestedNameSpecifier{,Loc} with no-ops?
I think that's the intended way to do it.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-11 Thread Andrey Ali Khan Bolshakov via cfe-commits


bolshakov-a wrote:

@kimgr, I've just succeeded in building IWYU against this and getting the tests 
green. However, I want to spend some time on self-review, probably writing 
additional tests, and so on.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-11 Thread Kim Gräsman via cfe-commits


kimgr wrote:

Did this PR intentionally break the `RecursiveASTVisitor` API? The new 
`TraverseQualifier` argument through the whole `Traverse.*Type` hierarchy makes 
all CRTP overrides not be called, unless I'm missing something.

It's a bit hard to test, because the NNS changes also break a lot of code in 
IWYU, so it's tricky to play with things in isolation.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-11 Thread Christian Kandeler via cfe-commits


ckandeler wrote:

Observation using clangd: In the following construct
```
namespace N { struct Foo{}; }
void f()
{
using namespace N;
Foo foo;
}
```
The "arcana" field of the AST node of "Foo" inside the function reports the 
"QualType" as "Foo", whereas before it was "N::Foo". Is that expected?

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-11 Thread David Spickett via cfe-commits


DavidSpickett wrote:

https://github.com/llvm/llvm-project/pull/152993 fixes this.

Pretty sure there's no problem with this PR, it uncovered an existing problem 
in the formatter itself.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-11 Thread David Spickett via cfe-commits


DavidSpickett wrote:

This has changed the output of lldb's std::string formatter when it's not a 
valid std::string object:
```
 TEST 'lldb-api :: 
functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py'
 FAILED 
Script:
--
/usr/bin/python3.10 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/dotest.py
 -u CXXFLAGS -u CFLAGS --env 
LLVM_LIBS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib --env 
LLVM_INCLUDE_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/include 
--env LLVM_TOOLS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin 
--arch aarch64 --build-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex 
--lldb-module-cache-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-lldb/lldb-api
 --clang-module-cache-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-clang/lldb-api
 --executable /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/lldb 
--compiler /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/clang 
--dsymutil /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/dsymutil 
--make /usr/bin/gmake --llvm-tools-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin --lldb-obj-root 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb --lldb-libs-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib --cmake-build-type 
Release 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string
 -p TestDataFormatterStdString.py
--
Exit Code: 1
<...>
--
Command Output (stderr):
--
<...>
==
FAIL: test_unavailable_summary_libstdcxx_dwarf 
(TestDataFormatterStdString.StdStringDataFormatterTestCase)
--
Traceback (most recent call last):
  File 
"/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 1805, in test_method
return attrvalue(self)
  File 
"/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py",
 line 223, in test_unavailable_summary_libstdcxx
self.do_test_summary_unavailable()
  File 
"/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py",
 line 213, in do_test_summary_unavailable
self.assertEqual(summary, "Summary Unavailable", "No summary for bad value")
AssertionError: '(null)' != 'Summary Unavailable'
- (null)
+ Summary Unavailable
 : No summary for bad value
Config=aarch64-/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang
==
FAIL: test_unavailable_summary_libstdcxx_dwo 
(TestDataFormatterStdString.StdStringDataFormatterTestCase)
--
Traceback (most recent call last):
  File 
"/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 1805, in test_method
return attrvalue(self)
  File 
"/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py",
 line 223, in test_unavailable_summary_libstdcxx
self.do_test_summary_unavailable()
  File 
"/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py",
 line 213, in do_test_summary_unavailable
self.assertEqual(summary, "Summary Unavailable", "No summary for bad value")
AssertionError: '(null)' != 'Summary Unavailable'
- (null)
+ Summary Unavailable
 : No summary for bad value
Config=aarch64-/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang
--
Ran 54 tests in 6.052s
```
We create the (not a) std::string like this:
```
std::string *not_a_string = (std::string *)0x0;
```
So in some sense, `(null)` is accurate, but users probably expect to see no 
summary at all.

This is from Linaro's bot where we only run libstdcxx tests. Libcxx testing 
seems fine 
(https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-matrix/). 
This could be because the formatter has different behaviour for the two 
standard libraries.

@Michael137 might know where to look for this problem, in the meantime, I'll do 
my own digging.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-09 Thread LLVM Continuous Integration via cfe-commits


llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `lldb-aarch64-ubuntu` 
running on `linaro-lldb-aarch64-ubuntu` while building 
`clang-tools-extra,clang,libcxx,lldb` at step 6 "test".

Full details are available at: 
https://lab.llvm.org/buildbot/#/builders/59/builds/22354


Here is the relevant piece of the build log for the reference

```
Step 6 (test) failure: build (failure)
...
UNSUPPORTED: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/generic/u8string_view/TestDataFormatterStdU8StringView.py
 (413 of 2304)
UNSUPPORTED: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/generic/valarray/TestDataFormatterStdValarray.py
 (414 of 2304)
PASS: lldb-api :: functionalities/completion/TestCompletion.py (415 of 2304)
PASS: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/libcxx-simulators/invalid-vector/TestDataFormatterLibcxxInvalidVectorSimulator.py
 (416 of 2304)
PASS: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/generic/vbool/TestDataFormatterStdVBool.py
 (417 of 2304)
PASS: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/libcxx-simulators/optional/TestDataFormatterLibcxxOptionalSimulator.py
 (418 of 2304)
PASS: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/generic/unique_ptr/TestDataFormatterStdUniquePtr.py
 (419 of 2304)
UNSUPPORTED: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/libcxx/invalid-string/TestDataFormatterLibcxxInvalidString.py
 (420 of 2304)
PASS: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/TestDataFormatterLibcxxUniquePtrSimulator.py
 (421 of 2304)
PASS: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/libstdcpp/invalid-variant/TestDataFormatterInvalidStdVariant.py
 (422 of 2304)
FAIL: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py
 (423 of 2304)
 TEST 'lldb-api :: 
functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py'
 FAILED 
Script:
--
/usr/bin/python3.10 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/dotest.py
 -u CXXFLAGS -u CFLAGS --env 
LLVM_LIBS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib --env 
LLVM_INCLUDE_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/include 
--env LLVM_TOOLS_DIR=/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin 
--arch aarch64 --build-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex 
--lldb-module-cache-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-lldb/lldb-api
 --clang-module-cache-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lldb-test-build.noindex/module-cache-clang/lldb-api
 --executable /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/lldb 
--compiler /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/clang 
--dsymutil /home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin/dsymutil 
--make /usr/bin/gmake --llvm-tools-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./bin --lldb-obj-root 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/tools/lldb --lldb-libs-dir 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/./lib --cmake-build-type 
Release 
/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string
 -p TestDataFormatterStdString.py
--
Exit Code: 1

Command Output (stdout):
--
lldb version 22.0.0git (https://github.com/llvm/llvm-project.git revision 
91cdd35008e9ab32dffb7e401cdd7313b3461892)
  clang revision 91cdd35008e9ab32dffb7e401cdd7313b3461892
  llvm revision 91cdd35008e9ab32dffb7e401cdd7313b3461892
Skipping the following test categories: ['libc++', 'msvcstl', 'dsym', 
'gmodules', 'debugserver', 'objc']

--
Command Output (stderr):
--
UNSUPPORTED: LLDB 
(/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) :: 
test_embedded_null_libcxx_dsym 
(TestDataFormatterStdString.StdStringDataFormatterTestCase) (test case does not 
fall in any category of interest for this run) 
UNSUPPORTED: LLDB 
(/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) :: 
test_embedded_null_libcxx_dwarf 
(TestDataFormatterStdString.StdStringDataFormatterTestCase) (test case does not 
fall in any category of interest for this run) 
UNSUPPORTED: LLDB 
(/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) :: 
test_embedded_null_libcxx_dwo 
(TestDataFormatterStdString.StdStringDataFormatterTestCase) (test case does not 
fall in any category of interest for this run) 
UNSUPPORTED: LLDB 
(/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang-aarch64) :: 
test_embedded_null_libstdcxx_dsym 
(TestDataFormatterStdString.StdStringDataFormatterTestCase) (test case does not 
fall in any category of interest for this run

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-09 Thread LLVM Continuous Integration via cfe-commits


llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `lldb-x86_64-debian` 
running on `lldb-x86_64-debian` while building 
`clang-tools-extra,clang,libcxx,lldb` at step 6 "test".

Full details are available at: 
https://lab.llvm.org/buildbot/#/builders/162/builds/28595


Here is the relevant piece of the build log for the reference

```
Step 6 (test) failure: build (failure)
...
PASS: lldb-api :: tools/lldb-server/TestGdbRemoteAuxvSupport.py (50 of 3137)
PASS: lldb-api :: python_api/find_in_memory/TestFindRangesInMemory.py (51 of 
3137)
PASS: lldb-api :: tools/lldb-dap/completions/TestDAP_completions.py (52 of 3137)
PASS: lldb-api :: tools/lldb-server/qSupported/TestGdbRemote_qSupported.py (53 
of 3137)
PASS: lldb-api :: 
functionalities/breakpoint/breakpoint_set_restart/TestBreakpointSetRestart.py 
(54 of 3137)
PASS: lldb-api :: tools/lldb-dap/databreakpoint/TestDAP_setDataBreakpoints.py 
(55 of 3137)
PASS: lldb-api :: commands/settings/TestSettings.py (56 of 3137)
PASS: lldb-api :: functionalities/thread/state/TestThreadStates.py (57 of 3137)
PASS: lldb-api :: tools/lldb-dap/server/TestDAP_server.py (58 of 3137)
PASS: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/generic/vector/TestDataFormatterStdVector.py
 (59 of 3137)
FAIL: lldb-api :: 
functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py
 (60 of 3137)
 TEST 'lldb-api :: 
functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py'
 FAILED 
Script:
--
/usr/bin/python3 
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/dotest.py -u 
CXXFLAGS -u CFLAGS --env 
LLVM_LIBS_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/./lib --env 
LLVM_INCLUDE_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/include --env 
LLVM_TOOLS_DIR=/home/worker/2.0.1/lldb-x86_64-debian/build/./bin --arch x86_64 
--build-dir /home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex 
--lldb-module-cache-dir 
/home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex/module-cache-lldb/lldb-api
 --clang-module-cache-dir 
/home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex/module-cache-clang/lldb-api
 --executable /home/worker/2.0.1/lldb-x86_64-debian/build/./bin/lldb --compiler 
/home/worker/2.0.1/lldb-x86_64-debian/build/./bin/clang --dsymutil 
/home/worker/2.0.1/lldb-x86_64-debian/build/./bin/dsymutil --make 
/usr/bin/gmake --llvm-tools-dir 
/home/worker/2.0.1/lldb-x86_64-debian/build/./bin --lldb-obj-root 
/home/worker/2.0.1/lldb-x86_64-debian/build/tools/lldb --lldb-libs-dir 
/home/worker/2.0.1/lldb-x86_64-debian/build/./lib --cmake-build-type Release -t 
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string
 -p TestDataFormatterStdString.py
--
Exit Code: 1

Command Output (stdout):
--
lldb version 22.0.0git (https://github.com/llvm/llvm-project.git revision 
91cdd35008e9ab32dffb7e401cdd7313b3461892)
  clang revision 91cdd35008e9ab32dffb7e401cdd7313b3461892
  llvm revision 91cdd35008e9ab32dffb7e401cdd7313b3461892
Skipping the following test categories: ['libc++', 'msvcstl', 'dsym', 
'gmodules', 'debugserver', 'objc']

--
Command Output (stderr):
--
Change dir to: 
/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string
UNSUPPORTED: LLDB 
(/home/worker/2.0.1/lldb-x86_64-debian/build/bin/clang-x86_64) :: 
test_embedded_null_libcxx_dsym 
(TestDataFormatterStdString.StdStringDataFormatterTestCase.test_embedded_null_libcxx_dsym)
 (test case does not fall in any category of interest for this run) 
UNSUPPORTED: LLDB 
(/home/worker/2.0.1/lldb-x86_64-debian/build/bin/clang-x86_64) :: 
test_embedded_null_libcxx_dwarf 
(TestDataFormatterStdString.StdStringDataFormatterTestCase.test_embedded_null_libcxx_dwarf)
 (test case does not fall in any category of interest for this run) 
UNSUPPORTED: LLDB 
(/home/worker/2.0.1/lldb-x86_64-debian/build/bin/clang-x86_64) :: 
test_embedded_null_libcxx_dwo 
(TestDataFormatterStdString.StdStringDataFormatterTestCase.test_embedded_null_libcxx_dwo)
 (test case does not fall in any category of interest for this run) 
UNSUPPORTED: LLDB 
(/home/worker/2.0.1/lldb-x86_64-debian/build/bin/clang-x86_64) :: 
test_embedded_null_libstdcxx_dsym 
(TestDataFormatterStdString.StdStringDataFormatterTestCase.test_embedded_null_libstdcxx_dsym)
 (test case does not fall in any category of interest for this run) 
runCmd: settings clear --all

output: 

runCmd: settings set symbols.enable-external-lookup false

output: 

runCmd: settings set target.inherit-tcc true

output: 

runCmd: settings set target.disable-aslr false

output: 


```



https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-09 Thread LLVM Continuous Integration via cfe-commits


llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder 
`libc-x86_64-debian-dbg-bootstrap-build` running on `libc-x86_64-debian` while 
building `clang-tools-extra,clang,libcxx,lldb` at step 4 "annotate".

Full details are available at: 
https://lab.llvm.org/buildbot/#/builders/200/builds/14983


Here is the relevant piece of the build log for the reference

```
Step 4 (annotate) failure: 'python 
../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py ...' (failure)
...
[396/659] Building CXX object 
tools/clang/lib/Frontend/CMakeFiles/obj.clangFrontend.dir/ASTMerge.cpp.o
[397/659] Building CXX object 
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/ASTReaderStmt.cpp.o
[398/659] Linking CXX static library lib/libclangAnalysis.a
[399/659] Building CXX object 
tools/clang/lib/Index/CMakeFiles/obj.clangIndex.dir/CommentToXML.cpp.o
[400/659] Building CXX object 
tools/clang/lib/Frontend/CMakeFiles/obj.clangFrontend.dir/CreateInvocationFromCommandLine.cpp.o
[401/659] Building CXX object 
tools/clang/lib/Index/CMakeFiles/obj.clangIndex.dir/FileIndexRecord.cpp.o
[402/659] Building CXX object 
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/ASTWriterDecl.cpp.o
[403/659] Building CXX object 
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/ASTWriterStmt.cpp.o
[404/659] Building CXX object 
tools/clang/lib/Frontend/CMakeFiles/obj.clangFrontend.dir/DependencyFile.cpp.o
[405/659] Building CXX object 
tools/clang/lib/Frontend/Rewrite/CMakeFiles/obj.clangRewriteFrontend.dir/RewriteObjC.cpp.o
FAILED: 
tools/clang/lib/Frontend/Rewrite/CMakeFiles/obj.clangRewriteFrontend.dir/RewriteObjC.cpp.o
 
/usr/bin/clang++ -DCLANG_EXPORTS -DGTEST_HAS_RTTI=0 -D_DEBUG 
-D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian/libc-x86_64-debian-dbg-bootstrap-build/build/tools/clang/lib/Frontend/Rewrite
 
-I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian/libc-x86_64-debian-dbg-bootstrap-build/llvm-project/clang/lib/Frontend/Rewrite
 
-I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian/libc-x86_64-debian-dbg-bootstrap-build/llvm-project/clang/include
 
-I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian/libc-x86_64-debian-dbg-bootstrap-build/build/tools/clang/include
 
-I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian/libc-x86_64-debian-dbg-bootstrap-build/build/include
 
-I/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian/libc-x86_64-debian-dbg-bootstrap-build/llvm-project/llvm/include
 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden 
-Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
-pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color 
-fno-common -Woverloaded-virtual -Wno-nested-anon-types -g  -fno-exceptions 
-funwind-tables -fno-rtti -std=c++17 -MD -MT 
tools/clang/lib/Frontend/Rewrite/CMakeFiles/obj.clangRewriteFrontend.dir/RewriteObjC.cpp.o
 -MF 
tools/clang/lib/Frontend/Rewrite/CMakeFiles/obj.clangRewriteFrontend.dir/RewriteObjC.cpp.o.d
 -o 
tools/clang/lib/Frontend/Rewrite/CMakeFiles/obj.clangRewriteFrontend.dir/RewriteObjC.cpp.o
 -c 
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian/libc-x86_64-debian-dbg-bootstrap-build/llvm-project/clang/lib/Frontend/Rewrite/RewriteObjC.cpp
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian/libc-x86_64-debian-dbg-bootstrap-build/llvm-project/clang/lib/Frontend/Rewrite/RewriteObjC.cpp:2361:52:
 error: no member named 'getTagDeclType' in 'clang::ASTContext'
  QualType argT = Context->getPointerType(Context->getTagDeclType(RD));
  ~~~  ^
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian/libc-x86_64-debian-dbg-bootstrap-build/llvm-project/clang/lib/Frontend/Rewrite/RewriteObjC.cpp:2404:52:
 error: no member named 'getTagDeclType' in 'clang::ASTContext'
  QualType argT = Context->getPointerType(Context->getTagDeclType(RD));
  ~~~  ^
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian/libc-x86_64-debian-dbg-bootstrap-build/llvm-project/clang/lib/Frontend/Rewrite/RewriteObjC.cpp:2555:19:
 error: no member named 'getTagDeclType' in 'clang::ASTContext'
  return Context->getTagDeclType(SuperStructDecl);
 ~~~  ^
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian/libc-x86_64-debian-dbg-bootstrap-build/llvm-project/clang/lib/Frontend/Rewrite/RewriteObjC.cpp:2588:19:
 error: no member named 'getTagDeclType' in 'clang::ASTContext'
  return Context->getTagDeclType(ConstantStringDecl);
 ~

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-09 Thread Matheus Izvekov via cfe-commits


https://github.com/mizvekov closed 
https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-09 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

The HLSL Tests bot failure was some GitHub permission issue when publishing the 
results of the successful run:
```
2025-08-09T07:06:35.4098240Z Request POST /repos/llvm/llvm-project/check-runs 
failed with 403: Forbidden
2025-08-09T07:06:35.4098670Z 2025-08-09 02:06:35 -0500 - github.GithubRetry -  
INFO - Request POST /repos/llvm/llvm-project/check-runs failed with 403: 
Forbidden
2025-08-09T07:06:35.4099210Z Traceback (most recent call last):
2025-08-09T07:06:35.4100200Z   File 
"/Users/cbieneman/actions-runner/_work/_actions/EnricoMi/publish-unit-test-result-action/170bf24d20d201b842d7a52403b73ed297e6645b/macos/../python/publish_test_results.py",
 line 546, in 
2025-08-09T07:06:35.4101240Z main(settings, gha)
2025-08-09T07:06:35.4101840Z   File 
"/Users/cbieneman/actions-runner/_work/_actions/EnricoMi/publish-unit-test-result-action/170bf24d20d201b842d7a52403b73ed297e6645b/macos/../python/publish_test_results.py",
 line 269, in main
2025-08-09T07:06:35.4102530Z Publisher(settings, gh, gha).publish(stats, 
results.case_results, conclusion)
2025-08-09T07:06:35.4103150Z   File 
"/Users/cbieneman/actions-runner/_work/_actions/EnricoMi/publish-unit-test-result-action/170bf24d20d201b842d7a52403b73ed297e6645b/python/publish/publisher.py",
 line 233, in publish
2025-08-09T07:06:35.4112040Z data = self.publish_check(data)
2025-08-09T07:06:35.4112950Z   File 
"/Users/cbieneman/actions-runner/_work/_actions/EnricoMi/publish-unit-test-result-action/170bf24d20d201b842d7a52403b73ed297e6645b/python/publish/publisher.py",
 line 461, in publish_check
2025-08-09T07:06:35.4114640Z check_run = 
self._repo.create_check_run(name=self._settings.check_name,
2025-08-09T07:06:35.4115270Z   File 
"/Users/cbieneman/actions-runner/_work/llvm-project/llvm-project/enricomi-publish-action-venv/lib/python3.9/site-packages/github/Repository.py",
 line 3885, in create_check_run
2025-08-09T07:06:35.4129000Z headers, data = 
self._requester.requestJsonAndCheck(
2025-08-09T07:06:35.4129600Z   File 
"/Users/cbieneman/actions-runner/_work/llvm-project/llvm-project/enricomi-publish-action-venv/lib/python3.9/site-packages/github/Requester.py",
 line 550, in requestJsonAndCheck
2025-08-09T07:06:35.4133670Z return self.__check(*self.requestJson(verb, 
url, parameters, headers, input, self.__customConnection(url)))
2025-08-09T07:06:35.4134330Z   File 
"/Users/cbieneman/actions-runner/_work/llvm-project/llvm-project/enricomi-publish-action-venv/lib/python3.9/site-packages/github/Requester.py",
 line 715, in requestJson
2025-08-09T07:06:35.4134930Z return self.__requestEncode(cnx, verb, url, 
parameters, headers, input, encode)
2025-08-09T07:06:35.4135520Z   File 
"/Users/cbieneman/actions-runner/_work/llvm-project/llvm-project/enricomi-publish-action-venv/lib/python3.9/site-packages/github/Requester.py",
 line 812, in __requestEncode
2025-08-09T07:06:35.4136240Z status, responseHeaders, output = 
self.__requestRaw(cnx, verb, url, requestHeaders, encoded_input)
2025-08-09T07:06:35.4136880Z   File 
"/Users/cbieneman/actions-runner/_work/llvm-project/llvm-project/enricomi-publish-action-venv/lib/python3.9/site-packages/github/Requester.py",
 line 846, in __requestRaw
2025-08-09T07:06:35.4137490Z response = cnx.getresponse()
2025-08-09T07:06:35.4138000Z   File 
"/Users/cbieneman/actions-runner/_work/llvm-project/llvm-project/enricomi-publish-action-venv/lib/python3.9/site-packages/github/Requester.py",
 line 198, in getresponse
2025-08-09T07:06:35.4138500Z r = verb(
2025-08-09T07:06:35.4138940Z   File 
"/Users/cbieneman/actions-runner/_work/llvm-project/llvm-project/enricomi-publish-action-venv/lib/python3.9/site-packages/requests/sessions.py",
 line 637, in post
2025-08-09T07:06:35.4141770Z return self.request("POST", url, data=data, 
json=json, **kwargs)
2025-08-09T07:06:35.4142390Z   File 
"/Users/cbieneman/actions-runner/_work/llvm-project/llvm-project/enricomi-publish-action-venv/lib/python3.9/site-packages/requests/sessions.py",
 line 589, in request
2025-08-09T07:06:35.4142900Z resp = self.send(prep, **send_kwargs)
2025-08-09T07:06:35.4143390Z   File 
"/Users/cbieneman/actions-runner/_work/llvm-project/llvm-project/enricomi-publish-action-venv/lib/python3.9/site-packages/requests/sessions.py",
 line 703, in send
2025-08-09T07:06:35.4143890Z r = adapter.send(request, **kwargs)
2025-08-09T07:06:35.4144370Z   File 
"/Users/cbieneman/actions-runner/_work/llvm-project/llvm-project/enricomi-publish-action-venv/lib/python3.9/site-packages/requests/adapters.py",
 line 667, in send
2025-08-09T07:06:35.4145190Z resp = conn.urlopen(
2025-08-09T07:06:35.4145680Z   File 
"/Users/cbieneman/actions-runner/_work/llvm-project/llvm-project/enricomi-publish-action-venv/lib/python3.9/site-packages/urllib3/connectionpool.py",
 line 934, in urlopen
2025-08-09T07:06:35.4149990Z retries = retries.increment(method, url, 
response=response, _pool=self)
2025-08-09T07:06:35.4150560Z   File 
"/Us

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-08 Thread Matheus Izvekov via cfe-commits


https://github.com/mizvekov edited 
https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-08-08 Thread Matheus Izvekov via cfe-commits


https://github.com/mizvekov edited 
https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-07-10 Thread Erich Keane via cfe-commits


erichkeane wrote:

> > Is there ANYTHING we can do to split this up? This is so huge that github 
> > is refusing to load half the changes.
> 
> I broke the commit down into others, now the first commit only has the AST 
> and TreeTransform changes.

Can we split them up in reviews/do reviews as a stack if necessary? reviewing 
each individual 'commit' in the same review is also really difficult.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-07-10 Thread Matheus Izvekov via cfe-commits


mizvekov wrote:

> Is there ANYTHING we can do to split this up? This is so huge that github is 
> refusing to load half the changes.

I broke the commit down into others, now the first commit only has the AST and 
TreeTransform changes.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-07-10 Thread Erich Keane via cfe-commits


https://github.com/erichkeane edited 
https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-07-10 Thread Erich Keane via cfe-commits


https://github.com/erichkeane commented:

Is there ANYTHING we can do to split this up?  This is so huge that github is 
refusing to lead half the changes.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Improve nested name specifier AST representation (PR #147835)

2025-07-09 Thread via cfe-commits


QuietMisdreavus wrote:

ExtractAPI changes look good.

https://github.com/llvm/llvm-project/pull/147835
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

82 matches

Mail list logo