[clang] [clang][NFC] Factor out VLA checks in type traits (PR #88646)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll edited 
https://github.com/llvm/llvm-project/pull/88646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][NFC] Factor out VLA checks in type traits (PR #88646)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll updated 
https://github.com/llvm/llvm-project/pull/88646

>From 34d735b2f85e3c24cbf725f6a519afec6c916820 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Sun, 14 Apr 2024 10:41:53 +0300
Subject: [PATCH] [clang][NFC] Factor out VLA check in type traits

---
 clang/lib/Sema/SemaExprCXX.cpp | 59 ++
 1 file changed, 31 insertions(+), 28 deletions(-)

diff --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index 1cfd3e56a583eb..d2f18d4aa9b980 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -5012,6 +5012,20 @@ Sema::PerformImplicitConversion(Expr *From, QualType 
ToType,
   return From;
 }
 
+/// Checks that type T is not a VLA.
+///
+/// @returns @c true if @p T is VLA and a diagnostic was emitted,
+/// @c false otherwise.
+static bool DiagnoseVLAInCXXTypeTrait(Sema , const TypeSourceInfo *T,
+  clang::tok::TokenKind TypeTraitID) {
+  if (!T->getType()->isVariableArrayType())
+return false;
+
+  S.Diag(T->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
+  << 1 << TypeTraitID;
+  return true;
+}
+
 /// Check the completeness of a type in a unary type trait.
 ///
 /// If the particular type trait requires a complete type, tries to complete
@@ -5188,7 +5202,9 @@ static bool HasNoThrowOperator(const RecordType *RT, 
OverloadedOperatorKind Op,
 }
 
 static bool EvaluateUnaryTypeTrait(Sema , TypeTrait UTT,
-   SourceLocation KeyLoc, QualType T) {
+   SourceLocation KeyLoc,
+   TypeSourceInfo *TInfo) {
+  QualType T = TInfo->getType();
   assert(!T->isDependentType() && "Cannot evaluate traits of dependent type");
 
   ASTContext  = Self.Context;
@@ -5205,21 +5221,13 @@ static bool EvaluateUnaryTypeTrait(Sema , 
TypeTrait UTT,
   case UTT_IsArray:
 return T->isArrayType();
   case UTT_IsBoundedArray:
-if (!T->isVariableArrayType()) {
-  return T->isArrayType() && !T->isIncompleteArrayType();
-}
-
-Self.Diag(KeyLoc, diag::err_vla_unsupported)
-<< 1 << tok::kw___is_bounded_array;
-return false;
+if (DiagnoseVLAInCXXTypeTrait(Self, TInfo, tok::kw___is_bounded_array))
+  return false;
+return T->isArrayType() && !T->isIncompleteArrayType();
   case UTT_IsUnboundedArray:
-if (!T->isVariableArrayType()) {
-  return T->isIncompleteArrayType();
-}
-
-Self.Diag(KeyLoc, diag::err_vla_unsupported)
-<< 1 << tok::kw___is_unbounded_array;
-return false;
+if (DiagnoseVLAInCXXTypeTrait(Self, TInfo, tok::kw___is_unbounded_array))
+  return false;
+return T->isIncompleteArrayType();
   case UTT_IsPointer:
 return T->isAnyPointerType();
   case UTT_IsNullPointer:
@@ -5631,7 +5639,7 @@ static bool EvaluateBooleanTypeTrait(Sema , TypeTrait 
Kind,
 return false;
 
   if (Kind <= UTT_Last)
-return EvaluateUnaryTypeTrait(S, Kind, KWLoc, Args[0]->getType());
+return EvaluateUnaryTypeTrait(S, Kind, KWLoc, Args[0]);
 
   // Evaluate ReferenceBindsToTemporary and ReferenceConstructsFromTemporary
   // alongside the IsConstructible traits to avoid duplication.
@@ -6093,12 +6101,9 @@ static bool EvaluateBinaryTypeTrait(Sema , 
TypeTrait BTT, const TypeSourceI
   Self.RequireCompleteType(Rhs->getTypeLoc().getBeginLoc(), RhsT,
diag::err_incomplete_type);
 
-if (LhsT->isVariableArrayType())
-  Self.Diag(Lhs->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
-  << 1 << tok::kw___is_layout_compatible;
-if (RhsT->isVariableArrayType())
-  Self.Diag(Rhs->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
-  << 1 << tok::kw___is_layout_compatible;
+DiagnoseVLAInCXXTypeTrait(Self, Lhs, tok::kw___is_layout_compatible);
+DiagnoseVLAInCXXTypeTrait(Self, Rhs, tok::kw___is_layout_compatible);
+
 return Self.IsLayoutCompatible(LhsT, RhsT);
   }
   case BTT_IsPointerInterconvertibleBaseOf: {
@@ -6108,12 +6113,10 @@ static bool EvaluateBinaryTypeTrait(Sema , 
TypeTrait BTT, const TypeSourceI
diag::err_incomplete_type);
 }
 
-if (LhsT->isVariableArrayType())
-  Self.Diag(Lhs->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
-  << 1 << tok::kw___is_pointer_interconvertible_base_of;
-if (RhsT->isVariableArrayType())
-  Self.Diag(Rhs->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
-  << 1 << tok::kw___is_pointer_interconvertible_base_of;
+DiagnoseVLAInCXXTypeTrait(Self, Lhs,
+  tok::kw___is_pointer_interconvertible_base_of);
+DiagnoseVLAInCXXTypeTrait(Self, Rhs,
+  tok::kw___is_pointer_interconvertible_base_of);
 
 return Self.IsPointerInterconvertibleBaseOf(Lhs, Rhs);
   }

___
cfe-commits mailing list

[clang] [clang][NFC] Factor out VLA checks in type traits (PR #88646)

[Vlad Serebrennikov via cfe-commits]

@@ -5012,6 +5012,20 @@ Sema::PerformImplicitConversion(Expr *From, QualType 
ToType,
   return From;
 }
 
+/// Checks that type T is not a VLA.
+///
+/// @returns @c true if @p T is VLA and a diagnostic was emitted,
+/// @c false otherwise.
+static bool DiagnoseVLAInCXXTypeTrait(Sema , const TypeSourceInfo *T,

Endilll wrote:

One reason might be the fact that current use case for this function is C++ 
traits specifically, since VLA is clearly an extension for them. I'll keep the 
`CXX` then.

https://github.com/llvm/llvm-project/pull/88646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Introduce `SemaOpenMP` (PR #88642)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

I intentionally split formatting changes into a separate commit if reviewers 
want to look at changes without formatting noise.

If, given the volume of changes here, there is an appetite to remove `OpenMP` 
and `OMP` from names inside `SemaOpenMP` right in this patch, I can do that. I 
did that for HLSL and OpenACC, but those were an order of magnitude smaller 
patches that this one.

https://github.com/llvm/llvm-project/pull/88642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][NFC] Factor out VLA check in type traits (PR #88646)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll created 
https://github.com/llvm/llvm-project/pull/88646

This is a follow-up to #88473 suggested by @cor3ntin in 
https://github.com/llvm/llvm-project/pull/88473#discussion_r1562198117.

>From 34d735b2f85e3c24cbf725f6a519afec6c916820 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Sun, 14 Apr 2024 10:41:53 +0300
Subject: [PATCH] [clang][NFC] Factor out VLA check in type traits

---
 clang/lib/Sema/SemaExprCXX.cpp | 59 ++
 1 file changed, 31 insertions(+), 28 deletions(-)

diff --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index 1cfd3e56a583eb..d2f18d4aa9b980 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -5012,6 +5012,20 @@ Sema::PerformImplicitConversion(Expr *From, QualType 
ToType,
   return From;
 }
 
+/// Checks that type T is not a VLA.
+///
+/// @returns @c true if @p T is VLA and a diagnostic was emitted,
+/// @c false otherwise.
+static bool DiagnoseVLAInCXXTypeTrait(Sema , const TypeSourceInfo *T,
+  clang::tok::TokenKind TypeTraitID) {
+  if (!T->getType()->isVariableArrayType())
+return false;
+
+  S.Diag(T->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
+  << 1 << TypeTraitID;
+  return true;
+}
+
 /// Check the completeness of a type in a unary type trait.
 ///
 /// If the particular type trait requires a complete type, tries to complete
@@ -5188,7 +5202,9 @@ static bool HasNoThrowOperator(const RecordType *RT, 
OverloadedOperatorKind Op,
 }
 
 static bool EvaluateUnaryTypeTrait(Sema , TypeTrait UTT,
-   SourceLocation KeyLoc, QualType T) {
+   SourceLocation KeyLoc,
+   TypeSourceInfo *TInfo) {
+  QualType T = TInfo->getType();
   assert(!T->isDependentType() && "Cannot evaluate traits of dependent type");
 
   ASTContext  = Self.Context;
@@ -5205,21 +5221,13 @@ static bool EvaluateUnaryTypeTrait(Sema , 
TypeTrait UTT,
   case UTT_IsArray:
 return T->isArrayType();
   case UTT_IsBoundedArray:
-if (!T->isVariableArrayType()) {
-  return T->isArrayType() && !T->isIncompleteArrayType();
-}
-
-Self.Diag(KeyLoc, diag::err_vla_unsupported)
-<< 1 << tok::kw___is_bounded_array;
-return false;
+if (DiagnoseVLAInCXXTypeTrait(Self, TInfo, tok::kw___is_bounded_array))
+  return false;
+return T->isArrayType() && !T->isIncompleteArrayType();
   case UTT_IsUnboundedArray:
-if (!T->isVariableArrayType()) {
-  return T->isIncompleteArrayType();
-}
-
-Self.Diag(KeyLoc, diag::err_vla_unsupported)
-<< 1 << tok::kw___is_unbounded_array;
-return false;
+if (DiagnoseVLAInCXXTypeTrait(Self, TInfo, tok::kw___is_unbounded_array))
+  return false;
+return T->isIncompleteArrayType();
   case UTT_IsPointer:
 return T->isAnyPointerType();
   case UTT_IsNullPointer:
@@ -5631,7 +5639,7 @@ static bool EvaluateBooleanTypeTrait(Sema , TypeTrait 
Kind,
 return false;
 
   if (Kind <= UTT_Last)
-return EvaluateUnaryTypeTrait(S, Kind, KWLoc, Args[0]->getType());
+return EvaluateUnaryTypeTrait(S, Kind, KWLoc, Args[0]);
 
   // Evaluate ReferenceBindsToTemporary and ReferenceConstructsFromTemporary
   // alongside the IsConstructible traits to avoid duplication.
@@ -6093,12 +6101,9 @@ static bool EvaluateBinaryTypeTrait(Sema , 
TypeTrait BTT, const TypeSourceI
   Self.RequireCompleteType(Rhs->getTypeLoc().getBeginLoc(), RhsT,
diag::err_incomplete_type);
 
-if (LhsT->isVariableArrayType())
-  Self.Diag(Lhs->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
-  << 1 << tok::kw___is_layout_compatible;
-if (RhsT->isVariableArrayType())
-  Self.Diag(Rhs->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
-  << 1 << tok::kw___is_layout_compatible;
+DiagnoseVLAInCXXTypeTrait(Self, Lhs, tok::kw___is_layout_compatible);
+DiagnoseVLAInCXXTypeTrait(Self, Rhs, tok::kw___is_layout_compatible);
+
 return Self.IsLayoutCompatible(LhsT, RhsT);
   }
   case BTT_IsPointerInterconvertibleBaseOf: {
@@ -6108,12 +6113,10 @@ static bool EvaluateBinaryTypeTrait(Sema , 
TypeTrait BTT, const TypeSourceI
diag::err_incomplete_type);
 }
 
-if (LhsT->isVariableArrayType())
-  Self.Diag(Lhs->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
-  << 1 << tok::kw___is_pointer_interconvertible_base_of;
-if (RhsT->isVariableArrayType())
-  Self.Diag(Rhs->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
-  << 1 << tok::kw___is_pointer_interconvertible_base_of;
+DiagnoseVLAInCXXTypeTrait(Self, Lhs,
+  tok::kw___is_pointer_interconvertible_base_of);
+DiagnoseVLAInCXXTypeTrait(Self, Rhs,
+  tok::kw___is_pointer_interconvertible_base_of);
 
 return 

[clang] [clang] Fix name conflict with `sys/mac.h` on AIX (PR #88644)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll updated 
https://github.com/llvm/llvm-project/pull/88644

>From 9d46b1ed31d2acbb772f9bb4b139fa1ec36a65ab Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Sun, 14 Apr 2024 08:46:27 +0300
Subject: [PATCH] [clang] Fix name conflict with `sys/mac.h` on AIX

Fixes clang-ppc64-aix bot failure after #88559 
(0a6f6df5b0c3d0f2a42f013bf5cafb9b5020dcac) 
https://lab.llvm.org/buildbot/#/builders/214/builds/11887
---
 clang/include/clang/Basic/Cuda.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/clang/include/clang/Basic/Cuda.h b/clang/include/clang/Basic/Cuda.h
index acc6bb6581d857..3908e10bc61061 100644
--- a/clang/include/clang/Basic/Cuda.h
+++ b/clang/include/clang/Basic/Cuda.h
@@ -50,6 +50,11 @@ const char *CudaVersionToString(CudaVersion V);
 // Input is "Major.Minor"
 CudaVersion CudaStringToVersion(const llvm::Twine );
 
+// We have a name conflict with sys/mac.h on AIX
+#ifdef _AIX
+#undef SM_32
+#endif
+
 enum class CudaArch {
   UNUSED,
   UNKNOWN,

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix name conflict with `sys/mac.h` on AIX (PR #88644)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll closed 
https://github.com/llvm/llvm-project/pull/88644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][NFC] Factor out VLA checks in type traits (PR #88646)

[Vlad Serebrennikov via cfe-commits]

@@ -5012,6 +5012,20 @@ Sema::PerformImplicitConversion(Expr *From, QualType 
ToType,
   return From;
 }
 
+/// Checks that type T is not a VLA.
+///
+/// @returns @c true if @p T is VLA and a diagnostic was emitted,
+/// @c false otherwise.
+static bool DiagnoseVLAInCXXTypeTrait(Sema , const TypeSourceInfo *T,

Endilll wrote:

I don't have a strong opinion on this. Just followed what Corentin suggested.

https://github.com/llvm/llvm-project/pull/88646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Introduce `SemaOpenMP` (PR #88642)

[Vlad Serebrennikov via cfe-commits]

@@ -997,6 +987,11 @@ class Sema final : public SemaBase {
 return *OpenACCPtr;
   }
 
+  SemaOpenMP () {

Endilll wrote:

This was discussed back when we started splitting `Sema` up: 
https://github.com/llvm/llvm-project/pull/84184#discussion_r1520027821. We can 
reopen the discussion if you insist, otherwise I'd like to keep it consistent 
with CUDA, HLSL, etc.

https://github.com/llvm/llvm-project/pull/88642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Introduce `SemaCUDA` (PR #88559)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

I think I exposed a name conflict with a system header on AIX by including 
`Cuda.h` in `Sema.h`. Given that this name conflict potentially affects both 
enum definition and its usage, how should we resolve this?

https://github.com/llvm/llvm-project/pull/88559
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][NFC] Factor out VLA checks in type traits (PR #88646)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll closed 
https://github.com/llvm/llvm-project/pull/88646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Introduce `SemaOpenMP` (PR #88642)

[Vlad Serebrennikov via cfe-commits]

@@ -11,6 +11,7 @@
 ///
 
//===--===//
 
+#include "clang/Sema/SemaOpenMP.h"

Endilll wrote:

Main module header goes first per our coding standard: 
https://llvm.org/docs/CodingStandards.html#include-style

https://github.com/llvm/llvm-project/pull/88642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Introduce `SemaOpenMP` (PR #88642)

[Vlad Serebrennikov via cfe-commits]

@@ -997,6 +987,11 @@ class Sema final : public SemaBase {
 return *OpenACCPtr;
   }
 
+  SemaOpenMP () {
+assert(OpenMPPtr);

Endilll wrote:

Done

https://github.com/llvm/llvm-project/pull/88642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Allow the value of unroll count to be zero in `#pragma GCC unroll` and `#pragma unroll` (PR #88666)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

`Sema.h` changes look good.

https://github.com/llvm/llvm-project/pull/88666
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Introduce `SemaOpenMP` (PR #88642)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll closed 
https://github.com/llvm/llvm-project/pull/88642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][NFC] Move more functions to `SemaHLSL` (PR #88354)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll created 
https://github.com/llvm/llvm-project/pull/88354

A follow-up to #87912. I'm moving more HLSL-related functions from `Sema` to 
`SemaHLSL`. I'm also dropping `HLSL` from their names in the process.

>From ecff8db824552872ba055fdc0bca42b1a0386c39 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Thu, 11 Apr 2024 07:56:46 +0300
Subject: [PATCH] [clang][NFC] Move more functions to `SemaHLSL`

---
 clang/include/clang/Sema/Sema.h |  15 ---
 clang/include/clang/Sema/SemaHLSL.h |  27 +++-
 clang/lib/Parse/ParseHLSL.cpp   |  10 +-
 clang/lib/Sema/SemaDecl.cpp | 130 +--
 clang/lib/Sema/SemaDeclAttr.cpp |  54 +---
 clang/lib/Sema/SemaHLSL.cpp | 186 +++-
 6 files changed, 218 insertions(+), 204 deletions(-)

diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index e3e255a0dd76f8..e904cd3ad13fb7 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -2940,13 +2940,6 @@ class Sema final : public SemaBase {
   QualType NewT, QualType OldT);
   void CheckMain(FunctionDecl *FD, const DeclSpec );
   void CheckMSVCRTEntryPoint(FunctionDecl *FD);
-  void ActOnHLSLTopLevelFunction(FunctionDecl *FD);
-  void CheckHLSLEntryPoint(FunctionDecl *FD);
-  void CheckHLSLSemanticAnnotation(FunctionDecl *EntryPoint, const Decl *Param,
-   const HLSLAnnotationAttr *AnnotationAttr);
-  void DiagnoseHLSLAttrStageMismatch(
-  const Attr *A, HLSLShaderAttr::ShaderType Stage,
-  std::initializer_list AllowedStages);
   Attr *getImplicitCodeSegOrSectionAttrForFunction(const FunctionDecl *FD,
bool IsDefinition);
   void CheckFunctionOrTemplateParamDeclarator(Scope *S, Declarator );
@@ -3707,14 +3700,6 @@ class Sema final : public SemaBase {
   StringRef UuidAsWritten, MSGuidDecl *GuidDecl);
 
   BTFDeclTagAttr *mergeBTFDeclTagAttr(Decl *D, const BTFDeclTagAttr );
-  HLSLNumThreadsAttr *mergeHLSLNumThreadsAttr(Decl *D,
-  const AttributeCommonInfo ,
-  int X, int Y, int Z);
-  HLSLShaderAttr *mergeHLSLShaderAttr(Decl *D, const AttributeCommonInfo ,
-  HLSLShaderAttr::ShaderType ShaderType);
-  HLSLParamModifierAttr *
-  mergeHLSLParamModifierAttr(Decl *D, const AttributeCommonInfo ,
- HLSLParamModifierAttr::Spelling Spelling);
 
   WebAssemblyImportNameAttr *
   mergeImportNameAttr(Decl *D, const WebAssemblyImportNameAttr );
diff --git a/clang/include/clang/Sema/SemaHLSL.h 
b/clang/include/clang/Sema/SemaHLSL.h
index acc675963c23a5..34acaf19517f2a 100644
--- a/clang/include/clang/Sema/SemaHLSL.h
+++ b/clang/include/clang/Sema/SemaHLSL.h
@@ -13,12 +13,16 @@
 #ifndef LLVM_CLANG_SEMA_SEMAHLSL_H
 #define LLVM_CLANG_SEMA_SEMAHLSL_H
 
+#include "clang/AST/Attr.h"
+#include "clang/AST/Decl.h"
 #include "clang/AST/DeclBase.h"
 #include "clang/AST/Expr.h"
+#include "clang/Basic/AttributeCommonInfo.h"
 #include "clang/Basic/IdentifierTable.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Sema/Scope.h"
 #include "clang/Sema/SemaBase.h"
+#include 
 
 namespace clang {
 
@@ -26,10 +30,25 @@ class SemaHLSL : public SemaBase {
 public:
   SemaHLSL(Sema );
 
-  Decl *ActOnStartHLSLBuffer(Scope *BufferScope, bool CBuffer,
- SourceLocation KwLoc, IdentifierInfo *Ident,
- SourceLocation IdentLoc, SourceLocation LBrace);
-  void ActOnFinishHLSLBuffer(Decl *Dcl, SourceLocation RBrace);
+  Decl *ActOnStartBuffer(Scope *BufferScope, bool CBuffer, SourceLocation 
KwLoc,
+ IdentifierInfo *Ident, SourceLocation IdentLoc,
+ SourceLocation LBrace);
+  void ActOnFinishBuffer(Decl *Dcl, SourceLocation RBrace);
+  HLSLNumThreadsAttr *mergeNumThreadsAttr(Decl *D,
+  const AttributeCommonInfo , int X,
+  int Y, int Z);
+  HLSLShaderAttr *mergeShaderAttr(Decl *D, const AttributeCommonInfo ,
+  HLSLShaderAttr::ShaderType ShaderType);
+  HLSLParamModifierAttr *
+  mergeParamModifierAttr(Decl *D, const AttributeCommonInfo ,
+ HLSLParamModifierAttr::Spelling Spelling);
+  void ActOnTopLevelFunction(FunctionDecl *FD);
+  void CheckEntryPoint(FunctionDecl *FD);
+  void CheckSemanticAnnotation(FunctionDecl *EntryPoint, const Decl *Param,
+   const HLSLAnnotationAttr *AnnotationAttr);
+  void DiagnoseAttrStageMismatch(
+  const Attr *A, HLSLShaderAttr::ShaderType Stage,
+  std::initializer_list AllowedStages);
 };
 
 } // namespace clang
diff --git a/clang/lib/Parse/ParseHLSL.cpp b/clang/lib/Parse/ParseHLSL.cpp
index 

[clang] [clang] Add test for CWG2149 "Brace elision and array length deduction" (PR #90079)

[Vlad Serebrennikov via cfe-commits]

@@ -0,0 +1,77 @@
+// RUN: %clang_cc1 -std=c++98 -triple x86_64-unknown-unknown %s 
-verify=expected,cxx98 -fexceptions -fcxx-exceptions -pedantic-errors -ast-dump 
| FileCheck %s --check-prefixes CXX98
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+// RUN: %clang_cc1 -std=c++17 -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+// RUN: %clang_cc1 -std=c++20 -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+// RUN: %clang_cc1 -std=c++23 -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+// RUN: %clang_cc1 -std=c++2c -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+
+#if __cplusplus == 199711L
+#define static_assert(...) __extension__ _Static_assert(__VA_ARGS__)
+// cxx98-error@-1 {{variadic macros are a C99 feature}}
+#endif
+
+namespace cwg2149 { // cwg2149: 3.1 drafting 2024-04

Endilll wrote:

The root cause of your confusion is the same as in the other comment you left. 
Responded there.

https://github.com/llvm/llvm-project/pull/90079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Enable C++17 relaxed template template argument matching by default (PR #89807)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll requested changes to this pull request.


https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Enable C++17 relaxed template template argument matching by default (PR #89807)

[Vlad Serebrennikov via cfe-commits]

@@ -0,0 +1,115 @@
+// RUN: %clang_cc1 %s -fsyntax-only -std=c++23 
-verify=expected,new
+// RUN: %clang_cc1 %s -fsyntax-only -std=c++23 
-fno-relaxed-template-template-args -verify=expected,old

Endilll wrote:

We don't test non-conforming modes of operation in DR test suite.
This should be tested elsewhere, e.g. in SemaTemplate tests.

https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Enable C++17 relaxed template template argument matching by default (PR #89807)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll edited 
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Enable C++17 relaxed template template argument matching by default (PR #89807)

[Vlad Serebrennikov via cfe-commits]

@@ -0,0 +1,115 @@
+// RUN: %clang_cc1 %s -fsyntax-only -std=c++23 
-verify=expected,new

Endilll wrote:

Why only C++23 is tested? DR tests should test all language modes.

https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Enable C++17 relaxed template template argument matching by default (PR #89807)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll edited 
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Enable C++17 relaxed template template argument matching by default (PR #89807)

[Vlad Serebrennikov via cfe-commits]

@@ -0,0 +1,115 @@
+// RUN: %clang_cc1 %s -fsyntax-only -std=c++23 
-verify=expected,new
+// RUN: %clang_cc1 %s -fsyntax-only -std=c++23 
-fno-relaxed-template-template-args -verify=expected,old

Endilll wrote:

> Since the core issue is not resolved by WG21, I don't want to claim to be 
> resolving it here with this patch.

It'd be far from the first time we're testing an issue that is still open 
(https://github.com/llvm/llvm-project/blob/bd53c7cce418fe7f3e171859d4718df15d03dc2b/clang/test/CXX/drs/dr24xx.cpp#L62),
 but the fact that 2398 filing lacks any possible resolution that we can be 
testing against, it complicates the matter.

https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add test for CWG2149 "Brace elision and array length deduction" (PR #90079)

[Vlad Serebrennikov via cfe-commits]

@@ -12702,7 +12702,7 @@ C++ defect report implementation 
status
 https://cplusplus.github.io/CWG/issues/2149.html;>2149
 drafting
 Brace elision and array length deduction
-Not resolved
+Not 
Resolved*

Endilll wrote:

As I mentioned in 
https://github.com/llvm/llvm-project/pull/90079#issuecomment-2077691304, CWG 
index page that we fetch from is not updated yet. I checked with CWG chair 
regarding most up-to-date source of CWG issue status, and I'll prepare an 
update to `make_cxx_dr_status` script to reduce amount of confusions like this 
one.

https://github.com/llvm/llvm-project/pull/90079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Enable C++17 relaxed template template argument matching by default (PR #89807)

[Vlad Serebrennikov via cfe-commits]

@@ -0,0 +1,115 @@
+// RUN: %clang_cc1 %s -fsyntax-only -std=c++23 
-verify=expected,new
+// RUN: %clang_cc1 %s -fsyntax-only -std=c++23 
-fno-relaxed-template-template-args -verify=expected,old

Endilll wrote:

Given that you're fixing CWG2398, you should be adding a test here to update 
https://clang.llvm.org/cxx_dr_status.html. This corner of our test suite lives 
by its own rules to some extent, so you should stay consistent with 700 tests 
we already have.

https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][HLSL] Add environment parameter to availability attribute (PR #89809)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

`Sema.h` changes look good.

https://github.com/llvm/llvm-project/pull/89809
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] MangledSymbol: remove pointless copy of vector (PR #90012)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

@shafik I wonder how checking size of a vector is now considered an expensive 
check.
(I stumbled upon it while reviewing)
https://github.com/llvm/llvm-project/blob/47682e4b4a0c8e7637d65868a7208aa6806a50f4/clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp#L99-L101

https://github.com/llvm/llvm-project/pull/90012
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] MangledSymbol: remove pointless copy of vector (PR #90012)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll approved this pull request.

Thank you for spotting and fixing this!

https://github.com/llvm/llvm-project/pull/90012
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -444,53 +435,57 @@ For example, the following example is allowed:
   # Inconsistent debugging level.
   $ clang++ -std=c++20 -g Use.cpp -fprebuilt-module-path=.
 
-Although the two examples have inconsistent optimization and debugging level, 
both of them are accepted.
+Although the optimization and debugging levels are inconsistent, these
+compilations are accepted because the compiler options do not impact the
+language dialect.
 
-Note that **currently** the compiler doesn't consider inconsistent macro 
definition a problem. For example:
+Note that the compiler **currently** doesn't reject inconsistent macro
+definitions (this may change in the future). For example:
 
 .. code-block:: console
 
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm
   # Inconsistent optimization level.
   $ clang++ -std=c++20 -O3 -DNDEBUG Use.cpp -fprebuilt-module-path=.
 
-Currently Clang would accept the above example. But it may produce surprising 
results if the
-debugging code depends on consistent use of ``NDEBUG`` also in other 
translation units.
-
-Definitions consistency
-^^^
-
-The C++ language defines that same declarations in different translation units 
should have
-the same definition, as known as ODR (One Definition Rule). Prior to modules, 
the translation
-units don't dependent on each other and the compiler itself can't perform a 
strong
-ODR violation check. With the introduction of modules, now the compiler have
-the chance to perform ODR violations with language semantics across 
translation units.
-
-However, in the practice, we found the existing ODR checking mechanism is not 
stable
-enough. Many people suffers from the false positive ODR violation diagnostics, 
AKA,
-the compiler are complaining two identical declarations have different 
definitions
-incorrectly. Also the true positive ODR violations are rarely reported.
-Also we learned that MSVC don't perform ODR check for declarations in the 
global module
-fragment.
-
-So in order to get better user experience, save the time checking ODR and keep 
consistent
-behavior with MSVC, we disabled the ODR check for the declarations in the 
global module
-fragment by default. Users who want more strict check can still use the
-``-Xclang -fno-skip-odr-check-in-gmf`` flag to get the ODR check enabled. It 
is also
-encouraged to report issues if users find false positive ODR violations or 
false negative ODR
-violations with the flag enabled.
+Currently, Clang accepts the above example though it may produce surprising
+results if the debugging code depends on consistent use of ``NDEBUG`` in other
+translation units.
+
+Object definition consistency
+^
+
+The C++ language requires that the same declarations in different translation
+units have the same definition, which is known as the One Definition Rule 
(ODR).
+Prior to modules, the compiler cannot perform strong ODR violation checking
+because it only sees one translation unit at a time. With use of modules, the

Endilll wrote:

```suggestion
because it only sees one translation unit at a time. Now, with the use of 
modules, the
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -312,75 +300,76 @@ So all of the following name is not valid by default:
 __test
 // and so on ...
 
-If you still want to use the reserved module names for any reason, use
-``-Wno-reserved-module-identifier`` to suppress the warning.
+Using a reserved module name is strongly discouraged, but
+``-Wno-reserved-module-identifier`` can be used to suppress the warning.
 
-How to specify the dependent BMIs
-~
+Specifying dependent BMIs
+~
 
-There are 3 methods to specify the dependent BMIs:
+There are 3 ways to specify a dependent BMI:
 
-* (1) ``-fprebuilt-module-path=``.
-* (2) ``-fmodule-file=`` (Deprecated).
-* (3) ``-fmodule-file==``.
+1. ``-fprebuilt-module-path=``.
+2. ``-fmodule-file=`` (Deprecated).
+3. ``-fmodule-file==``.
 
-The option ``-fprebuilt-module-path`` tells the compiler the path where to 
search for dependent BMIs.
-It may be used multiple times just like ``-I`` for specifying paths for header 
files. The look up rule here is:
+The ``-fprebuilt-module-path`` option specifies the path to search for
+dependent BMIs. Multiple paths may be specified, similar to using ``-I`` to
+specify a search path for header files. When importing a module ``M``, the
+compiler looks for ``M.pcm`` in the directories specified by
+``-fprebuilt-module-path``. Similarly,  When importing a partition module unit

Endilll wrote:

```suggestion
``-fprebuilt-module-path``. Similarly, when importing a partition module unit
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -444,53 +435,57 @@ For example, the following example is allowed:
   # Inconsistent debugging level.
   $ clang++ -std=c++20 -g Use.cpp -fprebuilt-module-path=.
 
-Although the two examples have inconsistent optimization and debugging level, 
both of them are accepted.
+Although the optimization and debugging levels are inconsistent, these
+compilations are accepted because the compiler options do not impact the
+language dialect.
 
-Note that **currently** the compiler doesn't consider inconsistent macro 
definition a problem. For example:
+Note that the compiler **currently** doesn't reject inconsistent macro
+definitions (this may change in the future). For example:
 
 .. code-block:: console
 
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm
   # Inconsistent optimization level.
   $ clang++ -std=c++20 -O3 -DNDEBUG Use.cpp -fprebuilt-module-path=.
 
-Currently Clang would accept the above example. But it may produce surprising 
results if the
-debugging code depends on consistent use of ``NDEBUG`` also in other 
translation units.
-
-Definitions consistency
-^^^
-
-The C++ language defines that same declarations in different translation units 
should have
-the same definition, as known as ODR (One Definition Rule). Prior to modules, 
the translation
-units don't dependent on each other and the compiler itself can't perform a 
strong
-ODR violation check. With the introduction of modules, now the compiler have
-the chance to perform ODR violations with language semantics across 
translation units.
-
-However, in the practice, we found the existing ODR checking mechanism is not 
stable
-enough. Many people suffers from the false positive ODR violation diagnostics, 
AKA,
-the compiler are complaining two identical declarations have different 
definitions
-incorrectly. Also the true positive ODR violations are rarely reported.
-Also we learned that MSVC don't perform ODR check for declarations in the 
global module
-fragment.
-
-So in order to get better user experience, save the time checking ODR and keep 
consistent
-behavior with MSVC, we disabled the ODR check for the declarations in the 
global module
-fragment by default. Users who want more strict check can still use the
-``-Xclang -fno-skip-odr-check-in-gmf`` flag to get the ODR check enabled. It 
is also
-encouraged to report issues if users find false positive ODR violations or 
false negative ODR
-violations with the flag enabled.
+Currently, Clang accepts the above example though it may produce surprising
+results if the debugging code depends on consistent use of ``NDEBUG`` in other
+translation units.
+
+Object definition consistency
+^
+
+The C++ language requires that the same declarations in different translation
+units have the same definition, which is known as the One Definition Rule 
(ODR).
+Prior to modules, the compiler cannot perform strong ODR violation checking
+because it only sees one translation unit at a time. With use of modules, the
+compiler can perform checks for ODR violations across translation units.
+
+However, the current ODR checking mechanisms are not perfect. There are a
+significant number of false positive ODR violation diagnostics, where the
+compiler incorrectly diagnoses two identical declarations as having different
+definitions. Further, true positive ODR violations are not always reported.
+Additionally, MSVC does not currently perform ODR checking for declarations in
+the global module fragment.
+
+To give a better user experience, improve compilation performance, and for
+consistentency with MSVC, ODR checking of declarations in the global module
+fragment is disabled by default. These checks can be enabled by specifying
+``-Xclang -fno-skip-odr-check-in-gmf`` when compiling. If the check is enabled
+and you encounter incorrect or missing diagnostics, please report them via the
+`community issue tracker `_.
 
 ABI Impacts
 ---
 
-This section describes the new ABI changes brought by modules.
-
-Only Itanium C++ ABI related change are mentioned
+This section describes the new ABI changes brought by modules. Only Itanium C++
+ABI related change are mentioned.

Endilll wrote:

"Only changes to Itanium C++ ABI are covered."

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -8,79 +8,60 @@ Standard C++ Modules
 Introduction
 
 
-The term ``modules`` has a lot of meanings. For the users of Clang, modules may
-refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header 
Modules``,
-etc.) or ``Standard C++ Modules``. The implementation of all these kinds of 
modules in Clang
-has a lot of shared code, but from the perspective of users, their semantics 
and
-command line interfaces are very different. This document focuses on
-an introduction of how to use standard C++ modules in Clang.
-
-There is already a detailed document about `Clang modules `_, it
-should be helpful to read `Clang modules `_ if you want to know
-more about the general idea of modules. Since standard C++ modules have 
different semantics
-(and work flows) from `Clang modules`, this page describes the background and 
use of
-Clang with standard C++ modules.
-
-Modules exist in two forms in the C++ Language Specification. They can refer to
-either "Named Modules" or to "Header Units". This document covers both forms.
+The term ``modules`` has a lot of meanings. For Clang users, modules may refer
+to ``Objective-C Modules``, `Clang Modules `_ (also called
+``Clang Header Modules``, etc.) or ``C++20 Modules`` (or
+``Standard C++ Modules``). The implementation of all these kinds of modules in
+Clang shares a lot of code, but from the perspective of users, their semantics
+and command line interfaces are very different. This document focuses on an
+introduction of focusing on the use of C++20 modules in Clang. In the remainder
+of this document, the term ``modules`` will refer to Standard C++20 modules and
+the term ``Clang modules`` will refer to the Clang modules extension.
+
+Modules exist in two forms in the C++ Standard. They can refer to either
+"Named Modules" or "Header Units". This document covers both forms.
 
 Standard C++ Named modules
 ==
 
-This document was intended to be a manual first and foremost, however, we 
consider it helpful to
-introduce some language background here for readers who are not familiar with
-the new language feature. This document is not intended to be a language
-tutorial; it will only introduce necessary concepts about the
-structure and building of the project.
+In order to understand compiler behavior, it is helpful to introduce some
+language background here for readers who are not familiar with the C++ feature.
+This document is not a tutorial on C++; it only introduces necessary concepts
+to better understand use of modules for a project.
 
 Background and terminology
 --
 
-Modules
-~~~
-
-In this document, the term ``Modules``/``modules`` refers to standard C++ 
modules
-feature if it is not decorated by ``Clang``.
-
-Clang Modules
-~
-
-In this document, the term ``Clang Modules``/``Clang modules`` refer to Clang
-c++ modules extension. These are also known as ``Clang header modules``,
-``Clang module map modules`` or ``Clang c++ modules``.
-
 Module and module unit
 ~~
 
-A module consists of one or more module units. A module unit is a special
-translation unit. Every module unit must have a module declaration. The syntax
-of the module declaration is:
+A module consists of one or more module units. A module unit is a special kind
+of translation unit. Every module unit must have a module declaration. The
+syntax of the module declaration is:
 
 .. code-block:: c++
 
   [export] module module_name[:partition_name];
 
-Terms enclosed in ``[]`` are optional. The syntax of ``module_name`` and 
``partition_name``
-in regex form corresponds to ``[a-zA-Z_][a-zA-Z_0-9\.]*``. In particular, a 
literal dot ``.``
-in the name has no semantic meaning (e.g. implying a hierarchy).
-
-In this document, module units are classified into:
-
-* Primary module interface unit.
-
-* Module implementation unit.
+Terms enclosed in ``[]`` are optional. ``module_name`` and ``partition_name``
+are typical C++ identifiers, except that they may contain a period (``.``).
+Note that a ``.`` in the name has no semantic meaning (e.g. implying a
+hierarchy).

Endilll wrote:

```suggestion
hierarchy or referring to the file system).
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -444,53 +435,57 @@ For example, the following example is allowed:
   # Inconsistent debugging level.
   $ clang++ -std=c++20 -g Use.cpp -fprebuilt-module-path=.
 
-Although the two examples have inconsistent optimization and debugging level, 
both of them are accepted.
+Although the optimization and debugging levels are inconsistent, these
+compilations are accepted because the compiler options do not impact the
+language dialect.
 
-Note that **currently** the compiler doesn't consider inconsistent macro 
definition a problem. For example:
+Note that the compiler **currently** doesn't reject inconsistent macro
+definitions (this may change in the future). For example:
 
 .. code-block:: console
 
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm
   # Inconsistent optimization level.
   $ clang++ -std=c++20 -O3 -DNDEBUG Use.cpp -fprebuilt-module-path=.
 
-Currently Clang would accept the above example. But it may produce surprising 
results if the
-debugging code depends on consistent use of ``NDEBUG`` also in other 
translation units.
-
-Definitions consistency
-^^^
-
-The C++ language defines that same declarations in different translation units 
should have
-the same definition, as known as ODR (One Definition Rule). Prior to modules, 
the translation
-units don't dependent on each other and the compiler itself can't perform a 
strong
-ODR violation check. With the introduction of modules, now the compiler have
-the chance to perform ODR violations with language semantics across 
translation units.
-
-However, in the practice, we found the existing ODR checking mechanism is not 
stable
-enough. Many people suffers from the false positive ODR violation diagnostics, 
AKA,
-the compiler are complaining two identical declarations have different 
definitions
-incorrectly. Also the true positive ODR violations are rarely reported.
-Also we learned that MSVC don't perform ODR check for declarations in the 
global module
-fragment.
-
-So in order to get better user experience, save the time checking ODR and keep 
consistent
-behavior with MSVC, we disabled the ODR check for the declarations in the 
global module
-fragment by default. Users who want more strict check can still use the
-``-Xclang -fno-skip-odr-check-in-gmf`` flag to get the ODR check enabled. It 
is also
-encouraged to report issues if users find false positive ODR violations or 
false negative ODR
-violations with the flag enabled.
+Currently, Clang accepts the above example though it may produce surprising
+results if the debugging code depends on consistent use of ``NDEBUG`` in other
+translation units.
+
+Object definition consistency
+^
+
+The C++ language requires that the same declarations in different translation
+units have the same definition, which is known as the One Definition Rule 
(ODR).
+Prior to modules, the compiler cannot perform strong ODR violation checking
+because it only sees one translation unit at a time. With use of modules, the
+compiler can perform checks for ODR violations across translation units.
+
+However, the current ODR checking mechanisms are not perfect. There are a
+significant number of false positive ODR violation diagnostics, where the
+compiler incorrectly diagnoses two identical declarations as having different
+definitions. Further, true positive ODR violations are not always reported.
+Additionally, MSVC does not currently perform ODR checking for declarations in

Endilll wrote:

```suggestion
It's worth noting that MSVC does not currently perform ODR checking for 
declarations in
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -8,79 +8,60 @@ Standard C++ Modules
 Introduction
 
 
-The term ``modules`` has a lot of meanings. For the users of Clang, modules may
-refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header 
Modules``,
-etc.) or ``Standard C++ Modules``. The implementation of all these kinds of 
modules in Clang
-has a lot of shared code, but from the perspective of users, their semantics 
and
-command line interfaces are very different. This document focuses on
-an introduction of how to use standard C++ modules in Clang.
-
-There is already a detailed document about `Clang modules `_, it
-should be helpful to read `Clang modules `_ if you want to know
-more about the general idea of modules. Since standard C++ modules have 
different semantics
-(and work flows) from `Clang modules`, this page describes the background and 
use of
-Clang with standard C++ modules.
-
-Modules exist in two forms in the C++ Language Specification. They can refer to
-either "Named Modules" or to "Header Units". This document covers both forms.
+The term ``modules`` has a lot of meanings. For Clang users, modules may refer

Endilll wrote:

It feels strange to define a term in plural form while singular is available 
and fits nicely.

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -925,45 +923,41 @@ In that case, you need to convert your source files (.cpp 
files) to module imple
   // Following off should be unchanged.
   ...
 
-The module implementation unit will import the primary module implicitly.
-We don't include any headers in the module implementation units
-here since we want to avoid duplicated declarations between translation units.
-This is the reason why we add non-exported using declarations from the third
-party libraries in the primary module interface unit.
+The module implementation unit will import the primary module implicitly. Do
+not include any headers in the module implementation units because that avoids
+duplicated declarations between translation units. This is why non-exported
+using declarations are added from third-party libraries in the primary module
+interface unit.
 
-And if you provide your library as ``libyour_library.so``, you probably need to
-provide a modular one ``libyour_library_modules.so`` since you changed the ABI.
+If the library is provided as ``libyour_library.so``, a modular library (e.g.,
+``libyour_library_modules.so``) may also need to be provided for ABI
+compatibility.
 
 What if there are headers only inclued by the source files
 ^^
 
-The above practice may be problematic if there are headers only included by 
the source
-files. If you're using private module fragment, you may solve the issue by 
including them
-in the private module fragment. While it is OK to solve it by including the 
implementation
-headers in the module purview if you're using implementation module units, it 
may be
-suboptimal since the primary module interface units now containing entities 
not belongs
-to the interface.
-
-If you're a perfectionist, maybe you can improve it by introducing internal 
module partition unit.
+The above practice may be problematic if there are headers only included by the
+source files. If using a private module fragment, this issue may be solved by

Endilll wrote:

```suggestion
source files. When using a private module fragment, this issue may be solved by
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -432,9 +424,8 @@ The following example is not allowed:
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm
   $ clang++ -std=c++23 Use.cpp -fprebuilt-module-path=.
 
-The compiler would reject the example due to the inconsistent language options.
-Not all options are language options.
-For example, the following example is allowed:
+Clang rejects the example due to the inconsistent language standard modes. Not
+all compiler options are language dialect options. For example:

Endilll wrote:

```suggestion
all compiler options are language dialect options, though. For example:
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -776,9 +773,9 @@ export-using style
 using decl_n;
   }
 
-As the example shows, you need to include all the headers containing 
declarations needs
-to be exported and `using` such declarations in an `export` block. Then, 
basically,
-we're done.
+This example shows how to include all the headers containing declarations which
+need to be exported and uses `using` declarations in an `export` block to
+produce the module interface. Then, basically, we're done.

Endilll wrote:

```suggestion
produce the module interface.
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -1817,27 +1804,29 @@ But with optimizations, things are different:
 │   │
 └---┘
 
-It would be very unfortunate if we end up with worse performance after using 
modules.
-The main concern is that when we compile a source file, the compiler needs to 
see the function body
-of imported module units so that it can perform IPO (InterProcedural 
Optimization, primarily inlining
-in practice) to optimize functions in current source file with the help of the 
information provided by
-the imported module units.
-In other words, the imported code would be processed again and again in 
importee units
-by optimizations (including IPO itself).
-The optimizations before IPO and the IPO itself are the most time-consuming 
part in whole compilation process.
-So from this perspective, we might not be able to get the improvements 
described in the theory.
-But we could still save the time for optimizations after IPO and the whole 
backend.
-
-Overall, at ``O0`` the implementations of functions defined in a module will 
not impact module users,
-but at higher optimization levels the definitions of such functions are 
provided to user compilations for the
-purposes of optimization (but definitions of these functions are still not 
included in the use's object file)-
-this means the build speedup at higher optimization levels may be lower than 
expected given ``O0`` experience,
-but does provide by more optimization opportunities.
+It would be very unfortunate if we end up with worse performance when using
+modules. The main concern is that when a source file is compiled, the compiler
+needs to see the body of imported module units so that it can perform IPO
+(InterProcedural Optimization, primarily inlining in practice) to optimize
+functions in the current source file with the help of the information provided
+by the imported module units. In other words, the imported code would be
+processed again and again in importee units by optimizations (including IPO
+itself). The optimizations before IPO and IPO itself are the most 
time-consuming
+part in whole compilation process. So from this perspective, it might not be
+possible to get the compile time improvements described in the theory, but
+there could be time savings for optimizations after IPO and the whole backend.
+
+Overall, at ``-O0`` the implementations of functions defined in a module will
+not impact module users, but at higher optimization levels the definitions of
+such functions are provided to user compilations for the purposes of
+optimization (but definitions of these functions are still not included in the
+use's object file) -- this means the build speedup at higher optimization

Endilll wrote:

```suggestion
use's object file). This means the build speedup at higher optimization
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -444,53 +435,57 @@ For example, the following example is allowed:
   # Inconsistent debugging level.
   $ clang++ -std=c++20 -g Use.cpp -fprebuilt-module-path=.
 
-Although the two examples have inconsistent optimization and debugging level, 
both of them are accepted.
+Although the optimization and debugging levels are inconsistent, these
+compilations are accepted because the compiler options do not impact the
+language dialect.
 
-Note that **currently** the compiler doesn't consider inconsistent macro 
definition a problem. For example:
+Note that the compiler **currently** doesn't reject inconsistent macro
+definitions (this may change in the future). For example:
 
 .. code-block:: console
 
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm
   # Inconsistent optimization level.
   $ clang++ -std=c++20 -O3 -DNDEBUG Use.cpp -fprebuilt-module-path=.
 
-Currently Clang would accept the above example. But it may produce surprising 
results if the
-debugging code depends on consistent use of ``NDEBUG`` also in other 
translation units.
-
-Definitions consistency
-^^^
-
-The C++ language defines that same declarations in different translation units 
should have
-the same definition, as known as ODR (One Definition Rule). Prior to modules, 
the translation
-units don't dependent on each other and the compiler itself can't perform a 
strong
-ODR violation check. With the introduction of modules, now the compiler have
-the chance to perform ODR violations with language semantics across 
translation units.
-
-However, in the practice, we found the existing ODR checking mechanism is not 
stable
-enough. Many people suffers from the false positive ODR violation diagnostics, 
AKA,
-the compiler are complaining two identical declarations have different 
definitions
-incorrectly. Also the true positive ODR violations are rarely reported.
-Also we learned that MSVC don't perform ODR check for declarations in the 
global module
-fragment.
-
-So in order to get better user experience, save the time checking ODR and keep 
consistent
-behavior with MSVC, we disabled the ODR check for the declarations in the 
global module
-fragment by default. Users who want more strict check can still use the
-``-Xclang -fno-skip-odr-check-in-gmf`` flag to get the ODR check enabled. It 
is also
-encouraged to report issues if users find false positive ODR violations or 
false negative ODR
-violations with the flag enabled.
+Currently, Clang accepts the above example though it may produce surprising
+results if the debugging code depends on consistent use of ``NDEBUG`` in other
+translation units.
+
+Object definition consistency
+^
+
+The C++ language requires that the same declarations in different translation
+units have the same definition, which is known as the One Definition Rule 
(ODR).
+Prior to modules, the compiler cannot perform strong ODR violation checking

Endilll wrote:

```suggestion
Prior to modules, the compiler wasn't able to perform strong ODR violation 
checking
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -633,36 +631,36 @@ example:
   // module M's interface, so is discarded
   int c = use_h();   // OK
 
-In the above example, the function definition of ``N::g`` is elided from the 
Reduced
-BMI of ``M.cppm``. Then the use of ``use_g`` in ``M-impl.cpp`` fails
-to instantiate. For such issues, users can add references to ``N::g`` in the 
module purview
-of ``M.cppm`` to make sure it is reachable, e.g., ``using N::g;``.
-
-We think the Reduced BMI is the correct direction. But given it is a drastic 
change,
-we'd like to make it experimental first to avoid breaking existing users. The 
roadmap
-of Reduced BMI may be:
-
-1. ``-fexperimental-modules-reduced-bmi`` is opt in for 1~2 releases. The 
period depends
-on testing feedbacks.
-2. We would announce Reduced BMI is not experimental and introduce 
``-fmodules-reduced-bmi``.
-and suggest users to enable this mode. This may takes 1~2 releases too.
-3. Finally we will enable this by default. When that time comes, the term BMI 
will refer to
-the reduced BMI today and the Full BMI will only be meaningful to build 
systems which
-loves to support two phase compilations.
+In the above example, the function definition of ``N::g`` is elided from the
+Reduced BMI of ``M.cppm``. Then the use of ``use_g`` in ``M-impl.cpp``
+fails to instantiate. For such issues, users can add references to ``N::g`` in
+the module purview of ``M.cppm`` to ensure it is reachable, e.g.,
+``using N::g;``.
+
+Long-term, Clang is likely to make Reduced BMIs the default rather than Full
+BMIs. But because it is a drastic change, it is initially an experimental
+option to avoid breaking existing users. The expected roadmap for Reduced BMIs
+as of Clang 19.x is:
+
+1. ``-fexperimental-modules-reduced-bmi`` is opt-in for 1~2 releases. The 
period depends
+   on user feedback and may be extended.
+2. Announce that Reduced BMIs are no longer experimental and introduce
+   ``-fmodules-reduced-bmi`` as a new option, and recommend use of the new
+   option. This transition is expected to take 1~2 additional releases as well.
+3. Finally, ``-fmodules-reduced-bmi`` will be the default. When that time
+   comes, the term BMI will refer to the reduced BMI and the Full BMI will only

Endilll wrote:

```suggestion
   comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -633,36 +631,36 @@ example:
   // module M's interface, so is discarded
   int c = use_h();   // OK
 
-In the above example, the function definition of ``N::g`` is elided from the 
Reduced
-BMI of ``M.cppm``. Then the use of ``use_g`` in ``M-impl.cpp`` fails
-to instantiate. For such issues, users can add references to ``N::g`` in the 
module purview
-of ``M.cppm`` to make sure it is reachable, e.g., ``using N::g;``.
-
-We think the Reduced BMI is the correct direction. But given it is a drastic 
change,
-we'd like to make it experimental first to avoid breaking existing users. The 
roadmap
-of Reduced BMI may be:
-
-1. ``-fexperimental-modules-reduced-bmi`` is opt in for 1~2 releases. The 
period depends
-on testing feedbacks.
-2. We would announce Reduced BMI is not experimental and introduce 
``-fmodules-reduced-bmi``.
-and suggest users to enable this mode. This may takes 1~2 releases too.
-3. Finally we will enable this by default. When that time comes, the term BMI 
will refer to
-the reduced BMI today and the Full BMI will only be meaningful to build 
systems which
-loves to support two phase compilations.
+In the above example, the function definition of ``N::g`` is elided from the
+Reduced BMI of ``M.cppm``. Then the use of ``use_g`` in ``M-impl.cpp``
+fails to instantiate. For such issues, users can add references to ``N::g`` in
+the module purview of ``M.cppm`` to ensure it is reachable, e.g.,
+``using N::g;``.
+
+Long-term, Clang is likely to make Reduced BMIs the default rather than Full
+BMIs. But because it is a drastic change, it is initially an experimental
+option to avoid breaking existing users. The expected roadmap for Reduced BMIs
+as of Clang 19.x is:
+
+1. ``-fexperimental-modules-reduced-bmi`` is opt-in for 1~2 releases. The 
period depends
+   on user feedback and may be extended.
+2. Announce that Reduced BMIs are no longer experimental and introduce
+   ``-fmodules-reduced-bmi`` as a new option, and recommend use of the new
+   option. This transition is expected to take 1~2 additional releases as well.
+3. Finally, ``-fmodules-reduced-bmi`` will be the default. When that time
+   comes, the term BMI will refer to the reduced BMI and the Full BMI will only
+   be meaningful to build systems which elect to support two-phase compilation.
 
 Performance Tips
 
 
 Reduce duplications
 ~~~
 
-While it is legal to have duplicated declarations in the global module 
fragments
-of different module units, it is not free for clang to deal with the duplicated
-declarations. In other word, for a translation unit, it will compile slower if 
the
-translation unit itself and its importing module units contains a lot 
duplicated
-declarations.
-
-For example,
+While it is valid to have duplicated declarations in the global module 
fragments
+of different module units, it is not free for Clang to deal with the duplicated
+declarations. A translation unit will compile more slowly if it and its
+imported module units contain a lot of duplicated declarations. For example:

Endilll wrote:

"A translation unit will compile more slowly if there is a lot of duplicated 
declarations between the translation unit and modules it imports."

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll edited 
https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -400,24 +389,27 @@ And the compilation process for module units are like:
 mod1.cppm -> clang++ mod1.cppm ... -> mod1.pcm --,--> clang++ 
mod1.pcm ... -> mod1.o -+
 src2.cpp +> clang++ 
src2.cpp ---> src2.o -'
 
-As the diagrams show, we need to compile the BMI from module units to object 
files and link the object files.
-(But we can't do this for the BMI from header units. See the later section for 
the definition of header units)
+As the diagrams show, we need to compile the BMI from module units to object
+files and then link the object files. (However, we can't do this for the BMI
+from header units. See the section on :ref:`header units ` for
+more details.
 
-If we want to create a module library, we can't just ship the BMIs in an 
archive.
-We must compile these BMIs(``*.pcm``) into object files(``*.o``) and add those 
object files to the archive instead.
+BMIs cannot be shipped in an archive to create a module library. Instead, the
+BMIs(``*.pcm``) are compiled into object files(``*.o``) and those object files
+are added to the archive instead.
 
-Consistency Requirement
-~~~
+Consistency Requirements
+
 
-If we envision modules as a cache to speed up compilation, then - as with 
other caching techniques -
-it is important to keep cache consistency.
-So **currently** Clang will do very strict check for consistency.
+If modules are thought of as a kind of cache to speed up compilation, then, as
+with other caching techniques, it is important to keep cache consistency.
+**Currently**, Clang does very strict checking for consistency.

Endilll wrote:

```suggestion
**Currently**, Clang does very strict checking for that.
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -8,79 +8,60 @@ Standard C++ Modules
 Introduction
 
 
-The term ``modules`` has a lot of meanings. For the users of Clang, modules may
-refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header 
Modules``,
-etc.) or ``Standard C++ Modules``. The implementation of all these kinds of 
modules in Clang
-has a lot of shared code, but from the perspective of users, their semantics 
and
-command line interfaces are very different. This document focuses on
-an introduction of how to use standard C++ modules in Clang.
-
-There is already a detailed document about `Clang modules `_, it
-should be helpful to read `Clang modules `_ if you want to know
-more about the general idea of modules. Since standard C++ modules have 
different semantics
-(and work flows) from `Clang modules`, this page describes the background and 
use of
-Clang with standard C++ modules.
-
-Modules exist in two forms in the C++ Language Specification. They can refer to
-either "Named Modules" or to "Header Units". This document covers both forms.
+The term ``modules`` has a lot of meanings. For Clang users, modules may refer
+to ``Objective-C Modules``, `Clang Modules `_ (also called
+``Clang Header Modules``, etc.) or ``C++20 Modules`` (or
+``Standard C++ Modules``). The implementation of all these kinds of modules in
+Clang shares a lot of code, but from the perspective of users, their semantics
+and command line interfaces are very different. This document focuses on an
+introduction of focusing on the use of C++20 modules in Clang. In the remainder

Endilll wrote:

```suggestion
introduction to the use of C++20 modules in Clang. In the remainder
```
> focuses on an introduction of focusing

doesn't sound good

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -8,79 +8,60 @@ Standard C++ Modules
 Introduction
 
 
-The term ``modules`` has a lot of meanings. For the users of Clang, modules may
-refer to ``Objective-C Modules``, ``Clang C++ Modules`` (or ``Clang Header 
Modules``,
-etc.) or ``Standard C++ Modules``. The implementation of all these kinds of 
modules in Clang
-has a lot of shared code, but from the perspective of users, their semantics 
and
-command line interfaces are very different. This document focuses on
-an introduction of how to use standard C++ modules in Clang.
-
-There is already a detailed document about `Clang modules `_, it
-should be helpful to read `Clang modules `_ if you want to know
-more about the general idea of modules. Since standard C++ modules have 
different semantics
-(and work flows) from `Clang modules`, this page describes the background and 
use of
-Clang with standard C++ modules.
-
-Modules exist in two forms in the C++ Language Specification. They can refer to
-either "Named Modules" or to "Header Units". This document covers both forms.
+The term ``modules`` has a lot of meanings. For Clang users, modules may refer
+to ``Objective-C Modules``, `Clang Modules `_ (also called
+``Clang Header Modules``, etc.) or ``C++20 Modules`` (or
+``Standard C++ Modules``). The implementation of all these kinds of modules in
+Clang shares a lot of code, but from the perspective of users, their semantics
+and command line interfaces are very different. This document focuses on an
+introduction of focusing on the use of C++20 modules in Clang. In the remainder
+of this document, the term ``modules`` will refer to Standard C++20 modules and
+the term ``Clang modules`` will refer to the Clang modules extension.
+
+Modules exist in two forms in the C++ Standard. They can refer to either
+"Named Modules" or "Header Units". This document covers both forms.
 
 Standard C++ Named modules
 ==
 
-This document was intended to be a manual first and foremost, however, we 
consider it helpful to
-introduce some language background here for readers who are not familiar with
-the new language feature. This document is not intended to be a language
-tutorial; it will only introduce necessary concepts about the
-structure and building of the project.
+In order to understand compiler behavior, it is helpful to introduce some
+language background here for readers who are not familiar with the C++ feature.
+This document is not a tutorial on C++; it only introduces necessary concepts
+to better understand use of modules for a project.

Endilll wrote:

```suggestion
to better understand use of modules in a project.
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

I have to admit that is rather shallow due to sheer amount of text, but it 
still took me more like 90 minutes. Hope you find it useful. 

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -95,22 +76,23 @@ In this document, we use the following umbrella terms:
 * A ``module interface unit`` refers to either a ``primary module interface 
unit``
   or a ``module interface partition unit``.
 
-* An ``importable module unit`` refers to either a ``module interface unit``
-  or a ``internal module partition unit``.
+* An ``importable module unit`` refers to either a ``module interface unit`` or

Endilll wrote:

This whole piece of documentation relies heavily on code font, and I feel we 
might be overusing it, like here. Maybe we should follow the example of the 
Standard, and use italics instead.

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -279,8 +266,9 @@ we could put ``-x c++-module`` in front of the file. For 
example,
 return 0;
   }
 
-Now the filename of the ``module interface`` ends with ``.cpp`` instead of 
``.cppm``,
-we can't compile them by the original command lines. But we are still able to 
do it by:
+In this example, the extension used by the ``module interface`` is ``.cpp``
+instead of ``.cppm``, so is cannot be compiled with the command lines from the

Endilll wrote:

```suggestion
instead of ``.cppm``, so it cannot be compiled with the command lines from the
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -738,22 +736,21 @@ the following style significantly:
   import M;
   ... // use declarations from module M.
 
-The key part of the tip is to reduce the duplications from the text includes.
+Reducing the duplication from textual includes is what improves compile-time
+performance.
 
-Ideas for converting to modules

+Transitioning to modules
+
 
-For new libraries, we encourage them to use modules completely from day one if 
possible.
-This will be pretty helpful to make the whole ecosystems to get ready.
-
-For many existing libraries, it may be a breaking change to refactor themselves
-into modules completely. So that many existing libraries need to provide 
headers and module
+New code and libraries should use modules from day one if possible. However,
+it may be a breaking change for existing code or libraries to refactor to use

Endilll wrote:

```suggestion
it may be a breaking change for existing code or libraries to switch to
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -444,53 +435,57 @@ For example, the following example is allowed:
   # Inconsistent debugging level.
   $ clang++ -std=c++20 -g Use.cpp -fprebuilt-module-path=.
 
-Although the two examples have inconsistent optimization and debugging level, 
both of them are accepted.
+Although the optimization and debugging levels are inconsistent, these
+compilations are accepted because the compiler options do not impact the
+language dialect.
 
-Note that **currently** the compiler doesn't consider inconsistent macro 
definition a problem. For example:
+Note that the compiler **currently** doesn't reject inconsistent macro
+definitions (this may change in the future). For example:
 
 .. code-block:: console
 
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm
   # Inconsistent optimization level.
   $ clang++ -std=c++20 -O3 -DNDEBUG Use.cpp -fprebuilt-module-path=.
 
-Currently Clang would accept the above example. But it may produce surprising 
results if the
-debugging code depends on consistent use of ``NDEBUG`` also in other 
translation units.
-
-Definitions consistency
-^^^
-
-The C++ language defines that same declarations in different translation units 
should have
-the same definition, as known as ODR (One Definition Rule). Prior to modules, 
the translation
-units don't dependent on each other and the compiler itself can't perform a 
strong
-ODR violation check. With the introduction of modules, now the compiler have
-the chance to perform ODR violations with language semantics across 
translation units.
-
-However, in the practice, we found the existing ODR checking mechanism is not 
stable
-enough. Many people suffers from the false positive ODR violation diagnostics, 
AKA,
-the compiler are complaining two identical declarations have different 
definitions
-incorrectly. Also the true positive ODR violations are rarely reported.
-Also we learned that MSVC don't perform ODR check for declarations in the 
global module
-fragment.
-
-So in order to get better user experience, save the time checking ODR and keep 
consistent
-behavior with MSVC, we disabled the ODR check for the declarations in the 
global module
-fragment by default. Users who want more strict check can still use the
-``-Xclang -fno-skip-odr-check-in-gmf`` flag to get the ODR check enabled. It 
is also
-encouraged to report issues if users find false positive ODR violations or 
false negative ODR
-violations with the flag enabled.
+Currently, Clang accepts the above example though it may produce surprising
+results if the debugging code depends on consistent use of ``NDEBUG`` in other
+translation units.
+
+Object definition consistency
+^
+
+The C++ language requires that the same declarations in different translation

Endilll wrote:

```suggestion
The C++ language requires that the declarations of the same entity in different 
translation
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -738,22 +736,21 @@ the following style significantly:
   import M;
   ... // use declarations from module M.
 
-The key part of the tip is to reduce the duplications from the text includes.
+Reducing the duplication from textual includes is what improves compile-time
+performance.
 
-Ideas for converting to modules

+Transitioning to modules
+
 
-For new libraries, we encourage them to use modules completely from day one if 
possible.
-This will be pretty helpful to make the whole ecosystems to get ready.
-
-For many existing libraries, it may be a breaking change to refactor themselves
-into modules completely. So that many existing libraries need to provide 
headers and module
+New code and libraries should use modules from day one if possible. However,

Endilll wrote:

```suggestion
New code and libraries should use modules from day 1 if possible. However,
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Revise the modules document for clarity (PR #90237)

[Vlad Serebrennikov via cfe-commits]

@@ -738,22 +736,21 @@ the following style significantly:
   import M;
   ... // use declarations from module M.
 
-The key part of the tip is to reduce the duplications from the text includes.
+Reducing the duplication from textual includes is what improves compile-time
+performance.
 
-Ideas for converting to modules

+Transitioning to modules
+
 
-For new libraries, we encourage them to use modules completely from day one if 
possible.
-This will be pretty helpful to make the whole ecosystems to get ready.
-
-For many existing libraries, it may be a breaking change to refactor themselves
-into modules completely. So that many existing libraries need to provide 
headers and module
+New code and libraries should use modules from day one if possible. However,
+it may be a breaking change for existing code or libraries to refactor to use
+modules. As a result, many existing libraries need to provide headers and 
module
 interfaces for a while to not break existing users.
-Here we provide some ideas to ease the transition process for existing 
libraries.
-**Note that the this section is only about helping ideas instead of 
requirement from clang**.
 
-Let's start with the case that there is no dependency or no dependent 
libraries providing
-modules for your library.
+This section provides some ideas on how to ease the transition process for

Endilll wrote:

```suggestion
This section suggests some ideas on how to ease the transition process for
```

https://github.com/llvm/llvm-project/pull/90237
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add test for CWG2149 "Brace elision and array length deduction" (PR #90079)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll closed 
https://github.com/llvm/llvm-project/pull/90079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix crash when destructor definition is preceded with '=' (PR #90220)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll created 
https://github.com/llvm/llvm-project/pull/90220

Fixes #89544

>From b9b17fa34dab666e4c77dad9cd4109f7a88d1c2e Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Fri, 26 Apr 2024 18:03:44 +0300
Subject: [PATCH] [clang] Fix crash when destructor definition is preceded with
 '='

Fixes #89544
---
 clang/docs/ReleaseNotes.rst   |  3 +++
 clang/lib/AST/Expr.cpp|  8 +---
 clang/test/SemaCXX/destructor.cpp | 12 
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 92563262cc6737..5d1260fbca7beb 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -436,6 +436,9 @@ Bug Fixes in This Version
 - Clang now correctly generates overloads for bit-precise integer types for
   builtin operators in C++. Fixes #GH82998.
 
+- Fix crash when destructor definition is preceded with an equals sign.
+  Fixes (#GH89544).
+
 - When performing mixed arithmetic between ``_Complex`` floating-point types 
and integers,
   Clang now correctly promotes the integer to its corresponding real 
floating-point
   type only rather than to the complex type (e.g. ``_Complex float / int`` is 
now evaluated
diff --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index 63dcdb919c7117..52c8c95b48abf7 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -3893,9 +3893,11 @@ namespace {
 }
 
 void VisitCXXBindTemporaryExpr(const CXXBindTemporaryExpr *E) {
-  if (E->getTemporary()->getDestructor()->isTrivial()) {
-Inherited::VisitStmt(E);
-return;
+  if (const CXXDestructorDecl *DtorDecl = 
E->getTemporary()->getDestructor()) {
+if (DtorDecl->isTrivial()) {
+  Inherited::VisitStmt(E);
+  return;
+}
   }
 
   NonTrivial = true;
diff --git a/clang/test/SemaCXX/destructor.cpp 
b/clang/test/SemaCXX/destructor.cpp
index beac50e449e96d..028bc7cc196989 100644
--- a/clang/test/SemaCXX/destructor.cpp
+++ b/clang/test/SemaCXX/destructor.cpp
@@ -565,4 +565,16 @@ struct Foo : public Baz { // expected-error {{cannot 
override a non-deleted func
 };
 }
 
+namespace GH89544 {
+class Foo {
+  ~Foo() = {}
+  // expected-error@-1 {{initializer on function does not look like a 
pure-specifier}}
+  // expected-error@-2 {{expected ';' at end of declaration list}}
+};
+
+static_assert(!__is_trivially_constructible(Foo), "");
+static_assert(!__is_trivially_constructible(Foo, const Foo &), "");
+static_assert(!__is_trivially_constructible(Foo, Foo &&), "");
+} // namespace GH89544
+
 #endif // BE_THE_HEADER

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix crash when destructor definition is preceded with '=' (PR #90220)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll updated 
https://github.com/llvm/llvm-project/pull/90220

>From b9b17fa34dab666e4c77dad9cd4109f7a88d1c2e Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Fri, 26 Apr 2024 18:03:44 +0300
Subject: [PATCH 1/2] [clang] Fix crash when destructor definition is preceded
 with '='

Fixes #89544
---
 clang/docs/ReleaseNotes.rst   |  3 +++
 clang/lib/AST/Expr.cpp|  8 +---
 clang/test/SemaCXX/destructor.cpp | 12 
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 92563262cc6737..5d1260fbca7beb 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -436,6 +436,9 @@ Bug Fixes in This Version
 - Clang now correctly generates overloads for bit-precise integer types for
   builtin operators in C++. Fixes #GH82998.
 
+- Fix crash when destructor definition is preceded with an equals sign.
+  Fixes (#GH89544).
+
 - When performing mixed arithmetic between ``_Complex`` floating-point types 
and integers,
   Clang now correctly promotes the integer to its corresponding real 
floating-point
   type only rather than to the complex type (e.g. ``_Complex float / int`` is 
now evaluated
diff --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index 63dcdb919c7117..52c8c95b48abf7 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -3893,9 +3893,11 @@ namespace {
 }
 
 void VisitCXXBindTemporaryExpr(const CXXBindTemporaryExpr *E) {
-  if (E->getTemporary()->getDestructor()->isTrivial()) {
-Inherited::VisitStmt(E);
-return;
+  if (const CXXDestructorDecl *DtorDecl = 
E->getTemporary()->getDestructor()) {
+if (DtorDecl->isTrivial()) {
+  Inherited::VisitStmt(E);
+  return;
+}
   }
 
   NonTrivial = true;
diff --git a/clang/test/SemaCXX/destructor.cpp 
b/clang/test/SemaCXX/destructor.cpp
index beac50e449e96d..028bc7cc196989 100644
--- a/clang/test/SemaCXX/destructor.cpp
+++ b/clang/test/SemaCXX/destructor.cpp
@@ -565,4 +565,16 @@ struct Foo : public Baz { // expected-error {{cannot 
override a non-deleted func
 };
 }
 
+namespace GH89544 {
+class Foo {
+  ~Foo() = {}
+  // expected-error@-1 {{initializer on function does not look like a 
pure-specifier}}
+  // expected-error@-2 {{expected ';' at end of declaration list}}
+};
+
+static_assert(!__is_trivially_constructible(Foo), "");
+static_assert(!__is_trivially_constructible(Foo, const Foo &), "");
+static_assert(!__is_trivially_constructible(Foo, Foo &&), "");
+} // namespace GH89544
+
 #endif // BE_THE_HEADER

>From 3633a834d382e4ed5890b3e3d4eb9662c643bc22 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Fri, 26 Apr 2024 18:11:53 +0300
Subject: [PATCH 2/2] Run clang-format

---
 clang/lib/AST/Expr.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index 52c8c95b48abf7..ac5653fe9478b8 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -3893,7 +3893,8 @@ namespace {
 }
 
 void VisitCXXBindTemporaryExpr(const CXXBindTemporaryExpr *E) {
-  if (const CXXDestructorDecl *DtorDecl = 
E->getTemporary()->getDestructor()) {
+  if (const CXXDestructorDecl *DtorDecl =
+  E->getTemporary()->getDestructor()) {
 if (DtorDecl->isTrivial()) {
   Inherited::VisitStmt(E);
   return;

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix crash when destructor definition is preceded with '=' (PR #90220)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

I have a vague feeling I might be fixing the symptom instead of the cause.

https://github.com/llvm/llvm-project/pull/90220
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] Reapply "[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

Changes to `Sema.h` and DR tests look good to me.

https://github.com/llvm/llvm-project/pull/90152
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Use `cwg_index.html` from GitHub for DR status page (PR #90352)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll created 
https://github.com/llvm/llvm-project/pull/90352

Currently we're using official publication of CWG issue list available at 
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_index.html. Unfortunately, 
it's not updated as frequently as we sometimes need. For instance, recently 
there was a confusion during review of CWG2149 test 
(https://github.com/llvm/llvm-project/pull/90079#discussion_r1580174003). This 
patch changes our `make_cxx_dr_status` script to use issue list from CWG GitHub 
repository. I confirmed with CWG chair that this is the most up-to-date source 
of information on CWG issues.

Changing the source of issue list uncovered previously unhandled "tentatively 
ready" status of an issue. This status is considered unresolved by the script 
(like `open`, `drafting`, and `review`), as the resolution might change during 
face-to-face CWG meeting.

I also noticed that CWG decided to handle 2561 differently from what we're 
doing, so this DR is now considered not available in Clang, despite being 
declared as available since 18. CC @cor3ntin.

This patch also brings new issues into our DR list, so if someone was waiting 
for a newly-filed issue to appear on our status page, it should appear with 
this PR.

>From bae40b1e7a894481227978df011e552a78484036 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Sat, 27 Apr 2024 21:16:07 +0300
Subject: [PATCH] [clang] Use `cwg_index.html` from GitHub for DR status page

---
 clang/test/CXX/drs/cwg2149.cpp |   2 +-
 clang/test/CXX/drs/dr20xx.cpp  |   2 +-
 clang/test/CXX/drs/dr21xx.cpp  |   2 +
 clang/test/CXX/drs/dr24xx.cpp  |   4 +-
 clang/test/CXX/drs/dr25xx.cpp  |   4 +-
 clang/test/CXX/drs/dr28xx.cpp  |   2 +-
 clang/www/cxx_dr_status.html   | 553 +++--
 clang/www/make_cxx_dr_status   |   6 +-
 8 files changed, 410 insertions(+), 165 deletions(-)

diff --git a/clang/test/CXX/drs/cwg2149.cpp b/clang/test/CXX/drs/cwg2149.cpp
index d0f8cb2dfc0a93..8416e42cbd6970 100644
--- a/clang/test/CXX/drs/cwg2149.cpp
+++ b/clang/test/CXX/drs/cwg2149.cpp
@@ -11,7 +11,7 @@
 // cxx98-error@-1 {{variadic macros are a C99 feature}}
 #endif
 
-namespace cwg2149 { // cwg2149: 3.1 drafting 2024-04
+namespace cwg2149 { // cwg2149: 3.1
 #if __cplusplus <= 201103L
 struct X { int i, j, k; };
 #else
diff --git a/clang/test/CXX/drs/dr20xx.cpp b/clang/test/CXX/drs/dr20xx.cpp
index 291a77e0cc71dd..9797097acce753 100644
--- a/clang/test/CXX/drs/dr20xx.cpp
+++ b/clang/test/CXX/drs/dr20xx.cpp
@@ -90,7 +90,7 @@ namespace cwg2026 { // cwg2026: 11
   }
 }
 
-namespace cwg2049 { // cwg2049: 18 drafting P2308R1
+namespace cwg2049 { // cwg2049: 18
 #if __cplusplus >= 202302L
 template  struct X {};
 X<> a;
diff --git a/clang/test/CXX/drs/dr21xx.cpp b/clang/test/CXX/drs/dr21xx.cpp
index 4fab10c279aa43..082deb42e4fa09 100644
--- a/clang/test/CXX/drs/dr21xx.cpp
+++ b/clang/test/CXX/drs/dr21xx.cpp
@@ -175,6 +175,8 @@ void foo() {
 }
 }
 
+// cwg2149 is in cwg2149.cpp
+
 namespace cwg2157 { // cwg2157: 11
 #if __cplusplus >= 201103L
   enum E : int;
diff --git a/clang/test/CXX/drs/dr24xx.cpp b/clang/test/CXX/drs/dr24xx.cpp
index 5ffaebda68c132..9f876cd8708347 100644
--- a/clang/test/CXX/drs/dr24xx.cpp
+++ b/clang/test/CXX/drs/dr24xx.cpp
@@ -45,7 +45,7 @@ void fallthrough(int n) {
 #endif
 }
 
-namespace cwg2450 { // cwg2450: 18 review P2308R1
+namespace cwg2450 { // cwg2450: 18
 #if __cplusplus >= 202302L
 struct S {int a;};
 template 
@@ -59,7 +59,7 @@ f<{.a= 0}>();
 #endif
 }
 
-namespace cwg2459 { // cwg2459: 18 drafting P2308R1
+namespace cwg2459 { // cwg2459: 18
 #if __cplusplus >= 202302L
 struct A {
   constexpr A(float) {}
diff --git a/clang/test/CXX/drs/dr25xx.cpp b/clang/test/CXX/drs/dr25xx.cpp
index 62b2a0a088cc13..481ae09cdb77ea 100644
--- a/clang/test/CXX/drs/dr25xx.cpp
+++ b/clang/test/CXX/drs/dr25xx.cpp
@@ -130,12 +130,14 @@ struct D3 : B {
 #endif
 
 #if __cplusplus >= 202302L
-namespace cwg2561 { // cwg2561: 18 review 2023-11-09
+namespace cwg2561 { // cwg2561: no
 struct C {
 constexpr C(auto) { }
 };
 void foo() {
 constexpr auto b = [](this C) { return 1; };
+// FIXME: closure type shouldn't have a conversion function to function
+//pointer, because explicit object parameter is present. 
 constexpr int (*fp)(C) = b;
 static_assert(fp(1) == 1);
 static_assert(((b)::operator())(1) == 1);
diff --git a/clang/test/CXX/drs/dr28xx.cpp b/clang/test/CXX/drs/dr28xx.cpp
index 4d9b0c76758d53..1967e8b751db2d 100644
--- a/clang/test/CXX/drs/dr28xx.cpp
+++ b/clang/test/CXX/drs/dr28xx.cpp
@@ -10,7 +10,7 @@
 // expected-no-diagnostics
 #endif
 
-namespace cwg2847 { // cwg2847: 19
+namespace cwg2847 { // cwg2847: 19 review 2024-03-01
 
 #if __cplusplus >= 202002L
 
diff --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index ea8872c91be604..19d29cb55d6ed0 100755
--- a/clang/www/cxx_dr_status.html
+++ b/clang/www/cxx_dr_status.html
@@ -1433,11 +1433,11 @@ C++ defect report 

[clang] [clang] Fix crash when destructor definition is preceded with '=' (PR #90220)

[Vlad Serebrennikov via cfe-commits]

@@ -3893,9 +3893,12 @@ namespace {
 }
 
 void VisitCXXBindTemporaryExpr(const CXXBindTemporaryExpr *E) {
-  if (E->getTemporary()->getDestructor()->isTrivial()) {
-Inherited::VisitStmt(E);
-return;
+  if (const CXXDestructorDecl *DtorDecl =
+  E->getTemporary()->getDestructor()) {
+if (DtorDecl->isTrivial()) {
+  Inherited::VisitStmt(E);
+  return;
+}

Endilll wrote:

It looks like it's normal for `nullptr` to slip into `CXXTemporary` as 
destructor:
https://github.com/llvm/llvm-project/blob/9145514fde484916971e6bb147c18f9235a9f2b5/clang/lib/Sema/SemaExprCXX.cpp#L7611-L7630
So the check I added might be a check in the right place.

https://github.com/llvm/llvm-project/pull/90220
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Implement C++26 P2748R5 "Disallow Binding a Returned Glvalue to a Temporary" (PR #89942)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll edited 
https://github.com/llvm/llvm-project/pull/89942
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Implement C++26 P2748R5 "Disallow Binding a Returned Glvalue to a Temporary" (PR #89942)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll edited 
https://github.com/llvm/llvm-project/pull/89942
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Implement C++26 P2748R5 "Disallow Binding a Returned Glvalue to a Temporary" (PR #89942)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

LGTM
@erichkeane mind giving CWG650 test a quick look?

https://github.com/llvm/llvm-project/pull/89942
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Implement C++26 P2748R5 "Disallow Binding a Returned Glvalue to a Temporary" (PR #89942)

[Vlad Serebrennikov via cfe-commits]

@@ -4,7 +4,7 @@
 // RUN: %clang_cc1 -std=c++17 %s -triple x86_64-linux-gnu -emit-llvm -o - 
-fexceptions -fcxx-exceptions -pedantic-errors | llvm-cxxfilt -n | FileCheck %s 
--check-prefixes CHECK
 // RUN: %clang_cc1 -std=c++20 %s -triple x86_64-linux-gnu -emit-llvm -o - 
-fexceptions -fcxx-exceptions -pedantic-errors | llvm-cxxfilt -n | FileCheck %s 
--check-prefixes CHECK
 // RUN: %clang_cc1 -std=c++23 %s -triple x86_64-linux-gnu -emit-llvm -o - 
-fexceptions -fcxx-exceptions -pedantic-errors | llvm-cxxfilt -n | FileCheck %s 
--check-prefixes CHECK
-// RUN: %clang_cc1 -std=c++2c %s -triple x86_64-linux-gnu -emit-llvm -o - 
-fexceptions -fcxx-exceptions -pedantic-errors | llvm-cxxfilt -n | FileCheck %s 
--check-prefixes CHECK
+// Since C++26, P2748R5 "Disallow Binding a Returned Glvalue to a Temporary". 
Therefore we do not test this issue after C++26.

Endilll wrote:

```suggestion
// We aren't testing this since C++26 because of P2748R5 "Disallow Binding a 
Returned Glvalue to a Temporary".
```

https://github.com/llvm/llvm-project/pull/89942
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] [CodeGen] Perform derived-to-base conversion on explicit object parameter in lambda (PR #89828)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

@Sirraide See example of 
https://github.com/llvm/llvm-project/blob/662ef8604268b207910225ecca90daf30a46720b/clang/test/CXX/drs/dr25xx.cpp#L148
In this case, the date should be 2024-04-19.

https://github.com/llvm/llvm-project/pull/89828
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add test for CWG2149 "Brace elision and array length deduction" (PR #90079)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll created 
https://github.com/llvm/llvm-project/pull/90079

This patch adds test for 
[CWG2149](https://cplusplus.github.io/CWG/issues/2149.html), following 
[P3106R1](https://wg21.link/p3106R1) "Clarifying rules for brace elision in 
aggregate initialization" and a clarification note on top of it added on April 
2024.

I haven't found a better way to check for equality of values inside array in 98 
mode than to dump AST. I'm open to suggestions there.

>From c919062d398afc758fc5d9f3cb09219ce81f72ef Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Thu, 25 Apr 2024 19:14:53 +0300
Subject: [PATCH] [clang] Add test for CWG2149

---
 clang/test/CXX/drs/cwg2149.cpp | 77 ++
 clang/www/cxx_dr_status.html   |  2 +-
 2 files changed, 78 insertions(+), 1 deletion(-)
 create mode 100644 clang/test/CXX/drs/cwg2149.cpp

diff --git a/clang/test/CXX/drs/cwg2149.cpp b/clang/test/CXX/drs/cwg2149.cpp
new file mode 100644
index 00..d0f8cb2dfc0a93
--- /dev/null
+++ b/clang/test/CXX/drs/cwg2149.cpp
@@ -0,0 +1,77 @@
+// RUN: %clang_cc1 -std=c++98 -triple x86_64-unknown-unknown %s 
-verify=expected,cxx98 -fexceptions -fcxx-exceptions -pedantic-errors -ast-dump 
| FileCheck %s --check-prefixes CXX98
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+// RUN: %clang_cc1 -std=c++17 -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+// RUN: %clang_cc1 -std=c++20 -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+// RUN: %clang_cc1 -std=c++23 -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+// RUN: %clang_cc1 -std=c++2c -triple x86_64-unknown-unknown %s 
-verify=expected,since-cxx11 -fexceptions -fcxx-exceptions -pedantic-errors
+
+#if __cplusplus == 199711L
+#define static_assert(...) __extension__ _Static_assert(__VA_ARGS__)
+// cxx98-error@-1 {{variadic macros are a C99 feature}}
+#endif
+
+namespace cwg2149 { // cwg2149: 3.1 drafting 2024-04
+#if __cplusplus <= 201103L
+struct X { int i, j, k; };
+#else
+struct X { int i, j, k = 42; };
+#endif
+
+template 
+void f1(const X(&)[N]); // #cwg2149-f1
+
+template
+void f2(const X(&)[N][2]); // #cwg2149-f2
+
+void f() {
+  X a[] = { 1, 2, 3, 4, 5, 6 };
+  static_assert(sizeof(a) / sizeof(X) == 2, "");
+  X b[2] = { { 1, 2, 3 }, { 4, 5, 6 } };
+  X c[][2] = { 1, 2, 3, 4, 5, 6 };
+  static_assert(sizeof(c) / sizeof(X[2]) == 1, "");
+  
+  #if __cplusplus >= 201103L
+  constexpr X ca[] = { 1, 2, 3, 4, 5, 6 };
+  constexpr X cb[2] = { { 1, 2, 3 }, { 4, 5, 6 } };
+  static_assert(ca[0].i == cb[0].i, "");
+  static_assert(ca[0].j == cb[0].j, "");
+  static_assert(ca[0].k == cb[0].k, "");
+  static_assert(ca[1].i == cb[1].i, "");
+  static_assert(ca[1].j == cb[1].j, "");
+  static_assert(ca[1].k == cb[1].k, "");
+
+  f1({ 1, 2, 3, 4, 5, 6 });
+  // since-cxx11-error@-1 {{no matching function for call to 'f1'}}
+  //   since-cxx11-note@#cwg2149-f1 {{candidate function [with N = 6] not 
viable: no known conversion from 'int' to 'const X' for 1st argument}}
+  f2({ 1, 2, 3, 4, 5, 6 });
+  // since-cxx11-error@-1 {{no matching function for call to 'f2'}}
+  //   since-cxx11-note@#cwg2149-f2 {{candidate function [with N = 6] not 
viable: no known conversion from 'int' to 'const X[2]' for 1st argument}}
+  #endif
+}
+} // namespace cwg2149
+
+// Constant evaluation is not powerful enough in 98 mode to check for equality
+// via static_assert, even with constant folding enabled.
+
+// CXX98:   VarDecl {{.+}} a 'X[2]'
+// CXX98-NEXT:  `-InitListExpr {{.+}} 'X[2]'
+// CXX98-NEXT:|-InitListExpr {{.+}} 'X':'cwg2149::X'
+// CXX98-NEXT:| |-IntegerLiteral {{.+}} 'int' 1
+// CXX98-NEXT:| |-IntegerLiteral {{.+}} 'int' 2
+// CXX98-NEXT:| `-IntegerLiteral {{.+}} 'int' 3
+// CXX98-NEXT:`-InitListExpr {{.+}} 'X':'cwg2149::X'
+// CXX98-NEXT:  |-IntegerLiteral {{.+}} 'int' 4
+// CXX98-NEXT:  |-IntegerLiteral {{.+}} 'int' 5
+// CXX98-NEXT:  `-IntegerLiteral {{.+}} 'int' 6
+
+// CXX98:   VarDecl {{.+}} b 'X[2]'
+// CXX98-NEXT:  `-InitListExpr {{.+}} 'X[2]'
+// CXX98-NEXT:|-InitListExpr {{.+}} 'X':'cwg2149::X'
+// CXX98-NEXT:| |-IntegerLiteral {{.+}} 'int' 1
+// CXX98-NEXT:| |-IntegerLiteral {{.+}} 'int' 2
+// CXX98-NEXT:| `-IntegerLiteral {{.+}} 'int' 3
+// CXX98-NEXT:`-InitListExpr {{.+}} 'X':'cwg2149::X'
+// CXX98-NEXT:  |-IntegerLiteral {{.+}} 'int' 4
+// CXX98-NEXT:  |-IntegerLiteral {{.+}} 'int' 5
+// CXX98-NEXT:  `-IntegerLiteral {{.+}} 'int' 6
diff --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index 83b71e7c122d1e..ea8872c91be604 

[clang] [clang] Add test for CWG2149 "Brace elision and array length deduction" (PR #90079)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

>Can you add examples 14, 16, 17, 18 of the paper?

I'll add them to conformance test suite in a subsequent PR. They don't belong 
here, as the issue is about deducing array length from brace initializer, but 
the examples you're listing are focusing on various aspects of how 
initializer-clauses appertain to aggregate elements.

I can, though, derive more tests from them that check for deduced array length 
in various appertainment cases, if you feel current coverage of the issue is 
not sufficient.

https://github.com/llvm/llvm-project/pull/90079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add test for CWG2149 "Brace elision and array length deduction" (PR #90079)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

Status of 2149 changed just yesterday to say DR per 2024 Tokyo straw poll. 
That's where the discrepancy between official `cwg_index.html` and CWG GitHub 
repo comes (that I link in the description).

https://github.com/llvm/llvm-project/pull/90079
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 662ef86 - [clang][NFC] Remove useless code in ASTWriter

[Vlad Serebrennikov via cfe-commits]

Author: Vlad Serebrennikov
Date: 2024-04-24T11:09:06+03:00
New Revision: 662ef8604268b207910225ecca90daf30a46720b

URL: 
https://github.com/llvm/llvm-project/commit/662ef8604268b207910225ecca90daf30a46720b
DIFF: 
https://github.com/llvm/llvm-project/commit/662ef8604268b207910225ecca90daf30a46720b.diff

LOG: [clang][NFC] Remove useless code in ASTWriter

A follow-up to #71709, addressing the static analysis finding reported in 
https://github.com/llvm/llvm-project/pull/71709/files#r1576846306

Added: 


Modified: 
clang/lib/Serialization/ASTWriter.cpp

Removed: 




diff  --git a/clang/lib/Serialization/ASTWriter.cpp 
b/clang/lib/Serialization/ASTWriter.cpp
index a1b340b252fb08..d0c1217156a593 100644
--- a/clang/lib/Serialization/ASTWriter.cpp
+++ b/clang/lib/Serialization/ASTWriter.cpp
@@ -3618,7 +3618,6 @@ class ASTIdentifierTableTrait {
   /// doesn't check whether the name has macros defined; use 
PublicMacroIterator
   /// to check that.
   bool isInterestingIdentifier(const IdentifierInfo *II, uint64_t MacroOffset) 
{
-II->getObjCOrBuiltinID();
 bool IsInteresting =
 II->getNotableIdentifierID() !=
 tok::NotableIdentifierKind::not_notable ||



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Refactor `IdentifierInfo::ObjcOrBuiltinID` (PR #71709)

[Vlad Serebrennikov via cfe-commits]

@@ -3597,8 +3597,13 @@ class ASTIdentifierTableTrait {
   /// doesn't check whether the name has macros defined; use 
PublicMacroIterator
   /// to check that.
   bool isInterestingIdentifier(const IdentifierInfo *II, uint64_t MacroOffset) 
{
-if (MacroOffset || II->isPoisoned() ||
-(!IsModule && II->getObjCOrBuiltinID()) ||
+II->getObjCOrBuiltinID();

Endilll wrote:

Thank you for reporting this!
No, might be a leftover from debugging sessions (this PR was a pain).
Fixed in 662ef8604268b207910225ecca90daf30a46720b

https://github.com/llvm/llvm-project/pull/71709
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Introduce `SemaCUDA` (PR #88559)

[Vlad Serebrennikov via cfe-commits]

@@ -0,0 +1,304 @@
+//===- SemaCUDA.h - Semantic Analysis for CUDA constructs 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+/// \file
+/// This file declares semantic analysis for CUDA constructs.
+///
+//===--===//
+
+#ifndef LLVM_CLANG_SEMA_SEMACUDA_H
+#define LLVM_CLANG_SEMA_SEMACUDA_H
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/Redeclarable.h"
+#include "clang/Basic/Cuda.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Sema/Lookup.h"
+#include "clang/Sema/Ownership.h"
+#include "clang/Sema/ParsedAttr.h"
+#include "clang/Sema/Scope.h"
+#include "clang/Sema/ScopeInfo.h"
+#include "clang/Sema/SemaBase.h"
+#include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/SmallVector.h"
+#include 
+
+namespace clang {
+
+enum class CUDAFunctionTarget;
+
+class SemaCUDA : public SemaBase {
+public:
+  SemaCUDA(Sema );
+
+  /// Increments our count of the number of times we've seen a pragma forcing
+  /// functions to be __host__ __device__.  So long as this count is greater
+  /// than zero, all functions encountered will be __host__ __device__.
+  void PushForceHostDevice();
+
+  /// Decrements our count of the number of times we've seen a pragma forcing
+  /// functions to be __host__ __device__.  Returns false if the count is 0
+  /// before incrementing, so you can emit an error.
+  bool PopForceHostDevice();
+
+  ExprResult ActOnExecConfigExpr(Scope *S, SourceLocation oc,
+ MultiExprArg ExecConfig,
+ SourceLocation GGGLoc);
+
+  /// A pair of a canonical FunctionDecl and a SourceLocation.  When used as 
the
+  /// key in a hashtable, both the FD and location are hashed.
+  struct FunctionDeclAndLoc {
+CanonicalDeclPtr FD;
+SourceLocation Loc;
+  };
+
+  /// FunctionDecls and SourceLocations for which CheckCall has emitted a
+  /// (maybe deferred) "bad call" diagnostic.  We use this to avoid emitting 
the
+  /// same deferred diag twice.
+  llvm::DenseSet LocsWithCUDACallDiags;
+
+  /// An inverse call graph, mapping known-emitted functions to one of their
+  /// known-emitted callers (plus the location of the call).
+  ///
+  /// Functions that we can tell a priori must be emitted aren't added to this
+  /// map.
+  llvm::DenseMap,
+ /* Caller = */ FunctionDeclAndLoc>
+  DeviceKnownEmittedFns;
+
+  /// Creates a SemaDiagnosticBuilder that emits the diagnostic if the current
+  /// context is "used as device code".
+  ///
+  /// - If CurContext is a __host__ function, does not emit any diagnostics
+  ///   unless \p EmitOnBothSides is true.
+  /// - If CurContext is a __device__ or __global__ function, emits the
+  ///   diagnostics immediately.
+  /// - If CurContext is a __host__ __device__ function and we are compiling 
for
+  ///   the device, creates a diagnostic which is emitted if and when we 
realize
+  ///   that the function will be codegen'ed.
+  ///
+  /// Example usage:
+  ///
+  ///  // Variable-length arrays are not allowed in CUDA device code.
+  ///  if (DiagIfDeviceCode(Loc, diag::err_cuda_vla) << CurrentTarget())
+  ///return ExprError();
+  ///  // Otherwise, continue parsing as normal.
+  SemaDiagnosticBuilder DiagIfDeviceCode(SourceLocation Loc, unsigned DiagID);
+
+  /// Creates a SemaDiagnosticBuilder that emits the diagnostic if the current
+  /// context is "used as host code".
+  ///
+  /// Same as DiagIfDeviceCode, with "host" and "device" switched.
+  SemaDiagnosticBuilder DiagIfHostCode(SourceLocation Loc, unsigned DiagID);
+
+  /// Determines whether the given function is a CUDA device/host/kernel/etc.
+  /// function.
+  ///
+  /// Use this rather than examining the function's attributes yourself -- you
+  /// will get it wrong.  Returns CUDAFunctionTarget::Host if D is null.
+  CUDAFunctionTarget IdentifyTarget(const FunctionDecl *D,
+bool IgnoreImplicitHDAttr = false);
+  CUDAFunctionTarget IdentifyTarget(const ParsedAttributesView );
+
+  enum CUDAVariableTarget {
+CVT_Device,  /// Emitted on device side with a shadow variable on host side
+CVT_Host,/// Emitted on host side only
+CVT_Both,/// Emitted on both sides with different addresses
+CVT_Unified, /// Emitted as a unified address, e.g. managed variables
+  };
+  /// Determines whether the given variable is emitted on host or device side.
+  CUDAVariableTarget IdentifyTarget(const VarDecl *D);
+
+  /// Defines kinds of CUDA global host/device context where a function may be
+  /// called.
+  enum CUDATargetContextKind {
+CTCK_Unknown,   /// Unknown context
+

[clang] [clang] Implement `__is_pointer_interconvertible_base_of()` (PR #88473)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll updated 
https://github.com/llvm/llvm-project/pull/88473

>From 84907542cecbe76b1971a50642d39ec4d1078687 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Fri, 12 Apr 2024 08:18:06 +0300
Subject: [PATCH 1/5] [clang] Implement
 `__is_pointer_interconvertible_base_of()`

---
 clang/include/clang/Basic/TokenKinds.def |  1 +
 clang/include/clang/Sema/Sema.h  |  2 +
 clang/lib/Sema/SemaChecking.cpp  | 21 ++
 clang/lib/Sema/SemaExprCXX.cpp   | 16 +
 clang/test/SemaCXX/type-traits.cpp   | 86 +++-
 5 files changed, 125 insertions(+), 1 deletion(-)

diff --git a/clang/include/clang/Basic/TokenKinds.def 
b/clang/include/clang/Basic/TokenKinds.def
index 800af0e6d04480..a27fbed358a60c 100644
--- a/clang/include/clang/Basic/TokenKinds.def
+++ b/clang/include/clang/Basic/TokenKinds.def
@@ -521,6 +521,7 @@ TYPE_TRAIT_1(__is_union, IsUnion, KEYCXX)
 TYPE_TRAIT_1(__has_unique_object_representations,
  HasUniqueObjectRepresentations, KEYCXX)
 TYPE_TRAIT_2(__is_layout_compatible, IsLayoutCompatible, KEYCXX)
+TYPE_TRAIT_2(__is_pointer_interconvertible_base_of, 
IsPointerInterconvertibleBaseOf, KEYCXX)
 
 #define TRANSFORM_TYPE_TRAIT_DEF(_, Trait) KEYWORD(__##Trait, KEYCXX)
 #include "clang/Basic/TransformTypeTraits.def"
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 0ee4f3c8e127f6..397c5ae8eee777 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -1975,6 +1975,8 @@ class Sema final : public SemaBase {
   };
 
   bool IsLayoutCompatible(QualType T1, QualType T2) const;
+  bool IsPointerInterconvertibleBaseOf(const TypeSourceInfo *Base,
+   const TypeSourceInfo *Derived);
 
   bool CheckFunctionCall(FunctionDecl *FDecl, CallExpr *TheCall,
  const FunctionProtoType *Proto);
diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index abfd9a3031577b..bbe82672183508 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -19710,6 +19710,27 @@ bool Sema::IsLayoutCompatible(QualType T1, QualType 
T2) const {
   return isLayoutCompatible(getASTContext(), T1, T2);
 }
 
+//===-- Pointer interconvertibility //
+
+bool Sema::IsPointerInterconvertibleBaseOf(const TypeSourceInfo *Base,
+   const TypeSourceInfo *Derived) {
+  QualType BaseT = Base->getType().getCanonicalType().getUnqualifiedType();
+  QualType DerivedT =
+  Derived->getType().getCanonicalType().getUnqualifiedType();
+
+  if (!BaseT->isUnionType() && !DerivedT->isUnionType() &&
+  getASTContext().hasSameType(BaseT, DerivedT))
+return true;
+
+  if (!IsDerivedFrom(Derived->getTypeLoc().getBeginLoc(), DerivedT, BaseT))
+return false;
+
+  if (DerivedT->getAsCXXRecordDecl()->isStandardLayout())
+return true;
+
+  return false;
+}
+
 //===--- CHECK: pointer_with_type_tag attribute: datatypes should match //
 
 /// Given a type tag expression find the type tag itself.
diff --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index 12f42f66e5e21b..1416dab9eb3a0e 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -6082,6 +6082,22 @@ static bool EvaluateBinaryTypeTrait(Sema , 
TypeTrait BTT, const TypeSourceI
   Self.Diag(Rhs->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
   << 1 << tok::kw___is_layout_compatible;
 return Self.IsLayoutCompatible(LhsT, RhsT);
+  }
+  case BTT_IsPointerInterconvertibleBaseOf: {
+if (!LhsT->isUnionType() && !RhsT->isUnionType() &&
+!Self.getASTContext().hasSameUnqualifiedType(LhsT, RhsT)) {
+  Self.RequireCompleteType(Rhs->getTypeLoc().getBeginLoc(), RhsT,
+   diag::err_incomplete_type);
+}
+
+if (LhsT->isVariableArrayType())
+  Self.Diag(Lhs->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
+  << 1 << tok::kw___is_pointer_interconvertible_base_of;
+if (RhsT->isVariableArrayType())
+  Self.Diag(Rhs->getTypeLoc().getBeginLoc(), diag::err_vla_unsupported)
+  << 1 << tok::kw___is_pointer_interconvertible_base_of;
+
+return Self.IsPointerInterconvertibleBaseOf(Lhs, Rhs);
   }
 default: llvm_unreachable("not a BTT");
   }
diff --git a/clang/test/SemaCXX/type-traits.cpp 
b/clang/test/SemaCXX/type-traits.cpp
index 421d3007d27ffe..7c22a7659de9e8 100644
--- a/clang/test/SemaCXX/type-traits.cpp
+++ b/clang/test/SemaCXX/type-traits.cpp
@@ -1740,7 +1740,7 @@ void is_layout_compatible(int n)
   static_assert(!__is_layout_compatible(void, int));
   static_assert(__is_layout_compatible(void, const void));
   static_assert(__is_layout_compatible(void, volatile void));
-  static_assert(__is_layout_compatible(const int, volatile int));
+  static_assert(__is_layout_compatible(const void, volatile void));
   

[clang] [clang] Introduce `SemaCUDA` (PR #88559)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

> Have you run the CUDA / HIP tests in the external test suite or anything?

No, just `check-clang` target. You think it's necessary to run something else 
before merging? If so, you should point me out to what to run, and preferably 
give some instructions, as CUDA development is completely foreign to me. 
Another option is to land and watch out for CUDA bots. I saw we have some, but 
not sure if they are in a good state.

https://github.com/llvm/llvm-project/pull/88559
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Stop double-diagnosing explicit convert operator in switch condition (PR #89142)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

I'm having second thoughts about leveraging recovery expressions as a side-band 
mechanism to de-duplicate diagnostics, because not modeling things properly in 
AST might backfire in the future. But I don't have anything better on my mind, 
so I don't want to block the progress of this PR.

https://github.com/llvm/llvm-project/pull/89142
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Migrate DR tests to `static_assert` (PR #88611)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll closed 
https://github.com/llvm/llvm-project/pull/88611
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix a bug on template partial specialization with issue on deduction of nontype tempalte parameter (PR #90376)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

`Sema.h` changes look good to me.

https://github.com/llvm/llvm-project/pull/90376
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Implement CWG2851: floating-point conversions in converted constant expressions (PR #90387)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

I'm fine with the way DR test is written, but I'm not qualified to review the 
contents on the test, unfortunately.

I'd like to point to related Core issues 
[CWG2836](https://cplusplus.github.io/CWG/issues/2836.html) and 
[CWG2864](https://cplusplus.github.io/CWG/issues/2864.html).

You also need to run `clang/www/make_cxx_dr_status` to update the DR status 
page.

https://github.com/llvm/llvm-project/pull/90387
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix crash when destructor definition is preceded with '=' (PR #90220)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll updated 
https://github.com/llvm/llvm-project/pull/90220

>From b9b17fa34dab666e4c77dad9cd4109f7a88d1c2e Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Fri, 26 Apr 2024 18:03:44 +0300
Subject: [PATCH 1/3] [clang] Fix crash when destructor definition is preceded
 with '='

Fixes #89544
---
 clang/docs/ReleaseNotes.rst   |  3 +++
 clang/lib/AST/Expr.cpp|  8 +---
 clang/test/SemaCXX/destructor.cpp | 12 
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 92563262cc6737..5d1260fbca7beb 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -436,6 +436,9 @@ Bug Fixes in This Version
 - Clang now correctly generates overloads for bit-precise integer types for
   builtin operators in C++. Fixes #GH82998.
 
+- Fix crash when destructor definition is preceded with an equals sign.
+  Fixes (#GH89544).
+
 - When performing mixed arithmetic between ``_Complex`` floating-point types 
and integers,
   Clang now correctly promotes the integer to its corresponding real 
floating-point
   type only rather than to the complex type (e.g. ``_Complex float / int`` is 
now evaluated
diff --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index 63dcdb919c7117..52c8c95b48abf7 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -3893,9 +3893,11 @@ namespace {
 }
 
 void VisitCXXBindTemporaryExpr(const CXXBindTemporaryExpr *E) {
-  if (E->getTemporary()->getDestructor()->isTrivial()) {
-Inherited::VisitStmt(E);
-return;
+  if (const CXXDestructorDecl *DtorDecl = 
E->getTemporary()->getDestructor()) {
+if (DtorDecl->isTrivial()) {
+  Inherited::VisitStmt(E);
+  return;
+}
   }
 
   NonTrivial = true;
diff --git a/clang/test/SemaCXX/destructor.cpp 
b/clang/test/SemaCXX/destructor.cpp
index beac50e449e96d..028bc7cc196989 100644
--- a/clang/test/SemaCXX/destructor.cpp
+++ b/clang/test/SemaCXX/destructor.cpp
@@ -565,4 +565,16 @@ struct Foo : public Baz { // expected-error {{cannot 
override a non-deleted func
 };
 }
 
+namespace GH89544 {
+class Foo {
+  ~Foo() = {}
+  // expected-error@-1 {{initializer on function does not look like a 
pure-specifier}}
+  // expected-error@-2 {{expected ';' at end of declaration list}}
+};
+
+static_assert(!__is_trivially_constructible(Foo), "");
+static_assert(!__is_trivially_constructible(Foo, const Foo &), "");
+static_assert(!__is_trivially_constructible(Foo, Foo &&), "");
+} // namespace GH89544
+
 #endif // BE_THE_HEADER

>From 3633a834d382e4ed5890b3e3d4eb9662c643bc22 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Fri, 26 Apr 2024 18:11:53 +0300
Subject: [PATCH 2/3] Run clang-format

---
 clang/lib/AST/Expr.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index 52c8c95b48abf7..ac5653fe9478b8 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -3893,7 +3893,8 @@ namespace {
 }
 
 void VisitCXXBindTemporaryExpr(const CXXBindTemporaryExpr *E) {
-  if (const CXXDestructorDecl *DtorDecl = 
E->getTemporary()->getDestructor()) {
+  if (const CXXDestructorDecl *DtorDecl =
+  E->getTemporary()->getDestructor()) {
 if (DtorDecl->isTrivial()) {
   Inherited::VisitStmt(E);
   return;

>From db72205f756ab05b8d433359e824d508c5732b10 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Tue, 30 Apr 2024 20:43:48 +0300
Subject: [PATCH 3/3] Add comments per reviewer request

---
 clang/include/clang/AST/ExprCXX.h | 2 ++
 clang/lib/AST/Expr.cpp| 2 ++
 2 files changed, 4 insertions(+)

diff --git a/clang/include/clang/AST/ExprCXX.h 
b/clang/include/clang/AST/ExprCXX.h
index a915745d2d7322..ab3f810b45192b 100644
--- a/clang/include/clang/AST/ExprCXX.h
+++ b/clang/include/clang/AST/ExprCXX.h
@@ -1482,6 +1482,8 @@ class CXXTemporary {
 /// const S _ref = S(); // Requires a CXXBindTemporaryExpr.
 ///   }
 /// \endcode
+///
+/// Destructor might be null if destructor declaration is not valid.
 class CXXBindTemporaryExpr : public Expr {
   CXXTemporary *Temp = nullptr;
   Stmt *SubExpr = nullptr;
diff --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index ac5653fe9478b8..bcb5ebfc85c453 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -3893,6 +3893,8 @@ namespace {
 }
 
 void VisitCXXBindTemporaryExpr(const CXXBindTemporaryExpr *E) {
+  // Destructor of the temporary might be null if destructor declaration
+  // is not valid.
   if (const CXXDestructorDecl *DtorDecl =
   E->getTemporary()->getDestructor()) {
 if (DtorDecl->isTrivial()) {

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Fix crash when destructor definition is preceded with '=' (PR #90220)

[Vlad Serebrennikov via cfe-commits]

@@ -3893,9 +3893,12 @@ namespace {
 }
 
 void VisitCXXBindTemporaryExpr(const CXXBindTemporaryExpr *E) {
-  if (E->getTemporary()->getDestructor()->isTrivial()) {
-Inherited::VisitStmt(E);
-return;
+  if (const CXXDestructorDecl *DtorDecl =
+  E->getTemporary()->getDestructor()) {
+if (DtorDecl->isTrivial()) {
+  Inherited::VisitStmt(E);
+  return;
+}

Endilll wrote:

Comments added.

https://github.com/llvm/llvm-project/pull/90220
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Fix lookup of dependent operator= named by using-declaration (PR #91503)

[Vlad Serebrennikov via cfe-commits]

@@ -137,17 +137,16 @@ namespace InhCtor {
   int n = b.T(); // expected-error {{'T' is a protected member of 
'InhCtor::A'}}
  // expected-note@-15 {{declared protected here}}
 
-  // FIXME: EDG and GCC reject this too, but it's not clear why it would be
-  // ill-formed.
   template
   struct S : T {
-struct U : S { // expected-note 6{{candidate}}
+// FIXME: S is incomplete here and we should diagnose this!
+struct U : S {

Endilll wrote:

This rings a bell. I've put something similar in our DR tests, probably in a PR 
about complete-class context. I'm running out of time today, but I'll look into 
this tomorrow if Shafik doesn't beat me to it. 

https://github.com/llvm/llvm-project/pull/91503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][NFC] Add examples from [dcl.init.aggr] to C++ conformance tests (PR #91435)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll updated 
https://github.com/llvm/llvm-project/pull/91435

>From 32e3c974d5f3f5651c5805210a7215af4d6df24b Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Wed, 8 May 2024 09:31:32 +0300
Subject: [PATCH] [clang] Add examples from [dcl.init.aggr] to C++ conformance
 tests

---
 clang/test/CXX/dcl/dcl.init/aggr.cpp | 294 +++
 1 file changed, 294 insertions(+)
 create mode 100644 clang/test/CXX/dcl/dcl.init/aggr.cpp

diff --git a/clang/test/CXX/dcl/dcl.init/aggr.cpp 
b/clang/test/CXX/dcl/dcl.init/aggr.cpp
new file mode 100644
index 0..3206d2e7f616a
--- /dev/null
+++ b/clang/test/CXX/dcl/dcl.init/aggr.cpp
@@ -0,0 +1,294 @@
+// RUN:  %clang_cc1 -std=c++2c -verify %s
+
+namespace ex1 {
+struct C {
+  union {
+int a;
+const char* p;
+  };
+  int x;
+};
+
+constexpr C c = { .a = 1, .x = 3 };
+static_assert(c.a == 1);
+static_assert(c.x == 3);
+
+static constexpr C c2 = { .a = 1.0, .x = 3 };
+// expected-error@-1 {{type 'double' cannot be narrowed to 'int' in 
initializer list}}
+//   expected-note@-2 {{insert an explicit cast to silence this issue}}
+} // namespace ex1
+
+namespace ex2 {
+struct A {
+  int x;
+  struct B {
+int i;
+int j;
+  } b;
+};
+
+constexpr A a = { 1, { 2, 3 } };
+static_assert(a.x == 1);
+static_assert(a.b.i == 2);
+static_assert(a.b.j == 3);
+
+struct base1 { int b1, b2 = 42; };
+struct base2 {
+  constexpr base2() {
+b3 = 43;
+  }
+  int b3;
+};
+struct derived : base1, base2 {
+  int d;
+};
+
+constexpr derived d1{{1, 2}, {}, 4};
+static_assert(d1.b1 == 1);
+static_assert(d1.b2 == 2);
+static_assert(d1.b3 == 43);
+static_assert(d1.d == 4);
+
+constexpr derived d2{{}, {}, 4};
+static_assert(d2.b1 == 0);
+static_assert(d2.b2 == 42);
+static_assert(d2.b3 == 43);
+static_assert(d2.d == 4);
+} // namespace ex2
+
+namespace ex3 {
+struct S {
+  int a;
+  const char* b;
+  int c;
+  int d = b[a];
+};
+
+constexpr S ss = { 1, "asdf" };
+static_assert(ss.a == 1);
+static_assert(__builtin_strcmp(ss.b, "asdf") == 0);
+static_assert(ss.c == int{});
+static_assert(ss.d == ss.b[ss.a]);
+
+struct string {
+  int d = 43;
+};
+
+struct A {
+  string a;
+  int b = 42;
+  int c = -1;
+};
+
+constexpr A a{.c = 21};
+static_assert(a.a.d == string{}.d);
+static_assert(a.b == 42);
+static_assert(a.c == 21);
+} // namespace ex3
+
+namespace ex4 {
+int x[] = { 1, 3, 5 };
+static_assert(sizeof(x) / sizeof(int) == 3);
+} // namespace ex4
+
+namespace ex5 {
+struct X { int i, j, k; };
+
+constexpr X a[] = { 1, 2, 3, 4, 5, 6 };
+constexpr X b[2] = { { 1, 2, 3 }, { 4, 5, 6 } };
+static_assert(sizeof(a) == sizeof(b));
+static_assert(a[0].i == b[0].i);
+static_assert(a[0].j == b[0].j);
+static_assert(a[0].k == b[0].k);
+static_assert(a[1].i == b[1].i);
+static_assert(a[1].j == b[1].j);
+static_assert(a[1].k == b[1].k);
+} // namespace ex5
+
+namespace ex6 {
+struct S {
+  int y[] = { 0 };
+  // expected-error@-1 {{array bound cannot be deduced from a default member 
initializer}}
+};
+} // namespace ex6
+
+namespace ex7 {
+struct A {
+  int i;
+  static int s;
+  int j;
+  int :17;
+  int k;
+};
+
+constexpr A a = { 1, 2, 3 };
+static_assert(a.i == 1);
+static_assert(a.j == 2);
+static_assert(a.k == 3);
+} // namespace ex7
+
+namespace ex8 {
+struct A;
+extern A a;
+struct A {
+  const A& a1 { A{a,a} };
+  const A& a2 { A{} };
+  // expected-error@-1 {{default member initializer for 'a2' needed within 
definition of enclosing class 'A' outside of member functions}}
+  //   expected-note@-2 {{default member initializer declared here}}
+};
+A a{a,a};
+
+struct B {
+  int n = B{}.n;
+  // expected-error@-1 {{default member initializer for 'n' needed within 
definition of enclosing class 'B' outside of member functions}}
+  //   expected-note@-2 {{default member initializer declared here}}
+};
+} // namespace ex8
+
+namespace ex9 {
+constexpr int x[2][2] = { 3, 1, 4, 2 };
+static_assert(x[0][0] == 3);
+static_assert(x[0][1] == 1);
+static_assert(x[1][0] == 4);
+static_assert(x[1][1] == 2);
+
+constexpr float y[4][3] = {
+  { 1 }, { 2 }, { 3 }, { 4 }
+};
+static_assert(y[0][0] == 1);
+static_assert(y[0][1] == 0);
+static_assert(y[0][2] == 0);
+static_assert(y[1][0] == 2);
+static_assert(y[1][1] == 0);
+static_assert(y[1][2] == 0);
+static_assert(y[2][0] == 3);
+static_assert(y[2][1] == 0);
+static_assert(y[2][2] == 0);
+static_assert(y[3][0] == 4);
+static_assert(y[3][1] == 0);
+static_assert(y[3][2] == 0);
+} // namespace ex9
+
+namespace ex10 {
+struct S1 { int a, b; };
+struct S2 { S1 s, t; };
+
+constexpr S2 x[2] = { 1, 2, 3, 4, 5, 6, 7, 8 };
+constexpr S2 y[2] = {
+  {
+{ 1, 2 },
+{ 3, 4 }
+  },
+  {
+{ 5, 6 },
+{ 7, 8 }
+  }
+};
+static_assert(x[0].s.a == 1);
+static_assert(x[0].s.b == 2);
+static_assert(x[0].t.a == 3);
+static_assert(x[0].t.b == 4);
+static_assert(x[1].s.a == 5);
+static_assert(x[1].s.b == 6);
+static_assert(x[1].t.a == 7);
+static_assert(x[1].t.b == 8);
+} // namespace ex10
+
+namespace ex11 {

[clang] [Clang][Sema] Fix lookup of dependent operator= named by using-declaration (PR #91503)

[Vlad Serebrennikov via cfe-commits]

@@ -137,17 +137,16 @@ namespace InhCtor {
   int n = b.T(); // expected-error {{'T' is a protected member of 
'InhCtor::A'}}
  // expected-note@-15 {{declared protected here}}
 
-  // FIXME: EDG and GCC reject this too, but it's not clear why it would be
-  // ill-formed.
   template
   struct S : T {
-struct U : S { // expected-note 6{{candidate}}
+// FIXME: S is incomplete here and we should diagnose this!
+struct U : S {

Endilll wrote:

There are somewhat related CWG issues 
[45](https://cplusplus.github.io/CWG/issues/45.html), 
[374](https://cplusplus.github.io/CWG/issues/347.html), and 
[500](https://cplusplus.github.io/CWG/issues/500.html), but I can't find one 
arguing that base specifiers should become a complete-class context. 
http://eel.is/c++draft/class#mem.general-8 seems quite clear on this.

https://github.com/llvm/llvm-project/pull/91503
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Enable C++17 relaxed template template argument matching by default (PR #89807)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

@bgra8 Your reduction has names replaced by the tool. This is quite hard to 
work with. Can you reduce again, but with renaming passes disabled?
I uploaded your reproducer to CE: https://godbolt.org/z/9PK1oPoPW

https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Enable C++17 relaxed template template argument matching by default (PR #89807)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

If you're using `creduce`, this set of arguments disables all renaming passes: 
`--remove-pass pass_clang rename-fun --remove-pass pass_clang rename-param 
--remove-pass pass_clang rename-var --remove-pass pass_clang rename-class 
--remove-pass pass_clang rename-cxx-method --remove-pass pass_clex rename-toks`

https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][NFC] Add examples from [dcl.init.aggr] to C++ conformance tests (PR #91435)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll closed 
https://github.com/llvm/llvm-project/pull/91435
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Fix Undefined Behavior introduced by #91199 (PR #91718)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll approved this pull request.

LGTM
You should leave a link in the description to the buildbot failure you're 
addressing.

https://github.com/llvm/llvm-project/pull/91718
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema] Fix handling of fields with initializers in nested anonymous unions. (PR #91692)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll approved this pull request.

LGTM, but someone else should take a look as well.

https://github.com/llvm/llvm-project/pull/91692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Explicit template arguments are not substituted into the exception specification of a function (PR #90760)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

Changes to DR tests look good to me.

https://github.com/llvm/llvm-project/pull/90760
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Implement provisional wording for CWG2398 regarding packs (PR #90820)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

This file is not going to be picked up by the `make_cxx_dr_status`, because 
it's not in `clang/test/CXX/drs`. If we're implementing what Jason Merill 
speaks of (_In deduction we can determine that P is more specialized than B, 
then substitute B into P, and then compare B to B_), then I 
agree with `// cwg2398: 19 drafting 2016-12-03` marking.

In the previous PR on this topic I asked for this test to be moved out of DR 
test suite, because it was testing with `-fno-relaxed-template-template-args`, 
which is not a conformance mode. This still holds, so this file can't be simply 
moved to DR test suite as is.

I also don't see why CWG2398 test can't be placed in `dr23xx.cpp`. We place DR 
tests in separate files only if they require special handling. Typical case is 
codegen tests. Note that special handling doesn't mean testing non-conformance 
modes, or reduced number of conformance modes.

https://github.com/llvm/llvm-project/pull/90820
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Implement provisional wording for CWG2398 regarding packs (PR #90820)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

> Also, this needs to test a non-conforming mode until we finally remove the 
> corresponding flag, and that is against the rules for the DR suite.

You should be able to split conforming part of the test into DR test, though.

https://github.com/llvm/llvm-project/pull/90820
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Implement provisional wording for CWG2398 regarding packs (PR #90820)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

`Sema.h` changes look good to me.

https://github.com/llvm/llvm-project/pull/90820
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [BoundsSafety] Allow 'counted_by' attribute on pointers in structs in C (PR #90786)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

`Sema.h` changes look good to me.

https://github.com/llvm/llvm-project/pull/90786
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Implement provisional wording for CWG2398 regarding packs (PR #90820)

[Vlad Serebrennikov via cfe-commits]

Endilll wrote:

> Sounds like should perhaps note that we are implementing our own resolution, 
> until there's an update to the cwg issue that can be referred to?

Our tooling is not ready for describing own own resolutions, unfortunately. 
Ideally if we have a resolution, it should be submitted to CWG and documented 
in the issue, making it easy to reference.

https://github.com/llvm/llvm-project/pull/90820
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Improve support for explicit specializations of constrained member functions & member function templates (PR #88963)

[Vlad Serebrennikov via cfe-commits]

@@ -9739,6 +9739,9 @@ class Sema final : public SemaBase {
  const PartialDiagnostic ,
  bool Complain = true, QualType TargetType = QualType());
 
+  FunctionDecl *getMoreConstrainedFunction(FunctionDecl *FD1,

Endilll wrote:

You put this declaration into `SemaTemplateDeclaration` section of `Sema.h`, 
but the function is implemented in `SemaTemplate.cpp`. They should be in sync.

https://github.com/llvm/llvm-project/pull/88963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] d358b2d - [clang][NFC] Rename C++ CWG DR test files to use `cwg` prefix

[Vlad Serebrennikov via cfe-commits]

Author: Vlad Serebrennikov
Date: 2024-05-10T19:00:20+03:00
New Revision: d358b2de458e0611a3f474a9c3e3deff926c07c4

URL: 
https://github.com/llvm/llvm-project/commit/d358b2de458e0611a3f474a9c3e3deff926c07c4
DIFF: 
https://github.com/llvm/llvm-project/commit/d358b2de458e0611a3f474a9c3e3deff926c07c4.diff

LOG: [clang][NFC] Rename C++ CWG DR test files to use `cwg` prefix

This is a follow-up for ed128c7df9b4e60bfd814dc9fd22de1dde4a2c1c

Added: 
clang/test/CXX/drs/cwg0xx.cpp
clang/test/CXX/drs/cwg10xx.cpp
clang/test/CXX/drs/cwg11xx.cpp
clang/test/CXX/drs/cwg12xx.cpp
clang/test/CXX/drs/cwg13xx.cpp
clang/test/CXX/drs/cwg14xx.cpp
clang/test/CXX/drs/cwg15xx.cpp
clang/test/CXX/drs/cwg16xx.cpp
clang/test/CXX/drs/cwg17xx.cpp
clang/test/CXX/drs/cwg18xx.cpp
clang/test/CXX/drs/cwg19xx.cpp
clang/test/CXX/drs/cwg1xx.cpp
clang/test/CXX/drs/cwg20xx.cpp
clang/test/CXX/drs/cwg21xx.cpp
clang/test/CXX/drs/cwg22xx.cpp
clang/test/CXX/drs/cwg23xx.cpp
clang/test/CXX/drs/cwg24xx.cpp
clang/test/CXX/drs/cwg25xx.cpp
clang/test/CXX/drs/cwg26xx.cpp
clang/test/CXX/drs/cwg27xx.cpp
clang/test/CXX/drs/cwg28xx.cpp
clang/test/CXX/drs/cwg2xx.cpp
clang/test/CXX/drs/cwg3xx.cpp
clang/test/CXX/drs/cwg4xx.cpp
clang/test/CXX/drs/cwg5xx.cpp
clang/test/CXX/drs/cwg6xx.cpp
clang/test/CXX/drs/cwg7xx.cpp
clang/test/CXX/drs/cwg8xx.cpp
clang/test/CXX/drs/cwg9xx.cpp

Modified: 


Removed: 
clang/test/CXX/drs/dr0xx.cpp
clang/test/CXX/drs/dr10xx.cpp
clang/test/CXX/drs/dr11xx.cpp
clang/test/CXX/drs/dr12xx.cpp
clang/test/CXX/drs/dr13xx.cpp
clang/test/CXX/drs/dr14xx.cpp
clang/test/CXX/drs/dr15xx.cpp
clang/test/CXX/drs/dr16xx.cpp
clang/test/CXX/drs/dr17xx.cpp
clang/test/CXX/drs/dr18xx.cpp
clang/test/CXX/drs/dr19xx.cpp
clang/test/CXX/drs/dr1xx.cpp
clang/test/CXX/drs/dr20xx.cpp
clang/test/CXX/drs/dr21xx.cpp
clang/test/CXX/drs/dr22xx.cpp
clang/test/CXX/drs/dr23xx.cpp
clang/test/CXX/drs/dr24xx.cpp
clang/test/CXX/drs/dr25xx.cpp
clang/test/CXX/drs/dr26xx.cpp
clang/test/CXX/drs/dr27xx.cpp
clang/test/CXX/drs/dr28xx.cpp
clang/test/CXX/drs/dr2xx.cpp
clang/test/CXX/drs/dr3xx.cpp
clang/test/CXX/drs/dr4xx.cpp
clang/test/CXX/drs/dr5xx.cpp
clang/test/CXX/drs/dr6xx.cpp
clang/test/CXX/drs/dr7xx.cpp
clang/test/CXX/drs/dr8xx.cpp
clang/test/CXX/drs/dr9xx.cpp



diff  --git a/clang/test/CXX/drs/dr0xx.cpp b/clang/test/CXX/drs/cwg0xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr0xx.cpp
rename to clang/test/CXX/drs/cwg0xx.cpp

diff  --git a/clang/test/CXX/drs/dr10xx.cpp b/clang/test/CXX/drs/cwg10xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr10xx.cpp
rename to clang/test/CXX/drs/cwg10xx.cpp

diff  --git a/clang/test/CXX/drs/dr11xx.cpp b/clang/test/CXX/drs/cwg11xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr11xx.cpp
rename to clang/test/CXX/drs/cwg11xx.cpp

diff  --git a/clang/test/CXX/drs/dr12xx.cpp b/clang/test/CXX/drs/cwg12xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr12xx.cpp
rename to clang/test/CXX/drs/cwg12xx.cpp

diff  --git a/clang/test/CXX/drs/dr13xx.cpp b/clang/test/CXX/drs/cwg13xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr13xx.cpp
rename to clang/test/CXX/drs/cwg13xx.cpp

diff  --git a/clang/test/CXX/drs/dr14xx.cpp b/clang/test/CXX/drs/cwg14xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr14xx.cpp
rename to clang/test/CXX/drs/cwg14xx.cpp

diff  --git a/clang/test/CXX/drs/dr15xx.cpp b/clang/test/CXX/drs/cwg15xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr15xx.cpp
rename to clang/test/CXX/drs/cwg15xx.cpp

diff  --git a/clang/test/CXX/drs/dr16xx.cpp b/clang/test/CXX/drs/cwg16xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr16xx.cpp
rename to clang/test/CXX/drs/cwg16xx.cpp

diff  --git a/clang/test/CXX/drs/dr17xx.cpp b/clang/test/CXX/drs/cwg17xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr17xx.cpp
rename to clang/test/CXX/drs/cwg17xx.cpp

diff  --git a/clang/test/CXX/drs/dr18xx.cpp b/clang/test/CXX/drs/cwg18xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr18xx.cpp
rename to clang/test/CXX/drs/cwg18xx.cpp

diff  --git a/clang/test/CXX/drs/dr19xx.cpp b/clang/test/CXX/drs/cwg19xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr19xx.cpp
rename to clang/test/CXX/drs/cwg19xx.cpp

diff  --git a/clang/test/CXX/drs/dr1xx.cpp b/clang/test/CXX/drs/cwg1xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr1xx.cpp
rename to clang/test/CXX/drs/cwg1xx.cpp

diff  --git a/clang/test/CXX/drs/dr20xx.cpp b/clang/test/CXX/drs/cwg20xx.cpp
similarity index 100%
rename from clang/test/CXX/drs/dr20xx.cpp
rename to clang/test/CXX/drs/cwg20xx.cpp

diff  --git a/clang/test/CXX/drs/dr21xx.cpp b/clang/test/CXX/drs/cwg21xx.cpp
similarity 

[clang] [clang] Add test for CWG1820 "Qualified typedef names" (PR #91765)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll created 
https://github.com/llvm/llvm-project/pull/91765

[P1787R6](https://wg21.link/p1787r6):
> [CWG1820](https://cplusplus.github.io/CWG/issues/1820.html) is resolved by 
> requiring that a qualified declarator-id declare an entity.

P1787R6 changes wording of [dcl.pre]/9. Quote from the current draft 
([[dcl.pre]/5](https://eel.is/c++draft/dcl.pre#5)):
> If a 
> [declarator-id](https://eel.is/c++draft/dcl.decl.general#nt:declarator-id) is 
> a name, the 
> [init-declarator](https://eel.is/c++draft/dcl.decl.general#nt:init-declarator)
>  and (hence) the declaration introduce that 
> name[.](https://eel.is/c++draft/dcl.pre#5.sentence-1)
> [Note [3](https://eel.is/c++draft/dcl.pre#note-3): Otherwise, the 
> [declarator-id](https://eel.is/c++draft/dcl.decl.general#nt:declarator-id) is 
> a [qualified-id](https://eel.is/c++draft/expr.prim.id.qual#nt:qualified-id) 
> or names a destructor or its 
> [unqualified-id](https://eel.is/c++draft/expr.prim.id.unqual#nt:unqualified-id)
>  is a [template-id](https://eel.is/c++draft/temp.names#nt:template-id) and no 
> name is introduced[.](https://eel.is/c++draft/dcl.pre#5.sentence-2)
— end note]

>From 79bc0e14c20f0326a63860c06e2a76fbc503c41b Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Fri, 10 May 2024 19:30:08 +0300
Subject: [PATCH] [clang] Add test for CWG1820

---
 clang/test/CXX/drs/cwg18xx.cpp | 47 ++
 clang/www/cxx_dr_status.html   |  2 +-
 2 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/clang/test/CXX/drs/cwg18xx.cpp b/clang/test/CXX/drs/cwg18xx.cpp
index 3a2248a1af551..ea322ff4c8be1 100644
--- a/clang/test/CXX/drs/cwg18xx.cpp
+++ b/clang/test/CXX/drs/cwg18xx.cpp
@@ -222,6 +222,53 @@ namespace cwg1815 { // cwg1815: no
 #endif
 }
 
+namespace cwg1820 { // cwg1820: 3.5
+typedef int A;
+typedef int cwg1820::A;
+// expected-warning@-1 {{extra qualification on member 'A'}}
+// expected-error@-2 {{typedef declarator cannot be qualified}}
+
+namespace B {
+typedef int cwg1820::A;
+// expected-error@-1 {{cannot define or redeclare 'A' here because namespace 
'B' does not enclose namespace 'cwg1820'}}
+// expected-error@-2 {{typedef declarator cannot be qualified}}
+}
+
+class C1 {
+  typedef int cwg1820::A;
+  // expected-error@-1 {{non-friend class member 'A' cannot have a qualified 
name}}
+  // expected-error@-2 {{typedef declarator cannot be qualified}}
+};
+
+template 
+class C2 {
+  typedef int cwg1820::A;
+  // expected-error@-1 {{non-friend class member 'A' cannot have a qualified 
name}}
+  // expected-error@-2 {{typedef declarator cannot be qualified}}
+};
+
+void d1() {
+  typedef int cwg1820::A;
+  // expected-error@-1 {{definition or redeclaration of 'A' not allowed inside 
a function}}
+  // expected-error@-2 {{typedef declarator cannot be qualified}}
+}
+
+template
+void d2() {
+  typedef int cwg1820::A;
+  // expected-error@-1 {{definition or redeclaration of 'A' not allowed inside 
a function}}
+  // expected-error@-2 {{typedef declarator cannot be qualified}}
+}
+
+#if __cplusplus >= 201103L
+auto e = [] {
+  typedef int cwg1820::A;
+  // expected-error@-1 {{definition or redeclaration of 'A' not allowed inside 
a function}}
+  // expected-error@-2 {{typedef declarator cannot be qualified}}
+};
+#endif
+} // namespace cwg1820
+
 namespace cwg1821 { // cwg1821: 2.9
 struct A {
   template  struct B {
diff --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index 992dc61d65e42..12ab59224e82e 100755
--- a/clang/www/cxx_dr_status.html
+++ b/clang/www/cxx_dr_status.html
@@ -10728,7 +10728,7 @@ C++ defect report implementation 
status
 https://cplusplus.github.io/CWG/issues/1820.html;>1820
 CD6
 Qualified typedef names
-Unknown
+Clang 3.5
   
   
 https://cplusplus.github.io/CWG/issues/1821.html;>1821

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] ef71c79 - [clang][NFC] Update C++ DR status page

[Vlad Serebrennikov via cfe-commits]

Author: Vlad Serebrennikov
Date: 2024-05-10T19:03:21+03:00
New Revision: ef71c79d85fb3f94f19a92a84ab44719d112c1bd

URL: 
https://github.com/llvm/llvm-project/commit/ef71c79d85fb3f94f19a92a84ab44719d112c1bd
DIFF: 
https://github.com/llvm/llvm-project/commit/ef71c79d85fb3f94f19a92a84ab44719d112c1bd.diff

LOG: [clang][NFC] Update C++ DR status page

Added: 


Modified: 
clang/www/cxx_dr_status.html

Removed: 




diff  --git a/clang/www/cxx_dr_status.html b/clang/www/cxx_dr_status.html
index 875521bd505d5..992dc61d65e42 100755
--- a/clang/www/cxx_dr_status.html
+++ b/clang/www/cxx_dr_status.html
@@ -16823,7 +16823,7 @@ C++ defect report implementation 
status
   
   
 https://cplusplus.github.io/CWG/issues/2836.html;>2836
-review
+tentatively ready
 Conversion rank of long double and extended floating-point 
types
 Not resolved
   
@@ -16997,7 +16997,7 @@ C++ defect report implementation 
status
   
   
 https://cplusplus.github.io/CWG/issues/2865.html;>2865
-open
+tentatively ready
 Regression on result of conditional operator
 Not resolved
   
@@ -17009,7 +17009,7 @@ C++ defect report implementation 
status
   
   
 https://cplusplus.github.io/CWG/issues/2867.html;>2867
-open
+review
 Order of initialization for structured bindings
 Not resolved
   
@@ -17126,6 +17126,18 @@ C++ defect report implementation 
status
 open
 Temporaries and trivial potentially-throwing special member 
functions
 Not resolved
+  
+  
+https://cplusplus.github.io/CWG/issues/2887.html;>2887
+open
+Missing compatibility entries for xvalues
+Not resolved
+  
+  
+https://cplusplus.github.io/CWG/issues/2888.html;>2888
+open
+Missing cases for reference and array types for argument-dependent 
lookup
+Not resolved
   
 
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Add test for CWG1820 "Qualified typedef names" (PR #91765)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll closed 
https://github.com/llvm/llvm-project/pull/91765
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Introduce `SemaObjC` (PR #89086)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll closed 
https://github.com/llvm/llvm-project/pull/89086
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Don't wrap immediate invocations in ConstantExprs within constexpr initializers (PR #89565)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

`Sema.h` changes look good.

https://github.com/llvm/llvm-project/pull/89565
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang][Sema] Explicit template arguments are not substituted into the exception specification of a function (PR #90760)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll commented:

DR tests changes LGTM

https://github.com/llvm/llvm-project/pull/90760
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits