date:20211125

[PATCH] D113118: [clang][AST] Check context of record in structural equivalence.

2021-11-25 Thread Balázs Kéri via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8e8658b19c05: [clang][AST] Check context of record in 
structural equivalence. (authored by balazske).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113118/new/

https://reviews.llvm.org/D113118

Files:
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/unittests/AST/StructuralEquivalenceTest.cpp

Index: clang/unittests/AST/StructuralEquivalenceTest.cpp
===
--- clang/unittests/AST/StructuralEquivalenceTest.cpp
+++ clang/unittests/AST/StructuralEquivalenceTest.cpp
@@ -929,6 +929,128 @@
   EXPECT_TRUE(testStructuralMatch(First, Second));
 }
 
+struct StructuralEquivalenceRecordContextTest : StructuralEquivalenceTest {};
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNoVsNamed) {
+  auto Decls =
+  makeNamedDecls("class X;", "namespace N { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNamedVsNamed) {
+  auto Decls = makeNamedDecls("namespace A { class X; }",
+  "namespace B { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceAnonVsNamed) {
+  auto Decls = makeNamedDecls("namespace { class X; }",
+  "namespace N { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNoVsAnon) {
+  auto Decls =
+  makeNamedDecls("class X;", "namespace { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceAnonVsAnon) {
+  auto Decls = makeNamedDecls("namespace { class X; }",
+  "namespace { class X; }", Lang_CXX03, "X");
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceAnonVsAnonAnon) {
+  auto Decls =
+  makeNamedDecls("namespace { class X; }",
+ "namespace { namespace { class X; } }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest,
+   NamespaceNamedNamedVsNamedNamed) {
+  auto Decls = makeNamedDecls("namespace A { namespace N { class X; } }",
+  "namespace B { namespace N { class X; } }",
+  Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNamedVsInline) {
+  auto Decls = makeNamedDecls("namespace A { namespace A { class X; } }",
+  "namespace A { inline namespace A { class X; } }",
+  Lang_CXX17, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceInlineVsInline) {
+  auto Decls = makeNamedDecls("namespace A { inline namespace A { class X; } }",
+  "namespace A { inline namespace B { class X; } }",
+  Lang_CXX17, "X");
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceInlineTopLevel) {
+  auto Decls =
+  makeNamedDecls("inline namespace A { class X; } }",
+ "inline namespace B { class X; } }", Lang_CXX17, "X");
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, TransparentContext) {
+  auto Decls =
+  makeNamedDecls("extern \"C\" { class X; }", "class X;", Lang_CXX03, "X");
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, TransparentContextNE) {
+  auto Decls = makeNamedDecls("extern \"C\" { class X; }",
+  "namespace { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, TransparentContextInNamespace) {
+  auto Decls = makeNamedDecls("extern \"C\" { namespace N { class X; } }",
+  "namespace N { extern \"C\" { class X; } }",
+  Lang_CXX03, "X");
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceTest, NamespaceOfRecordMember) {
+  auto Decls = makeNamedDecls(
+  R"(
+  class X;
+  class Y { X* x; };
+  )",
+  R"(
+  namespace N { class X; }
+  class Y { N::X* x; };
+  )",
+  Lang_CXX03, "Y");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceTest, StructDefinitionInPrototype) {
+  auto Decls =
+  makeNamedDecls("struct Param { int a; }; void foo(struct Param *p);",
+ "void foo(struct Param { int a; } *p);", Lang_C89);
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+

[clang] 8e8658b - [clang][AST] Check context of record in structural equivalence.

2021-11-25 Thread Balázs Kéri via cfe-commits


Author: Balázs Kéri
Date: 2021-11-26T08:54:34+01:00
New Revision: 8e8658b19c057a48264514483f188bf7b6c2db7d

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

LOG: [clang][AST] Check context of record in structural equivalence.

The AST structural equivalence check did not differentiate between
a struct and a struct with same name in different namespace. When
type of a member is checked it is possible to encounter such a case
and wrongly decide that the types are similar. This problem is fixed
by check for the namespaces of a record declaration.

Reviewed By: martong

Differential Revision: https://reviews.llvm.org/D113118

Added: 


Modified: 
clang/lib/AST/ASTStructuralEquivalence.cpp
clang/unittests/AST/StructuralEquivalenceTest.cpp

Removed: 




diff  --git a/clang/lib/AST/ASTStructuralEquivalence.cpp 
b/clang/lib/AST/ASTStructuralEquivalence.cpp
index e85feb779190f..7fd24e2aa9ad2 100644
--- a/clang/lib/AST/ASTStructuralEquivalence.cpp
+++ b/clang/lib/AST/ASTStructuralEquivalence.cpp
@@ -1347,6 +1347,42 @@ 
IsStructurallyEquivalentLambdas(StructuralEquivalenceContext ,
   return true;
 }
 
+/// Determine if context of a class is equivalent.
+static bool IsRecordContextStructurallyEquivalent(RecordDecl *D1,
+  RecordDecl *D2) {
+  // The context should be completely equal, including anonymous and inline
+  // namespaces.
+  // We compare objects as part of full translation units, not subtrees of
+  // translation units.
+  DeclContext *DC1 = D1->getDeclContext()->getNonTransparentContext();
+  DeclContext *DC2 = D2->getDeclContext()->getNonTransparentContext();
+  while (true) {
+// Special case: We allow a struct defined in a function to be equivalent
+// with a similar struct defined outside of a function.
+if ((DC1->isFunctionOrMethod() && DC2->isTranslationUnit()) ||
+(DC2->isFunctionOrMethod() && DC1->isTranslationUnit()))
+  return true;
+
+if (DC1->getDeclKind() != DC2->getDeclKind())
+  return false;
+if (DC1->isTranslationUnit())
+  break;
+if (DC1->isInlineNamespace() != DC2->isInlineNamespace())
+  return false;
+if (const auto *ND1 = dyn_cast(DC1)) {
+  const auto *ND2 = cast(DC2);
+  if (!DC1->isInlineNamespace() &&
+  !IsStructurallyEquivalent(ND1->getIdentifier(), 
ND2->getIdentifier()))
+return false;
+}
+
+DC1 = DC1->getParent()->getNonTransparentContext();
+DC2 = DC2->getParent()->getNonTransparentContext();
+  }
+
+  return true;
+}
+
 /// Determine structural equivalence of two records.
 static bool IsStructurallyEquivalent(StructuralEquivalenceContext ,
  RecordDecl *D1, RecordDecl *D2) {
@@ -1386,6 +1422,12 @@ static bool 
IsStructurallyEquivalent(StructuralEquivalenceContext ,
 }
   }
 
+  // If the records occur in 
diff erent context (namespace), these should be
+  // 
diff erent. This is specially important if the definition of one or both
+  // records is missing.
+  if (!IsRecordContextStructurallyEquivalent(D1, D2))
+return false;
+
   // If both declarations are class template specializations, we know
   // the ODR applies, so check the template and template arguments.
   const auto *Spec1 = dyn_cast(D1);

diff  --git a/clang/unittests/AST/StructuralEquivalenceTest.cpp 
b/clang/unittests/AST/StructuralEquivalenceTest.cpp
index 9ae0da8b9dd2c..a1b506c3c28d9 100644
--- a/clang/unittests/AST/StructuralEquivalenceTest.cpp
+++ b/clang/unittests/AST/StructuralEquivalenceTest.cpp
@@ -929,6 +929,128 @@ TEST_F(StructuralEquivalenceTest, ExplicitBoolSame) {
   EXPECT_TRUE(testStructuralMatch(First, Second));
 }
 
+struct StructuralEquivalenceRecordContextTest : StructuralEquivalenceTest {};
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNoVsNamed) {
+  auto Decls =
+  makeNamedDecls("class X;", "namespace N { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNamedVsNamed) {
+  auto Decls = makeNamedDecls("namespace A { class X; }",
+  "namespace B { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceAnonVsNamed) {
+  auto Decls = makeNamedDecls("namespace { class X; }",
+  "namespace N { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNoVsAnon) {
+  auto Decls =
+  makeNamedDecls("class X;", "namespace { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest,

[PATCH] D114522: [clangd] Add desugared type to hover

2021-11-25 Thread liu hui via Phabricator via cfe-commits

lh123 updated this revision to Diff 389924.
lh123 added a comment.

rename `TTP` to `TAT`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114522/new/

https://reviews.llvm.org/D114522

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/Hover.h
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang/include/clang/AST/ASTDiagnostic.h
  clang/lib/AST/ASTDiagnostic.cpp

Index: clang/lib/AST/ASTDiagnostic.cpp
===
--- clang/lib/AST/ASTDiagnostic.cpp
+++ clang/lib/AST/ASTDiagnostic.cpp
@@ -26,7 +26,7 @@
 
 // Returns a desugared version of the QualType, and marks ShouldAKA as true
 // whenever we remove significant sugar from the type.
-static QualType Desugar(ASTContext , QualType QT, bool ) {
+QualType clang::Desugar(ASTContext , QualType QT, bool ) {
   QualifierCollector QC;
 
   while (true) {
Index: clang/include/clang/AST/ASTDiagnostic.h
===
--- clang/include/clang/AST/ASTDiagnostic.h
+++ clang/include/clang/AST/ASTDiagnostic.h
@@ -9,6 +9,7 @@
 #ifndef LLVM_CLANG_AST_ASTDIAGNOSTIC_H
 #define LLVM_CLANG_AST_ASTDIAGNOSTIC_H
 
+#include "clang/AST/Type.h"
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/DiagnosticAST.h"
 
@@ -31,6 +32,10 @@
   SmallVectorImpl ,
   void *Cookie,
   ArrayRef QualTypeVals);
+
+  /// Returns a desugared version of the QualType, and marks ShouldAKA as true
+  /// whenever we remove significant sugar from the type.
+  QualType Desugar(ASTContext , QualType QT, bool );
 }  // end namespace clang
 
 #endif
Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -45,8 +45,8 @@
  HI.Kind = index::SymbolKind::Function;
  HI.Documentation = "Best foo ever.";
  HI.Definition = "void foo()";
- HI.ReturnType = "void";
- HI.Type = "void ()";
+ HI.ReturnType = {"void", llvm::None};
+ HI.Type = {"void ()", llvm::None};
  HI.Parameters.emplace();
}},
   // Inside namespace
@@ -62,8 +62,8 @@
  HI.Kind = index::SymbolKind::Function;
  HI.Documentation = "Best foo ever.";
  HI.Definition = "void foo()";
- HI.ReturnType = "void";
- HI.Type = "void ()";
+ HI.ReturnType = {"void", llvm::None};
+ HI.Type = {"void ()", llvm::None};
  HI.Parameters.emplace();
}},
   // Field
@@ -81,7 +81,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Offset = 0;
  HI.Size = 1;
  HI.Padding = 7;
@@ -100,7 +100,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Size = 1;
  HI.Padding = 15;
  HI.AccessSpecifier = "public";
@@ -118,7 +118,7 @@
  HI.Name = "x";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "int x : 1";
- HI.Type = "int";
+ HI.Type = {"int", llvm::None};
  HI.AccessSpecifier = "public";
}},
   // Local to class method.
@@ -137,7 +137,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Variable;
  HI.Definition = "int bar";
- HI.Type = "int";
+ HI.Type = {"int", llvm::None};
}},
   // Anon namespace and local scope.
   {R"cpp(
@@ -153,7 +153,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Offset = 0;
  HI.Size = 1;
  HI.AccessSpecifier = "public";
@@ -179,7 +179,7 @@
  HI.Name = "foo";
  HI.Kind = index::SymbolKind::Variable;
  HI.Definition = "Foo foo = Foo(5)";
- HI.Type = "Foo";
+ HI.Type = {"Foo", llvm::None};
}},
   // Implicit template instantiation
   {R"cpp(
@@ -211,12 +211,19 @@
   bool Q = false, class... Ts>
 class Foo {})cpp";
  HI.TemplateParameters = {
- {std::string("template  class"),
-  std::string("C"), llvm::None},
- {std::string("typename"), llvm::None, std::string("char")},
- {std::string("int"), llvm::None, std::string("0")},
- {std::string("bool"), std::string("Q"), std::string("false")},
- {std::string("class..."), std::string("Ts"), llvm::None},
+ {{{std::string("template  class"), llvm::None}},
+  std::string("C"),
+  llvm::None},
+

[PATCH] D114522: [clangd] Add desugared type to hover

2021-11-25 Thread liu hui via Phabricator via cfe-commits

lh123 updated this revision to Diff 389921.
lh123 added a comment.

handle `TypeAliasTemplateDecl`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114522/new/

https://reviews.llvm.org/D114522

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/Hover.h
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang/include/clang/AST/ASTDiagnostic.h
  clang/lib/AST/ASTDiagnostic.cpp

Index: clang/lib/AST/ASTDiagnostic.cpp
===
--- clang/lib/AST/ASTDiagnostic.cpp
+++ clang/lib/AST/ASTDiagnostic.cpp
@@ -26,7 +26,7 @@
 
 // Returns a desugared version of the QualType, and marks ShouldAKA as true
 // whenever we remove significant sugar from the type.
-static QualType Desugar(ASTContext , QualType QT, bool ) {
+QualType clang::Desugar(ASTContext , QualType QT, bool ) {
   QualifierCollector QC;
 
   while (true) {
Index: clang/include/clang/AST/ASTDiagnostic.h
===
--- clang/include/clang/AST/ASTDiagnostic.h
+++ clang/include/clang/AST/ASTDiagnostic.h
@@ -9,6 +9,7 @@
 #ifndef LLVM_CLANG_AST_ASTDIAGNOSTIC_H
 #define LLVM_CLANG_AST_ASTDIAGNOSTIC_H
 
+#include "clang/AST/Type.h"
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/DiagnosticAST.h"
 
@@ -31,6 +32,10 @@
   SmallVectorImpl ,
   void *Cookie,
   ArrayRef QualTypeVals);
+
+  /// Returns a desugared version of the QualType, and marks ShouldAKA as true
+  /// whenever we remove significant sugar from the type.
+  QualType Desugar(ASTContext , QualType QT, bool );
 }  // end namespace clang
 
 #endif
Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -45,8 +45,8 @@
  HI.Kind = index::SymbolKind::Function;
  HI.Documentation = "Best foo ever.";
  HI.Definition = "void foo()";
- HI.ReturnType = "void";
- HI.Type = "void ()";
+ HI.ReturnType = {"void", llvm::None};
+ HI.Type = {"void ()", llvm::None};
  HI.Parameters.emplace();
}},
   // Inside namespace
@@ -62,8 +62,8 @@
  HI.Kind = index::SymbolKind::Function;
  HI.Documentation = "Best foo ever.";
  HI.Definition = "void foo()";
- HI.ReturnType = "void";
- HI.Type = "void ()";
+ HI.ReturnType = {"void", llvm::None};
+ HI.Type = {"void ()", llvm::None};
  HI.Parameters.emplace();
}},
   // Field
@@ -81,7 +81,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Offset = 0;
  HI.Size = 1;
  HI.Padding = 7;
@@ -100,7 +100,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Size = 1;
  HI.Padding = 15;
  HI.AccessSpecifier = "public";
@@ -118,7 +118,7 @@
  HI.Name = "x";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "int x : 1";
- HI.Type = "int";
+ HI.Type = {"int", llvm::None};
  HI.AccessSpecifier = "public";
}},
   // Local to class method.
@@ -137,7 +137,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Variable;
  HI.Definition = "int bar";
- HI.Type = "int";
+ HI.Type = {"int", llvm::None};
}},
   // Anon namespace and local scope.
   {R"cpp(
@@ -153,7 +153,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Offset = 0;
  HI.Size = 1;
  HI.AccessSpecifier = "public";
@@ -179,7 +179,7 @@
  HI.Name = "foo";
  HI.Kind = index::SymbolKind::Variable;
  HI.Definition = "Foo foo = Foo(5)";
- HI.Type = "Foo";
+ HI.Type = {"Foo", llvm::None};
}},
   // Implicit template instantiation
   {R"cpp(
@@ -211,12 +211,19 @@
   bool Q = false, class... Ts>
 class Foo {})cpp";
  HI.TemplateParameters = {
- {std::string("template  class"),
-  std::string("C"), llvm::None},
- {std::string("typename"), llvm::None, std::string("char")},
- {std::string("int"), llvm::None, std::string("0")},
- {std::string("bool"), std::string("Q"), std::string("false")},
- {std::string("class..."), std::string("Ts"), llvm::None},
+ {{{std::string("template  class"), llvm::None}},
+  std::string("C"),
+  llvm::None},
+

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

2021-11-25 Thread Bill Wendling via Phabricator via cfe-commits

void updated this revision to Diff 389922.
void added a comment.

WIP: Implement zeroing out registers.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110869/new/

https://reviews.llvm.org/D110869

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/zero-call-used-regs.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/zero_call_used_regs.c
  llvm/include/llvm/CodeGen/MachineRegisterInfo.h
  llvm/include/llvm/CodeGen/TargetFrameLowering.h
  llvm/include/llvm/CodeGen/TargetRegisterInfo.h
  llvm/include/llvm/Support/CodeGen.h
  llvm/lib/CodeGen/MachineRegisterInfo.cpp
  llvm/lib/CodeGen/PrologEpilogInserter.cpp
  llvm/lib/Target/X86/X86FrameLowering.cpp
  llvm/lib/Target/X86/X86FrameLowering.h
  llvm/lib/Target/X86/X86RegisterInfo.cpp
  llvm/lib/Target/X86/X86RegisterInfo.h
  llvm/test/CodeGen/X86/zero-call-used-regs-all-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all-gpr-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all-gpr.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-all.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-fmod.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-skip.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-smoke-tests.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr-arg.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
  llvm/test/CodeGen/X86/zero-call-used-regs-used.ll

Index: llvm/test/CodeGen/X86/zero-call-used-regs-used.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/zero-call-used-regs-used.ll
@@ -0,0 +1,28 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s
+
+@result = dso_local global i32 0, align 4
+
+define dso_local i32 @foo(i32 returned %x) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl %edi, %eax
+; CHECK-NEXT:xorl %edi, %edi
+; CHECK-NEXT:retq
+entry:
+  ret i32 %x
+}
+
+define dso_local i32 @main() local_unnamed_addr #1 {
+; CHECK-LABEL: main:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl $2, result(%rip)
+; CHECK-NEXT:xorl %eax, %eax
+; CHECK-NEXT:retq
+entry:
+  store volatile i32 2, i32* @result, align 4
+  ret i32 0
+}
+
+attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone uwtable willreturn "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used" }
+attributes #1 = { nofree norecurse nounwind uwtable "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used" }
Index: llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr.ll
@@ -0,0 +1,28 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu | FileCheck %s
+
+@result = dso_local global i32 0, align 4
+
+define dso_local i32 @foo(i32 returned %x) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl %edi, %eax
+; CHECK-NEXT:xorl %edi, %edi
+; CHECK-NEXT:retq
+entry:
+  ret i32 %x
+}
+
+define dso_local i32 @main() local_unnamed_addr #1 {
+; CHECK-LABEL: main:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:movl $2, result(%rip)
+; CHECK-NEXT:xorl %eax, %eax
+; CHECK-NEXT:retq
+entry:
+  store volatile i32 2, i32* @result, align 4
+  ret i32 0
+}
+
+attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone uwtable willreturn "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used-gpr" }
+attributes #1 = { nofree norecurse nounwind uwtable "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "zero-call-used-regs"="used-gpr" }
Index: llvm/test/CodeGen/X86/zero-call-used-regs-used-gpr-arg.ll
===
--- /dev/null
+++

[PATCH] D112881: [clang-tidy] Allow disabling integer to floating-point narrowing conversions for cppcoreguidelines-narrowing-conversions

2021-11-25 Thread Paul Altin via Phabricator via cfe-commits

paulaltin added a comment.

Ping.

I'm a bit stuck with this submission, any help or pointers on how to proceed 
(i.e. how to fix the pre-merge tests) would be much appreciated.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112881/new/

https://reviews.llvm.org/D112881

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

[PATCH] D114522: [clangd] Add desugared type to hover

2021-11-25 Thread liu hui via Phabricator via cfe-commits

lh123 updated this revision to Diff 389915.
lh123 retitled this revision from "[clangd] Add canonical type to hover" to 
"[clangd] Add desugared type to hover".
lh123 edited the summary of this revision.
lh123 added a comment.

1. rename `CanType` to `DesugaredTy`.
2. fix some bug in compare `PrintedType`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114522/new/

https://reviews.llvm.org/D114522

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/Hover.h
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang/include/clang/AST/ASTDiagnostic.h
  clang/lib/AST/ASTDiagnostic.cpp

Index: clang/lib/AST/ASTDiagnostic.cpp
===
--- clang/lib/AST/ASTDiagnostic.cpp
+++ clang/lib/AST/ASTDiagnostic.cpp
@@ -26,7 +26,7 @@
 
 // Returns a desugared version of the QualType, and marks ShouldAKA as true
 // whenever we remove significant sugar from the type.
-static QualType Desugar(ASTContext , QualType QT, bool ) {
+QualType clang::Desugar(ASTContext , QualType QT, bool ) {
   QualifierCollector QC;
 
   while (true) {
Index: clang/include/clang/AST/ASTDiagnostic.h
===
--- clang/include/clang/AST/ASTDiagnostic.h
+++ clang/include/clang/AST/ASTDiagnostic.h
@@ -9,6 +9,7 @@
 #ifndef LLVM_CLANG_AST_ASTDIAGNOSTIC_H
 #define LLVM_CLANG_AST_ASTDIAGNOSTIC_H
 
+#include "clang/AST/Type.h"
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/DiagnosticAST.h"
 
@@ -31,6 +32,10 @@
   SmallVectorImpl ,
   void *Cookie,
   ArrayRef QualTypeVals);
+
+  /// Returns a desugared version of the QualType, and marks ShouldAKA as true
+  /// whenever we remove significant sugar from the type.
+  QualType Desugar(ASTContext , QualType QT, bool );
 }  // end namespace clang
 
 #endif
Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -45,8 +45,8 @@
  HI.Kind = index::SymbolKind::Function;
  HI.Documentation = "Best foo ever.";
  HI.Definition = "void foo()";
- HI.ReturnType = "void";
- HI.Type = "void ()";
+ HI.ReturnType = {"void", llvm::None};
+ HI.Type = {"void ()", llvm::None};
  HI.Parameters.emplace();
}},
   // Inside namespace
@@ -62,8 +62,8 @@
  HI.Kind = index::SymbolKind::Function;
  HI.Documentation = "Best foo ever.";
  HI.Definition = "void foo()";
- HI.ReturnType = "void";
- HI.Type = "void ()";
+ HI.ReturnType = {"void", llvm::None};
+ HI.Type = {"void ()", llvm::None};
  HI.Parameters.emplace();
}},
   // Field
@@ -81,7 +81,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Offset = 0;
  HI.Size = 1;
  HI.Padding = 7;
@@ -100,7 +100,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Size = 1;
  HI.Padding = 15;
  HI.AccessSpecifier = "public";
@@ -118,7 +118,7 @@
  HI.Name = "x";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "int x : 1";
- HI.Type = "int";
+ HI.Type = {"int", llvm::None};
  HI.AccessSpecifier = "public";
}},
   // Local to class method.
@@ -137,7 +137,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Variable;
  HI.Definition = "int bar";
- HI.Type = "int";
+ HI.Type = {"int", llvm::None};
}},
   // Anon namespace and local scope.
   {R"cpp(
@@ -153,7 +153,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Offset = 0;
  HI.Size = 1;
  HI.AccessSpecifier = "public";
@@ -179,7 +179,7 @@
  HI.Name = "foo";
  HI.Kind = index::SymbolKind::Variable;
  HI.Definition = "Foo foo = Foo(5)";
- HI.Type = "Foo";
+ HI.Type = {"Foo", llvm::None};
}},
   // Implicit template instantiation
   {R"cpp(
@@ -211,12 +211,19 @@
   bool Q = false, class... Ts>
 class Foo {})cpp";
  HI.TemplateParameters = {
- {std::string("template  class"),
-  std::string("C"), llvm::None},
- {std::string("typename"), llvm::None, std::string("char")},
- {std::string("int"), llvm::None, std::string("0")},
- {std::string("bool"), std::string("Q"),

[PATCH] D114162: [X86][clang] Enable floating-point type for -mno-x87 option on 32-bits

2021-11-25 Thread Phoebe Wang via Phabricator via cfe-commits

pengfei added inline comments.



Comment at: clang/lib/Basic/Targets/X86.cpp:385
 
-  if (!HasX87) {
-if (LongDoubleFormat == ::APFloat::x87DoubleExtended())
-  HasLongDouble = false;
-if (getTriple().getArch() == llvm::Triple::x86)
-  HasFPReturn = false;
-  }
+  if (!HasX87 && getTriple().getArch() == llvm::Triple::x86_64 &&
+  LongDoubleFormat == ::APFloat::x87DoubleExtended())

asavonic wrote:
> pengfei wrote:
> > asavonic wrote:
> > > I see that D112143 changed the ABI so that FP return values do not use 
> > > x87 registers on i386. Therefore HasFPReturn flag can be removed.
> > > 
> > > However, operations with long double (x87 80-bit) should still be 
> > > unsupported on both targets, because IIRC there is no SSE equivalent for 
> > > them. GCC compiles them as soft-fp when -mno-x87 is set, but I haven't 
> > > found 80-bit soft-fp implementation in LLVM.
> > > ```
> > > long double baz(long double a, long double b) {
> > > return a + b;
> > > }
> > > ```
> > > 
> > > ```
> > > baz:
> > >[...]
> > >call  __addxf3
> > > ```
> > > For some reason GCC only does this for for i386 target, for x86_64 it 
> > > just emits the diagnostic about disabled x87.
> > Thanks for looking at this patch.
> > I don't think we need to exclude f80 particularly. IIUC, backend tries all 
> > possible ways to lower a given operation. Lowering to library is always the 
> > last choice. So the behavior is not confined to soft-fp.
> > It's true LLVM has problems with f80 lowering without x87. I commented it 
> > in D112143 and hope D100091 will fix them. We don't need to bother to 
> > change it again in future.
> > 
> > > For some reason GCC only does this for for i386 target, for x86_64 it 
> > > just emits the diagnostic about disabled x87.
> > I think the root reason is the difference in ABI. 32-bits ABI allows 
> > passing and returning f80 without x87 registers while 64-bits doesn't. So 
> > we have to and only need to disable it for x86_64.
> > I don't think we need to exclude f80 particularly. IIUC, backend tries all 
> > possible ways to lower a given operation. Lowering to library is always the 
> > last choice. So the behavior is not confined to soft-fp.
> > It's true LLVM has problems with f80 lowering without x87. I commented it 
> > in D112143 and hope D100091 will fix them. We don't need to bother to 
> > change it again in future.
> 
> Right, but can LLVM lower any x87 80-bit fp operations other than return 
> values?
> If it cannot, then I think a source level diagnostic is a good thing to have. 
> Otherwise the only handling we have is the codegen crash with "x87 register 
> return with x87 disabled" and no source-level context.
No. I checked we are able to lower with changes like below. But it requires 
enabling all operations with full test. So emitting diagnostic seems good for 
now.
```
--- a/llvm/lib/Target/X86/X86ISelLowering.cpp
+++ b/llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -729,6 +729,8 @@ X86TargetLowering::X86TargetLowering(const X86TargetMachine 
,
 // FIXME: When the target is 64-bit, STRICT_FP_ROUND will be overwritten
 // as Custom.
 setOperationAction(ISD::STRICT_FP_ROUND, MVT::f80, Legal);
+  } else {
+setOperationAction(ISD::FADD,MVT::f80, LibCall);
   }

   // f128 uses xmm registers, but most operations require libcalls.


--- a/llvm/lib/Target/X86/X86InstrFormats.td
+++ b/llvm/lib/Target/X86/X86InstrFormats.td
@@ -472,6 +472,7 @@ class Ii32PCRel o, Format f, dag outs, dag ins, 
string asm,
 class FPI o, Format F, dag outs, dag ins, string asm>
   : I {
   let Defs = [FPSW];
+  let Predicates = [HasX87];
 }

 // FpI_ - Floating Point Pseudo Instruction template. Not Predicated.
@@ -479,6 +480,7 @@ class FpI_ 
pattern>
   : PseudoI {
   let FPForm = fp;
   let Defs = [FPSW];
+  let Predicates = [HasX87];
 }

 // Templates for instructions that use a 16- or 32-bit segmented address as


--- a/llvm/lib/Target/X86/X86InstrInfo.td
+++ b/llvm/lib/Target/X86/X86InstrInfo.td
@@ -929,6 +929,7 @@ def HasAES   : Predicate<"Subtarget->hasAES()">;
 def HasVAES  : Predicate<"Subtarget->hasVAES()">;
 def NoVLX_Or_NoVAES : Predicate<"!Subtarget->hasVLX() || 
!Subtarget->hasVAES()">;
 def HasFXSR  : Predicate<"Subtarget->hasFXSR()">;
+def HasX87   : Predicate<"Subtarget->hasX87()">;
 def HasXSAVE : Predicate<"Subtarget->hasXSAVE()">;
 def HasXSAVEOPT  : Predicate<"Subtarget->hasXSAVEOPT()">;
 def HasXSAVEC: Predicate<"Subtarget->hasXSAVEC()">;

```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114162/new/

https://reviews.llvm.org/D114162

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

[PATCH] D114162: [X86][clang] Enable floating-point type for -mno-x87 option on 32-bits

2021-11-25 Thread Phoebe Wang via Phabricator via cfe-commits

pengfei updated this revision to Diff 389914.
pengfei added a comment.

Emit diagnostic for long double for i386 target too.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114162/new/

https://reviews.llvm.org/D114162

Files:
  clang/lib/Basic/Targets/X86.cpp
  clang/test/Sema/x86-no-x87.cpp


Index: clang/test/Sema/x86-no-x87.cpp
===
--- clang/test/Sema/x86-no-x87.cpp
+++ clang/test/Sema/x86-no-x87.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -triple i686-linux-gnu 
-target-feature -x87 -DRET_ERROR
+// RUN: %clang_cc1 -fsyntax-only -verify %s -triple i686-linux-gnu 
-target-feature -x87
 // RUN: %clang_cc1 -fsyntax-only -verify %s -triple i686-linux-gnu -DNOERROR
 
 #ifdef NOERROR
@@ -123,42 +123,22 @@
   long_double ld = 0.42;
 }
 
-#ifndef NOERROR
-// expected-note@+3{{'d_ret1' defined here}}
-// expected-error@+2{{'d_ret1' requires  'double' return type support, but 
target 'i686-unknown-linux-gnu' does not support it}}
-#endif
 double d_ret1(float x) {
   return 0.0;
 }
 
-#ifndef NOERROR
-// expected-note@+2{{'d_ret2' defined here}}
-#endif
 double d_ret2(float x);
 
 int d_ret3(float x) {
-#ifndef NOERROR
-  // expected-error@+2{{'d_ret2' requires  'double' return type support, but 
target 'i686-unknown-linux-gnu' does not support it}}
-#endif
   return (int)d_ret2(x);
 }
 
-#ifndef NOERROR
-// expected-note@+3{{'f_ret1' defined here}}
-// expected-error@+2{{'f_ret1' requires  'float' return type support, but 
target 'i686-unknown-linux-gnu' does not support it}}
-#endif
 float f_ret1(float x) {
   return 0.0f;
 }
 
-#ifndef NOERROR
-// expected-note@+2{{'f_ret2' defined here}}
-#endif
 float f_ret2(float x);
 
 int f_ret3(float x) {
-#ifndef NOERROR
-  // expected-error@+2{{'f_ret2' requires  'float' return type support, but 
target 'i686-unknown-linux-gnu' does not support it}}
-#endif
   return (int)f_ret2(x);
 }
Index: clang/lib/Basic/Targets/X86.cpp
===
--- clang/lib/Basic/Targets/X86.cpp
+++ clang/lib/Basic/Targets/X86.cpp
@@ -382,12 +382,10 @@
   SimdDefaultAlign =
   hasFeature("avx512f") ? 512 : hasFeature("avx") ? 256 : 128;
 
-  if (!HasX87) {
-if (LongDoubleFormat == ::APFloat::x87DoubleExtended())
-  HasLongDouble = false;
-if (getTriple().getArch() == llvm::Triple::x86)
-  HasFPReturn = false;
-  }
+  // FIXME: We should allow long double type on 32-bits to match with GCC.
+  // This requires backend to be able to lower f80 without x87 first.
+  if (!HasX87 && LongDoubleFormat == ::APFloat::x87DoubleExtended())
+HasLongDouble = false;
 
   return true;
 }


Index: clang/test/Sema/x86-no-x87.cpp
===
--- clang/test/Sema/x86-no-x87.cpp
+++ clang/test/Sema/x86-no-x87.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -triple i686-linux-gnu -target-feature -x87 -DRET_ERROR
+// RUN: %clang_cc1 -fsyntax-only -verify %s -triple i686-linux-gnu -target-feature -x87
 // RUN: %clang_cc1 -fsyntax-only -verify %s -triple i686-linux-gnu -DNOERROR
 
 #ifdef NOERROR
@@ -123,42 +123,22 @@
   long_double ld = 0.42;
 }
 
-#ifndef NOERROR
-// expected-note@+3{{'d_ret1' defined here}}
-// expected-error@+2{{'d_ret1' requires  'double' return type support, but target 'i686-unknown-linux-gnu' does not support it}}
-#endif
 double d_ret1(float x) {
   return 0.0;
 }
 
-#ifndef NOERROR
-// expected-note@+2{{'d_ret2' defined here}}
-#endif
 double d_ret2(float x);
 
 int d_ret3(float x) {
-#ifndef NOERROR
-  // expected-error@+2{{'d_ret2' requires  'double' return type support, but target 'i686-unknown-linux-gnu' does not support it}}
-#endif
   return (int)d_ret2(x);
 }
 
-#ifndef NOERROR
-// expected-note@+3{{'f_ret1' defined here}}
-// expected-error@+2{{'f_ret1' requires  'float' return type support, but target 'i686-unknown-linux-gnu' does not support it}}
-#endif
 float f_ret1(float x) {
   return 0.0f;
 }
 
-#ifndef NOERROR
-// expected-note@+2{{'f_ret2' defined here}}
-#endif
 float f_ret2(float x);
 
 int f_ret3(float x) {
-#ifndef NOERROR
-  // expected-error@+2{{'f_ret2' requires  'float' return type support, but target 'i686-unknown-linux-gnu' does not support it}}
-#endif
   return (int)f_ret2(x);
 }
Index: clang/lib/Basic/Targets/X86.cpp
===
--- clang/lib/Basic/Targets/X86.cpp
+++ clang/lib/Basic/Targets/X86.cpp
@@ -382,12 +382,10 @@
   SimdDefaultAlign =
   hasFeature("avx512f") ? 512 : hasFeature("avx") ? 256 : 128;
 
-  if (!HasX87) {
-if (LongDoubleFormat == ::APFloat::x87DoubleExtended())
-  HasLongDouble = false;
-if (getTriple().getArch() == llvm::Triple::x86)
-  HasFPReturn = false;
-  }
+  // FIXME: We should allow long double type on 32-bits to match with GCC.
+  // This requires backend to be able to lower f80

[PATCH] D114522: [clangd] Add canonical type to hover

2021-11-25 Thread liu hui via Phabricator via cfe-commits

lh123 updated this revision to Diff 389911.
lh123 added a comment.

fix some bug.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114522/new/

https://reviews.llvm.org/D114522

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/Hover.h
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang/include/clang/AST/ASTDiagnostic.h
  clang/lib/AST/ASTDiagnostic.cpp

Index: clang/lib/AST/ASTDiagnostic.cpp
===
--- clang/lib/AST/ASTDiagnostic.cpp
+++ clang/lib/AST/ASTDiagnostic.cpp
@@ -26,7 +26,7 @@
 
 // Returns a desugared version of the QualType, and marks ShouldAKA as true
 // whenever we remove significant sugar from the type.
-static QualType Desugar(ASTContext , QualType QT, bool ) {
+QualType clang::Desugar(ASTContext , QualType QT, bool ) {
   QualifierCollector QC;
 
   while (true) {
Index: clang/include/clang/AST/ASTDiagnostic.h
===
--- clang/include/clang/AST/ASTDiagnostic.h
+++ clang/include/clang/AST/ASTDiagnostic.h
@@ -9,6 +9,7 @@
 #ifndef LLVM_CLANG_AST_ASTDIAGNOSTIC_H
 #define LLVM_CLANG_AST_ASTDIAGNOSTIC_H
 
+#include "clang/AST/Type.h"
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/DiagnosticAST.h"
 
@@ -31,6 +32,10 @@
   SmallVectorImpl ,
   void *Cookie,
   ArrayRef QualTypeVals);
+
+  /// Returns a desugared version of the QualType, and marks ShouldAKA as true
+  /// whenever we remove significant sugar from the type.
+  QualType Desugar(ASTContext , QualType QT, bool );
 }  // end namespace clang
 
 #endif
Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -45,8 +45,8 @@
  HI.Kind = index::SymbolKind::Function;
  HI.Documentation = "Best foo ever.";
  HI.Definition = "void foo()";
- HI.ReturnType = "void";
- HI.Type = "void ()";
+ HI.ReturnType = {"void", llvm::None};
+ HI.Type = {"void ()", llvm::None};
  HI.Parameters.emplace();
}},
   // Inside namespace
@@ -62,8 +62,8 @@
  HI.Kind = index::SymbolKind::Function;
  HI.Documentation = "Best foo ever.";
  HI.Definition = "void foo()";
- HI.ReturnType = "void";
- HI.Type = "void ()";
+ HI.ReturnType = {"void", llvm::None};
+ HI.Type = {"void ()", llvm::None};
  HI.Parameters.emplace();
}},
   // Field
@@ -81,7 +81,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Offset = 0;
  HI.Size = 1;
  HI.Padding = 7;
@@ -100,7 +100,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Size = 1;
  HI.Padding = 15;
  HI.AccessSpecifier = "public";
@@ -118,7 +118,7 @@
  HI.Name = "x";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "int x : 1";
- HI.Type = "int";
+ HI.Type = {"int", llvm::None};
  HI.AccessSpecifier = "public";
}},
   // Local to class method.
@@ -137,7 +137,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Variable;
  HI.Definition = "int bar";
- HI.Type = "int";
+ HI.Type = {"int", llvm::None};
}},
   // Anon namespace and local scope.
   {R"cpp(
@@ -153,7 +153,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Offset = 0;
  HI.Size = 1;
  HI.AccessSpecifier = "public";
@@ -179,7 +179,7 @@
  HI.Name = "foo";
  HI.Kind = index::SymbolKind::Variable;
  HI.Definition = "Foo foo = Foo(5)";
- HI.Type = "Foo";
+ HI.Type = {"Foo", llvm::None};
}},
   // Implicit template instantiation
   {R"cpp(
@@ -211,12 +211,19 @@
   bool Q = false, class... Ts>
 class Foo {})cpp";
  HI.TemplateParameters = {
- {std::string("template  class"),
-  std::string("C"), llvm::None},
- {std::string("typename"), llvm::None, std::string("char")},
- {std::string("int"), llvm::None, std::string("0")},
- {std::string("bool"), std::string("Q"), std::string("false")},
- {std::string("class..."), std::string("Ts"), llvm::None},
+ {{{std::string("template  class"), llvm::None}},
+  std::string("C"),
+  llvm::None},
+

[PATCH] D114522: [clangd] Add canonical type to hover

2021-11-25 Thread liu hui via Phabricator via cfe-commits

lh123 updated this revision to Diff 389909.
lh123 added a comment.
Herald added a project: clang.

address comment.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114522/new/

https://reviews.llvm.org/D114522

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/Hover.h
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang/include/clang/AST/ASTDiagnostic.h
  clang/lib/AST/ASTDiagnostic.cpp

Index: clang/lib/AST/ASTDiagnostic.cpp
===
--- clang/lib/AST/ASTDiagnostic.cpp
+++ clang/lib/AST/ASTDiagnostic.cpp
@@ -26,7 +26,7 @@
 
 // Returns a desugared version of the QualType, and marks ShouldAKA as true
 // whenever we remove significant sugar from the type.
-static QualType Desugar(ASTContext , QualType QT, bool ) {
+QualType clang::Desugar(ASTContext , QualType QT, bool ) {
   QualifierCollector QC;
 
   while (true) {
Index: clang/include/clang/AST/ASTDiagnostic.h
===
--- clang/include/clang/AST/ASTDiagnostic.h
+++ clang/include/clang/AST/ASTDiagnostic.h
@@ -9,6 +9,7 @@
 #ifndef LLVM_CLANG_AST_ASTDIAGNOSTIC_H
 #define LLVM_CLANG_AST_ASTDIAGNOSTIC_H
 
+#include "clang/AST/Type.h"
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/DiagnosticAST.h"
 
@@ -31,6 +32,10 @@
   SmallVectorImpl ,
   void *Cookie,
   ArrayRef QualTypeVals);
+
+  /// Returns a desugared version of the QualType, and marks ShouldAKA as true
+  /// whenever we remove significant sugar from the type.
+  QualType Desugar(ASTContext , QualType QT, bool );
 }  // end namespace clang
 
 #endif
Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -45,8 +45,8 @@
  HI.Kind = index::SymbolKind::Function;
  HI.Documentation = "Best foo ever.";
  HI.Definition = "void foo()";
- HI.ReturnType = "void";
- HI.Type = "void ()";
+ HI.ReturnType = {"void", llvm::None};
+ HI.Type = {"void ()", llvm::None};
  HI.Parameters.emplace();
}},
   // Inside namespace
@@ -62,8 +62,8 @@
  HI.Kind = index::SymbolKind::Function;
  HI.Documentation = "Best foo ever.";
  HI.Definition = "void foo()";
- HI.ReturnType = "void";
- HI.Type = "void ()";
+ HI.ReturnType = {"void", llvm::None};
+ HI.Type = {"void ()", llvm::None};
  HI.Parameters.emplace();
}},
   // Field
@@ -81,7 +81,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Offset = 0;
  HI.Size = 1;
  HI.Padding = 7;
@@ -100,7 +100,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Size = 1;
  HI.Padding = 15;
  HI.AccessSpecifier = "public";
@@ -118,7 +118,7 @@
  HI.Name = "x";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "int x : 1";
- HI.Type = "int";
+ HI.Type = {"int", llvm::None};
  HI.AccessSpecifier = "public";
}},
   // Local to class method.
@@ -137,7 +137,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Variable;
  HI.Definition = "int bar";
- HI.Type = "int";
+ HI.Type = {"int", llvm::None};
}},
   // Anon namespace and local scope.
   {R"cpp(
@@ -153,7 +153,7 @@
  HI.Name = "bar";
  HI.Kind = index::SymbolKind::Field;
  HI.Definition = "char bar";
- HI.Type = "char";
+ HI.Type = {"char", llvm::None};
  HI.Offset = 0;
  HI.Size = 1;
  HI.AccessSpecifier = "public";
@@ -179,7 +179,7 @@
  HI.Name = "foo";
  HI.Kind = index::SymbolKind::Variable;
  HI.Definition = "Foo foo = Foo(5)";
- HI.Type = "Foo";
+ HI.Type = {"Foo", llvm::None};
}},
   // Implicit template instantiation
   {R"cpp(
@@ -211,12 +211,19 @@
   bool Q = false, class... Ts>
 class Foo {})cpp";
  HI.TemplateParameters = {
- {std::string("template  class"),
-  std::string("C"), llvm::None},
- {std::string("typename"), llvm::None, std::string("char")},
- {std::string("int"), llvm::None, std::string("0")},
- {std::string("bool"), std::string("Q"), std::string("false")},
- {std::string("class..."), std::string("Ts"), llvm::None},
+ {{{std::string("template  class"), llvm::None}},
+  std::string("C"),
+

[PATCH] D114411: [WIP][modules] Avoid deserializing Decls from hidden (sub)modules.

2021-11-25 Thread Volodymyr Sapsai via Phabricator via cfe-commits

vsapsai abandoned this revision.
vsapsai added a comment.

After more investigation and comparing different entities (like structs, enums) 
this approach seems to be too involved and probably wrong. A better choice 
seems to be following the same direction as in ⦗Modules⦘ Implement ODR-like 
semantics for tag types in C/ObjC  than 
inventing something new. Specifically, I plan to look into discrepancies 
between EnumDecl and EnumConstantDecl as we don't have problems with enums 
themselves, only with the constants.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114411/new/

https://reviews.llvm.org/D114411

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

[PATCH] D113393: [c++2b] Implement P0849R8 auto(x)

2021-11-25 Thread Zhihao Yuan via Phabricator via cfe-commits

lichray updated this revision to Diff 389890.
lichray added a comment.

Ping. Please review.

- Reformat code after clang-format lands D114519 



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113393/new/

https://reviews.llvm.org/D113393

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Parse/ParseTentative.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p5.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
  clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx14.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
  clang/test/Parser/cxx2b-auto-x.cpp
  clang/test/SemaCXX/deduced-return-type-cxx14.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1379,6 +1379,11 @@
   https://wg21.link/P2360R0;>P2360R0
   Clang 14
 
+
+  auto(x): decay-copy in the language
+  https://wg21.link/P0849R8;>P0849R8
+  Clang 14
+
 
 
 
Index: clang/test/SemaCXX/deduced-return-type-cxx14.cpp
===
--- clang/test/SemaCXX/deduced-return-type-cxx14.cpp
+++ clang/test/SemaCXX/deduced-return-type-cxx14.cpp
@@ -442,6 +442,13 @@
   B() : decltype(auto)() {} // expected-error {{'decltype(auto)' not allowed here}}
 };
   }
+
+  namespace Cast {
+void foo() {
+  (void)decltype(auto)(0); // cxx14_20-error{{'decltype(auto)' not allowed here}}
+  (void)decltype(auto){0}; // cxx14_20-error{{'decltype(auto)' not allowed here}}
+}
+  }
 }
 
 namespace CurrentInstantiation {
@@ -638,5 +645,7 @@
   using B = auto (*)() -> auto; // expected-error {{'auto' not allowed in type alias}}
   template auto> struct X {}; // cxx14-error {{'auto' not allowed in template parameter until C++17}}
   template struct Y { T x; };
-  Y auto> y; // expected-error {{'auto' not allowed in template argument}}
+  Y auto> y; // cxx14_20-error {{'auto' not allowed in template argument}} \
+  cxx2b-error {{initializer for functional-style cast to 'auto' is empty}} \
+  cxx2b-error {{expected unqualified-id}}
 }
Index: clang/test/Parser/cxx2b-auto-x.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx2b-auto-x.cpp
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx2b -std=c++2b %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx20 -std=c++20 %s
+
+void looks_like_decltype_auto() {
+  decltype(auto(42)) b = 42; // cxx20-error {{'auto' not allowed here}}
+  decltype(long *) a = 42;   // expected-error {{expected '(' for function-style cast or type construction}} \
+expected-error {{expected expression}}
+  decltype(auto *) a = 42;   // expected-error {{expected '(' for function-style cast or type construction}} \
+expected-error {{expected expression}}
+  decltype(auto()) c = 42;   // cxx2b-error {{initializer for functional-style cast to 'auto' is empty}} \
+cxx20-error {{'auto' not allowed here}}
+}
+
+struct looks_like_declaration {
+  int n;
+} a;
+
+using T = looks_like_declaration *;
+void f() { T()->n = 1; }
+void g() { auto()->n = 0; } // cxx20-error {{declaration of variable 'a' with deduced type 'auto (&)' requires an initializer}} \
+ cxx20-error {{expected ';' at end of declaration}}
+void h() { auto{}->n = 0; } // cxx20-error {{expected unqualified-id}} \
+ cxx20-error {{expected expression}}
Index: clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
===
--- clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
+++ clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
@@ -1,11 +1,30 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++14
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++17 -pedantic
 
+// [expr.new]p2 ... the invented declaration: T x init ;
+// C++2b [dcl.type.auto.deduct]p2.2
+// For a variable declared with a type that contains a placeholder type, T is the declared type of the variable.
 void f() {
+  // - If the initializer is a parenthesized expression-list, the expression-list shall be a single assignmentexpression and E is the assignment-expression.
   new auto('a');
-  new auto {2};
-  new auto {1, 2}; // expected-error{{new expression for type 'auto' contains multiple constructor

[PATCH] D114615: Increase the number of driver diagnostics

2021-11-25 Thread Steven Wan via Phabricator via cfe-commits

stevewan created this revision.
stevewan requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

We're close to hitting the limited number of driver diagnostics, increase 
`DIAG_SIZE_DRIVER` to accommodate more.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D114615

Files:
  clang/include/clang/Basic/DiagnosticIDs.h


Index: clang/include/clang/Basic/DiagnosticIDs.h
===
--- clang/include/clang/Basic/DiagnosticIDs.h
+++ clang/include/clang/Basic/DiagnosticIDs.h
@@ -30,7 +30,7 @@
 // Size of each of the diagnostic categories.
 enum {
   DIAG_SIZE_COMMON=  300,
-  DIAG_SIZE_DRIVER=  250,
+  DIAG_SIZE_DRIVER=  300,
   DIAG_SIZE_FRONTEND  =  150,
   DIAG_SIZE_SERIALIZATION =  120,
   DIAG_SIZE_LEX   =  400,


Index: clang/include/clang/Basic/DiagnosticIDs.h
===
--- clang/include/clang/Basic/DiagnosticIDs.h
+++ clang/include/clang/Basic/DiagnosticIDs.h
@@ -30,7 +30,7 @@
 // Size of each of the diagnostic categories.
 enum {
   DIAG_SIZE_COMMON=  300,
-  DIAG_SIZE_DRIVER=  250,
+  DIAG_SIZE_DRIVER=  300,
   DIAG_SIZE_FRONTEND  =  150,
   DIAG_SIZE_SERIALIZATION =  120,
   DIAG_SIZE_LEX   =  400,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D114234: [clang][dataflow] Add base types for building dataflow analyses

2021-11-25 Thread Gábor Horváth via Phabricator via cfe-commits

xazax.hun accepted this revision.
xazax.hun added a comment.
This revision is now accepted and ready to land.

Thanks, it looks good to me. Most of my comments are just brainstorming, 
exploring alternative ideas. Feel free to ignore some/all of them.




Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h:48
+/// Type-erased base class for dataflow analyses built on a single lattice 
type.
+class DataflowAnalysisDynamic {
+public:

sgatev wrote:
> xazax.hun wrote:
> > Does the `Dynamic` in the suffix refer to the fact this is using type 
> > erasure as opposed to templates? 
> > 
> > I have multiple questions at this point:
> > * Why do we prefer type erasure over generic programming?
> > * Do you plan to have non-dynamic counterparts?
> > 
> > Nit: having Dynamic both in the class name and in the method names sounds 
> > overly verbose to me.
> > Nit: please add a comment what dynamic refers to in the name,
> Right. The "Dynamic" suffix emphasizes the type-erased nature of the class 
> and its members and is used to differentiate them from their typed 
> counterparts in `DataflowAnalysis`. I added this to the documentation of the 
> type. I also split the typed and type-erased interfaces in separate files. 
> Users of the framework shouldn't need to interact with types and functions 
> from `DataflowAnalysisDynamic.h`.
> 
> The names are verbose, but should be used in relatively few internal places 
> in the framework. Currently, we have one call site for each of the methods of 
> `DataflowAnalysisDynamic`. Nevertheless, if you have ideas for better names 
> I'd be happy to change them.
> 
> The reason we went with a type-erased layer is to avoid pulling a lot of code 
> in the templates. Over time the implementation got cleaner and as I'm 
> preparing these patches I see some opportunities to simplify it further. 
> However, it's still non-trivial amount of code. I think we should revisit 
> this decision at some point and consider having entirely template-based 
> implementation of the algorithm. I personally don't see clear benefits of one 
> approach over the other at this point. If you have strong preference for 
> using templates, we can consider going down that route now.
Thanks for the explanation! I don't have a strong preference, we could stick 
with the type-erased version unless we see some reason to change in the future. 
However, I don't see much value in the "Dynamic" suffix for the method names. 
What do you think about simply dropping them?



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h:94
+// Model of the program at a given program point.
+template  struct DataflowAnalysisState {
+  // Model of a program property.

If I understand this correctly, this could derive from 
`DataflowAnalysisStateDynamic`, it could just provide a getter function that 
casts the type erased lattice element to `LatticeT`, returning a reference to 
the contents of the `any` object. As a result, you would no longer need to do 
move/copy in `runDataflowAnalysis`. On the other hand, the user would need to 
call a getter to get out the lattice element. I guess we expect lattice 
elements to be relatively cheap to move. Feel free to leave this unchanged, it 
is more of an observation.



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h:102
+
+/// Performs dataflow analysis and returns a mapping from basic block IDs to
+/// dataflow analysis states that model the respective basic blocks.

While it is probably obvious to most of us, I wonder if it is obvious to all 
future readers that the block IDs are the indices of the vector. Depending on 
how beginner-friendly do we want these comments to be we could make that more 
explicit.



Comment at: 
clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisDynamic.h:45
+/// in `DataflowAnalysis`.
+class DataflowAnalysisDynamic {
+public:

Alternatively, we could replace `Dynamic` with `TypeErased` in the class name 
making the comment redundant.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114234/new/

https://reviews.llvm.org/D114234

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

[PATCH] D112730: [clang-tidy] Add AUTOSAR module

2021-11-25 Thread Carlos Galvez via Phabricator via cfe-commits

carlosgalvezp added a comment.

@tstellar I totally missed your fast reply, sorry about that! I have just 
forwarded the mail chain to the indicated address. Let me know if there's 
anything else I can do to help.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112730/new/

https://reviews.llvm.org/D112730

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

[PATCH] D109856: [libunwind][ARM] Handle end of stack during unwind

2021-11-25 Thread Martin Storsjö via Phabricator via cfe-commits

mstorsjo added a comment.

Looks reasonable I think. Is this a deficiency in the EHABI implementation 
only, i.e. this aspect works as it should in the regular dwarf implementation?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109856/new/

https://reviews.llvm.org/D109856

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

[PATCH] D112430: [ARM][libunwind] add PACBTI-M support for libunwind

2021-11-25 Thread Louis Dionne via Phabricator via cfe-commits

ldionne added a comment.

Please rebase onto `main` and re-upload before submitting, so that the CI runs. 
There was a flaky failure previously, but I'd like to see it run before merging.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112430/new/

https://reviews.llvm.org/D112430

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

[PATCH] D112430: [ARM][libunwind] add PACBTI-M support for libunwind

2021-11-25 Thread Martin Storsjö via Phabricator via cfe-commits

mstorsjo accepted this revision.
mstorsjo added a comment.
This revision is now accepted and ready to land.

I guess this is ok then. I can't say I've followed every bit in detail, but it 
looks sensible overall.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112430/new/

https://reviews.llvm.org/D112430

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

[PATCH] D114029: [clang][NFC] Inclusive terms: rename AccessDeclContextSanity to AccessDeclContextCheck

2021-11-25 Thread Zarko Todorovski via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5162b558d8c0: [clang][NFC] Inclusive terms: rename 
AccessDeclContextSanity to… (authored by ZarkoCA).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114029/new/

https://reviews.llvm.org/D114029

Files:
  clang/include/clang/AST/DeclBase.h
  clang/lib/AST/DeclBase.cpp
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp


Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -91,7 +91,7 @@
   assert(decl && "VerifyDecl called with nullptr?");
 #ifndef NDEBUG
   // We don't care about the actual access value here but only want to trigger
-  // that Clang calls its internal Decl::AccessDeclContextSanity check.
+  // that Clang calls its internal Decl::AccessDeclContextCheck validation.
   decl->getAccess();
 #endif
 }
Index: clang/lib/AST/DeclBase.cpp
===
--- clang/lib/AST/DeclBase.cpp
+++ clang/lib/AST/DeclBase.cpp
@@ -964,7 +964,7 @@
   return {};
 }
 
-bool Decl::AccessDeclContextSanity() const {
+bool Decl::AccessDeclContextCheck() const {
 #ifndef NDEBUG
   // Suppress this check if any of the following hold:
   // 1. this is the translation unit (and thus has no parent)
Index: clang/include/clang/AST/DeclBase.h
===
--- clang/include/clang/AST/DeclBase.h
+++ clang/include/clang/AST/DeclBase.h
@@ -352,7 +352,7 @@
  DeclContext *Parent, std::size_t Extra = 0);
 
 private:
-  bool AccessDeclContextSanity() const;
+  bool AccessDeclContextCheck() const;
 
   /// Get the module ownership kind to use for a local lexical child of \p DC,
   /// which may be either a local or (rarely) an imported declaration.
@@ -472,11 +472,11 @@
 
   void setAccess(AccessSpecifier AS) {
 Access = AS;
-assert(AccessDeclContextSanity());
+assert(AccessDeclContextCheck());
   }
 
   AccessSpecifier getAccess() const {
-assert(AccessDeclContextSanity());
+assert(AccessDeclContextCheck());
 return AccessSpecifier(Access);
   }
 


Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -91,7 +91,7 @@
   assert(decl && "VerifyDecl called with nullptr?");
 #ifndef NDEBUG
   // We don't care about the actual access value here but only want to trigger
-  // that Clang calls its internal Decl::AccessDeclContextSanity check.
+  // that Clang calls its internal Decl::AccessDeclContextCheck validation.
   decl->getAccess();
 #endif
 }
Index: clang/lib/AST/DeclBase.cpp
===
--- clang/lib/AST/DeclBase.cpp
+++ clang/lib/AST/DeclBase.cpp
@@ -964,7 +964,7 @@
   return {};
 }
 
-bool Decl::AccessDeclContextSanity() const {
+bool Decl::AccessDeclContextCheck() const {
 #ifndef NDEBUG
   // Suppress this check if any of the following hold:
   // 1. this is the translation unit (and thus has no parent)
Index: clang/include/clang/AST/DeclBase.h
===
--- clang/include/clang/AST/DeclBase.h
+++ clang/include/clang/AST/DeclBase.h
@@ -352,7 +352,7 @@
  DeclContext *Parent, std::size_t Extra = 0);
 
 private:
-  bool AccessDeclContextSanity() const;
+  bool AccessDeclContextCheck() const;
 
   /// Get the module ownership kind to use for a local lexical child of \p DC,
   /// which may be either a local or (rarely) an imported declaration.
@@ -472,11 +472,11 @@
 
   void setAccess(AccessSpecifier AS) {
 Access = AS;
-assert(AccessDeclContextSanity());
+assert(AccessDeclContextCheck());
   }
 
   AccessSpecifier getAccess() const {
-assert(AccessDeclContextSanity());
+assert(AccessDeclContextCheck());
 return AccessSpecifier(Access);
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 5162b55 - [clang][NFC] Inclusive terms: rename AccessDeclContextSanity to AccessDeclContextCheck

2021-11-25 Thread Zarko Todorovski via cfe-commits


Author: Zarko Todorovski
Date: 2021-11-25T16:21:06-05:00
New Revision: 5162b558d8c0b542e752b037e72a69d5fd51eb1e

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

LOG: [clang][NFC] Inclusive terms: rename AccessDeclContextSanity to 
AccessDeclContextCheck

Rename function to more inclusive name.

Reviewed By: quinnp

Differential Revision: https://reviews.llvm.org/D114029

Added: 


Modified: 
clang/include/clang/AST/DeclBase.h
clang/lib/AST/DeclBase.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Removed: 




diff  --git a/clang/include/clang/AST/DeclBase.h 
b/clang/include/clang/AST/DeclBase.h
index 18468c8ca1c47..2a0a19597391f 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -352,7 +352,7 @@ class alignas(8) Decl {
  DeclContext *Parent, std::size_t Extra = 0);
 
 private:
-  bool AccessDeclContextSanity() const;
+  bool AccessDeclContextCheck() const;
 
   /// Get the module ownership kind to use for a local lexical child of \p DC,
   /// which may be either a local or (rarely) an imported declaration.
@@ -472,11 +472,11 @@ class alignas(8) Decl {
 
   void setAccess(AccessSpecifier AS) {
 Access = AS;
-assert(AccessDeclContextSanity());
+assert(AccessDeclContextCheck());
   }
 
   AccessSpecifier getAccess() const {
-assert(AccessDeclContextSanity());
+assert(AccessDeclContextCheck());
 return AccessSpecifier(Access);
   }
 

diff  --git a/clang/lib/AST/DeclBase.cpp b/clang/lib/AST/DeclBase.cpp
index 4044404f74ef2..d8eaf706384f5 100644
--- a/clang/lib/AST/DeclBase.cpp
+++ b/clang/lib/AST/DeclBase.cpp
@@ -964,7 +964,7 @@ SourceLocation Decl::getBodyRBrace() const {
   return {};
 }
 
-bool Decl::AccessDeclContextSanity() const {
+bool Decl::AccessDeclContextCheck() const {
 #ifndef NDEBUG
   // Suppress this check if any of the following hold:
   // 1. this is the translation unit (and thus has no parent)

diff  --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index b20ae32a08ac7..b1dbc382ff041 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -91,7 +91,7 @@ static void VerifyDecl(clang::Decl *decl) {
   assert(decl && "VerifyDecl called with nullptr?");
 #ifndef NDEBUG
   // We don't care about the actual access value here but only want to trigger
-  // that Clang calls its internal Decl::AccessDeclContextSanity check.
+  // that Clang calls its internal Decl::AccessDeclContextCheck validation.
   decl->getAccess();
 #endif
 }



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

[PATCH] D114090: [NFC] Inclusive language: rename master flag to main flag

2021-11-25 Thread Quinn Pham via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb11c66accfb1: [NFC] Inclusive language: rename master flag 
to main flag (authored by quinnp).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114090/new/

https://reviews.llvm.org/D114090

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp


Index: llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
===
--- llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
+++ llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
@@ -148,7 +148,7 @@
   AlignBranchType.addKind(X86::AlignBranchJcc);
   AlignBranchType.addKind(X86::AlignBranchJmp);
 }
-// Allow overriding defaults set by master flag
+// Allow overriding defaults set by main flag
 if (X86AlignBranchBoundary.getNumOccurrences())
   AlignBoundary = assumeAligned(X86AlignBranchBoundary);
 if (X86AlignBranch.getNumOccurrences())
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -403,7 +403,7 @@
 }
 
 /// Adds exception related arguments to the driver command arguments. There's a
-/// master flag, -fexceptions and also language specific flags to 
enable/disable
+/// main flag, -fexceptions and also language specific flags to enable/disable
 /// C++ and Objective-C exceptions. This makes it possible to for example
 /// disable C++ exceptions but enable Objective-C exceptions.
 static bool addExceptionArgs(const ArgList , types::ID InputType,


Index: llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
===
--- llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
+++ llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
@@ -148,7 +148,7 @@
   AlignBranchType.addKind(X86::AlignBranchJcc);
   AlignBranchType.addKind(X86::AlignBranchJmp);
 }
-// Allow overriding defaults set by master flag
+// Allow overriding defaults set by main flag
 if (X86AlignBranchBoundary.getNumOccurrences())
   AlignBoundary = assumeAligned(X86AlignBranchBoundary);
 if (X86AlignBranch.getNumOccurrences())
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -403,7 +403,7 @@
 }
 
 /// Adds exception related arguments to the driver command arguments. There's a
-/// master flag, -fexceptions and also language specific flags to enable/disable
+/// main flag, -fexceptions and also language specific flags to enable/disable
 /// C++ and Objective-C exceptions. This makes it possible to for example
 /// disable C++ exceptions but enable Objective-C exceptions.
 static bool addExceptionArgs(const ArgList , types::ID InputType,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] b11c66a - [NFC] Inclusive language: rename master flag to main flag

2021-11-25 Thread Quinn Pham via cfe-commits


Author: Quinn Pham
Date: 2021-11-25T15:16:11-06:00
New Revision: b11c66accfb1d78324278072ed0069d3bbe835cd

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

LOG: [NFC] Inclusive language: rename master flag to main flag

[NFC] As part of using inclusive language within the llvm project, this patch
renames master flag to main flag in these comments.

Reviewed By: ZarkoCA

Differential Revision: https://reviews.llvm.org/D114090

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 0f20abac043ca..5b773621a4af9 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -403,7 +403,7 @@ shouldUseExceptionTablesForObjCExceptions(const ObjCRuntime 
,
 }
 
 /// Adds exception related arguments to the driver command arguments. There's a
-/// master flag, -fexceptions and also language specific flags to 
enable/disable
+/// main flag, -fexceptions and also language specific flags to enable/disable
 /// C++ and Objective-C exceptions. This makes it possible to for example
 /// disable C++ exceptions but enable Objective-C exceptions.
 static bool addExceptionArgs(const ArgList , types::ID InputType,

diff  --git a/llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp 
b/llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
index d4f39b5713941..70208ee5b806b 100644
--- a/llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
+++ b/llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp
@@ -148,7 +148,7 @@ class X86AsmBackend : public MCAsmBackend {
   AlignBranchType.addKind(X86::AlignBranchJcc);
   AlignBranchType.addKind(X86::AlignBranchJmp);
 }
-// Allow overriding defaults set by master flag
+// Allow overriding defaults set by main flag
 if (X86AlignBranchBoundary.getNumOccurrences())
   AlignBoundary = assumeAligned(X86AlignBranchBoundary);
 if (X86AlignBranch.getNumOccurrences())



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

[PATCH] D114583: [clang-format] Adjust braced list detection

2021-11-25 Thread Björn Schäpers via Phabricator via cfe-commits

HazardyKnusperkeks requested changes to this revision.
HazardyKnusperkeks added a comment.
This revision now requires changes to proceed.

That will be a pain in the ass to merge with my current changes, but looks good.

In D114583#3153780 , @curdeius wrote:

> First of all, the test seems ok for https://llvm.org/PR48305, but I'd like to 
> see a test case for https://llvm.org/PR38314 (since you wrote in the 
> description that this bug gets fixed as well).

But I second that.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114583/new/

https://reviews.llvm.org/D114583

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

[libunwind] ebfeeec - [libunwind] Fix testing with sanitizers enabled

2021-11-25 Thread Louis Dionne via cfe-commits


Author: Louis Dionne
Date: 2021-11-25T15:28:17-05:00
New Revision: ebfeeec4c4bcc4373e5d5dfaff7ee75959a7c931

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

LOG: [libunwind] Fix testing with sanitizers enabled

When testing with sanitizers enabled, we need to link against a plethora
of system libraries. Using `-nodefaultlibs` like we used to breaks this,
and we would have to add all these system libraries manually, which is
not portable and error prone. Instead, stop using `-nodefaultlibs` so
that we get the libraries added by default by the compiler.

The only caveat with this approach is that we are now relying on the
fact that `-L ` will cause the just built
libunwind to be selected before the system implementation (either of
libunwind or libgcc_s.so), which is somewhat fragile.

This patch also turns the 32 bit multilib build into a soft failure
since we are in the process of removing it anyway, see D114473 for
details. This patch is incompatible with the 32 bit multilib build
because Ubuntu does not provide a proper libstdc++ for 32 bits, and
that is required when running with sanitizers enabled.

Differential Revision: https://reviews.llvm.org/D114385

Added: 


Modified: 
libcxx/utils/ci/buildkite-pipeline.yml
libunwind/test/configs/llvm-libunwind-shared.cfg.in
libunwind/test/configs/llvm-libunwind-static.cfg.in
libunwind/test/forceunwind.pass.cpp
libunwind/test/frameheadercache_test.pass.cpp
libunwind/test/libunwind_01.pass.cpp
libunwind/test/libunwind_02.pass.cpp
libunwind/test/remember_state_leak.pass.sh.s
libunwind/test/signal_frame.pass.cpp
libunwind/test/signal_unwind.pass.cpp
libunwind/test/unw_getcontext.pass.cpp
libunwind/test/unwind_leaffunction.pass.cpp

Removed: 




diff  --git a/libcxx/utils/ci/buildkite-pipeline.yml 
b/libcxx/utils/ci/buildkite-pipeline.yml
index 96e2cb37cff79..08e0bce056fd6 100644
--- a/libcxx/utils/ci/buildkite-pipeline.yml
+++ b/libcxx/utils/ci/buildkite-pipeline.yml
@@ -385,6 +385,8 @@ steps:
   automatic:
 - exit_status: -1  # Agent was lost
   limit: 2
+soft_fail:
+- exit_status: 1
 timeout_in_minutes: 120
 
   - label: "Single-threaded"

diff  --git a/libunwind/test/configs/llvm-libunwind-shared.cfg.in 
b/libunwind/test/configs/llvm-libunwind-shared.cfg.in
index 206c2b9c3e4f5..9de82e9d20fbc 100644
--- a/libunwind/test/configs/llvm-libunwind-shared.cfg.in
+++ b/libunwind/test/configs/llvm-libunwind-shared.cfg.in
@@ -47,7 +47,7 @@ config.substitutions.append(('%{compile_flags}',
 '-nostdinc++ -I {}/include {}'.format('@LIBUNWIND_SOURCE_DIR@', ' 
'.join(compile_flags))
 ))
 config.substitutions.append(('%{link_flags}',
-'-nodefaultlibs -L {0} -Wl,-rpath,{0} -lunwind -ldl -lc 
{1}'.format('@LIBUNWIND_LIBRARY_DIR@', ' '.join(link_flags))
+'-L {0} -Wl,-rpath,{0} -lunwind -ldl 
{1}'.format('@LIBUNWIND_LIBRARY_DIR@', ' '.join(link_flags))
 ))
 config.substitutions.append(('%{exec}', ''))
 

diff  --git a/libunwind/test/configs/llvm-libunwind-static.cfg.in 
b/libunwind/test/configs/llvm-libunwind-static.cfg.in
index dd292e7c88df9..9382ad3f92a36 100644
--- a/libunwind/test/configs/llvm-libunwind-static.cfg.in
+++ b/libunwind/test/configs/llvm-libunwind-static.cfg.in
@@ -49,7 +49,7 @@ config.substitutions.append(('%{compile_flags}',
 '-nostdinc++ -I {}/include {}'.format('@LIBUNWIND_SOURCE_DIR@', ' 
'.join(compile_flags))
 ))
 config.substitutions.append(('%{link_flags}',
-'-nodefaultlibs {}/libunwind.a -ldl -lc 
{}'.format('@LIBUNWIND_LIBRARY_DIR@', ' '.join(link_flags))
+'{}/libunwind.a -ldl {}'.format('@LIBUNWIND_LIBRARY_DIR@', ' 
'.join(link_flags))
 ))
 config.substitutions.append(('%{exec}', ''))
 

diff  --git a/libunwind/test/forceunwind.pass.cpp 
b/libunwind/test/forceunwind.pass.cpp
index 120663293df15..466697264035b 100644
--- a/libunwind/test/forceunwind.pass.cpp
+++ b/libunwind/test/forceunwind.pass.cpp
@@ -9,9 +9,6 @@
 
 // REQUIRES: linux
 
-// TODO: Investigate these failures
-// XFAIL: asan, tsan, ubsan
-
 // Basic test for _Unwind_ForcedUnwind.
 // See libcxxabi/test/forced_unwind* tests too.
 

diff  --git a/libunwind/test/frameheadercache_test.pass.cpp 
b/libunwind/test/frameheadercache_test.pass.cpp
index a50b2b663b6ab..9abff5e8cda9a 100644
--- a/libunwind/test/frameheadercache_test.pass.cpp
+++ b/libunwind/test/frameheadercache_test.pass.cpp
@@ -1,6 +1,3 @@
-// TODO: Investigate these failures
-// XFAIL: asan, tsan, ubsan
-
 // The other libunwind tests don't test internal interfaces, so the include 
path
 // is a little wonky.
 #include "../src/config.h"

diff  --git a/libunwind/test/libunwind_01.pass.cpp 
b/libunwind/test/libunwind_01.pass.cpp
index 6c1e1bbe45cd7..e5737450a568f 100644
---

[PATCH] D114029: [clang][NFC] Inclusive terms: rename AccessDeclContextSanity to AccessDeclContextCheck

2021-11-25 Thread Quinn Pham via Phabricator via cfe-commits

quinnp accepted this revision.
quinnp added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114029/new/

https://reviews.llvm.org/D114029

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

[PATCH] D114381: [AIX] Disable unsupported offloading gpu tests

2021-11-25 Thread Jake Egan via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG0796869e4e1e: [AIX] Disable unsupported offloading gpu tests 
(authored by Jake-Egan).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114381/new/

https://reviews.llvm.org/D114381

Files:
  clang/test/Driver/clang-offload-bundler-asserts-on.c
  clang/test/Driver/clang-offload-bundler.c
  clang/test/Driver/openmp-offload-gpu.c


Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -8,6 +8,8 @@
 // REQUIRES: nvptx-registered-target
 // REQUIRES: amdgpu-registered-target
 
+// UNSUPPORTED: aix
+
 /// ###
 
 /// Check -Xopenmp-target uses one of the archs provided when several archs 
are used.
Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -1,6 +1,6 @@
 // REQUIRES: x86-registered-target
 // REQUIRES: powerpc-registered-target
-// UNSUPPORTED: darwin
+// UNSUPPORTED: darwin, aix
 
 //
 // Generate all the types of files we can bundle.
Index: clang/test/Driver/clang-offload-bundler-asserts-on.c
===
--- clang/test/Driver/clang-offload-bundler-asserts-on.c
+++ clang/test/Driver/clang-offload-bundler-asserts-on.c
@@ -1,6 +1,6 @@
 // REQUIRES: x86-registered-target
 // REQUIRES: asserts
-// UNSUPPORTED: darwin
+// UNSUPPORTED: darwin, aix
 
 // Generate the file we can bundle.
 // RUN: %clang -O0 -target %itanium_abi_triple %s -c -o %t.o


Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -8,6 +8,8 @@
 // REQUIRES: nvptx-registered-target
 // REQUIRES: amdgpu-registered-target
 
+// UNSUPPORTED: aix
+
 /// ###
 
 /// Check -Xopenmp-target uses one of the archs provided when several archs are used.
Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -1,6 +1,6 @@
 // REQUIRES: x86-registered-target
 // REQUIRES: powerpc-registered-target
-// UNSUPPORTED: darwin
+// UNSUPPORTED: darwin, aix
 
 //
 // Generate all the types of files we can bundle.
Index: clang/test/Driver/clang-offload-bundler-asserts-on.c
===
--- clang/test/Driver/clang-offload-bundler-asserts-on.c
+++ clang/test/Driver/clang-offload-bundler-asserts-on.c
@@ -1,6 +1,6 @@
 // REQUIRES: x86-registered-target
 // REQUIRES: asserts
-// UNSUPPORTED: darwin
+// UNSUPPORTED: darwin, aix
 
 // Generate the file we can bundle.
 // RUN: %clang -O0 -target %itanium_abi_triple %s -c -o %t.o
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 0796869 - [AIX] Disable unsupported offloading gpu tests

2021-11-25 Thread Jake Egan via cfe-commits


Author: Jake Egan
Date: 2021-11-25T15:10:51-05:00
New Revision: 0796869e4e1e517a0f77f8e84d94e1e3525b1061

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

LOG: [AIX] Disable unsupported offloading gpu tests

GPUs are not supported on AIX, so this patch sets these tests as unsupported.

Reviewed By: stevewan

Differential Revision: https://reviews.llvm.org/D114381

Added: 


Modified: 
clang/test/Driver/clang-offload-bundler-asserts-on.c
clang/test/Driver/clang-offload-bundler.c
clang/test/Driver/openmp-offload-gpu.c

Removed: 




diff  --git a/clang/test/Driver/clang-offload-bundler-asserts-on.c 
b/clang/test/Driver/clang-offload-bundler-asserts-on.c
index c11028d16343a..7622998c9c182 100644
--- a/clang/test/Driver/clang-offload-bundler-asserts-on.c
+++ b/clang/test/Driver/clang-offload-bundler-asserts-on.c
@@ -1,6 +1,6 @@
 // REQUIRES: x86-registered-target
 // REQUIRES: asserts
-// UNSUPPORTED: darwin
+// UNSUPPORTED: darwin, aix
 
 // Generate the file we can bundle.
 // RUN: %clang -O0 -target %itanium_abi_triple %s -c -o %t.o

diff  --git a/clang/test/Driver/clang-offload-bundler.c 
b/clang/test/Driver/clang-offload-bundler.c
index 9eb305d4d0eeb..a307af4473a1d 100644
--- a/clang/test/Driver/clang-offload-bundler.c
+++ b/clang/test/Driver/clang-offload-bundler.c
@@ -1,6 +1,6 @@
 // REQUIRES: x86-registered-target
 // REQUIRES: powerpc-registered-target
-// UNSUPPORTED: darwin
+// UNSUPPORTED: darwin, aix
 
 //
 // Generate all the types of files we can bundle.

diff  --git a/clang/test/Driver/openmp-offload-gpu.c 
b/clang/test/Driver/openmp-offload-gpu.c
index b1ab7888d5652..dd62b1e5a0760 100644
--- a/clang/test/Driver/openmp-offload-gpu.c
+++ b/clang/test/Driver/openmp-offload-gpu.c
@@ -8,6 +8,8 @@
 // REQUIRES: nvptx-registered-target
 // REQUIRES: amdgpu-registered-target
 
+// UNSUPPORTED: aix
+
 /// ###
 
 /// Check -Xopenmp-target uses one of the archs provided when several archs 
are used.



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

[PATCH] D114320: [clang-format] Extend AllowShortBlocksOnASingleLine for else blocks

2021-11-25 Thread Jesses Gott via Phabricator via cfe-commits

jessesna added a comment.

Thanks a lot for your time and help @MyDeveloperDay


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114320/new/

https://reviews.llvm.org/D114320

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

[PATCH] D114320: [clang-format] Extend AllowShortBlocksOnASingleLine for else blocks

2021-11-25 Thread MyDeveloperDay via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG813d486cbc99: [clang-format] Extend 
AllowShortBlocksOnASingleLine for else blocks (authored by jessesna, committed 
by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114320/new/

https://reviews.llvm.org/D114320

Files:
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -5407,6 +5407,27 @@
   EXPECT_EQ("void f() { }", format("void f() {}", Style));
   Style.AllowShortBlocksOnASingleLine = FormatStyle::SBS_Empty;
   EXPECT_EQ("while (true) { }", format("while (true) {}", Style));
+  Style.BreakBeforeBraces = FormatStyle::BS_Custom;
+  Style.BraceWrapping.BeforeElse = false;
+  Style.BraceWrapping.AfterControlStatement = FormatStyle::BWACS_Always;
+  verifyFormat("if (a)\n"
+   "{\n"
+   "} else if (b)\n"
+   "{\n"
+   "} else\n"
+   "{ }",
+   Style);
+  Style.BraceWrapping.AfterControlStatement = FormatStyle::BWACS_Never;
+  verifyFormat("if (a) {\n"
+   "} else if (b) {\n"
+   "} else {\n"
+   "}",
+   Style);
+  Style.BraceWrapping.BeforeElse = true;
+  verifyFormat("if (a) { }\n"
+   "else if (b) { }\n"
+   "else { }",
+   Style);
 }
 
 TEST_F(FormatTest, FormatBeginBlockEndMacros) {
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -320,9 +320,9 @@
 }
 // Try to merge a control statement block with left brace wrapped
 if (I[1]->First->is(tok::l_brace) &&
-(TheLine->First->isOneOf(tok::kw_if, tok::kw_while, tok::kw_for,
- tok::kw_switch, tok::kw_try, tok::kw_do,
- TT_ForEachMacro) ||
+(TheLine->First->isOneOf(tok::kw_if, tok::kw_else, tok::kw_while,
+ tok::kw_for, tok::kw_switch, tok::kw_try,
+ tok::kw_do, TT_ForEachMacro) ||
  (TheLine->First->is(tok::r_brace) && TheLine->First->Next &&
   TheLine->First->Next->isOneOf(tok::kw_else, tok::kw_catch))) &&
 Style.BraceWrapping.AfterControlStatement ==
@@ -335,7 +335,7 @@
  ? 1
  : 0;
 } else if (I[1]->First->is(tok::l_brace) &&
-   TheLine->First->isOneOf(tok::kw_if, tok::kw_while,
+   TheLine->First->isOneOf(tok::kw_if, tok::kw_else, tok::kw_while,
tok::kw_for)) {
   return (Style.BraceWrapping.AfterControlStatement ==
   FormatStyle::BWACS_Always)
@@ -569,7 +569,7 @@
 
 // Check that the current line allows merging. This depends on whether we
 // are in a control flow statements as well as several style flags.
-if (Line.First->isOneOf(tok::kw_else, tok::kw_case) ||
+if (Line.First->is(tok::kw_case) ||
 (Line.First->Next && Line.First->Next->is(tok::kw_else)))
   return 0;
 // default: in switch statement
@@ -578,20 +578,21 @@
   if (Tok && Tok->is(tok::colon))
 return 0;
 }
-if (Line.First->isOneOf(tok::kw_if, tok::kw_while, tok::kw_do, tok::kw_try,
-tok::kw___try, tok::kw_catch, tok::kw___finally,
-tok::kw_for, tok::r_brace, Keywords.kw___except)) {
+if (Line.First->isOneOf(tok::kw_if, tok::kw_else, tok::kw_while, 
tok::kw_do,
+tok::kw_try, tok::kw___try, tok::kw_catch,
+tok::kw___finally, tok::kw_for, tok::r_brace,
+Keywords.kw___except)) {
   if (Style.AllowShortBlocksOnASingleLine == FormatStyle::SBS_Never)
 return 0;
   // Don't merge when we can't except the case when
   // the control statement block is empty
   if (!Style.AllowShortIfStatementsOnASingleLine &&
-  Line.startsWith(tok::kw_if) &&
+  Line.First->isOneOf(tok::kw_if, tok::kw_else) &&
   !Style.BraceWrapping.AfterControlStatement &&
   !I[1]->First->is(tok::r_brace))
 return 0;
   if (!Style.AllowShortIfStatementsOnASingleLine &&
-  Line.startsWith(tok::kw_if) &&
+  Line.First->isOneOf(tok::kw_if, tok::kw_else) &&
   Style.BraceWrapping.AfterControlStatement ==
   FormatStyle::BWACS_Always &&
   I + 2 != E && !I[2]->First->is(tok::r_brace))


Index: clang/unittests/Format/FormatTest.cpp
===
---

[clang] 813d486 - [clang-format] Extend AllowShortBlocksOnASingleLine for else blocks

2021-11-25 Thread via cfe-commits


Author: Jesses Gott
Date: 2021-11-25T19:45:07Z
New Revision: 813d486cbc99836ea4e75996e2667cb38f7113a8

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

LOG: [clang-format] Extend AllowShortBlocksOnASingleLine for else blocks

Extend AllowShortBlocksOnASingleLine for else blocks. See 
https://bugs.llvm.org/show_bug.cgi?id=49722

Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D114320

Added: 


Modified: 
clang/lib/Format/UnwrappedLineFormatter.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/lib/Format/UnwrappedLineFormatter.cpp 
b/clang/lib/Format/UnwrappedLineFormatter.cpp
index 516b1bcac314c..d099cfee9dea2 100644
--- a/clang/lib/Format/UnwrappedLineFormatter.cpp
+++ b/clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -320,9 +320,9 @@ class LineJoiner {
 }
 // Try to merge a control statement block with left brace wrapped
 if (I[1]->First->is(tok::l_brace) &&
-(TheLine->First->isOneOf(tok::kw_if, tok::kw_while, tok::kw_for,
- tok::kw_switch, tok::kw_try, tok::kw_do,
- TT_ForEachMacro) ||
+(TheLine->First->isOneOf(tok::kw_if, tok::kw_else, tok::kw_while,
+ tok::kw_for, tok::kw_switch, tok::kw_try,
+ tok::kw_do, TT_ForEachMacro) ||
  (TheLine->First->is(tok::r_brace) && TheLine->First->Next &&
   TheLine->First->Next->isOneOf(tok::kw_else, tok::kw_catch))) &&
 Style.BraceWrapping.AfterControlStatement ==
@@ -335,7 +335,7 @@ class LineJoiner {
  ? 1
  : 0;
 } else if (I[1]->First->is(tok::l_brace) &&
-   TheLine->First->isOneOf(tok::kw_if, tok::kw_while,
+   TheLine->First->isOneOf(tok::kw_if, tok::kw_else, tok::kw_while,
tok::kw_for)) {
   return (Style.BraceWrapping.AfterControlStatement ==
   FormatStyle::BWACS_Always)
@@ -569,7 +569,7 @@ class LineJoiner {
 
 // Check that the current line allows merging. This depends on whether we
 // are in a control flow statements as well as several style flags.
-if (Line.First->isOneOf(tok::kw_else, tok::kw_case) ||
+if (Line.First->is(tok::kw_case) ||
 (Line.First->Next && Line.First->Next->is(tok::kw_else)))
   return 0;
 // default: in switch statement
@@ -578,20 +578,21 @@ class LineJoiner {
   if (Tok && Tok->is(tok::colon))
 return 0;
 }
-if (Line.First->isOneOf(tok::kw_if, tok::kw_while, tok::kw_do, tok::kw_try,
-tok::kw___try, tok::kw_catch, tok::kw___finally,
-tok::kw_for, tok::r_brace, Keywords.kw___except)) {
+if (Line.First->isOneOf(tok::kw_if, tok::kw_else, tok::kw_while, 
tok::kw_do,
+tok::kw_try, tok::kw___try, tok::kw_catch,
+tok::kw___finally, tok::kw_for, tok::r_brace,
+Keywords.kw___except)) {
   if (Style.AllowShortBlocksOnASingleLine == FormatStyle::SBS_Never)
 return 0;
   // Don't merge when we can't except the case when
   // the control statement block is empty
   if (!Style.AllowShortIfStatementsOnASingleLine &&
-  Line.startsWith(tok::kw_if) &&
+  Line.First->isOneOf(tok::kw_if, tok::kw_else) &&
   !Style.BraceWrapping.AfterControlStatement &&
   !I[1]->First->is(tok::r_brace))
 return 0;
   if (!Style.AllowShortIfStatementsOnASingleLine &&
-  Line.startsWith(tok::kw_if) &&
+  Line.First->isOneOf(tok::kw_if, tok::kw_else) &&
   Style.BraceWrapping.AfterControlStatement ==
   FormatStyle::BWACS_Always &&
   I + 2 != E && !I[2]->First->is(tok::r_brace))

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 79a74b5141e82..845b1e5e8809a 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -5407,6 +5407,27 @@ TEST_F(FormatTest, PutEmptyBlocksIntoOneLine) {
   EXPECT_EQ("void f() { }", format("void f() {}", Style));
   Style.AllowShortBlocksOnASingleLine = FormatStyle::SBS_Empty;
   EXPECT_EQ("while (true) { }", format("while (true) {}", Style));
+  Style.BreakBeforeBraces = FormatStyle::BS_Custom;
+  Style.BraceWrapping.BeforeElse = false;
+  Style.BraceWrapping.AfterControlStatement = FormatStyle::BWACS_Always;
+  verifyFormat("if (a)\n"
+   "{\n"
+   "} else if (b)\n"
+   "{\n"
+   "} else\n"
+   "{ }",
+   Style);
+  Style.BraceWrapping.AfterControlStatement =

[PATCH] D114609: [clang] Fix crash on broken parameter declarators

2021-11-25 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet created this revision.
kadircet added reviewers: sammccall, hokein.
kadircet requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D114609

Files:
  clang/lib/Parse/ParseDecl.cpp
  clang/test/Parser/cxx-decltype-parameter.cpp


Index: clang/test/Parser/cxx-decltype-parameter.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx-decltype-parameter.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+struct Bar {};
+struct Foo {
+  Bar bar(*decltype(Bar{}) aux); // expected-error {{C++ requires a type 
specifier for all declarations}}. \
+ // expected-error {{expected ')'}} 
expected-note {{to match this '('}}
+};
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -6978,13 +6978,13 @@
   //
   // We care about case 1) where the declarator type should be known, and
   // the identifier should be null.
-  if (!ParmDeclarator.isInvalidType() && !ParmDeclarator.hasName()) {
-if (Tok.getIdentifierInfo() &&
-Tok.getIdentifierInfo()->isKeyword(getLangOpts())) {
-  Diag(Tok, diag::err_keyword_as_parameter) << PP.getSpelling(Tok);
-  // Consume the keyword.
-  ConsumeToken();
-}
+  if (!ParmDeclarator.isInvalidType() && !ParmDeclarator.hasName() &&
+  Tok.isNot(tok::raw_identifier) && !Tok.isAnnotation() &&
+  Tok.getIdentifierInfo() &&
+  Tok.getIdentifierInfo()->isKeyword(getLangOpts())) {
+Diag(Tok, diag::err_keyword_as_parameter) << PP.getSpelling(Tok);
+// Consume the keyword.
+ConsumeToken();
   }
   // Inform the actions module about the parameter declarator, so it gets
   // added to the current scope.


Index: clang/test/Parser/cxx-decltype-parameter.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx-decltype-parameter.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+struct Bar {};
+struct Foo {
+  Bar bar(*decltype(Bar{}) aux); // expected-error {{C++ requires a type specifier for all declarations}}. \
+ // expected-error {{expected ')'}} expected-note {{to match this '('}}
+};
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -6978,13 +6978,13 @@
   //
   // We care about case 1) where the declarator type should be known, and
   // the identifier should be null.
-  if (!ParmDeclarator.isInvalidType() && !ParmDeclarator.hasName()) {
-if (Tok.getIdentifierInfo() &&
-Tok.getIdentifierInfo()->isKeyword(getLangOpts())) {
-  Diag(Tok, diag::err_keyword_as_parameter) << PP.getSpelling(Tok);
-  // Consume the keyword.
-  ConsumeToken();
-}
+  if (!ParmDeclarator.isInvalidType() && !ParmDeclarator.hasName() &&
+  Tok.isNot(tok::raw_identifier) && !Tok.isAnnotation() &&
+  Tok.getIdentifierInfo() &&
+  Tok.getIdentifierInfo()->isKeyword(getLangOpts())) {
+Diag(Tok, diag::err_keyword_as_parameter) << PP.getSpelling(Tok);
+// Consume the keyword.
+ConsumeToken();
   }
   // Inform the actions module about the parameter declarator, so it gets
   // added to the current scope.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113049: [AIX] Disable tests that fail because of no 64-bit XCOFF object file support

2021-11-25 Thread Jake Egan via Phabricator via cfe-commits

Jake-Egan updated this revision to Diff 389849.
Jake-Egan added a comment.

Removed some tests already disabled by D114481 
.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113049/new/

https://reviews.llvm.org/D113049

Files:
  clang/test/ASTMerge/anonymous-fields/test.cpp
  clang/test/ASTMerge/codegen-body/test.c
  clang/test/ASTMerge/injected-class-name-decl/test.cpp
  clang/test/ClangScanDeps/modules-full-by-mod-name.cpp
  clang/test/ClangScanDeps/resource_directory.c
  clang/test/Driver/as-version.s
  clang/test/Driver/cc-print-proc-stat.c
  clang/test/Driver/compilation_database.c
  clang/test/Driver/modules-ts.cpp
  clang/test/Driver/report-stat.c
  clang/test/lit.cfg.py
  llvm/test/LTO/X86/remangle_intrinsics.ll
  llvm/test/lit.cfg.py
  llvm/unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp

Index: llvm/unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
===
--- llvm/unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
+++ llvm/unittests/DebugInfo/DWARF/DWARFDebugInfoTest.cpp
@@ -1131,7 +1131,11 @@
   EXPECT_STREQ(String1, *Extracted3);
 }
 
+#if defined(_AIX) && defined(__64BIT__)
+TEST(DWARFDebugInfo, DISABLED_TestEmptyStringOffsets) {
+#else
 TEST(DWARFDebugInfo, TestEmptyStringOffsets) {
+#endif
   Triple Triple = getNormalizedDefaultTargetTriple();
   if (!isObjectEmissionSupported(Triple))
 return;
@@ -1160,7 +1164,11 @@
   DwarfContext->getDWARFObj().getStrOffsetsSection().Data.empty());
 }
 
+#if defined(_AIX) && defined(__64BIT__)
+TEST(DWARFDebugInfo, DISABLED_TestRelations) {
+#else
 TEST(DWARFDebugInfo, TestRelations) {
+#endif
   Triple Triple = getNormalizedDefaultTargetTriple();
   if (!isObjectEmissionSupported(Triple))
 return;
@@ -1347,7 +1355,11 @@
   EXPECT_FALSE(DefaultDie.getSibling().isValid());
 }
 
+#if defined(_AIX) && defined(__64BIT__)
+TEST(DWARFDebugInfo, DISABLED_TestChildIterators) {
+#else
 TEST(DWARFDebugInfo, TestChildIterators) {
+#endif
   Triple Triple = getNormalizedDefaultTargetTriple();
   if (!isObjectEmissionSupported(Triple))
 return;
@@ -1456,7 +1468,11 @@
   EXPECT_EQ(CUDie.begin(), CUDie.end());
 }
 
+#if defined(_AIX) && defined(__64BIT__)
+TEST(DWARFDebugInfo, DISABLED_TestAttributeIterators) {
+#else
 TEST(DWARFDebugInfo, TestAttributeIterators) {
+#endif
   Triple Triple = getNormalizedDefaultTargetTriple();
   if (!isObjectEmissionSupported(Triple))
 return;
@@ -1518,7 +1534,11 @@
   EXPECT_EQ(E, ++I);
 }
 
+#if defined(_AIX) && defined(__64BIT__)
+TEST(DWARFDebugInfo, DISABLED_TestFindRecurse) {
+#else
 TEST(DWARFDebugInfo, TestFindRecurse) {
+#endif
   Triple Triple = getNormalizedDefaultTargetTriple();
   if (!isObjectEmissionSupported(Triple))
 return;
@@ -1732,7 +1752,11 @@
   // Test
 }
 
+#if defined(_AIX) && defined(__64BIT__)
+TEST(DWARFDebugInfo, DISABLED_TestFindAttrs) {
+#else
 TEST(DWARFDebugInfo, TestFindAttrs) {
+#endif
   Triple Triple = getNormalizedDefaultTargetTriple();
   if (!isObjectEmissionSupported(Triple))
 return;
@@ -1795,7 +1819,11 @@
   EXPECT_EQ(DieMangled, toString(NameOpt, ""));
 }
 
+#if defined(_AIX) && defined(__64BIT__)
+TEST(DWARFDebugInfo, DISABLED_TestImplicitConstAbbrevs) {
+#else
 TEST(DWARFDebugInfo, TestImplicitConstAbbrevs) {
+#endif
   Triple Triple = getNormalizedDefaultTargetTriple();
   if (!isObjectEmissionSupported(Triple))
 return;
Index: llvm/test/lit.cfg.py
===
--- llvm/test/lit.cfg.py
+++ llvm/test/lit.cfg.py
@@ -402,3 +402,22 @@
 
 if "MemoryWithOrigins" in config.llvm_use_sanitizer:
 config.available_features.add('use_msan_with_origins')
+
+def exclude_unsupported_files_for_aix(dirname):
+   for filename in os.listdir(dirname):
+   source_path = os.path.join( dirname, filename)
+   if os.path.isdir(source_path):
+   continue
+   f = open(source_path, 'r')
+   try:
+  data = f.read()
+  # 64-bit object files are not supported on AIX, so exclude the tests.
+  if ('-emit-obj' in data or '-filetype=obj' in data) and '64' in config.target_triple:
+config.excludes += [ filename ]
+   finally:
+  f.close()
+
+if 'aix' in config.target_triple:
+for directory in ('/CodeGen/X86', '/DebugInfo', '/DebugInfo/X86', '/DebugInfo/Generic', '/LTO/X86', '/Linker'):
+exclude_unsupported_files_for_aix(config.test_source_root + directory)
+
Index: llvm/test/LTO/X86/remangle_intrinsics.ll
===
--- llvm/test/LTO/X86/remangle_intrinsics.ll
+++ llvm/test/LTO/X86/remangle_intrinsics.ll
@@ -1,3 +1,4 @@
+; UNSUPPORTED: powerpc64-ibm-aix
 ; RUN: llvm-as < %s > %t1
 ; RUN: llvm-as < %p/Inputs/remangle_intrinsics.ll > %t2
 ; RUN: llvm-lto %t1 %t2 | FileCheck %s
Index: clang/test/lit.cfg.py

[PATCH] D113049: [AIX] Disable tests that fail because of no 64-bit XCOFF object file support

2021-11-25 Thread Jake Egan via Phabricator via cfe-commits

Jake-Egan added inline comments.



Comment at: clang/test/ClangScanDeps/modules-full-by-mod-name.cpp:1
+// UNSUPPORTED: powerpc64-ibm-aix
 // RUN: rm -rf %t.dir

jsji wrote:
> there is no `fmodule-format=obj` here, why are we failing here?
> 
They have the same error as the other tests:

```
64-bit XCOFF object files are not supported yet.
```



Comment at: clang/test/lit.cfg.py:259
+if 'aix' in config.target_triple:
+for directory in ('/CodeGenCXX', '/Misc', '/Modules', '/PCH'):
+exclude_unsupported_files_for_aix(config.test_source_root + directory)

jsji wrote:
> Why not adding `ASTMerge` and its subfolders?
Adding those folders were causing regressions:

```
Clang :: utils/update_cc_test_checks/global-hex-value-regex.test
Clang :: utils/update_cc_test_checks/global-value-regex.test
```
With error:

```
did not discover any tests for provided path(s)
```

I think because the only test in the folder gets excluded, so LIT can't find 
any test to run.

I could create a lit.local.cfg in each `ASTMerge` subfolder to unsupport each 
one if that's preferred.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113049/new/

https://reviews.llvm.org/D113049

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

[PATCH] D114553: [HIP] Add atomic load, atomic store and atomic cmpxchng_weak builtin support in HIP-clang

2021-11-25 Thread Anshil Gandhi via Phabricator via cfe-commits

gandhi21299 added a comment.

Passed internal CI


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114553/new/

https://reviews.llvm.org/D114553

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

[PATCH] D114553: [HIP] Add atomic load, atomic store and atomic cmpxchng_weak builtin support in HIP-clang

2021-11-25 Thread Anshil Gandhi via Phabricator via cfe-commits

gandhi21299 updated this revision to Diff 389834.
gandhi21299 added a comment.

- applied clang-format


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114553/new/

https://reviews.llvm.org/D114553

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/Builtins.def
  clang/lib/AST/Expr.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/CodeGen/CGAtomic.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGenCUDA/atomic-ops.cu
  clang/test/SemaCUDA/atomic-ops.cu

Index: clang/test/SemaCUDA/atomic-ops.cu
===
--- /dev/null
+++ clang/test/SemaCUDA/atomic-ops.cu
@@ -0,0 +1,73 @@
+// RUN: %clang_cc1 -x hip -std=c++11 -triple amdgcn -fcuda-is-device -verify -fsyntax-only %s
+
+#include "Inputs/cuda.h"
+
+__device__ int test_hip_atomic_load(int *pi32, unsigned int *pu32, long long *pll, unsigned long long *pull, float *fp, double *dbl) {
+  int val = __hip_atomic_load(0);  // expected-error {{too few arguments to function call, expected 3, have 1}}
+  val = __hip_atomic_load(0, 0, 0, 0); // expected-error {{too many arguments to function call, expected 3, have 4}}
+  val = __hip_atomic_load(0, 0, 0);// expected-error {{address argument to atomic builtin must be a pointer ('int' invalid)}}
+  val = __hip_atomic_load(pi32, 0, 0); // expected-error {{synchronization scope argument to atomic operation is invalid}}
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_WAVEFRONT);
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_WORKGROUP);
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_AGENT);
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_SYSTEM);
+  val = __hip_atomic_load(pi32, 0, 6); // expected-error {{synchronization scope argument to atomic operation is invalid}}
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pi32, 1, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pi32, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pi32, 3, __HIP_MEMORY_SCOPE_SINGLETHREAD); // expected-warning {{memory order argument to atomic operation is invalid}}
+  val = __hip_atomic_load(pu32, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pll, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pull, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(fp, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(dbl, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  return val;
+}
+
+__device__ int test_hip_atomic_store(int *pi32, unsigned int *pu32, long long *pll, unsigned long long *pull, float *fp, double *dbl,
+ int i32, unsigned int u32, long long i64, unsigned long long u64, float f32, double f64) {
+  __hip_atomic_store(0); // expected-error {{too few arguments to function call, expected 4, have 1}}
+  __hip_atomic_store(0, 0, 0, 0, 0); // expected-error {{too many arguments to function call, expected 4, have 5}}
+  __hip_atomic_store(0, 0, 0, 0);// expected-error {{address argument to atomic builtin must be a pointer ('int' invalid)}}
+  __hip_atomic_store(pi32, 0, 0, 0); // expected-error {{synchronization scope argument to atomic operation is invalid}}
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_WAVEFRONT);
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_WORKGROUP);
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_AGENT);
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_SYSTEM);
+  __hip_atomic_store(pi32, 0, 0, 6); // expected-error {{synchronization scope argument to atomic operation is invalid}}
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, i32, 1, __HIP_MEMORY_SCOPE_SINGLETHREAD); // expected-warning {{memory order argument to atomic operation is invalid}}
+  __hip_atomic_store(pi32, i32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, i32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pu32, u32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pll, i64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pull, u64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(fp, f32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(dbl, f64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, u32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, i64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, u64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pll, i32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(fp, i32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(fp, i64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(dbl, i64, 0,

[PATCH] D114553: [HIP] Add atomic load, atomic store and atomic cmpxchng_weak builtin support in HIP-clang

2021-11-25 Thread Anshil Gandhi via Phabricator via cfe-commits

gandhi21299 updated this revision to Diff 389833.
gandhi21299 added a comment.

- added order argument in the builtins and changed the tests accordingly
- adding Sema test


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114553/new/

https://reviews.llvm.org/D114553

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/Builtins.def
  clang/lib/AST/Expr.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/CodeGen/CGAtomic.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGenCUDA/atomic-ops.cu
  clang/test/SemaCUDA/atomic-ops.cu

Index: clang/test/SemaCUDA/atomic-ops.cu
===
--- /dev/null
+++ clang/test/SemaCUDA/atomic-ops.cu
@@ -0,0 +1,73 @@
+// RUN: %clang_cc1 -x hip -std=c++11 -triple amdgcn -fcuda-is-device -verify -fsyntax-only %s
+
+#include "Inputs/cuda.h"
+
+__device__ int test_hip_atomic_load(int *pi32, unsigned int *pu32, long long *pll, unsigned long long *pull, float *fp, double *dbl) {
+  int val = __hip_atomic_load(0); // expected-error {{too few arguments to function call, expected 3, have 1}}
+  val = __hip_atomic_load(0, 0, 0, 0); // expected-error {{too many arguments to function call, expected 3, have 4}}
+  val = __hip_atomic_load(0, 0, 0); // expected-error {{address argument to atomic builtin must be a pointer ('int' invalid)}}
+  val = __hip_atomic_load(pi32, 0, 0);  // expected-error {{synchronization scope argument to atomic operation is invalid}}
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_WAVEFRONT);
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_WORKGROUP);
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_AGENT);
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_SYSTEM);
+  val = __hip_atomic_load(pi32, 0, 6);  // expected-error {{synchronization scope argument to atomic operation is invalid}}
+  val = __hip_atomic_load(pi32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pi32, 1, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pi32, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pi32, 3, __HIP_MEMORY_SCOPE_SINGLETHREAD); // expected-warning {{memory order argument to atomic operation is invalid}}
+  val = __hip_atomic_load(pu32, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pll, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(pull, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(fp, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  val = __hip_atomic_load(dbl, 2, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  return val;
+}
+
+__device__ int test_hip_atomic_store(int *pi32, unsigned int *pu32, long long *pll, unsigned long long *pull, float *fp, double *dbl,
+int i32, unsigned int u32, long long i64, unsigned long long u64, float f32, double f64){
+  __hip_atomic_store(0); // expected-error {{too few arguments to function call, expected 4, have 1}}
+  __hip_atomic_store(0, 0, 0, 0, 0); // expected-error {{too many arguments to function call, expected 4, have 5}}
+  __hip_atomic_store(0, 0, 0, 0); // expected-error {{address argument to atomic builtin must be a pointer ('int' invalid)}}
+  __hip_atomic_store(pi32, 0, 0, 0);  // expected-error {{synchronization scope argument to atomic operation is invalid}}
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_WAVEFRONT);
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_WORKGROUP);
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_AGENT);
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_SYSTEM);
+  __hip_atomic_store(pi32, 0, 0, 6);  // expected-error {{synchronization scope argument to atomic operation is invalid}}
+  __hip_atomic_store(pi32, 0, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, i32, 1, __HIP_MEMORY_SCOPE_SINGLETHREAD); // expected-warning {{memory order argument to atomic operation is invalid}}
+  __hip_atomic_store(pi32, i32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, i32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pu32, u32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pll, i64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pull, u64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(fp, f32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(dbl, f64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, u32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, i64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pi32, u64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(pll, i32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(fp, i32, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(fp, i64, 0, __HIP_MEMORY_SCOPE_SINGLETHREAD);
+  __hip_atomic_store(dbl, i64, 0,

[PATCH] D114320: [clang-format] Extend AllowShortBlocksOnASingleLine for else blocks

2021-11-25 Thread Jesses Gott via Phabricator via cfe-commits

jessesna added a comment.

Great. Thanks a lot. It's Jesses Gott and jesses.gott.na+l...@gmail.com


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114320/new/

https://reviews.llvm.org/D114320

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

[PATCH] D114320: [clang-format] Extend AllowShortBlocksOnASingleLine for else blocks

2021-11-25 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

one of us can commit it for you but we need to do the following to attribute it 
to you

commit --amend --author="John Doe "

So I need your name and email address.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114320/new/

https://reviews.llvm.org/D114320

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

[PATCH] D114583: [clang-format] Adjust braced list detection

2021-11-25 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.
This revision is now accepted and ready to land.

I ran the examples from https://bugs.llvm.org/show_bug.cgi?id=38314 and its so 
much better than the previous state!

Thanks for this patch, LGTM

  namespace n {
  void foo() {
  {
  {
  {
  statement();
  if (false) {
  }
  }
  }
  {}
  }
  }
  }  // namespace n
  
  void foo() {
  {
  {
  statement();
  if (false) {
  }
  }
  }
  {}
  }  // namespace n


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114583/new/

https://reviews.llvm.org/D114583

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

[PATCH] D114564: Fix the use of -fno-approx-func along with -Ofast or -ffast-math

2021-11-25 Thread Masoud Ataei via Phabricator via cfe-commits

masoud.ataei marked 2 inline comments as done.
masoud.ataei added inline comments.

Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2760
 case options::OPT_fno_honor_nans:   HonorNaNs = false;break;
 case options::OPT_fapprox_func: ApproxFunc = true;break;
 case options::OPT_fno_approx_func:  ApproxFunc = false;   break;

andrew.w.kaylor wrote:
> Should this also imply "MathErrno = false"?
I don't think setting ApproxFunc to true should imply "MathErrno = false". 

Let say someone have a math library that compute approximate result for none 
special input/output but returns NaN, INF and errno correctly otherwise. That 
is actually can be fairly common, because performance in the none special cases 
are much more important that the special ones. So returning errno in the 
special outputs theoretically should not effect the performance on the main 
path. Therefore, I think compiler should not assume anything about MathErrno 
value based on ApproxFunc value.

Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2762
 case options::OPT_fno_approx_func:  ApproxFunc = false;   break;
 case options::OPT_fmath_errno:  MathErrno = true; break;
 case options::OPT_fno_math_errno:   MathErrno = false;break;

andrew.w.kaylor wrote:
> Should this conflict with -fapprox-func?
Same as above.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114564/new/

https://reviews.llvm.org/D114564

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

[PATCH] D114583: [clang-format] Adjust braced list detection

2021-11-25 Thread S. B. Tam via Phabricator via cfe-commits

cpplearner updated this revision to Diff 389822.
cpplearner added a comment.

Fixed tests.

Since in JavaScript, the thing after `extends` must be an expression, and the 
thing after `implements` must be an object type, I decided to parse both as 
braced lists without going through `tryToParseBracedList`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114583/new/

https://reviews.llvm.org/D114583

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -11731,6 +11731,15 @@
"  f(v);\n"
"}");
 
+  verifyFormat("void foo() {\n"
+   "  { // asdf\n"
+   "{ int a; }\n"
+   "  }\n"
+   "  {\n"
+   "{ int b; }\n"
+   "  }\n"
+   "}");
+
   // Long lists should be formatted in columns even if they are nested.
   verifyFormat(
   "vector x = function({1, 22, 333, , 5, 66, 777,\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -513,17 +513,14 @@
   // BlockKind later if we parse a braced list (where all blocks
   // inside are by default braced lists), or when we explicitly detect
   // blocks (for example while parsing lambdas).
-  // FIXME: Some of these do not apply to JS, e.g. "} {" can never be a
-  // braced list in JS.
   ProbablyBracedList =
   (Style.Language == FormatStyle::LK_JavaScript &&
NextTok->isOneOf(Keywords.kw_of, Keywords.kw_in,
 Keywords.kw_as)) ||
   (Style.isCpp() && NextTok->is(tok::l_paren)) ||
   NextTok->isOneOf(tok::comma, tok::period, tok::colon,
-   tok::r_paren, tok::r_square, tok::l_brace,
-   tok::ellipsis) ||
-  (NextTok->is(tok::identifier) &&
+   tok::r_paren, tok::r_square, tok::ellipsis) ||
+  (NextTok->isOneOf(tok::l_brace, tok::identifier) &&
!PrevTok->isOneOf(tok::semi, tok::r_brace, tok::l_brace)) ||
   (NextTok->is(tok::semi) &&
(!ExpectClassBody || LBraceStack.size() != 1)) ||
@@ -2761,7 +2758,7 @@
   // class Foo implements {bar: number} { }
   nextToken();
   if (FormatTok->is(tok::l_brace)) {
-tryToParseBracedList();
+parseBracedList();
 continue;
   }
 }


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -11731,6 +11731,15 @@
"  f(v);\n"
"}");
 
+  verifyFormat("void foo() {\n"
+   "  { // asdf\n"
+   "{ int a; }\n"
+   "  }\n"
+   "  {\n"
+   "{ int b; }\n"
+   "  }\n"
+   "}");
+
   // Long lists should be formatted in columns even if they are nested.
   verifyFormat(
   "vector x = function({1, 22, 333, , 5, 66, 777,\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -513,17 +513,14 @@
   // BlockKind later if we parse a braced list (where all blocks
   // inside are by default braced lists), or when we explicitly detect
   // blocks (for example while parsing lambdas).
-  // FIXME: Some of these do not apply to JS, e.g. "} {" can never be a
-  // braced list in JS.
   ProbablyBracedList =
   (Style.Language == FormatStyle::LK_JavaScript &&
NextTok->isOneOf(Keywords.kw_of, Keywords.kw_in,
 Keywords.kw_as)) ||
   (Style.isCpp() && NextTok->is(tok::l_paren)) ||
   NextTok->isOneOf(tok::comma, tok::period, tok::colon,
-   tok::r_paren, tok::r_square, tok::l_brace,
-   tok::ellipsis) ||
-  (NextTok->is(tok::identifier) &&
+   tok::r_paren, tok::r_square, tok::ellipsis) ||
+  (NextTok->isOneOf(tok::l_brace, tok::identifier) &&
!PrevTok->isOneOf(tok::semi, tok::r_brace, tok::l_brace)) ||
   (NextTok->is(tok::semi) &&
(!ExpectClassBody || LBraceStack.size() != 1)) ||
@@ -2761,7 +2758,7 @@
   // class Foo implements {bar: number} { }
   nextToken();
   if

[PATCH] D114564: Fix the use of -fno-approx-func along with -Ofast or -ffast-math

2021-11-25 Thread Masoud Ataei via Phabricator via cfe-commits

masoud.ataei updated this revision to Diff 389820.
masoud.ataei edited the summary of this revision.
masoud.ataei added a comment.

Updated the test combining -ffast-math and -fno-approx-func options.
@andrew.w.kaylor I hope you don't mind that I put those tests on 
`clang/test/Driver/fast-math.c` instead.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114564/new/

https://reviews.llvm.org/D114564

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/fast-math.c
  clang/test/Preprocessor/aarch64-target-features.c
  clang/test/Preprocessor/arm-target-features.c

Index: clang/test/Preprocessor/arm-target-features.c
===
--- clang/test/Preprocessor/arm-target-features.c
+++ clang/test/Preprocessor/arm-target-features.c
@@ -267,7 +267,7 @@
 // CHECK-DEFS:#define __ARM_SIZEOF_WCHAR_T 4
 
 // RUN: %clang -target arm-none-linux-gnu -fno-math-errno -fno-signed-zeros\
-// RUN:-fno-trapping-math -fassociative-math -freciprocal-math\
+// RUN:-fno-trapping-math -fassociative-math -freciprocal-math -fapprox-func\
 // RUN:-x c -E -dM %s -o - | FileCheck -match-full-lines --check-prefix=CHECK-FASTMATH %s
 // RUN: %clang -target arm-none-linux-gnu -ffast-math -x c -E -dM %s -o -\
 // RUN:| FileCheck -match-full-lines --check-prefix=CHECK-FASTMATH %s
Index: clang/test/Preprocessor/aarch64-target-features.c
===
--- clang/test/Preprocessor/aarch64-target-features.c
+++ clang/test/Preprocessor/aarch64-target-features.c
@@ -115,7 +115,7 @@
 // CHECK-CRC32: __ARM_FEATURE_CRC32 1
 
 // RUN: %clang -target aarch64-none-linux-gnu -fno-math-errno -fno-signed-zeros\
-// RUN:-fno-trapping-math -fassociative-math -freciprocal-math\
+// RUN:-fno-trapping-math -fassociative-math -freciprocal-math -fapprox-func\
 // RUN:-x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-FASTMATH %s
 // RUN: %clang -target aarch64-none-linux-gnu -ffast-math -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-FASTMATH %s
 // RUN: %clang -target arm64-none-linux-gnu -ffast-math -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-FASTMATH %s
Index: clang/test/Driver/fast-math.c
===
--- clang/test/Driver/fast-math.c
+++ clang/test/Driver/fast-math.c
@@ -70,6 +70,23 @@
 // CHECK-NO-NANS-NO-FAST-MATH: "-cc1"
 // CHECK-NO-NANS-NO-FAST-MATH-NOT: "-menable-no-nans"
 //
+// RUN: %clang -### -ffast-math -fno-approx-func -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FAST-MATH-NO-APPROX-FUNC %s
+// CHECK-FAST-MATH-NO-APPROX-FUNC: "-cc1"
+// CHECK-FAST-MATH-NO-APPROX-FUNC: "-menable-no-infs"
+// CHECK-FAST-MATH-NO-APPROX-FUNC: "-menable-no-nans"
+// CHECK-FAST-MATH-NO-APPROX-FUNC: "-fno-signed-zeros"
+// CHECK-FAST-MATH-NO-APPROX-FUNC: "-mreassociate"
+// CHECK-FAST-MATH-NO-APPROX-FUNC: "-freciprocal-math"
+// CHECK-FAST-MATH-NO-APPROX-FUNC: "-ffp-contract=fast"
+// CHECK-FAST-MATH-NO-APPROX-FUNC-NOT: "-ffast-math"
+// CHECK-FAST-MATH-NO-APPROX-FUNC-NOT: "-fapprox-func"
+//
+// RUN: %clang -### -fno-approx-func -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-NO-APPROX-FUNC-FAST-MATH %s
+// CHECK-NO-APPROX-FUNC-FAST-MATH: "-cc1"
+// CHECK-NO-APPROX-FUNC-FAST-MATH: "-ffast-math"
+//
 // RUN: %clang -### -fapprox-func -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-APPROX-FUNC %s
 // CHECK-APPROX-FUNC: "-cc1"
@@ -130,14 +147,14 @@
 // RUN:   | FileCheck --check-prefix=CHECK-NO-MATH-ERRNO %s
 //
 // RUN: %clang -### -fno-math-errno -fassociative-math -freciprocal-math \
-// RUN: -fno-signed-zeros -fno-trapping-math -c %s 2>&1 \
+// RUN: -fno-signed-zeros -fno-trapping-math -fapprox-func -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-UNSAFE-MATH %s
 // CHECK-UNSAFE-MATH: "-cc1"
 // CHECK-UNSAFE-MATH: "-menable-unsafe-fp-math"
 // CHECK-UNSAFE-MATH: "-mreassociate"
 //
 // RUN: %clang -### -fno-fast-math -fno-math-errno -fassociative-math -freciprocal-math \
-// RUN: -fno-signed-zeros -fno-trapping-math -c %s 2>&1 \
+// RUN: -fno-signed-zeros -fno-trapping-math -fapprox-func -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-NO-FAST-MATH-UNSAFE-MATH %s
 // CHECK-NO-FAST-MATH-UNSAFE-MATH: "-cc1"
 // CHECK-NO-FAST-MATH-UNSAFE-MATH: "-menable-unsafe-fp-math"
@@ -178,7 +195,7 @@
 // RUN: -fno-math-errno -ffp-contract=fast -fno-rounding-math -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-FAST-MATH %s
 // RUN: %clang -### -fno-honor-infinities -fno-honor-nans -fno-math-errno \
-// RUN: -fassociative-math -freciprocal-math -fno-signed-zeros \
+// RUN: -fassociative-math -freciprocal-math -fno-signed-zeros -fapprox-func \
 // RUN: -fno-trapping-math -ffp-contract=fast -fno-rounding-math -c %s 2>&1 \
 // RUN:   | FileCheck

[PATCH] D114533: LLVM IR should allow bitcast between address spaces with the same size.

2021-11-25 Thread Jessica Clarke via Phabricator via cfe-commits

jrtc27 added a comment.

In D114533#3154225 , @arsenm wrote:

> In D114533#3153924 , @jrtc27 wrote:
>
>> This seems like it should not apply to non-integral address spaces?
>
> No, it shouldn’t care about the individual address spaces. It’s a reinterpret 
> of the bits, the type meanings don’t matter

Well, they absolutely do for us downstream, but we also don't use the 
non-integral address space feature, since it didn't exist when our fork started 
and also has overly restrictive semantics. Normally the places we need to stop 
these kinds of casts/reinterpretations are a subset of those for non-integral 
address spaces, but maybe this is one of those exceptions then. I certainly 
have no clue about what the non-integral address spaces are actually used for 
and mean :)

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114533/new/

https://reviews.llvm.org/D114533

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

[PATCH] D114326: Update the list of CUDA versions up to 11.5

2021-11-25 Thread Mojca Miklavec via Phabricator via cfe-commits

mojca added a comment.

Somewhat off-topic from a discussion earlier in the thread.
What's the purpose of the following code then if users are supposed to 
explicitly specify the `-L` flag anyway?

  c++
  if (HostTriple.isArch64Bit() && FS.exists(InstallPath + "/lib64"))
LibPath = InstallPath + "/lib64";
  else if (FS.exists(InstallPath + "/lib"))
LibPath = InstallPath + "/lib";
  else
continue;

The code above may be improved for Windows (it needs a different path there), 
for example like this:

  c++
  if (HostTriple.isOSWindows() && (HostTriple.getArch() == 
llvm::Triple::ArchType::x86_64) && FS.exists(InstallPath + "/lib/x64"))
LibPath = InstallPath + "/lib/x64";
  if (HostTriple.isArch64Bit() && FS.exists(InstallPath + "/lib64"))
LibPath = InstallPath + "/lib64";
  else if (FS.exists(InstallPath + "/lib"))
LibPath = InstallPath + "/lib";
  else
continue;

but I fail to figure out how to make use of this variable.

CMake might be able to add the right flags automatically (but it doesn't 
currently support Clang with CUDA on Windows), but writing the following down 
"manually" is relatively annoying:

  clang++.exe hello.cu -o hello --cuda-path="C:/Program Files/NVIDIA GPU 
Computing Toolkit/CUDA/v11.4" -l cudart -L "C:/Program Files/NVIDIA GPU 
Computing Toolkit/CUDA/v11.4/lib/x64"

Also, it's probably destined to lead into issues if the user needs to manually 
specify the library path, while the cuda path is determined automatically.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114326/new/

https://reviews.llvm.org/D114326

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

[PATCH] D114533: LLVM IR should allow bitcast between address spaces with the same size.

2021-11-25 Thread Matt Arsenault via Phabricator via cfe-commits

arsenm added a comment.

In D114533#3153924 , @jrtc27 wrote:

> This seems like it should not apply to non-integral address spaces?

No, it shouldn’t care about the individual address spaces. It’s a reinterpret 
of the bits, the type meanings don’t matter


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114533/new/

https://reviews.llvm.org/D114533

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

[PATCH] D114602: [clang-tidy] Improve documentation of bugprone-unhandled-exception-at-new [NFC]

2021-11-25 Thread Eugene Zelenko via Phabricator via cfe-commits

Eugene.Zelenko added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-exception-at-new.rst:31
+
+
+

Two excessive newlines.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114602/new/

https://reviews.llvm.org/D114602

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

[PATCH] D114100: [NFC][clang-tools-extra] Inclusive language: replace master with main

2021-11-25 Thread Quinn Pham via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc3dc6b081da6: [NFC][clang-tools-extra] Inclusive language: 
replace master with main (authored by quinnp).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114100/new/

https://reviews.llvm.org/D114100

Files:
  clang-tools-extra/test/modularize/SubModule2.h


Index: clang-tools-extra/test/modularize/SubModule2.h
===
--- clang-tools-extra/test/modularize/SubModule2.h
+++ clang-tools-extra/test/modularize/SubModule2.h
@@ -1,3 +1,3 @@
-// SubModule2.h - Master header with same name as directory.
+// SubModule2.h - Main header with same name as directory.
 #include "SubModule2/Header3.h"
 #include "SubModule2/Header4.h"


Index: clang-tools-extra/test/modularize/SubModule2.h
===
--- clang-tools-extra/test/modularize/SubModule2.h
+++ clang-tools-extra/test/modularize/SubModule2.h
@@ -1,3 +1,3 @@
-// SubModule2.h - Master header with same name as directory.
+// SubModule2.h - Main header with same name as directory.
 #include "SubModule2/Header3.h"
 #include "SubModule2/Header4.h"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] c3dc6b0 - [NFC][clang-tools-extra] Inclusive language: replace master with main

2021-11-25 Thread Quinn Pham via cfe-commits


Author: Quinn Pham
Date: 2021-11-25T11:01:16-06:00
New Revision: c3dc6b081da6ba503e67d260033f81f61eb38ea3

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

LOG: [NFC][clang-tools-extra] Inclusive language: replace master with main

[NFC] As part of using inclusive language within the llvm project, this patch
replaces master with main in `SubModule2.h`.

Reviewed By: sammccall

Differential Revision: https://reviews.llvm.org/D114100

Added: 


Modified: 
clang-tools-extra/test/modularize/SubModule2.h

Removed: 




diff  --git a/clang-tools-extra/test/modularize/SubModule2.h 
b/clang-tools-extra/test/modularize/SubModule2.h
index 70d711b7e36c4..b2e5a626ac459 100644
--- a/clang-tools-extra/test/modularize/SubModule2.h
+++ b/clang-tools-extra/test/modularize/SubModule2.h
@@ -1,3 +1,3 @@
-// SubModule2.h - Master header with same name as directory.
+// SubModule2.h - Main header with same name as directory.
 #include "SubModule2/Header3.h"
 #include "SubModule2/Header4.h"



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

[PATCH] D112421: [clang][ARM] PACBTI-M frontend support

2021-11-25 Thread Momchil Velikov via Phabricator via cfe-commits

chill added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:6377
+
+static const char *SignReturnAddrStr[] = {"none", "non-leaf", "all"};
+Fn->addFnAttr("sign-return-address",

vhscampos wrote:
> I reckon selecting the string using a switch statement on BPI.SignReturnAddr 
> is more type safe than doing it like this. The current selection is prone to 
> out of bounds accesses to the array in case the enum changes. Please consider 
> so.
Guard it with an assert.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112421/new/

https://reviews.llvm.org/D112421

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

[PATCH] D114583: [clang-format] Adjust braced list detection

2021-11-25 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

For your test I think its your test that is wrong, looking at the simpler 
versions (using clang-format-12)

  void foo() {
{
  { int a; }
}
  }
  
  void foo() {
{ int a; }
  }


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114583/new/

https://reviews.llvm.org/D114583

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

[PATCH] D112421: [clang][ARM] PACBTI-M frontend support

2021-11-25 Thread Victor Campos via Phabricator via cfe-commits

vhscampos added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2979
+def warn_unsupported_branch_protection_spec : Warning<
+  "unsupported branch protection specification '%0'">,  
InGroup;
+

Still need to remove extraneous whitespace



Comment at: clang/lib/CodeGen/TargetInfo.cpp:6377
+
+static const char *SignReturnAddrStr[] = {"none", "non-leaf", "all"};
+Fn->addFnAttr("sign-return-address",

I reckon selecting the string using a switch statement on BPI.SignReturnAddr is 
more type safe than doing it like this. The current selection is prone to out 
of bounds accesses to the array in case the enum changes. Please consider so.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112421/new/

https://reviews.llvm.org/D112421

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

[PATCH] D114602: [clang-tidy] Improve documentation of bugprone-unhandled-exception-at-new [NFC]

2021-11-25 Thread Balázs Kéri via Phabricator via cfe-commits

balazske created this revision.
Herald added subscribers: steakhal, martong, gamesh411, Szelethus, dkrupp, 
xazax.hun.
balazske requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D114602

Files:
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-exception-at-new.rst


Index: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-exception-at-new.rst
===
--- 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-exception-at-new.rst
+++ 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-exception-at-new.rst
@@ -5,21 +5,54 @@
 
 Finds calls to ``new`` with missing exception handler for ``std::bad_alloc``.
 
-.. code-block:: c++
-
-  int *f() noexcept {
-int *p = new int[1000];
-// ...
-return p;
-  }
-
 Calls to ``new`` can throw exceptions of type ``std::bad_alloc`` that should
 be handled by the code. Alternatively, the nonthrowing form of ``new`` can be
 used. The check verifies that the exception is handled in the function
-that calls ``new``, unless a nonthrowing version is used or the exception
-is allowed to propagate out of the function (exception handler is checked for
-types ``std::bad_alloc``, ``std::exception``, and catch-all handler).
+that calls ``new``.
+
+If a nonthrowing version is used or the exception is allowed to propagate out
+of the function no warning is generated.
+
+The exception handler is checked for types ``std::bad_alloc``,
+``std::exception``, and catch-all handler.
 The check assumes that any user-defined ``operator new`` is either
 ``noexcept`` or may throw an exception of type ``std::bad_alloc`` (or derived
 from it). Other exception types or exceptions occurring in the object's
 constructor are not taken into account.
+
+.. code-block:: c++
+
+  int *f() noexcept {
+int *p = new int[1000]; // warning: exception handler is missing
+// ...
+return p;
+  }
+
+
+
+.. code-block:: c++
+
+  int *f1() { // no 'noexcept'
+int *p = new int[1000]; // no warning: exception can be handled outside
+// of this function
+// ...
+return p;
+  }
+
+  int *f2() noexcept {
+try {
+  int *p = new int[1000]; // no warning: exception is handled
+  // ...
+  return p;
+} catch (std::bad_alloc &) {
+  // ...
+}
+// ...
+  }
+
+  int *f3() noexcept {
+int *p = new (std::nothrow) int[1000]; // no warning: "nothrow" is used
+// ...
+return p;
+  }
+


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-exception-at-new.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-exception-at-new.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-exception-at-new.rst
@@ -5,21 +5,54 @@
 
 Finds calls to ``new`` with missing exception handler for ``std::bad_alloc``.
 
-.. code-block:: c++
-
-  int *f() noexcept {
-int *p = new int[1000];
-// ...
-return p;
-  }
-
 Calls to ``new`` can throw exceptions of type ``std::bad_alloc`` that should
 be handled by the code. Alternatively, the nonthrowing form of ``new`` can be
 used. The check verifies that the exception is handled in the function
-that calls ``new``, unless a nonthrowing version is used or the exception
-is allowed to propagate out of the function (exception handler is checked for
-types ``std::bad_alloc``, ``std::exception``, and catch-all handler).
+that calls ``new``.
+
+If a nonthrowing version is used or the exception is allowed to propagate out
+of the function no warning is generated.
+
+The exception handler is checked for types ``std::bad_alloc``,
+``std::exception``, and catch-all handler.
 The check assumes that any user-defined ``operator new`` is either
 ``noexcept`` or may throw an exception of type ``std::bad_alloc`` (or derived
 from it). Other exception types or exceptions occurring in the object's
 constructor are not taken into account.
+
+.. code-block:: c++
+
+  int *f() noexcept {
+int *p = new int[1000]; // warning: exception handler is missing
+// ...
+return p;
+  }
+
+
+
+.. code-block:: c++
+
+  int *f1() { // no 'noexcept'
+int *p = new int[1000]; // no warning: exception can be handled outside
+// of this function
+// ...
+return p;
+  }
+
+  int *f2() noexcept {
+try {
+  int *p = new int[1000]; // no warning: exception is handled
+  // ...
+  return p;
+} catch (std::bad_alloc &) {
+  // ...
+}
+// ...
+  }
+
+  int *f3() noexcept {
+int *p = new (std::nothrow) int[1000]; // no warning: "nothrow" is used
+// ...
+return p;
+  }
+
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D114601: Read path to CUDA from env. variable CUDA_PATH on Windows

2021-11-25 Thread Mojca Miklavec via Phabricator via cfe-commits

mojca updated this revision to Diff 389811.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114601/new/

https://reviews.llvm.org/D114601

Files:
  clang/lib/Driver/ToolChains/Cuda.cpp


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -134,10 +134,11 @@
 Candidates.emplace_back(
 Args.getLastArgValue(clang::driver::options::OPT_cuda_path_EQ).str());
   } else if (HostTriple.isOSWindows()) {
-for (const char *Ver : Versions)
-  Candidates.emplace_back(
-  D.SysRoot + "/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v" +
-  Ver);
+if (Optional CudaPathValue =
+llvm::sys::Process::GetEnv("CUDA_PATH")) {
+  StringRef CudaPath = *CudaPathValue;
+  Candidates.emplace_back(CudaPath.str());
+}
   } else {
 if (!Args.hasArg(clang::driver::options::OPT_cuda_path_ignore_env)) {
   // Try to find ptxas binary. If the executable is located in a directory


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -134,10 +134,11 @@
 Candidates.emplace_back(
 Args.getLastArgValue(clang::driver::options::OPT_cuda_path_EQ).str());
   } else if (HostTriple.isOSWindows()) {
-for (const char *Ver : Versions)
-  Candidates.emplace_back(
-  D.SysRoot + "/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v" +
-  Ver);
+if (Optional CudaPathValue =
+llvm::sys::Process::GetEnv("CUDA_PATH")) {
+  StringRef CudaPath = *CudaPathValue;
+  Candidates.emplace_back(CudaPath.str());
+}
   } else {
 if (!Args.hasArg(clang::driver::options::OPT_cuda_path_ignore_env)) {
   // Try to find ptxas binary. If the executable is located in a directory
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D114601: Read path to CUDA from env. variable CUDA_PATH on Windows

2021-11-25 Thread Mojca Miklavec via Phabricator via cfe-commits

mojca updated this revision to Diff 389808.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114601/new/

https://reviews.llvm.org/D114601

Files:
  clang/lib/Driver/ToolChains/Cuda.cpp


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -135,10 +135,7 @@
 Candidates.emplace_back(
 Args.getLastArgValue(clang::driver::options::OPT_cuda_path_EQ).str());
   } else if (HostTriple.isOSWindows()) {
-for (const char *Ver : Versions)
-  Candidates.emplace_back(
-  D.SysRoot + "/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v" +
-  Ver);
+Candidates.emplace_back(llvm::sys::Process::GetEnv("CUDA_PATH"));
   } else {
 if (!Args.hasArg(clang::driver::options::OPT_cuda_path_ignore_env)) {
   // Try to find ptxas binary. If the executable is located in a directory


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -135,10 +135,7 @@
 Candidates.emplace_back(
 Args.getLastArgValue(clang::driver::options::OPT_cuda_path_EQ).str());
   } else if (HostTriple.isOSWindows()) {
-for (const char *Ver : Versions)
-  Candidates.emplace_back(
-  D.SysRoot + "/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v" +
-  Ver);
+Candidates.emplace_back(llvm::sys::Process::GetEnv("CUDA_PATH"));
   } else {
 if (!Args.hasArg(clang::driver::options::OPT_cuda_path_ignore_env)) {
   // Try to find ptxas binary. If the executable is located in a directory
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D114077: [clangd] Basic IncludeCleaner support for c/c++ standard library

2021-11-25 Thread Sam McCall via Phabricator via cfe-commits

sammccall added a comment.

I can't remember how we discussed this offline, but my plan was to land this 
and address the limitations as followups rather than extend the scope of this 
patch.
So I think this is ready for review, though certainly not urgent.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114077/new/

https://reviews.llvm.org/D114077

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

[PATCH] D114370: [clangd] IncludeCleaner: Attribute symbols from non self-contained headers to their parents

2021-11-25 Thread Sam McCall via Phabricator via cfe-commits

sammccall added a comment.

Thanks, this mostly LG now.
I'd consider splitting out the new infra change (IncludeStructure) from the 
feature change (include-cleaner treatment).
In case the latter causes some problems...




Comment at: clang-tools-extra/clangd/Headers.cpp:92
 InBuiltinFile = false;
+  // At the file exit time HeaderSearchInfo is valid and can be used to
+  // determine whether the file was a self-contained header or not.

nit: at the file exit time -> at file exit time



Comment at: clang-tools-extra/clangd/Headers.h:65
   SrcMgr::CharacteristicKind FileKind = SrcMgr::C_User;
+  bool SelfContained = true;
   llvm::Optional HeaderID;

Why redundantly track this on Inclusion? It's already available via 
IncludeStructure.SelfContained.contains(*HeaderID)



Comment at: clang-tools-extra/clangd/Headers.h:128
   // populates the structure.
-  std::unique_ptr collect(const SourceManager );
+  std::unique_ptr collect(const SourceManager ,
+   HeaderSearch );

Maybe it's neater just to pass the CompilerInstance& - there's no other 
practical way to use this.



Comment at: clang-tools-extra/clangd/Headers.h:158
+  // Contains HeaderIDs of all self-contained entries in the IncludeStructure.
+  llvm::DenseSet SelfContained;
+

I think i'd prefer to see this private with an `isSelfContained` accessor, 
because the representation isn't the only sensible one.

Case in point: almost all headers in practice are self-contained, so in fact 
storing the set of non-self-contained headers seems preferable.



Comment at: clang-tools-extra/clangd/SourceCode.cpp:53
 
+namespace {
+

these helpers are 1000 lines away from the only place they're used, please move 
them closer



Comment at: clang-tools-extra/clangd/SourceCode.h:330
+/// guard, does not rely on preprocessor state). This will read a portion of 
the
+/// file which might be discouraged in performance-sensitive context.
+bool isSelfContainedHeader(const FileEntry *FE, FileID ID,

This still doesn't really describe the situation:
 - if you're not getting the header from a preamble, it won't have to read 
anything as it'll be in-memory already
 - if you are, then the fact that the content may have changed is at least as 
big a problem
 - the string scanning itself is not ideal to do redundantly from a performance 
POV

I'd rather say:
"This scans source code, and should not be called when using a preamble.
Prefer to access the cache in IncludeStructure::isSelfContained if you can."


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114370/new/

https://reviews.llvm.org/D114370

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

[PATCH] D114601: Read path to CUDA from env. variable CUDA_PATH on Windows

2021-11-25 Thread Mojca Miklavec via Phabricator via cfe-commits

mojca added inline comments.



Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:138
   } else if (HostTriple.isOSWindows()) {
-for (const char *Ver : Versions)
-  Candidates.emplace_back(
-  D.SysRoot + "/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v" +
-  Ver);
+Candidates.emplace_back(llvm::sys::Process::GetEnv("CUDA_PATH"));
   } else {

Sorry, wrong patch. I'll upload it again.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114601/new/

https://reviews.llvm.org/D114601

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

[PATCH] D114326: Update the list of CUDA versions up to 11.5

2021-11-25 Thread Mojca Miklavec via Phabricator via cfe-commits

mojca added a comment.

I opened https://reviews.llvm.org/D114601. I wasn't sure if that's something 
that should have been combined with this ticket or not because it can be merged 
or rejected independently.

I also opened a ticket for Microsoft STL on 
https://github.com/microsoft/STL/issues/2359.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114326/new/

https://reviews.llvm.org/D114326

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

[PATCH] D114234: [clang][dataflow] Add base types for building dataflow analyses

2021-11-25 Thread Stanislav Gatev via Phabricator via cfe-commits

sgatev added inline comments.



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h:48
+/// Type-erased base class for dataflow analyses built on a single lattice 
type.
+class DataflowAnalysisDynamic {
+public:

xazax.hun wrote:
> Does the `Dynamic` in the suffix refer to the fact this is using type erasure 
> as opposed to templates? 
> 
> I have multiple questions at this point:
> * Why do we prefer type erasure over generic programming?
> * Do you plan to have non-dynamic counterparts?
> 
> Nit: having Dynamic both in the class name and in the method names sounds 
> overly verbose to me.
> Nit: please add a comment what dynamic refers to in the name,
Right. The "Dynamic" suffix emphasizes the type-erased nature of the class and 
its members and is used to differentiate them from their typed counterparts in 
`DataflowAnalysis`. I added this to the documentation of the type. I also split 
the typed and type-erased interfaces in separate files. Users of the framework 
shouldn't need to interact with types and functions from 
`DataflowAnalysisDynamic.h`.

The names are verbose, but should be used in relatively few internal places in 
the framework. Currently, we have one call site for each of the methods of 
`DataflowAnalysisDynamic`. Nevertheless, if you have ideas for better names I'd 
be happy to change them.

The reason we went with a type-erased layer is to avoid pulling a lot of code 
in the templates. Over time the implementation got cleaner and as I'm preparing 
these patches I see some opportunities to simplify it further. However, it's 
still non-trivial amount of code. I think we should revisit this decision at 
some point and consider having entirely template-based implementation of the 
algorithm. I personally don't see clear benefits of one approach over the other 
at this point. If you have strong preference for using templates, we can 
consider going down that route now.



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h:140
+struct DataflowAnalysisState {
+  DataflowAnalysisState(AnyLatticeElement Lattice, Environment Env)
+  : Lattice(std::move(Lattice)), Env(std::move(Env)) {}

xazax.hun wrote:
> Do we need a ctor? Or is this a workaround for aggregate initialization not 
> working well with certain library facilities?
We don't really need it at this point. Removed.



Comment at: clang/lib/Analysis/FlowSensitive/DataflowAnalysis.cpp:26
+runDataflowAnalysis(const CFG , DataflowAnalysisDynamic ,
+const Environment ) {
+  // FIXME: Implement work list-based algorithm to compute the fixed

xazax.hun wrote:
> Is there a way to query how the CFG was built? Adding an assert to see if 
> `setAlwaysAdd` was set might be useful.
Good point. I believe there isn't a way to do that currently, but this is 
something we should consider implementing. I added a FIXME.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114234/new/

https://reviews.llvm.org/D114234

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

[PATCH] D114601: Read path to CUDA from env. variable CUDA_PATH on Windows

2021-11-25 Thread Mojca Miklavec via Phabricator via cfe-commits

mojca created this revision.
mojca added reviewers: tra, carlosgalvezp, Hahnfeld.
mojca added a project: clang.
Herald added a subscriber: yaxunl.
mojca requested review of this revision.
Herald added a subscriber: cfe-commits.

This is heavily related to https://reviews.llvm.org/D114326 and uses a 
different approach for locating path to CUDA on Windows.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D114601

Files:
  clang/lib/Driver/ToolChains/Cuda.cpp


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -135,10 +135,7 @@
 Candidates.emplace_back(
 Args.getLastArgValue(clang::driver::options::OPT_cuda_path_EQ).str());
   } else if (HostTriple.isOSWindows()) {
-for (const char *Ver : Versions)
-  Candidates.emplace_back(
-  D.SysRoot + "/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v" +
-  Ver);
+Candidates.emplace_back(llvm::sys::Process::GetEnv("CUDA_PATH"));
   } else {
 if (!Args.hasArg(clang::driver::options::OPT_cuda_path_ignore_env)) {
   // Try to find ptxas binary. If the executable is located in a directory


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -135,10 +135,7 @@
 Candidates.emplace_back(
 Args.getLastArgValue(clang::driver::options::OPT_cuda_path_EQ).str());
   } else if (HostTriple.isOSWindows()) {
-for (const char *Ver : Versions)
-  Candidates.emplace_back(
-  D.SysRoot + "/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v" +
-  Ver);
+Candidates.emplace_back(llvm::sys::Process::GetEnv("CUDA_PATH"));
   } else {
 if (!Args.hasArg(clang::driver::options::OPT_cuda_path_ignore_env)) {
   // Try to find ptxas binary. If the executable is located in a directory
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D114525: [clang] Change ordering of PreableCallbacks to make sure PP can be referenced in them

2021-11-25 Thread Sam McCall via Phabricator via cfe-commits

sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Yeah this change definitely looks safe:

- we've moving it across BeginSourceFile only, which doesn't seem to do 
anything for the usual parse that we'd use when building preambles.
- BeforeExecute isn't widely used

Also it seems saner: Before/AfterExecute are now consistently nested inside 
Begin/EndSourceFile.

I don't have particular insight into the original motivation, but I guess it 
was just driven by what was needed: why go for the "more powerful" thing if we 
only needed to inspect the CompilerInstance?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114525/new/

https://reviews.llvm.org/D114525

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

[PATCH] D114583: [clang-format] Adjust braced list detection

2021-11-25 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

The other failure is

  -class C extends {} {}
  +class C extends {}
  +{}

I'm slightly struggling to work out in both cases if its the test that is wrong 
@cpplearner what do you think?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114583/new/

https://reviews.llvm.org/D114583

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

[PATCH] D114583: [clang-format] Adjust braced list detection

2021-11-25 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

FormatsBracedListsInColumnLayout is actually failing in its own test... it now 
produces

  void foo() {
{ // asdf
  { int a; }
}
{
  { int b; }
}
  }

rather than previously

  void foo() {
{// asdf
 {int a;
  }
  }
  {
{ int b; }
  }
  }


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114583/new/

https://reviews.llvm.org/D114583

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

[PATCH] D114100: [NFC][clang-tools-extra] Inclusive language: replace master with main

2021-11-25 Thread Sam McCall via Phabricator via cfe-commits

sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Sorry, LG!
(I'm not very familiar with clang-modularize, but this seems to be the only 
place the term is used)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114100/new/

https://reviews.llvm.org/D114100

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

[PATCH] D72326: [clang-format] Rebased on master: Add option to specify explicit config file

2021-11-25 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

The reason I have picked this us was because of:

https://twitter.com/bruxisma/status/1462987809879257101

This slightly annoys me because :

a) What they were talking about was in my view is disrespectful and inaccurate.
b) I thought we'd already landed this (which we had)

I went looking for this review which had previously been accepted and landed, 
but got reverted because it seemed to fail the tests

The original author and the original-original-author has both obviously moved 
on a dropped it and so it didn't get fixed.

I don't like wasting all that effort, especailly if we are going to get grief 
for it. So I rebased the review so we can land it again, (and checked both the 
unit tests and lit tests)

I hope we don't have to go around the houses on this too much.

Comment at: clang/lib/Format/Format.cpp:3274
+  llvm::SmallVector FilesToLookFor;
+  // User provided clang-format file using -style=file:/path/to/format/file
+  // Check for explicit config filename

HazardyKnusperkeks wrote:
> MyDeveloperDay wrote:
> > part of me wonders if this format should be
> > 
> > `file://` rather than `file:`
> > 
> > ```User provided clang-format file using 
> > -style=file:///path/to/format/file```
> > 
> > vs
> > 
> > ```User provided clang-format file using -style=file:/path/to/format/file```
> > 
> > This would leave the way open to other protocols http:// or https:// or 
> > anything else.
> Maybe, but I doubt we want http. And if we use `file://` a windows path 
> `D:\Path\` would not be valid, would it?
yes file://C:\Windows\Kernel32.dll is a valid file url.

but I on reflection I think `file:`  will be ok.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72326/new/

https://reviews.llvm.org/D72326

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

[PATCH] D72326: [clang-format] Rebased on master: Add option to specify explicit config file

2021-11-25 Thread Björn Schäpers via Phabricator via cfe-commits

HazardyKnusperkeks added inline comments.



Comment at: clang/lib/Format/Format.cpp:3274
+  llvm::SmallVector FilesToLookFor;
+  // User provided clang-format file using -style=file:/path/to/format/file
+  // Check for explicit config filename

MyDeveloperDay wrote:
> part of me wonders if this format should be
> 
> `file://` rather than `file:`
> 
> ```User provided clang-format file using -style=file:///path/to/format/file```
> 
> vs
> 
> ```User provided clang-format file using -style=file:/path/to/format/file```
> 
> This would leave the way open to other protocols http:// or https:// or 
> anything else.
Maybe, but I doubt we want http. And if we use `file://` a windows path 
`D:\Path\` would not be valid, would it?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72326/new/

https://reviews.llvm.org/D72326

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

[PATCH] D114533: LLVM IR should allow bitcast between address spaces with the same size.

2021-11-25 Thread Jessica Clarke via Phabricator via cfe-commits

jrtc27 added a comment.

This seems like it should not apply to non-integral address spaces?




Comment at: llvm/docs/LangRef.rst:10999
+with this instruction. Conversion of pointers to different address spaces 
+are legal, but may result in undefined behaviour where such a reinterpretation 
+of bits is not supported by the target. To convert pointers to other 

This should be illegal, not legal and undefined, you really want the IR 
verifier to be able to pick up on this at least, if not an assertion at 
creation time



Comment at: llvm/include/llvm/IR/InstrTypes.h:729
 
+  /// This method can e used to determine if a cast from SrcTy to DstTy using
+  /// Opcode op and DataLayout DL is valid or not

Typo "e"


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114533/new/

https://reviews.llvm.org/D114533

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

[PATCH] D114320: [clang-format] Extend AllowShortBlocksOnASingleLine for else blocks

2021-11-25 Thread Jesses Gott via Phabricator via cfe-commits

jessesna added a comment.

In D114320#3153795 , @MyDeveloperDay 
wrote:

> Thank you for the patch, Do you need help committing this? if so we need your 
> name and email address to do so
>
> https://llvm.org/docs/DeveloperPolicy.html#commit-messages

Thanks for the reminder. I wasn't sure about where we are in the process. I 
just did a rebase, compiled and run the tests again and it's all still fine but 
this is my first contribution and i don't think i have commit access according 
to https://www.llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access . I'd 
be glad if someone else could commit for me. What's the best method to send the 
email address?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114320/new/

https://reviews.llvm.org/D114320

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

[PATCH] D114418: [clang][ASTImporter] Update lookup table correctly at deduction guides.

2021-11-25 Thread Balázs Kéri via Phabricator via cfe-commits

balazske added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:6082-6085
+  // "from" context. Because these DeclContext values look already not stable
+  // and unimportant this change looks acceptable.
+  // For these reasons the old DeclContext must be saved to change the lookup
+  // table later.

martong wrote:
> balazske wrote:
> > martong wrote:
> > > balazske wrote:
> > > > martong wrote:
> > > > > I think this sentence does not provide any meaningful information and 
> > > > > does not increase the understand-ability. Plus the word `change` is 
> > > > > overloaded, first I though you meant the patch itself...
> > > > It is still good to have an explanation of why the DeclContext is not 
> > > > exactly preserved at import. And the DeclContext is really not 
> > > > "stable", not easily predictable from the source code.
> > > Okay, then we could write "Consequently, the DeclContext of these Decls 
> > > may change several times until the top-level import call is finished."
> > The meaning of this is still different from what my original intent was: 
> > The DeclContext in the "To" context is different from the "From", even 
> > after the top-level import call. I wanted to emphasize here that this 
> > change of DeclContext after (top-level) import has no relevance, should 
> > cause no problems.
> So, you say that is it possible that the DeclContext of the params are equal 
> in the "from" context, but after the import we may end up having different 
> DeclContexts for the imported params in the "to" context?
They can be (are in the current case) not all equal in the **From** context and 
can be different in the **To** context (related to the corresponding AST nodes 
in the **From** context). At least the code does not ensure that these will be 
the same. There was originally a FIXME at this place, I wanted to change it to 
this new comment. Because from semantic point of view it should not matter if 
the DeclContext of a template parameter is some implicit deduction guide or 
another one, probably both are correct (this is why I don't wanted to add 
assertion for exactly one case).



Comment at: clang/unittests/AST/ASTImporterTest.cpp:7348-7353
+  // Get the implicit deduction guide for (non-default) constructor of 'B'.
+  auto *FromDG1 = FirstDeclMatcher().match(
+  FromTU, functionTemplateDecl(templateParameterCountIs(3)));
+  // User defined deduction guide.
+  auto *FromDG2 = FirstDeclMatcher().match(
+  FromTU, cxxDeductionGuideDecl(unless(isImplicit(;

martong wrote:
> balazske wrote:
> > martong wrote:
> > > balazske wrote:
> > > > martong wrote:
> > > > > Could you please formulate expectations (assertions) on the 
> > > > > DeclContext's of the two template parameters? I'd expect them to be 
> > > > > different.
> > > > I left this out because the "instability" mentioned above. It is 
> > > > possible to make the assertions for this exact code. We can better say 
> > > > that it comes from a set of possible values,  these are the current 
> > > > `DeductionGuideDecl`, or another one for the same class, or the class 
> > > > itself (but I am not sure in this any more). It is possible to get 
> > > > different value for different template parameters of the same template.
> > > So, we could have 
> > > ```
> > > ASSERT_NE(cast(FromDG1->getTemplateParameters()->getParam(0)->getDeclContext()),
> > >  
> > > cast(FromDG1->getTemplateParameters()->getParam(1)->getDeclContext()));
> > > ASSERT_NE(cast(FromDG1->getTemplateParameters()->getParam(0)->getDeclContext()),
> > >  
> > > cast(FromDG1->getTemplateParameters()->getParam(2)->getDeclContext()));
> > > ASSERT_EQ(cast(FromDG1->getTemplateParameters()->getParam(1)->getDeclContext()),
> > >  
> > > cast(FromDG1->getTemplateParameters()->getParam(2)->getDeclContext()))
> > > ```
> > > 
> > > And then after the `Import` calls we could have the same expectations on 
> > > `ToDG1->getParam(0)` and the rest. Couldn't we?
> > Probably at the "explicit" template parameters (the ones not coming from 
> > the class template) the DeclContext is always the deduction guide, so an 
> > `ASSERT_EQ(FromDG1->getTemplateParameters()->getParam(1)->getDeclContext(), 
> > FromDG1->getTemplatedDecl())` do work (for param 2 similar). I would not 
> > say that param 0 has always necessary a different DeclContext than the 
> > others, in this one case yes but not generally. This is why I do not like 
> > an assert for that. (Such an assert would not point out an invariant that 
> > is true always in the AST: An "unrelated" change in the source, for example 
> > different order of declarations, change in template-template parameters, 
> > may result in change of the DeclContext.)
> > An "unrelated" change in the source, for example different order of 
> > declarations, change in template-template parameters, may result in change 
> > of the DeclContext.)
> 
> I think having a

[PATCH] D40319: [libcxx] Support getentropy as a source of randomness for std::random_device

2021-11-25 Thread Jonathan Wakely via Phabricator via cfe-commits

jwakely added inline comments.



Comment at: libcxx/trunk/src/random.cpp:29
+#if defined(_LIBCPP_USING_GETENTROPY)
+#include 
+#elif defined(_LIBCPP_USING_DEV_RANDOM)

jwakely wrote:
> musl only declares `getentropy` in `` not ``. Glibc 
> declares it in both. Should `` also be included when 
> `_LIBCPP_USING_GETENTROPY` is defined, so it can work more portably?
I suppose it doesn't really matter, since `_LIBCPP_USING_GETENTROPY` is 
currently only defined for fuchsia and wasi, which both declare `getentropy` in 
``.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D40319/new/

https://reviews.llvm.org/D40319

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

[PATCH] D114540: Big-endian version of vpermxor

2021-11-25 Thread Tarique Islam via Phabricator via cfe-commits

tislam updated this revision to Diff 389775.
tislam edited the summary of this revision.
tislam added a comment.

- Added test for `vpermxor_be` in `clang/test/CodeGen/builtins-ppc-crypto.c`.
- Placed `vpermxor_be` under `[HasVSX, HasP8Altivec]` in 
`llvm/lib/Target/PowerPC/PPCInstrVSX.td`.
- Updated test `llvm/test/CodeGen/PowerPC/crypto_bifs_be.ll`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114540/new/

https://reviews.llvm.org/D114540

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/test/CodeGen/builtins-ppc-crypto.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrVSX.td
  llvm/test/CodeGen/PowerPC/crypto_bifs_be.ll

Index: llvm/test/CodeGen/PowerPC/crypto_bifs_be.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/crypto_bifs_be.ll
@@ -0,0 +1,167 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr8 < %s | FileCheck %s --check-prefixes=CHECK-LE-P8
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefixes=CHECK-P9
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr8 < %s | FileCheck %s --check-prefixes=CHECK-BE-P8
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefixes=CHECK-P9
+
+define <16 x i8> @test_vpermxorb() local_unnamed_addr {
+; CHECK-LE-P8-LABEL: test_vpermxorb:
+; CHECK-LE-P8:   # %bb.0: # %entry
+; CHECK-LE-P8-NEXT:addis 3, 2, .LCPI0_0@toc@ha
+; CHECK-LE-P8-NEXT:addis 4, 2, .LCPI0_1@toc@ha
+; CHECK-LE-P8-NEXT:addi 3, 3, .LCPI0_0@toc@l
+; CHECK-LE-P8-NEXT:lvx 2, 0, 3
+; CHECK-LE-P8-NEXT:addi 3, 4, .LCPI0_1@toc@l
+; CHECK-LE-P8-NEXT:lvx 3, 0, 3
+; CHECK-LE-P8-NEXT:vpermxor 2, 3, 2, 2
+; CHECK-LE-P8-NEXT:blr
+;
+; CHECK-P9-LABEL: test_vpermxorb:
+; CHECK-P9:   # %bb.0: # %entry
+; CHECK-P9-NEXT:addis 3, 2, .LCPI0_0@toc@ha
+; CHECK-P9-NEXT:addi 3, 3, .LCPI0_0@toc@l
+; CHECK-P9-NEXT:lxv 34, 0(3)
+; CHECK-P9-NEXT:addis 3, 2, .LCPI0_1@toc@ha
+; CHECK-P9-NEXT:addi 3, 3, .LCPI0_1@toc@l
+; CHECK-P9-NEXT:lxv 35, 0(3)
+; CHECK-P9-NEXT:vpermxor 2, 3, 2, 2
+; CHECK-P9-NEXT:blr
+;
+; CHECK-BE-P8-LABEL: test_vpermxorb:
+; CHECK-BE-P8:   # %bb.0: # %entry
+; CHECK-BE-P8-NEXT:addis 3, 2, .LCPI0_0@toc@ha
+; CHECK-BE-P8-NEXT:addis 4, 2, .LCPI0_1@toc@ha
+; CHECK-BE-P8-NEXT:addi 3, 3, .LCPI0_0@toc@l
+; CHECK-BE-P8-NEXT:addi 4, 4, .LCPI0_1@toc@l
+; CHECK-BE-P8-NEXT:lxvw4x 34, 0, 3
+; CHECK-BE-P8-NEXT:lxvw4x 35, 0, 4
+; CHECK-BE-P8-NEXT:vpermxor 2, 3, 2, 2
+; CHECK-BE-P8-NEXT:blr
+entry:
+  %0 = tail call <16 x i8> @llvm.ppc.altivec.crypto.vpermxor.be(<16 x i8> , <16 x i8> , <16 x i8> )
+  ret <16 x i8> %0
+}
+
+declare <16 x i8> @llvm.ppc.altivec.crypto.vpermxor.be(<16 x i8>, <16 x i8>, <16 x i8>)
+
+define <8 x i16> @test_vpermxorh() local_unnamed_addr {
+; CHECK-LE-P8-LABEL: test_vpermxorh:
+; CHECK-LE-P8:   # %bb.0: # %entry
+; CHECK-LE-P8-NEXT:addis 3, 2, .LCPI1_0@toc@ha
+; CHECK-LE-P8-NEXT:addis 4, 2, .LCPI1_1@toc@ha
+; CHECK-LE-P8-NEXT:addi 3, 3, .LCPI1_0@toc@l
+; CHECK-LE-P8-NEXT:lvx 2, 0, 3
+; CHECK-LE-P8-NEXT:addi 3, 4, .LCPI1_1@toc@l
+; CHECK-LE-P8-NEXT:lvx 3, 0, 3
+; CHECK-LE-P8-NEXT:vpermxor 2, 3, 2, 2
+; CHECK-LE-P8-NEXT:blr
+;
+; CHECK-P9-LABEL: test_vpermxorh:
+; CHECK-P9:   # %bb.0: # %entry
+; CHECK-P9-NEXT:addis 3, 2, .LCPI1_0@toc@ha
+; CHECK-P9-NEXT:addi 3, 3, .LCPI1_0@toc@l
+; CHECK-P9-NEXT:lxv 34, 0(3)
+; CHECK-P9-NEXT:addis 3, 2, .LCPI1_1@toc@ha
+; CHECK-P9-NEXT:addi 3, 3, .LCPI1_1@toc@l
+; CHECK-P9-NEXT:lxv 35, 0(3)
+; CHECK-P9-NEXT:vpermxor 2, 3, 2, 2
+; CHECK-P9-NEXT:blr
+;
+; CHECK-BE-P8-LABEL: test_vpermxorh:
+; CHECK-BE-P8:   # %bb.0: # %entry
+; CHECK-BE-P8-NEXT:addis 3, 2, .LCPI1_0@toc@ha
+; CHECK-BE-P8-NEXT:addis 4, 2, .LCPI1_1@toc@ha
+; CHECK-BE-P8-NEXT:addi 3, 3, .LCPI1_0@toc@l
+; CHECK-BE-P8-NEXT:addi 4, 4, .LCPI1_1@toc@l
+; CHECK-BE-P8-NEXT:lxvw4x 34, 0, 3
+; CHECK-BE-P8-NEXT:lxvw4x 35, 0, 4
+; CHECK-BE-P8-NEXT:vpermxor 2, 3, 2, 2
+; CHECK-BE-P8-NEXT:blr
+entry:
+  %0 = tail call <16 x i8> @llvm.ppc.altivec.crypto.vpermxor.be(<16 x i8> , <16 x i8> , <16 x i8> )
+  %1 = bitcast <16 x i8> %0 to <8 x i16>
+  ret <8 x i16> %1
+}
+
+define <4 x i32> @test_vpermxorw() local_unnamed_addr {
+; CHECK-LE-P8-LABEL: test_vpermxorw:
+; CHECK-LE-P8:   # %bb.0: # %entry
+; CHECK-LE-P8-NEXT:addis 3, 2, .LCPI2_0@toc@ha
+; CHECK-LE-P8-NEXT:addis 4, 2, .LCPI2_1@toc@ha
+; CHECK-LE-P8-NEXT:addi 3, 3, .LCPI2_0@toc@l
+; CHECK-LE-P8-NEXT:lvx 2, 0, 3
+; CHECK-LE-P8-NEXT:addi 3, 4, .LCPI2_1@toc@l
+; CHECK-LE-P8-NEXT:lvx 3, 0, 3
+;

[PATCH] D40319: [libcxx] Support getentropy as a source of randomness for std::random_device

2021-11-25 Thread Jonathan Wakely via Phabricator via cfe-commits

jwakely added inline comments.
Herald added a subscriber: abrachet.



Comment at: libcxx/trunk/src/random.cpp:29
+#if defined(_LIBCPP_USING_GETENTROPY)
+#include 
+#elif defined(_LIBCPP_USING_DEV_RANDOM)

musl only declares `getentropy` in `` not ``. Glibc 
declares it in both. Should `` also be included when 
`_LIBCPP_USING_GETENTROPY` is defined, so it can work more portably?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D40319/new/

https://reviews.llvm.org/D40319

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

[PATCH] D114234: [clang][dataflow] Add base types for building dataflow analyses

2021-11-25 Thread Stanislav Gatev via Phabricator via cfe-commits

sgatev updated this revision to Diff 389774.
sgatev added a comment.

Rename Environment.h to DataflowEnvironment.h.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114234/new/

https://reviews.llvm.org/D114234

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisDynamic.h
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  clang/include/clang/Analysis/FlowSensitive/DataflowLattice.h
  clang/lib/Analysis/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/DataflowAnalysisDynamic.cpp

Index: clang/lib/Analysis/FlowSensitive/DataflowAnalysisDynamic.cpp
===
--- /dev/null
+++ clang/lib/Analysis/FlowSensitive/DataflowAnalysisDynamic.cpp
@@ -0,0 +1,34 @@
+//===- DataflowAnalysisDynamic.cpp ===//
+//
+// 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
+//
+//===--===//
+//
+//  This file defines type-erased base types and functions for building dataflow
+//  analyses that run over Control-Flow Graphs (CFGs).
+//
+//===--===//
+
+#include 
+
+#include "clang/Analysis/CFG.h"
+#include "clang/Analysis/FlowSensitive/DataflowAnalysisDynamic.h"
+#include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
+#include "llvm/ADT/Optional.h"
+
+using namespace clang;
+using namespace dataflow;
+
+std::vector>
+runDataflowAnalysisDynamic(const CFG , DataflowAnalysisDynamic ,
+   const Environment ) {
+  // FIXME: Consider enforcing that `Cfg` meets the requirements that
+  // are specified in the header. This could be done by remembering
+  // what options were used to build `Cfg` and asserting on them here.
+
+  // FIXME: Implement work list-based algorithm to compute the fixed
+  // point of `Analysis::transform` for every basic block in `Cfg`.
+  return {};
+}
Index: clang/lib/Analysis/FlowSensitive/CMakeLists.txt
===
--- /dev/null
+++ clang/lib/Analysis/FlowSensitive/CMakeLists.txt
@@ -0,0 +1,7 @@
+add_clang_library(clangAnalysisFlowSensitive
+  DataflowAnalysisDynamic.cpp
+
+  LINK_LIBS
+  clangAnalysis
+  clangAST
+  )
Index: clang/lib/Analysis/CMakeLists.txt
===
--- clang/lib/Analysis/CMakeLists.txt
+++ clang/lib/Analysis/CMakeLists.txt
@@ -44,3 +44,4 @@
   )
 
 add_subdirectory(plugins)
+add_subdirectory(FlowSensitive)
Index: clang/include/clang/Analysis/FlowSensitive/DataflowLattice.h
===
--- /dev/null
+++ clang/include/clang/Analysis/FlowSensitive/DataflowLattice.h
@@ -0,0 +1,29 @@
+//===- DataflowLattice.h *- C++ -*-===//
+//
+// 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
+//
+//===--===//
+//
+//  This file defines base types for building lattices to be used in dataflow
+//  analyses that run over Control-Flow Graphs (CFGs).
+//
+//===--===//
+
+#ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_DATAFLOWLATTICE_H
+#define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_DATAFLOWLATTICE_H
+
+namespace clang {
+namespace dataflow {
+
+/// Effect indicating whether a lattice join operation resulted in a new value.
+enum class LatticeJoinEffect {
+  Unchanged,
+  Changed,
+};
+
+} // namespace dataflow
+} // namespace clang
+
+#endif // LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_DATAFLOWLATTICE_H
Index: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
===
--- /dev/null
+++ clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -0,0 +1,27 @@
+//===-- DataflowEnvironment.h ---*- C++ -*-===//
+//
+// 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
+//
+//===--===//
+//
+//  This file defines an Environment class that is used by dataflow analyses
+//  that run over Control-Flow Graphs (CFGs) to keep track of the state of the
+//  program at given program points.
+//

[PATCH] D114234: [clang][dataflow] Add base types for building dataflow analyses

2021-11-25 Thread Stanislav Gatev via Phabricator via cfe-commits

sgatev updated this revision to Diff 389773.
sgatev added a comment.

Put typed and type-erased interfaces in separate files.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114234/new/

https://reviews.llvm.org/D114234

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisDynamic.h
  clang/include/clang/Analysis/FlowSensitive/DataflowLattice.h
  clang/include/clang/Analysis/FlowSensitive/Environment.h
  clang/lib/Analysis/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/DataflowAnalysisDynamic.cpp

Index: clang/lib/Analysis/FlowSensitive/DataflowAnalysisDynamic.cpp
===
--- /dev/null
+++ clang/lib/Analysis/FlowSensitive/DataflowAnalysisDynamic.cpp
@@ -0,0 +1,34 @@
+//===- DataflowAnalysisDynamic.cpp ===//
+//
+// 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
+//
+//===--===//
+//
+//  This file defines type-erased base types and functions for building dataflow
+//  analyses that run over Control-Flow Graphs (CFGs).
+//
+//===--===//
+
+#include 
+
+#include "clang/Analysis/CFG.h"
+#include "clang/Analysis/FlowSensitive/DataflowAnalysisDynamic.h"
+#include "clang/Analysis/FlowSensitive/Environment.h"
+#include "llvm/ADT/Optional.h"
+
+using namespace clang;
+using namespace dataflow;
+
+std::vector>
+runDataflowAnalysisDynamic(const CFG , DataflowAnalysisDynamic ,
+   const Environment ) {
+  // FIXME: Consider enforcing that `Cfg` meets the requirements that
+  // are specified in the header. This could be done by remembering
+  // what options were used to build `Cfg` and asserting on them here.
+
+  // FIXME: Implement work list-based algorithm to compute the fixed
+  // point of `Analysis::transform` for every basic block in `Cfg`.
+  return {};
+}
Index: clang/lib/Analysis/FlowSensitive/CMakeLists.txt
===
--- /dev/null
+++ clang/lib/Analysis/FlowSensitive/CMakeLists.txt
@@ -0,0 +1,7 @@
+add_clang_library(clangAnalysisFlowSensitive
+  DataflowAnalysisDynamic.cpp
+
+  LINK_LIBS
+  clangAnalysis
+  clangAST
+  )
Index: clang/lib/Analysis/CMakeLists.txt
===
--- clang/lib/Analysis/CMakeLists.txt
+++ clang/lib/Analysis/CMakeLists.txt
@@ -44,3 +44,4 @@
   )
 
 add_subdirectory(plugins)
+add_subdirectory(FlowSensitive)
Index: clang/include/clang/Analysis/FlowSensitive/Environment.h
===
--- /dev/null
+++ clang/include/clang/Analysis/FlowSensitive/Environment.h
@@ -0,0 +1,27 @@
+//===-- Environment.h ---*- C++ -*-===//
+//
+// 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
+//
+//===--===//
+//
+//  This file defines an Environment class that is used by dataflow analyses
+//  that run over Control-Flow Graphs (CFGs) to keep track of the state of the
+//  program at given program points.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_ENVIRONMENT_H
+#define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_ENVIRONMENT_H
+
+namespace clang {
+namespace dataflow {
+
+/// Holds the state of the program (store and heap) at a given program point.
+class Environment {};
+
+} // namespace dataflow
+} // namespace clang
+
+#endif // LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_ENVIRONMENT_H
Index: clang/include/clang/Analysis/FlowSensitive/DataflowLattice.h
===
--- /dev/null
+++ clang/include/clang/Analysis/FlowSensitive/DataflowLattice.h
@@ -0,0 +1,29 @@
+//===- DataflowLattice.h *- C++ -*-===//
+//
+// 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
+//
+//===--===//
+//
+//  This file defines base types for building lattices to be used in dataflow
+//  analyses that run over Control-Flow Graphs (CFGs).
+//
+//===--===//
+
+#ifndef

[PATCH] D114522: [clangd] Add canonical type to hover

2021-11-25 Thread Sam McCall via Phabricator via cfe-commits

sammccall added a comment.

I agree we often show the wrong amount of sugar, and with the thrust of this 
patch.

Some pareto-improments are possible with a single type, but we can't solve this 
problem satisfactorily:

- the right amount of sugar can vary for the same code pattern 
(`vector::iterator` vs `cast_retty::ret_type`)
- it can depend on what the reader's context is, which we can't know

However I think desugaring all the way to the canonical type, and showing it 
whenever the strings are not exactly equal, are too blunt as policies.
A similar situation in clang is deciding when to print "aka" in a diagnostic, 
and what the AKA type should be. The code controlling that is in `Desugar()` in 
`clang/lib/AST/ASTDiagnostic.cpp`. It's handled pretty carefully, and in a 
place that's likely to be well-maintained.
(It's also wrapped in functions that process a whole diagnostic to take into 
account multiple types that appear, which we can ignore).

I'd suggest we expose that function from ASTDiagnostic.h and use it for this 
purpose.




Comment at: clang-tools-extra/clangd/Hover.cpp:691
   } else {
 HI.Definition = printType(QT, PP);
 

This seems like a pretty important case to handle.
A wrinkle is that this gets treated as C++ code (e.g. client-side syntax 
highlighted).

So we might need something like

```
int64_t
// aka
long long
```

or
```
int64_t
// aka: long long
```



Comment at: clang-tools-extra/clangd/Hover.cpp:1076
+if (CanonicalReturnType && CanonicalReturnType != ReturnType)
+  ReturnTypeStr += llvm::formatv(" (aka '{0}')", *CanonicalReturnType);
+Output.addParagraph().appendText("→ ").appendCode(ReturnTypeStr);

I'm not sure that quoting the aka type when we don't quote the original is 
appropriate



Comment at: clang-tools-extra/clangd/Hover.cpp:1129
+  CalleeArgInfo->CanonicalType != CalleeArgInfo->Type)
+ConvertedTypeStr +=
+llvm::formatv(" aka '{0}'", *CalleeArgInfo->CanonicalType);

I think printing two types here is too disruptive to the reading flow, this is 
a parenthetical already



Comment at: clang-tools-extra/clangd/Hover.h:35
+/// CanonicalType
+llvm::Optional CanonicalType;
 /// None for unnamed parameters.

instead of these ad-hoc pairs, I'd suggest introducing a common struct like:

```
Optional Type;

struct PrintedType {
  std::string Type;
  Optional AKA;
};
```

that way producing function like printType and formatting functions that 
produce "foo (aka bar)" can more simply be shared between instances of this 
pattern


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114522/new/

https://reviews.llvm.org/D114522

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

[PATCH] D114320: [clang-format] Extend AllowShortBlocksOnASingleLine for else blocks

2021-11-25 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

Thank you for the patch, Do you need help committing this? if so we need your 
name and email address to do so

https://llvm.org/docs/DeveloperPolicy.html#commit-messages


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114320/new/

https://reviews.llvm.org/D114320

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

[PATCH] D114418: [clang][ASTImporter] Update lookup table correctly at deduction guides.

2021-11-25 Thread Gabor Marton via Phabricator via cfe-commits

martong added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:6082-6085
+  // "from" context. Because these DeclContext values look already not stable
+  // and unimportant this change looks acceptable.
+  // For these reasons the old DeclContext must be saved to change the lookup
+  // table later.

balazske wrote:
> martong wrote:
> > balazske wrote:
> > > martong wrote:
> > > > I think this sentence does not provide any meaningful information and 
> > > > does not increase the understand-ability. Plus the word `change` is 
> > > > overloaded, first I though you meant the patch itself...
> > > It is still good to have an explanation of why the DeclContext is not 
> > > exactly preserved at import. And the DeclContext is really not "stable", 
> > > not easily predictable from the source code.
> > Okay, then we could write "Consequently, the DeclContext of these Decls may 
> > change several times until the top-level import call is finished."
> The meaning of this is still different from what my original intent was: The 
> DeclContext in the "To" context is different from the "From", even after the 
> top-level import call. I wanted to emphasize here that this change of 
> DeclContext after (top-level) import has no relevance, should cause no 
> problems.
So, you say that is it possible that the DeclContext of the params are equal in 
the "from" context, but after the import we may end up having different 
DeclContexts for the imported params in the "to" context?



Comment at: clang/unittests/AST/ASTImporterTest.cpp:7348-7353
+  // Get the implicit deduction guide for (non-default) constructor of 'B'.
+  auto *FromDG1 = FirstDeclMatcher().match(
+  FromTU, functionTemplateDecl(templateParameterCountIs(3)));
+  // User defined deduction guide.
+  auto *FromDG2 = FirstDeclMatcher().match(
+  FromTU, cxxDeductionGuideDecl(unless(isImplicit(;

balazske wrote:
> martong wrote:
> > balazske wrote:
> > > martong wrote:
> > > > Could you please formulate expectations (assertions) on the 
> > > > DeclContext's of the two template parameters? I'd expect them to be 
> > > > different.
> > > I left this out because the "instability" mentioned above. It is possible 
> > > to make the assertions for this exact code. We can better say that it 
> > > comes from a set of possible values,  these are the current 
> > > `DeductionGuideDecl`, or another one for the same class, or the class 
> > > itself (but I am not sure in this any more). It is possible to get 
> > > different value for different template parameters of the same template.
> > So, we could have 
> > ```
> > ASSERT_NE(cast(FromDG1->getTemplateParameters()->getParam(0)->getDeclContext()),
> >  
> > cast(FromDG1->getTemplateParameters()->getParam(1)->getDeclContext()));
> > ASSERT_NE(cast(FromDG1->getTemplateParameters()->getParam(0)->getDeclContext()),
> >  
> > cast(FromDG1->getTemplateParameters()->getParam(2)->getDeclContext()));
> > ASSERT_EQ(cast(FromDG1->getTemplateParameters()->getParam(1)->getDeclContext()),
> >  
> > cast(FromDG1->getTemplateParameters()->getParam(2)->getDeclContext()))
> > ```
> > 
> > And then after the `Import` calls we could have the same expectations on 
> > `ToDG1->getParam(0)` and the rest. Couldn't we?
> Probably at the "explicit" template parameters (the ones not coming from the 
> class template) the DeclContext is always the deduction guide, so an 
> `ASSERT_EQ(FromDG1->getTemplateParameters()->getParam(1)->getDeclContext(), 
> FromDG1->getTemplatedDecl())` do work (for param 2 similar). I would not say 
> that param 0 has always necessary a different DeclContext than the others, in 
> this one case yes but not generally. This is why I do not like an assert for 
> that. (Such an assert would not point out an invariant that is true always in 
> the AST: An "unrelated" change in the source, for example different order of 
> declarations, change in template-template parameters, may result in change of 
> the DeclContext.)
> An "unrelated" change in the source, for example different order of 
> declarations, change in template-template parameters, may result in change of 
> the DeclContext.)

I think having a different order of the declarations would be a different test 
case since the source code in the raw string literal would change.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114418/new/

https://reviews.llvm.org/D114418

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

[PATCH] D114504: [clang][DebugInfo] Debug support for private variables inside an OpenMP task construct

2021-11-25 Thread Alok Kumar Sharma via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG36cb7477d1d4: [clang][OpenMP][DebugInfo] Debug support for 
private variables inside an OpenMP… (authored by alok).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114504/new/

https://reviews.llvm.org/D114504

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/debug_private.c


Index: clang/test/OpenMP/debug_private.c
===
--- /dev/null
+++ clang/test/OpenMP/debug_private.c
@@ -0,0 +1,45 @@
+// This testcase checks emission of debug info for variables inside
+// private/firstprivate/lastprivate.
+
+// REQUIRES: x86_64-linux
+
+// RUN: %clang_cc1 -debug-info-kind=constructor -x c -verify -triple 
x86_64-pc-linux-gnu -fopenmp -emit-llvm %s -o - | FileCheck %s
+// expected-no-diagnostics
+
+// CHECK: define internal i32 @.omp_task_entry.
+
+// CHECK:  call void @llvm.dbg.declare(metadata i32** %.priv.ptr.addr.i, 
metadata [[PRIV1:![0-9]+]], metadata !DIExpression(DW_OP_deref))
+// CHECK:  call void @llvm.dbg.declare(metadata i32** %.priv.ptr.addr1.i, 
metadata [[PRIV2:![0-9]+]], metadata !DIExpression(DW_OP_deref))
+// CHECK:  call void @llvm.dbg.declare(metadata i32** %.firstpriv.ptr.addr.i, 
metadata [[FPRIV:![0-9]+]], metadata !DIExpression(DW_OP_deref))
+
+// CHECK: [[PRIV1]] = !DILocalVariable(name: "priv1"
+// CHECK: [[PRIV2]] = !DILocalVariable(name: "priv2"
+// CHECK: [[FPRIV]] = !DILocalVariable(name: "fpriv"
+
+extern int printf(const char *, ...);
+
+int foo(int n) {
+  int res, priv1, priv2, fpriv;
+  fpriv = n + 4;
+
+  if (n < 2)
+return n;
+  else {
+#pragma omp task shared(res) private(priv1, priv2) firstprivate(fpriv)
+{
+  priv1 = n;
+  priv2 = n + 2;
+  printf("Task n=%d,priv1=%d,priv2=%d,fpriv=%d\n", n, priv1, priv2, fpriv);
+
+  res = priv1 + priv2 + fpriv + foo(n - 1);
+}
+#pragma omp taskwait
+return res;
+  }
+}
+
+int main() {
+  int n = 10;
+  printf("foo(%d) = %d\n", n, foo(n));
+  return 0;
+}
Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -4510,6 +4510,9 @@
 Address Replacement(CGF.Builder.CreateLoad(Pair.second),
 CGF.getContext().getDeclAlign(Pair.first));
 Scope.addPrivate(Pair.first, [Replacement]() { return Replacement; });
+if (auto *DI = CGF.getDebugInfo())
+  DI->EmitDeclareOfAutoVariable(Pair.first, Pair.second.getPointer(),
+CGF.Builder, /*UsePointerValue*/ true);
   }
   // Adjust mapping for internal locals by mapping actual memory instead of
   // a pointer to this memory.


Index: clang/test/OpenMP/debug_private.c
===
--- /dev/null
+++ clang/test/OpenMP/debug_private.c
@@ -0,0 +1,45 @@
+// This testcase checks emission of debug info for variables inside
+// private/firstprivate/lastprivate.
+
+// REQUIRES: x86_64-linux
+
+// RUN: %clang_cc1 -debug-info-kind=constructor -x c -verify -triple x86_64-pc-linux-gnu -fopenmp -emit-llvm %s -o - | FileCheck %s
+// expected-no-diagnostics
+
+// CHECK: define internal i32 @.omp_task_entry.
+
+// CHECK:  call void @llvm.dbg.declare(metadata i32** %.priv.ptr.addr.i, metadata [[PRIV1:![0-9]+]], metadata !DIExpression(DW_OP_deref))
+// CHECK:  call void @llvm.dbg.declare(metadata i32** %.priv.ptr.addr1.i, metadata [[PRIV2:![0-9]+]], metadata !DIExpression(DW_OP_deref))
+// CHECK:  call void @llvm.dbg.declare(metadata i32** %.firstpriv.ptr.addr.i, metadata [[FPRIV:![0-9]+]], metadata !DIExpression(DW_OP_deref))
+
+// CHECK: [[PRIV1]] = !DILocalVariable(name: "priv1"
+// CHECK: [[PRIV2]] = !DILocalVariable(name: "priv2"
+// CHECK: [[FPRIV]] = !DILocalVariable(name: "fpriv"
+
+extern int printf(const char *, ...);
+
+int foo(int n) {
+  int res, priv1, priv2, fpriv;
+  fpriv = n + 4;
+
+  if (n < 2)
+return n;
+  else {
+#pragma omp task shared(res) private(priv1, priv2) firstprivate(fpriv)
+{
+  priv1 = n;
+  priv2 = n + 2;
+  printf("Task n=%d,priv1=%d,priv2=%d,fpriv=%d\n", n, priv1, priv2, fpriv);
+
+  res = priv1 + priv2 + fpriv + foo(n - 1);
+}
+#pragma omp taskwait
+return res;
+  }
+}
+
+int main() {
+  int n = 10;
+  printf("foo(%d) = %d\n", n, foo(n));
+  return 0;
+}
Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -4510,6 +4510,9 @@
 Address Replacement(CGF.Builder.CreateLoad(Pair.second),
 CGF.getContext().getDeclAlign(Pair.first));
 Scope.addPrivate(Pair.first, [Replacement]() { return

[clang] 36cb747 - [clang][OpenMP][DebugInfo] Debug support for private variables inside an OpenMP task construct

2021-11-25 Thread Alok Kumar Sharma via cfe-commits


Author: Alok Kumar Sharma
Date: 2021-11-25T19:55:22+05:30
New Revision: 36cb7477d1d43de1d97a4c2b4ba0eb5ae29cbafd

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

LOG: [clang][OpenMP][DebugInfo] Debug support for private variables inside an 
OpenMP task construct

Currently variables appearing inside private/firstprivate/lastprivate
clause of openmp task construct are not visible inside lldb debugger.
This is because compiler does not generate debug info for it.

Please consider the testcase debug_private.c attached with patch.

```
   28   #pragma omp task shared(res) private(priv1, priv2) firstprivate(fpriv)
   29   {
   30 priv1 = n;
   31 priv2 = n + 2;
   32 printf("Task 
n=%d,priv1=%d,priv2=%d,fpriv=%d\n",n,priv1,priv2,fpriv);
   33
-> 34 res = priv1 + priv2 + fpriv + foo(n - 1);
   35   }
   36   #pragma omp taskwait
   37   return res;
(lldb) p priv1
error: :1:1: use of undeclared identifier 'priv1'
priv1
^
(lldb) p priv2
error: :1:1: use of undeclared identifier 'priv2'
priv2
^
(lldb) p fpriv
error: :1:1: use of undeclared identifier 'fpriv'
fpriv
^
```

After the current patch, lldb is able to show the variables

```
(lldb) p priv1
(int) $0 = 10
(lldb) p priv2
(int) $1 = 12
(lldb) p fpriv
(int) $2 = 14
```

Reviewed By: djtodoro

Differential Revision: https://reviews.llvm.org/D114504

Added: 
clang/test/OpenMP/debug_private.c

Modified: 
clang/lib/CodeGen/CGStmtOpenMP.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index 4f14459e4d285..f6853a22cd361 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -4510,6 +4510,9 @@ void CodeGenFunction::EmitOMPTaskBasedDirective(
 Address Replacement(CGF.Builder.CreateLoad(Pair.second),
 CGF.getContext().getDeclAlign(Pair.first));
 Scope.addPrivate(Pair.first, [Replacement]() { return Replacement; });
+if (auto *DI = CGF.getDebugInfo())
+  DI->EmitDeclareOfAutoVariable(Pair.first, Pair.second.getPointer(),
+CGF.Builder, /*UsePointerValue*/ true);
   }
   // Adjust mapping for internal locals by mapping actual memory instead of
   // a pointer to this memory.

diff  --git a/clang/test/OpenMP/debug_private.c 
b/clang/test/OpenMP/debug_private.c
new file mode 100644
index 0..a68e1d1be7526
--- /dev/null
+++ b/clang/test/OpenMP/debug_private.c
@@ -0,0 +1,45 @@
+// This testcase checks emission of debug info for variables inside
+// private/firstprivate/lastprivate.
+
+// REQUIRES: x86_64-linux
+
+// RUN: %clang_cc1 -debug-info-kind=constructor -x c -verify -triple 
x86_64-pc-linux-gnu -fopenmp -emit-llvm %s -o - | FileCheck %s
+// expected-no-diagnostics
+
+// CHECK: define internal i32 @.omp_task_entry.
+
+// CHECK:  call void @llvm.dbg.declare(metadata i32** %.priv.ptr.addr.i, 
metadata [[PRIV1:![0-9]+]], metadata !DIExpression(DW_OP_deref))
+// CHECK:  call void @llvm.dbg.declare(metadata i32** %.priv.ptr.addr1.i, 
metadata [[PRIV2:![0-9]+]], metadata !DIExpression(DW_OP_deref))
+// CHECK:  call void @llvm.dbg.declare(metadata i32** %.firstpriv.ptr.addr.i, 
metadata [[FPRIV:![0-9]+]], metadata !DIExpression(DW_OP_deref))
+
+// CHECK: [[PRIV1]] = !DILocalVariable(name: "priv1"
+// CHECK: [[PRIV2]] = !DILocalVariable(name: "priv2"
+// CHECK: [[FPRIV]] = !DILocalVariable(name: "fpriv"
+
+extern int printf(const char *, ...);
+
+int foo(int n) {
+  int res, priv1, priv2, fpriv;
+  fpriv = n + 4;
+
+  if (n < 2)
+return n;
+  else {
+#pragma omp task shared(res) private(priv1, priv2) firstprivate(fpriv)
+{
+  priv1 = n;
+  priv2 = n + 2;
+  printf("Task n=%d,priv1=%d,priv2=%d,fpriv=%d\n", n, priv1, priv2, fpriv);
+
+  res = priv1 + priv2 + fpriv + foo(n - 1);
+}
+#pragma omp taskwait
+return res;
+  }
+}
+
+int main() {
+  int n = 10;
+  printf("foo(%d) = %d\n", n, foo(n));
+  return 0;
+}



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

[PATCH] D114418: [clang][ASTImporter] Update lookup table correctly at deduction guides.

2021-11-25 Thread Balázs Kéri via Phabricator via cfe-commits

balazske added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:6082-6085
+  // "from" context. Because these DeclContext values look already not stable
+  // and unimportant this change looks acceptable.
+  // For these reasons the old DeclContext must be saved to change the lookup
+  // table later.

martong wrote:
> balazske wrote:
> > martong wrote:
> > > I think this sentence does not provide any meaningful information and 
> > > does not increase the understand-ability. Plus the word `change` is 
> > > overloaded, first I though you meant the patch itself...
> > It is still good to have an explanation of why the DeclContext is not 
> > exactly preserved at import. And the DeclContext is really not "stable", 
> > not easily predictable from the source code.
> Okay, then we could write "Consequently, the DeclContext of these Decls may 
> change several times until the top-level import call is finished."
The meaning of this is still different from what my original intent was: The 
DeclContext in the "To" context is different from the "From", even after the 
top-level import call. I wanted to emphasize here that this change of 
DeclContext after (top-level) import has no relevance, should cause no problems.



Comment at: clang/unittests/AST/ASTImporterTest.cpp:7348-7353
+  // Get the implicit deduction guide for (non-default) constructor of 'B'.
+  auto *FromDG1 = FirstDeclMatcher().match(
+  FromTU, functionTemplateDecl(templateParameterCountIs(3)));
+  // User defined deduction guide.
+  auto *FromDG2 = FirstDeclMatcher().match(
+  FromTU, cxxDeductionGuideDecl(unless(isImplicit(;

martong wrote:
> balazske wrote:
> > martong wrote:
> > > Could you please formulate expectations (assertions) on the DeclContext's 
> > > of the two template parameters? I'd expect them to be different.
> > I left this out because the "instability" mentioned above. It is possible 
> > to make the assertions for this exact code. We can better say that it comes 
> > from a set of possible values,  these are the current `DeductionGuideDecl`, 
> > or another one for the same class, or the class itself (but I am not sure 
> > in this any more). It is possible to get different value for different 
> > template parameters of the same template.
> So, we could have 
> ```
> ASSERT_NE(cast(FromDG1->getTemplateParameters()->getParam(0)->getDeclContext()),
>  cast(FromDG1->getTemplateParameters()->getParam(1)->getDeclContext()));
> ASSERT_NE(cast(FromDG1->getTemplateParameters()->getParam(0)->getDeclContext()),
>  cast(FromDG1->getTemplateParameters()->getParam(2)->getDeclContext()));
> ASSERT_EQ(cast(FromDG1->getTemplateParameters()->getParam(1)->getDeclContext()),
>  cast(FromDG1->getTemplateParameters()->getParam(2)->getDeclContext()))
> ```
> 
> And then after the `Import` calls we could have the same expectations on 
> `ToDG1->getParam(0)` and the rest. Couldn't we?
Probably at the "explicit" template parameters (the ones not coming from the 
class template) the DeclContext is always the deduction guide, so an 
`ASSERT_EQ(FromDG1->getTemplateParameters()->getParam(1)->getDeclContext(), 
FromDG1->getTemplatedDecl())` do work (for param 2 similar). I would not say 
that param 0 has always necessary a different DeclContext than the others, in 
this one case yes but not generally. This is why I do not like an assert for 
that. (Such an assert would not point out an invariant that is true always in 
the AST: An "unrelated" change in the source, for example different order of 
declarations, change in template-template parameters, may result in change of 
the DeclContext.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114418/new/

https://reviews.llvm.org/D114418

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

[PATCH] D114256: [clang-tidy] Fix crashing altera-struct-pack-align on invalid RecordDecls

2021-11-25 Thread Gabor Marton via Phabricator via cfe-commits

martong accepted this revision.
martong added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: rnkovacs.

LGTM!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114256/new/

https://reviews.llvm.org/D114256

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

[PATCH] D114418: [clang][ASTImporter] Update lookup table correctly at deduction guides.

2021-11-25 Thread Gabor Marton via Phabricator via cfe-commits

martong added a comment.

> Probably this is a bug in the AST creation but currently it works this way.

I don't think this is a bug, deduction guides have a convoluted implementation. 
See the related DeclContext issue with them when local typdefs are involved:
https://reviews.llvm.org/D92209




Comment at: clang/lib/AST/ASTImporter.cpp:6081
+  // FunctionTemplateDecl objects are created, but in different order. In this
+  // way DeclContext of these template parameters may change relative to the
+  // "from" context. Because these DeclContext values look already not stable

balazske wrote:
> martong wrote:
> > ?
> Probably better:
> In this way the DeclContext of these template parameters is not necessary the 
> same as in the "from" context.
okay, but necessary->necessarily



Comment at: clang/lib/AST/ASTImporter.cpp:6082-6085
+  // "from" context. Because these DeclContext values look already not stable
+  // and unimportant this change looks acceptable.
+  // For these reasons the old DeclContext must be saved to change the lookup
+  // table later.

balazske wrote:
> martong wrote:
> > I think this sentence does not provide any meaningful information and does 
> > not increase the understand-ability. Plus the word `change` is overloaded, 
> > first I though you meant the patch itself...
> It is still good to have an explanation of why the DeclContext is not exactly 
> preserved at import. And the DeclContext is really not "stable", not easily 
> predictable from the source code.
Okay, then we could write "Consequently, the DeclContext of these Decls may 
change several times until the top-level import call is finished."



Comment at: clang/unittests/AST/ASTImporterTest.cpp:7336
+
+TEST_P(ASTImporterOptionSpecificTestBase, ImportDeductionGuide) {
+  TranslationUnitDecl *FromTU = getTuDecl(

balazske wrote:
> martong wrote:
> > Does this test provide an assertion failure in the base?
> We get the "trying to remove not contained Decl" in ASTImporterLookupTable.
ok.



Comment at: clang/unittests/AST/ASTImporterTest.cpp:7348-7353
+  // Get the implicit deduction guide for (non-default) constructor of 'B'.
+  auto *FromDG1 = FirstDeclMatcher().match(
+  FromTU, functionTemplateDecl(templateParameterCountIs(3)));
+  // User defined deduction guide.
+  auto *FromDG2 = FirstDeclMatcher().match(
+  FromTU, cxxDeductionGuideDecl(unless(isImplicit(;

balazske wrote:
> martong wrote:
> > Could you please formulate expectations (assertions) on the DeclContext's 
> > of the two template parameters? I'd expect them to be different.
> I left this out because the "instability" mentioned above. It is possible to 
> make the assertions for this exact code. We can better say that it comes from 
> a set of possible values,  these are the current `DeductionGuideDecl`, or 
> another one for the same class, or the class itself (but I am not sure in 
> this any more). It is possible to get different value for different template 
> parameters of the same template.
So, we could have 
```
ASSERT_NE(cast(FromDG1->getTemplateParameters()->getParam(0)->getDeclContext()),
 cast(FromDG1->getTemplateParameters()->getParam(1)->getDeclContext()));
ASSERT_NE(cast(FromDG1->getTemplateParameters()->getParam(0)->getDeclContext()),
 cast(FromDG1->getTemplateParameters()->getParam(2)->getDeclContext()));
ASSERT_EQ(cast(FromDG1->getTemplateParameters()->getParam(1)->getDeclContext()),
 cast(FromDG1->getTemplateParameters()->getParam(2)->getDeclContext()))
```

And then after the `Import` calls we could have the same expectations on 
`ToDG1->getParam(0)` and the rest. Couldn't we?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114418/new/

https://reviews.llvm.org/D114418

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

[PATCH] D114105: [clang-tidy] Ignore narrowing conversions in case of bitfields

2021-11-25 Thread Clement Courbet via Phabricator via cfe-commits

courbet accepted this revision.
courbet added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-bitfields.cpp:62
+void take(T);
+void test_parameter_passing(NoBitfield x) {
+  take(x.id);

[nit] newline after take


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114105/new/

https://reviews.llvm.org/D114105

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

[PATCH] D114562: [clang][docs] Inclusive language: remove use of sanity check in option description

2021-11-25 Thread Zarko Todorovski via Phabricator via cfe-commits

ZarkoCA updated this revision to Diff 389737.
ZarkoCA added a comment.

- Fix description
- Remove `three`


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114562/new/

https://reviews.llvm.org/D114562

Files:
  clang/docs/ThreadSafetyAnalysis.rst


Index: clang/docs/ThreadSafetyAnalysis.rst
===
--- clang/docs/ThreadSafetyAnalysis.rst
+++ clang/docs/ThreadSafetyAnalysis.rst
@@ -466,9 +466,9 @@
 Warning flags
 -
 
-* ``-Wthread-safety``:  Umbrella flag which turns on the following three:
+* ``-Wthread-safety``:  Umbrella flag which turns on the following:
 
-  + ``-Wthread-safety-attributes``: Sanity checks on attribute syntax.
+  + ``-Wthread-safety-attributes``: Semantic checks for thread safety 
attributes.
   + ``-Wthread-safety-analysis``: The core analysis.
   + ``-Wthread-safety-precise``: Requires that mutex expressions match 
precisely.
This warning can be disabled for code which has a lot of aliases.


Index: clang/docs/ThreadSafetyAnalysis.rst
===
--- clang/docs/ThreadSafetyAnalysis.rst
+++ clang/docs/ThreadSafetyAnalysis.rst
@@ -466,9 +466,9 @@
 Warning flags
 -
 
-* ``-Wthread-safety``:  Umbrella flag which turns on the following three:
+* ``-Wthread-safety``:  Umbrella flag which turns on the following:
 
-  + ``-Wthread-safety-attributes``: Sanity checks on attribute syntax.
+  + ``-Wthread-safety-attributes``: Semantic checks for thread safety attributes.
   + ``-Wthread-safety-analysis``: The core analysis.
   + ``-Wthread-safety-precise``: Requires that mutex expressions match precisely.
This warning can be disabled for code which has a lot of aliases.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D114025: [clang][NFC] Inclusive terms: replace some uses of sanity in clang

2021-11-25 Thread Zarko Todorovski via Phabricator via cfe-commits

ZarkoCA added a comment.

@rjmccall thanks for having a look, I will clarify the comments with your 
suggestions.

In D114025#3152900 , @tstellar wrote:

> @ZarkoCA If you are planning to do a lot of this, it might be good to write a 
> script (or a clang-tidy check even) that we can add to CI, so these terms 
> don't get re-introduced.

That's a good idea, I will look into this definitely.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114025/new/

https://reviews.llvm.org/D114025

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

[PATCH] D114504: [clang][DebugInfo] Debug support for private variables inside an OpenMP task construct

2021-11-25 Thread Djordje Todorovic via Phabricator via cfe-commits

djtodoro accepted this revision.
djtodoro added a comment.
This revision is now accepted and ready to land.

LGTM


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114504/new/

https://reviews.llvm.org/D114504

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

[clang-tools-extra] 59e4a67 - [clangd] Move IncludeCleaner tracer to the actual computation

2021-11-25 Thread Kirill Bobyrev via cfe-commits


Author: Kirill Bobyrev
Date: 2021-11-25T13:19:01+01:00
New Revision: 59e4a6708152b42a55653bd8a44a6e0781fd4caf

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

LOG: [clangd] Move IncludeCleaner tracer to the actual computation

This way we won't get results with 0 ms for all the users with disabled
IncludeCleaner.

Added: 


Modified: 
clang-tools-extra/clangd/IncludeCleaner.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/IncludeCleaner.cpp 
b/clang-tools-extra/clangd/IncludeCleaner.cpp
index b9267ff71120..a0b9e303e3bf 100644
--- a/clang-tools-extra/clangd/IncludeCleaner.cpp
+++ b/clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -317,12 +317,12 @@ std::vector 
computeUnusedIncludes(ParsedAST ) {
 
 std::vector issueUnusedIncludesDiagnostics(ParsedAST ,
  llvm::StringRef Code) {
-  trace::Span Tracer("IncludeCleaner::issueUnusedIncludesDiagnostics");
   const Config  = Config::current();
   if (Cfg.Diagnostics.UnusedIncludes != Config::UnusedIncludesPolicy::Strict ||
   Cfg.Diagnostics.SuppressAll ||
   Cfg.Diagnostics.Suppress.contains("unused-includes"))
 return {};
+  trace::Span Tracer("IncludeCleaner::issueUnusedIncludesDiagnostics");
   std::vector Result;
   std::string FileName =
   AST.getSourceManager()



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

[PATCH] D114579: [clang-tidy] Exempt _MSVC_EXECUTION_CHARACTER_SET from cppcoreguidelines-macro-usage

2021-11-25 Thread Markus Böck via Phabricator via cfe-commits

zero9178 created this revision.
zero9178 added reviewers: MaskRay, aaron.ballman, lebedev.ri, JonasToth, hokein.
Herald added subscribers: carlosgalvezp, shchenz, kbarton, xazax.hun, nemanjai.
zero9178 requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

In https://reviews.llvm.org/D114576 I am trying to add an unconditional define 
to the MSVC cc1 driver which sadly then leads to a test failure in 
`cppcoreguidelines-macro-usage-command-line-macros.cpp` with MSVC builds.

The solution is a bit hacky IMO, but there seems to already be a similar 
workaround for `__GCC_HAVE_DWARF2_CFI_ASM`. I don't know of any way to 
differentiate between defines passed on the CLI by users, and ones set by the 
driver, so this will have to do for now.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D114579

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp


Index: clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp
@@ -47,7 +47,8 @@
   return;
 
 StringRef MacroName = MacroNameTok.getIdentifierInfo()->getName();
-if (MacroName == "__GCC_HAVE_DWARF2_CFI_ASM")
+if (MacroName == "__GCC_HAVE_DWARF2_CFI_ASM" ||
+MacroName == "_MSVC_EXECUTION_CHARACTER_SET")
   return;
 if (!CheckCapsOnly && !RegExp.match(MacroName))
   Check->warnMacro(MD, MacroName);


Index: clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/MacroUsageCheck.cpp
@@ -47,7 +47,8 @@
   return;
 
 StringRef MacroName = MacroNameTok.getIdentifierInfo()->getName();
-if (MacroName == "__GCC_HAVE_DWARF2_CFI_ASM")
+if (MacroName == "__GCC_HAVE_DWARF2_CFI_ASM" ||
+MacroName == "_MSVC_EXECUTION_CHARACTER_SET")
   return;
 if (!CheckCapsOnly && !RegExp.match(MacroName))
   Check->warnMacro(MD, MacroName);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D114151: [clang-format] [C++20] [Module] clang-format couldn't recognize partitions

2021-11-25 Thread MyDeveloperDay via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc2fe2b5a63bb: [clang-format] [C++20] [Module] clang-format 
couldnt recognize partitions (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114151/new/

https://reviews.llvm.org/D114151

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Format/FormatToken.h
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/lib/Format/UnwrappedLineParser.h
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -22616,6 +22616,71 @@
   verifyFormat("auto(*p)() = f;");   // actually a declaration; TODO FIXME
 }
 
+TEST_F(FormatTest, Cpp20ModulesSupport) {
+  FormatStyle Style = getLLVMStyle();
+  Style.AllowShortBlocksOnASingleLine = FormatStyle::SBS_Never;
+  Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
+
+  verifyFormat("export import foo;", Style);
+  verifyFormat("export import foo:bar;", Style);
+  verifyFormat("export import foo.bar;", Style);
+  verifyFormat("export import foo.bar:baz;", Style);
+  verifyFormat("export import :bar;", Style);
+  verifyFormat("export module foo:bar;", Style);
+  verifyFormat("export module foo;", Style);
+  verifyFormat("export module foo.bar;", Style);
+  verifyFormat("export module foo.bar:baz;", Style);
+  verifyFormat("export import ;", Style);
+
+  verifyFormat("export type_name var;", Style);
+  verifyFormat("template  export using A = B;", Style);
+  verifyFormat("export using A = B;", Style);
+  verifyFormat("export int func() {\n"
+   "  foo();\n"
+   "}",
+   Style);
+  verifyFormat("export struct {\n"
+   "  int foo;\n"
+   "};",
+   Style);
+  verifyFormat("export {\n"
+   "  int foo;\n"
+   "};",
+   Style);
+  verifyFormat("export export char const *hello() { return \"hello\"; }");
+
+  verifyFormat("import bar;", Style);
+  verifyFormat("import foo.bar;", Style);
+  verifyFormat("import foo:bar;", Style);
+  verifyFormat("import :bar;", Style);
+  verifyFormat("import ;", Style);
+  verifyFormat("import \"header\";", Style);
+
+  verifyFormat("module foo;", Style);
+  verifyFormat("module foo:bar;", Style);
+  verifyFormat("module foo.bar;", Style);
+  verifyFormat("module;", Style);
+
+  verifyFormat("export namespace hi {\n"
+   "const char *sayhi();\n"
+   "}",
+   Style);
+
+  verifyFormat("module :private;", Style);
+  verifyFormat("import ;", Style);
+  verifyFormat("import foo...bar;", Style);
+  verifyFormat("import ..;", Style);
+  verifyFormat("module foo:private;", Style);
+  verifyFormat("import a", Style);
+  verifyFormat("module a", Style);
+  verifyFormat("export import a", Style);
+  verifyFormat("export module a", Style);
+
+  verifyFormat("import", Style);
+  verifyFormat("module", Style);
+  verifyFormat("export", Style);
+}
+
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/lib/Format/UnwrappedLineParser.h
===
--- clang/lib/Format/UnwrappedLineParser.h
+++ clang/lib/Format/UnwrappedLineParser.h
@@ -110,6 +110,7 @@
   void parseCaseLabel();
   void parseSwitch();
   void parseNamespace();
+  void parseModuleImport();
   void parseNew();
   void parseAccessSpecifier();
   bool parseEnum();
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1114,6 +1114,35 @@
   return Tok->Previous && Tok->Previous->isOneOf(tok::l_paren, tok::comma);
 }
 
+void UnwrappedLineParser::parseModuleImport() {
+  nextToken();
+  while (!eof()) {
+if (FormatTok->is(tok::colon)) {
+  FormatTok->setType(TT_ModulePartitionColon);
+}
+// Handle import  as we would an include statement.
+else if (FormatTok->is(tok::less)) {
+  nextToken();
+  while (!FormatTok->isOneOf(tok::semi, tok::greater, tok::eof)) {
+// Mark tokens up to the trailing line comments as implicit string
+// literals.
+if (FormatTok->isNot(tok::comment) &&
+!FormatTok->TokenText.startswith("//"))
+  FormatTok->setType(TT_ImplicitStringLiteral);
+nextToken();
+  }
+}
+if (FormatTok->is(tok::semi)) {
+  nextToken();
+  break;
+}
+nextToken();
+  }
+
+  addUnwrappedLine();
+  return;
+}
+
 // readTokenWithJavaScriptASI reads the next token and terminates the current
 // line if JavaScript Automatic Semicolon Insertion must
 // happen between the current token and the next token.
@@ -1312,6 +1341,10 @@

[clang] c2fe2b5 - [clang-format] [C++20] [Module] clang-format couldn't recognize partitions

2021-11-25 Thread via cfe-commits


Author: mydeveloperday
Date: 2021-11-25T11:51:21Z
New Revision: c2fe2b5a63bb7ec82d0a221bd144f6ce04661f90

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

LOG: [clang-format] [C++20] [Module] clang-format couldn't recognize partitions

https://bugs.llvm.org/show_bug.cgi?id=52517

clang-format is butchering modules, this could easily become a barrier to entry 
for modules given clang-formats wide spread use.

Prevent the following from adding spaces around the  `:`  (cf was considering 
the ':' as an InheritanceColon)

Reviewed By: HazardyKnusperkeks, owenpan, ChuanqiXu

Differential Revision: https://reviews.llvm.org/D114151

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Format/FormatToken.h
clang/lib/Format/TokenAnnotator.cpp
clang/lib/Format/UnwrappedLineParser.cpp
clang/lib/Format/UnwrappedLineParser.h
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index df2a6e71c534b..20e99fbf2e136 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -265,6 +265,8 @@ clang-format
   space before parentheses. The custom options can be set using
   ``SpaceBeforeParensOptions``.
 
+- Improved Cpp20 Modules support.
+
 libclang
 
 

diff  --git a/clang/lib/Format/FormatToken.h b/clang/lib/Format/FormatToken.h
index 06d51dd95f50f..1a2858018fde5 100644
--- a/clang/lib/Format/FormatToken.h
+++ b/clang/lib/Format/FormatToken.h
@@ -76,6 +76,7 @@ namespace format {
   TYPE(LineComment)
\
   TYPE(MacroBlockBegin)
\
   TYPE(MacroBlockEnd)  
\
+  TYPE(ModulePartitionColon)   
\
   TYPE(NamespaceMacro) 
\
   TYPE(NonNullAssertion)   
\
   TYPE(NullCoalescingEqual)
\

diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index e6564a3511de2..fba55fb32da2d 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -903,9 +903,13 @@ class AnnotatingParser {
   break;
 }
   }
-  if (Contexts.back().ColonIsDictLiteral ||
-  Style.Language == FormatStyle::LK_Proto ||
-  Style.Language == FormatStyle::LK_TextProto) {
+  if (Line.First->isOneOf(Keywords.kw_module, Keywords.kw_import) ||
+  Line.First->startsSequence(tok::kw_export, Keywords.kw_module) ||
+  Line.First->startsSequence(tok::kw_export, Keywords.kw_import)) {
+Tok->setType(TT_ModulePartitionColon);
+  } else if (Contexts.back().ColonIsDictLiteral ||
+ Style.Language == FormatStyle::LK_Proto ||
+ Style.Language == FormatStyle::LK_TextProto) {
 Tok->setType(TT_DictLiteral);
 if (Style.Language == FormatStyle::LK_TextProto) {
   if (FormatToken *Previous = Tok->getPreviousNonComment())
@@ -3244,6 +3248,7 @@ bool TokenAnnotator::spaceRequiredBefore(const 
AnnotatedLine ,
   auto HasExistingWhitespace = []() {
 return Right.WhitespaceRange.getBegin() != Right.WhitespaceRange.getEnd();
   };
+
   if (Right.Tok.getIdentifierInfo() && Left.Tok.getIdentifierInfo())
 return true; // Never ever merge two identifiers.
 
@@ -3253,6 +3258,25 @@ bool TokenAnnotator::spaceRequiredBefore(const 
AnnotatedLine ,
 return true;
 
   if (Style.isCpp()) {
+// Space between import .
+// or import .;
+if (Left.is(Keywords.kw_import) && Right.isOneOf(tok::less, tok::ellipsis))
+  return true;
+// No space between module :.
+if (Left.isOneOf(Keywords.kw_module, Keywords.kw_import) &&
+Right.is(TT_ModulePartitionColon))
+  return true;
+// No space between import foo:bar but keep a space between import :bar;
+if (Left.is(tok::identifier) && Right.is(TT_ModulePartitionColon))
+  return false;
+// No space between :bar;
+if (Left.is(TT_ModulePartitionColon) &&
+Right.isOneOf(tok::identifier, tok::kw_private))
+  return false;
+if (Left.is(tok::ellipsis) && Right.is(tok::identifier) &&
+Line.First->is(Keywords.kw_import))
+  return false;
+
 if (Left.is(tok::kw_operator))
   return Right.is(tok::coloncolon);
 if (Right.is(tok::l_brace) && Right.is(BK_BracedInit) &&

diff  --git a/clang/lib/Format/UnwrappedLineParser.cpp 
b/clang/lib/Format/UnwrappedLineParser.cpp
index 12f912305f590..da35648ef1ca0 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++

[PATCH] D114576: [PR52549][clang-cl] Predefine _MSVC_EXECUTION_CHARACTER_SET

2021-11-25 Thread Markus Böck via Phabricator via cfe-commits

zero9178 added a comment.

Seems like this is causing failures in a test for clang-tidy if the triple used 
is an MSVC one. Let me see what I can do about it


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114576/new/

https://reviews.llvm.org/D114576

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

[clang] d44f2a6 - [clang-format]NFC improve the comment to match the code

2021-11-25 Thread via cfe-commits


Author: mydeveloperday
Date: 2021-11-25T11:11:30Z
New Revision: d44f2a6db2c71be04a588431a8ffb80d2d9e76f1

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

LOG: [clang-format]NFC improve the comment to match the code

Missing from {D114519}

Added: 


Modified: 
clang/lib/Format/TokenAnnotator.cpp

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 19f30b5ce36ae..e6564a3511de2 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -314,6 +314,7 @@ class AnnotatingParser {
 //
 // void (*FunctionPointer)(void);
 // void ()(void);
+// void (&)(void);
 // void (^ObjCBlock)(void);
 bool MightBeFunctionType = !Contexts[Contexts.size() - 2].IsExpression;
 bool ProbablyFunctionType =



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

[PATCH] D114519: [clang-format] [PR52595] clang-format does not recognize rvalue references to array

2021-11-25 Thread MyDeveloperDay via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc94667a810e4: [clang-format] [PR52595] clang-format does not 
recognize rvalue references to… (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114519/new/

https://reviews.llvm.org/D114519

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -9670,6 +9670,9 @@
   verifyFormat("void f() { a->operator()(a & a); }");
   verifyFormat("void f() { a.operator()(*a & *a); }");
   verifyFormat("void f() { a->operator()(*a * *a); }");
+
+  verifyFormat("int operator()(T (&&)[N]) { return 1; }");
+  verifyFormat("int operator()(T (&)[N]) { return 0; }");
 }
 
 TEST_F(FormatTest, UnderstandsAttributes) {
@@ -21876,6 +21879,7 @@
   verifyFormat("Foo::operator&(void &);", Style);
   verifyFormat("Foo::operator&();", Style);
   verifyFormat("operator&(int (&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&)(), class Foo);", Style);
 
   verifyFormat("Foo::operator&&();", Style);
   verifyFormat("Foo::operator**();", Style);
@@ -21884,7 +21888,7 @@
   verifyFormat("Foo::operator()(void &&);", Style);
   verifyFormat("Foo::operator&&(void &&);", Style);
   verifyFormat("Foo::operator&&();", Style);
-  verifyFormat("operator&&(int(&&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&&)(), class Foo);", Style);
   verifyFormat("operator const nsTArrayRight &()", Style);
   verifyFormat("[[nodiscard]] operator const nsTArrayRight &()",
Style);
@@ -21935,6 +21939,8 @@
   verifyFormat("Foo::operator&(void&);", Style);
   verifyFormat("Foo::operator&();", Style);
   verifyFormat("operator&(int (&)(), class Foo);", Style);
+  verifyFormat("operator&(int (&&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&&)(), class Foo);", Style);
 
   verifyFormat("Foo::operator&&();", Style);
   verifyFormat("Foo::operator void&&();", Style);
@@ -21945,7 +21951,7 @@
   verifyFormat("Foo::operator()(void&&);", Style);
   verifyFormat("Foo::operator&&(void&&);", Style);
   verifyFormat("Foo::operator&&();", Style);
-  verifyFormat("operator&&(int(&&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&&)(), class Foo);", Style);
   verifyFormat("operator const nsTArrayLeft&()", Style);
   verifyFormat("[[nodiscard]] operator const nsTArrayLeft&()",
Style);
@@ -21986,7 +21992,7 @@
   verifyFormat("Foo::operator()(void &&);", Style);
   verifyFormat("Foo::operator&&(void &&);", Style);
   verifyFormat("Foo::operator&&();", Style);
-  verifyFormat("operator&&(int(&&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&&)(), class Foo);", Style);
 }
 
 TEST_F(FormatTest, OperatorPassedAsAFunctionPtr) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -317,7 +317,7 @@
 // void (^ObjCBlock)(void);
 bool MightBeFunctionType = !Contexts[Contexts.size() - 2].IsExpression;
 bool ProbablyFunctionType =
-CurrentToken->isOneOf(tok::star, tok::amp, tok::caret);
+CurrentToken->isOneOf(tok::star, tok::amp, tok::ampamp, tok::caret);
 bool HasMultipleLines = false;
 bool HasMultipleParametersOnALine = false;
 bool MightBeObjCForRangeLoop =


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -9670,6 +9670,9 @@
   verifyFormat("void f() { a->operator()(a & a); }");
   verifyFormat("void f() { a.operator()(*a & *a); }");
   verifyFormat("void f() { a->operator()(*a * *a); }");
+
+  verifyFormat("int operator()(T (&&)[N]) { return 1; }");
+  verifyFormat("int operator()(T (&)[N]) { return 0; }");
 }
 
 TEST_F(FormatTest, UnderstandsAttributes) {
@@ -21876,6 +21879,7 @@
   verifyFormat("Foo::operator&(void &);", Style);
   verifyFormat("Foo::operator&();", Style);
   verifyFormat("operator&(int (&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&)(), class Foo);", Style);
 
   verifyFormat("Foo::operator&&();", Style);
   verifyFormat("Foo::operator**();", Style);
@@ -21884,7 +21888,7 @@
   verifyFormat("Foo::operator()(void &&);", Style);
   verifyFormat("Foo::operator&&(void &&);", Style);
   verifyFormat("Foo::operator&&();", Style);
-  verifyFormat("operator&&(int(&&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&&)(), class Foo);", Style);
   verifyFormat("operator const nsTArrayRight &()", Style);
   verifyFormat("[[nodiscard]] operator const nsTArrayRight &()",
Style);
@@ -21935,6 +21939,8 @@

[PATCH] D114105: [clang-tidy] Ignore narrowing conversions in case of bitfields

2021-11-25 Thread Balázs Benics via Phabricator via cfe-commits

steakhal added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-bitfields.cpp:1
+// RUN: %check_clang_tidy %s cppcoreguidelines-narrowing-conversions %t \
+// RUN:   -std=c++17 -- -target x86_64-unknown-linux

courbet wrote:
> Can you add a test with:
> 
> ```
> 
> void takesInt(int);
> 
> ...
> 
> takesInt(x.id);
> ```
> 
> I think this suffers from the same problem currently.
Sure, great idea! It actually revealed a logical flaw. Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114105/new/

https://reviews.llvm.org/D114105

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

[clang] c94667a - [clang-format] [PR52595] clang-format does not recognize rvalue references to array

2021-11-25 Thread via cfe-commits


Author: mydeveloperday
Date: 2021-11-25T11:05:46Z
New Revision: c94667a810e44c44fd355f9f014ffe161d75d761

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

LOG: [clang-format] [PR52595] clang-format does not recognize rvalue references 
to array

https://bugs.llvm.org/show_bug.cgi?id=52595

missing space between `T(&&)` but not between `T (&` due to && being 
incorrectly thought of as `UnaryOperator`  rather than `PointerOrReference`

```
int operator()(T (&)[N]) { return 0; }
int operator()(T(&&)[N]) { return 1; }
```

Existing Unit tests are changed because actually I think they are originally 
incorrect, and are inconsistent with the (&) cases that are 4 or 5 lines above 
them.

Reviewed By: curdeius

Differential Revision: https://reviews.llvm.org/D114519

Added: 


Modified: 
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 2cd57c10425f5..19f30b5ce36ae 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -317,7 +317,7 @@ class AnnotatingParser {
 // void (^ObjCBlock)(void);
 bool MightBeFunctionType = !Contexts[Contexts.size() - 2].IsExpression;
 bool ProbablyFunctionType =
-CurrentToken->isOneOf(tok::star, tok::amp, tok::caret);
+CurrentToken->isOneOf(tok::star, tok::amp, tok::ampamp, tok::caret);
 bool HasMultipleLines = false;
 bool HasMultipleParametersOnALine = false;
 bool MightBeObjCForRangeLoop =

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 096d6a32ecfce..fb04b4f359859 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -9670,6 +9670,9 @@ TEST_F(FormatTest, UnderstandsUsesOfStarAndAmp) {
   verifyFormat("void f() { a->operator()(a & a); }");
   verifyFormat("void f() { a.operator()(*a & *a); }");
   verifyFormat("void f() { a->operator()(*a * *a); }");
+
+  verifyFormat("int operator()(T (&&)[N]) { return 1; }");
+  verifyFormat("int operator()(T (&)[N]) { return 0; }");
 }
 
 TEST_F(FormatTest, UnderstandsAttributes) {
@@ -21876,6 +21879,7 @@ TEST_F(FormatTest, OperatorSpacing) {
   verifyFormat("Foo::operator&(void &);", Style);
   verifyFormat("Foo::operator&();", Style);
   verifyFormat("operator&(int (&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&)(), class Foo);", Style);
 
   verifyFormat("Foo::operator&&();", Style);
   verifyFormat("Foo::operator**();", Style);
@@ -21884,7 +21888,7 @@ TEST_F(FormatTest, OperatorSpacing) {
   verifyFormat("Foo::operator()(void &&);", Style);
   verifyFormat("Foo::operator&&(void &&);", Style);
   verifyFormat("Foo::operator&&();", Style);
-  verifyFormat("operator&&(int(&&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&&)(), class Foo);", Style);
   verifyFormat("operator const nsTArrayRight &()", Style);
   verifyFormat("[[nodiscard]] operator const nsTArrayRight &()",
Style);
@@ -21935,6 +21939,8 @@ TEST_F(FormatTest, OperatorSpacing) {
   verifyFormat("Foo::operator&(void&);", Style);
   verifyFormat("Foo::operator&();", Style);
   verifyFormat("operator&(int (&)(), class Foo);", Style);
+  verifyFormat("operator&(int (&&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&&)(), class Foo);", Style);
 
   verifyFormat("Foo::operator&&();", Style);
   verifyFormat("Foo::operator void&&();", Style);
@@ -21945,7 +21951,7 @@ TEST_F(FormatTest, OperatorSpacing) {
   verifyFormat("Foo::operator()(void&&);", Style);
   verifyFormat("Foo::operator&&(void&&);", Style);
   verifyFormat("Foo::operator&&();", Style);
-  verifyFormat("operator&&(int(&&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&&)(), class Foo);", Style);
   verifyFormat("operator const nsTArrayLeft&()", Style);
   verifyFormat("[[nodiscard]] operator const nsTArrayLeft&()",
Style);
@@ -21986,7 +21992,7 @@ TEST_F(FormatTest, OperatorSpacing) {
   verifyFormat("Foo::operator()(void &&);", Style);
   verifyFormat("Foo::operator&&(void &&);", Style);
   verifyFormat("Foo::operator&&();", Style);
-  verifyFormat("operator&&(int(&&)(), class Foo);", Style);
+  verifyFormat("operator&&(int (&&)(), class Foo);", Style);
 }
 
 TEST_F(FormatTest, OperatorPassedAsAFunctionPtr) {



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

[PATCH] D114105: [clang-tidy] Ignore narrowing conversions in case of bitfields

2021-11-25 Thread Balázs Benics via Phabricator via cfe-commits

steakhal updated this revision to Diff 389711.
steakhal marked an inline comment as done.
steakhal added a comment.

Added the `test_parameter_passing()` tests, demonstrating the implicit 
conversion triggered by parameter passing.
It turns out my previous revision suppressed a useful report.
Now, I fixed that and we get a warning for `take(x.id) // warn` when `x` 
is `CompleteBitfield` with `32` bitwidth.
Aside from this, no behavioral change happened compared to the previous 
revision.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114105/new/

https://reviews.llvm.org/D114105

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-bitfields.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-bitfields.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-narrowing-conversions-bitfields.cpp
@@ -0,0 +1,202 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-narrowing-conversions %t \
+// RUN:   -std=c++17 -- -target x86_64-unknown-linux
+
+#define CHAR_BITS 8
+static_assert(sizeof(unsigned int) == 32 / CHAR_BITS);
+
+template 
+struct is_same {
+  static constexpr bool value = false;
+};
+template 
+struct is_same {
+  static constexpr bool value = true;
+};
+
+template 
+static constexpr bool is_same_v = is_same::value;
+
+struct NoBitfield {
+  unsigned int id;
+};
+struct SmallBitfield {
+  unsigned int id : 4;
+};
+
+struct BigBitfield {
+  unsigned int id : 31;
+};
+struct CompleteBitfield {
+  unsigned int id : 32;
+};
+
+int example_warning(unsigned x) {
+  // CHECK-MESSAGES: :[[@LINE+1]]:10: warning: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]
+  return x;
+}
+
+void test_binary_and(SmallBitfield x) {
+  static_assert(is_same_v);
+  static_assert(is_same_v);
+
+  x.id & 1;
+  x.id & 1u;
+
+  1 & x.id;
+  1u & x.id;
+}
+
+void test_binary_or(SmallBitfield x) {
+  static_assert(is_same_v);
+  static_assert(is_same_v);
+
+  x.id | 1;
+  x.id | 1u;
+
+  1 | x.id;
+  1u | x.id;
+}
+
+template 
+void take(T);
+void test_parameter_passing(NoBitfield x) {
+  take(x.id);
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: narrowing conversion from 'unsigned int' to signed type 'char' is implementation-defined
+  take(x.id);
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: narrowing conversion from 'unsigned int' to signed type 'short' is implementation-defined
+  take(x.id);
+  take(x.id);
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined
+  take(x.id);
+  take(x.id);
+}
+
+void test_parameter_passing(SmallBitfield x) {
+  take(x.id);
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: narrowing conversion from 'unsigned int' to signed type 'char' is implementation-defined
+  take(x.id);
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: narrowing conversion from 'unsigned int' to signed type 'short' is implementation-defined
+  take(x.id);
+  take(x.id); // no-warning
+  take(x.id);
+  take(x.id);
+}
+
+void test_parameter_passing(BigBitfield x) {
+  take(x.id);
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: narrowing conversion from 'unsigned int' to signed type 'char' is implementation-defined
+  take(x.id);
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: narrowing conversion from 'unsigned int' to signed type 'short' is implementation-defined
+  take(x.id);
+  take(x.id); // no-warning
+  take(x.id);
+  take(x.id);
+}
+
+void test_parameter_passing(CompleteBitfield x) {
+  take(x.id);
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: narrowing conversion from 'unsigned int' to signed type 'char' is implementation-defined
+  take(x.id);
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: narrowing conversion from 'unsigned int' to signed type 'short' is implementation-defined
+  take(x.id);
+  take(x.id);
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined
+  take(x.id);
+  take(x.id);
+}
+
+void test(NoBitfield x) {
+  static_assert(is_same_v);
+  static_assert(is_same_v);
+  static_assert(is_same_v);
+  static_assert(is_same_v);
+
+  x.id << 1;
+  x.id << 1u;
+  x.id >> 1;
+  x.id >> 1u;
+  x.id + 1;
+  x.id + 1u;
+
+  1 << x.id;
+  1u << x.id;
+  1 >> x.id;
+  1u >> x.id;
+  1 + x.id;
+  1u + x.id;
+}
+
+void test(SmallBitfield x) {
+  static_assert(is_same_v);
+  static_assert(is_same_v);
+
+  x.id << 1;
+  x.id << 1u;
+  x.id >> 1;
+  x.id >> 1u;
+
+  x.id + 1;
+  x.id + 1u;
+
+  1 << x.id;
+  1u << x.id;
+  1 >> x.id;
+  1u >> x.id;
+
+  1 + x.id;
+  1u + x.id;
+}
+
+void test(BigBitfield x) {
+  static_assert(is_same_v);
+  static_assert(is_same_v);
+
+  x.id << 1;
+  x.id << 1u;
+  x.id >> 1;
+  x.id

[PATCH] D114576: [PR52549][clang-cl] Predefine _MSVC_EXECUTION_CHARACTER_SET

2021-11-25 Thread Casey Carter via Phabricator via cfe-commits

CaseyCarter accepted this revision.
CaseyCarter added a comment.

LGTM - thanks for the quick response!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114576/new/

https://reviews.llvm.org/D114576

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

[PATCH] D113118: [clang][AST] Check context of record in structural equivalence.

2021-11-25 Thread Balázs Kéri via Phabricator via cfe-commits

balazske updated this revision to Diff 389709.
balazske added a comment.

Using correct AST match in the tests to fix failures on Windows.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113118/new/

https://reviews.llvm.org/D113118

Files:
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/unittests/AST/StructuralEquivalenceTest.cpp

Index: clang/unittests/AST/StructuralEquivalenceTest.cpp
===
--- clang/unittests/AST/StructuralEquivalenceTest.cpp
+++ clang/unittests/AST/StructuralEquivalenceTest.cpp
@@ -929,6 +929,128 @@
   EXPECT_TRUE(testStructuralMatch(First, Second));
 }
 
+struct StructuralEquivalenceRecordContextTest : StructuralEquivalenceTest {};
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNoVsNamed) {
+  auto Decls =
+  makeNamedDecls("class X;", "namespace N { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNamedVsNamed) {
+  auto Decls = makeNamedDecls("namespace A { class X; }",
+  "namespace B { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceAnonVsNamed) {
+  auto Decls = makeNamedDecls("namespace { class X; }",
+  "namespace N { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNoVsAnon) {
+  auto Decls =
+  makeNamedDecls("class X;", "namespace { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceAnonVsAnon) {
+  auto Decls = makeNamedDecls("namespace { class X; }",
+  "namespace { class X; }", Lang_CXX03, "X");
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceAnonVsAnonAnon) {
+  auto Decls =
+  makeNamedDecls("namespace { class X; }",
+ "namespace { namespace { class X; } }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest,
+   NamespaceNamedNamedVsNamedNamed) {
+  auto Decls = makeNamedDecls("namespace A { namespace N { class X; } }",
+  "namespace B { namespace N { class X; } }",
+  Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNamedVsInline) {
+  auto Decls = makeNamedDecls("namespace A { namespace A { class X; } }",
+  "namespace A { inline namespace A { class X; } }",
+  Lang_CXX17, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceInlineVsInline) {
+  auto Decls = makeNamedDecls("namespace A { inline namespace A { class X; } }",
+  "namespace A { inline namespace B { class X; } }",
+  Lang_CXX17, "X");
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceInlineTopLevel) {
+  auto Decls =
+  makeNamedDecls("inline namespace A { class X; } }",
+ "inline namespace B { class X; } }", Lang_CXX17, "X");
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, TransparentContext) {
+  auto Decls =
+  makeNamedDecls("extern \"C\" { class X; }", "class X;", Lang_CXX03, "X");
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, TransparentContextNE) {
+  auto Decls = makeNamedDecls("extern \"C\" { class X; }",
+  "namespace { class X; }", Lang_CXX03, "X");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceRecordContextTest, TransparentContextInNamespace) {
+  auto Decls = makeNamedDecls("extern \"C\" { namespace N { class X; } }",
+  "namespace N { extern \"C\" { class X; } }",
+  Lang_CXX03, "X");
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceTest, NamespaceOfRecordMember) {
+  auto Decls = makeNamedDecls(
+  R"(
+  class X;
+  class Y { X* x; };
+  )",
+  R"(
+  namespace N { class X; }
+  class Y { N::X* x; };
+  )",
+  Lang_CXX03, "Y");
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceTest, StructDefinitionInPrototype) {
+  auto Decls =
+  makeNamedDecls("struct Param { int a; }; void foo(struct Param *p);",
+ "void foo(struct Param { int a; } *p);", Lang_C89);
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}
+
+TEST_F(StructuralEquivalenceTest,

[PATCH] D113118: [clang][AST] Check context of record in structural equivalence.

2021-11-25 Thread Balázs Kéri via Phabricator via cfe-commits

balazske reopened this revision.
balazske added a comment.
This revision is now accepted and ready to land.

Windows test failures occurred because wrong AST matchers in the tests. Tests 
will be updated to use named match.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113118/new/

https://reviews.llvm.org/D113118

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

1 2 >

1 - 100 of 131 matches

Mail list logo