date:20211125

[clang] 8804d08 - Revert "[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-25T09:31:41+01:00
New Revision: 8804d08e9921b86eb96e993af5d753f63f3c8829

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

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

Revert commit 6b96b2a0bf65ff838d4dbf909a5120d4d1083e29 because Windows
test failure.

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 7fd24e2aa9ad2..e85feb779190f 100644
--- a/clang/lib/AST/ASTStructuralEquivalence.cpp
+++ b/clang/lib/AST/ASTStructuralEquivalence.cpp
@@ -1347,42 +1347,6 @@ 
IsStructurallyEquivalentLambdas(StructuralEquivalenceContext &Context,
   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 &Context,
  RecordDecl *D1, RecordDecl *D2) {
@@ -1422,12 +1386,6 @@ static bool 
IsStructurallyEquivalent(StructuralEquivalenceContext &Context,
 }
   }
 
-  // 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 2f5b5c1460950..9ae0da8b9dd2c 100644
--- a/clang/unittests/AST/StructuralEquivalenceTest.cpp
+++ b/clang/unittests/AST/StructuralEquivalenceTest.cpp
@@ -929,136 +929,6 @@ TEST_F(StructuralEquivalenceTest, ExplicitBoolSame) {
   EXPECT_TRUE(testStructuralMatch(First, Second));
 }
 
-struct StructuralEquivalenceRecordContextTest : StructuralEquivalenceTest {};
-
-TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNoVsNamed) {
-  auto Decls = makeDecls("class X;", "namespace N { class X; }",
-Lang_CXX03, cxxRecordDecl());
-  EXPECT_FALSE(testStructuralMatch(Decls));
-}
-
-TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNamedVsNamed) {
-  auto Decls = makeDecls("namespace A { class X; }",
-"namespace B { class X; }", Lang_CXX03,
-cxxRecordDecl());
-  EXPECT_FALSE(testStructuralMatch(Decls));
-}
-
-TEST_F(StructuralEquivalenceRecordContextTest, NamespaceAnonVsNamed) {
-  auto Decls = makeDecls("namespace { class X; }",
-"namespace N { class X; }", Lang_CXX03,
-cxxRecordDecl());
-  EXPECT_FALSE(testStructuralMatch(Decls));
-}
-
-TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNoVsAnon) {
-  auto Decls = makeDecls("class X;", "namespace { class X; }",
-Lang_CXX03, cxxRecordDecl());
-  EXPECT_FALSE(testStructuralMatch(Decls));
-}
-
-TEST_F(StructuralEquivalenceRecordContextTest, NamespaceAnonVsAnon) {
-  auto Decls = makeDecls("namespace { class X; }",
-

[PATCH] D114521: [clang-format] [PR47936] AfterControlStatement: MultiLine breaks AllowShortFunctionsOnASingleLine

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

MyDeveloperDay added a comment.

The if/for/while case is way more involved and requires a change in a separate 
piece of code, I'm going to land this and we can handle 52598 separately


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114521

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

[PATCH] D114539: [clang-tidy] performance-unnecessary-copy-initialization: handle pointer containers.

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

courbet updated this revision to Diff 389667.
courbet added a comment.

Add more comments on the approach.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114539

Files:
  clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
  clang-tools-extra/clang-tidy/utils/DeclRefExprUtils.cpp
  
clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-copy-initialization.cpp
  clang-tools-extra/unittests/clang-tidy/DeclRefExprUtilsTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/DeclRefExprUtilsTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/DeclRefExprUtilsTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/DeclRefExprUtilsTest.cpp
@@ -101,23 +101,23 @@
 void f(const S target) {
   useVal(/*const*/target);
   useConstRef(/*const*/target);
-  useConstPtr(&target);
-  useConstPtrConstRef(&target);
+  useConstPtr(&/*const*/target);
+  useConstPtrConstRef(&/*const*/target);
   /*const*/target.constMethod();
   /*const*/target(ConstTag{});
   /*const*/target[42];
   useConstRef((/*const*/target));
   (/*const*/target).constMethod();
   (void)(/*const*/target == /*const*/target);
-  (void)target;
-  (void)⌖
-  (void)*⌖
+  (void)/*const*/target;
+  (void)&/*const*/target;
+  (void)*&/*const*/target;
   S copy1 = /*const*/target;
   S copy2(/*const*/target);
-  useInt(target.int_member);
-  useIntConstRef(target.int_member);
+  useInt(/*const*/target.int_member);
+  useIntConstRef(/*const*/target.int_member);
   useIntPtr(target.ptr_member);
-  useIntConstPtr(&target.int_member);
+  useIntConstPtr(&/*const*/target.int_member);
 }
 )");
 }
@@ -127,23 +127,23 @@
 void f(const S& target) {
   useVal(/*const*/target);
   useConstRef(/*const*/target);
-  useConstPtr(&target);
-  useConstPtrConstRef(&target);
+  useConstPtr(&/*const*/target);
+  useConstPtrConstRef(&/*const*/target);
   /*const*/target.constMethod();
   /*const*/target(ConstTag{});
   /*const*/target[42];
   useConstRef((/*const*/target));
   (/*const*/target).constMethod();
   (void)(/*const*/target == /*const*/target);
-  (void)target;
-  (void)⌖
-  (void)*⌖
+  (void)/*const*/target;
+  (void)&/*const*/target;
+  (void)*&/*const*/target;
   S copy1 = /*const*/target;
   S copy2(/*const*/target);
-  useInt(target.int_member);
-  useIntConstRef(target.int_member);
+  useInt(/*const*/target.int_member);
+  useIntConstRef(/*const*/target.int_member);
   useIntPtr(target.ptr_member);
-  useIntConstPtr(&target.int_member);
+  useIntConstPtr(&/*const*/target.int_member);
 }
 )");
 }
@@ -153,8 +153,8 @@
 void f(S target, const S& other) {
   useConstRef(/*const*/target);
   useVal(/*const*/target);
-  useConstPtr(&target);
-  useConstPtrConstRef(&target);
+  useConstPtr(&/*const*/target);
+  useConstPtrConstRef(&/*const*/target);
   /*const*/target.constMethod();
   target.nonConstMethod();
   /*const*/target(ConstTag{});
@@ -167,15 +167,15 @@
   (/*const*/target).constMethod();
   (void)(/*const*/target == /*const*/target);
   (void)(/*const*/target == other);
-  (void)target;
-  (void)⌖
-  (void)*⌖
+  (void)/*const*/target;
+  (void)&/*const*/target;
+  (void)*&/*const*/target;
   S copy1 = /*const*/target;
   S copy2(/*const*/target);
-  useInt(target.int_member);
-  useIntConstRef(target.int_member);
+  useInt(/*const*/target.int_member);
+  useIntConstRef(/*const*/target.int_member);
   useIntPtr(target.ptr_member);
-  useIntConstPtr(&target.int_member);
+  useIntConstPtr(&/*const*/target.int_member);
 }
 )");
 }
@@ -185,8 +185,8 @@
 void f(S& target) {
   useVal(/*const*/target);
   useConstRef(/*const*/target);
-  useConstPtr(&target);
-  useConstPtrConstRef(&target);
+  useConstPtr(&/*const*/target);
+  useConstPtrConstRef(&/*const*/target);
   /*const*/target.constMethod();
   target.nonConstMethod();
   /*const*/target(ConstTag{});
@@ -194,15 +194,15 @@
   useConstRef((/*const*/target));
   (/*const*/target).constMethod();
   (void)(/*const*/target == /*const*/target);
-  (void)target;
-  (void)⌖
-  (void)*⌖
+  (void)/*const*/target;
+  (void)&/*const*/target;
+  (void)*&/*const*/target;
   S copy1 = /*const*/target;
   S copy2(/*const*/target);
-  useInt(target.int_member);
-  useIntConstRef(target.int_member);
+  useInt(/*const*/target.int_member);
+  useIntConstRef(/*const*/target.int_member);
   useIntPtr(target.ptr_member);
-  useIntConstPtr(&target.int_member);
+  useIntConstPtr(&/*const*/target.int_member);

[clang] 72e4f4a - [clang-format] [PR47936] AfterControlStatement: MultiLine breaks AllowShortFunctionsOnASingleLine

2021-11-25 Thread via cfe-commits


Author: mydeveloperday
Date: 2021-11-25T08:30:31Z
New Revision: 72e4f4a2a117f97118692857d91210fc62c066b0

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

LOG: [clang-format] [PR47936] AfterControlStatement: MultiLine breaks 
AllowShortFunctionsOnASingleLine

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

Using the MultiLine setting for BraceWrapping.AfterControlStatement appears to 
disable AllowShortFunctionsOnASingleLine, even in cases without any control 
statements

Reviewed By: HazardyKnusperkeks, curdeius

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

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 299536cd806eb..516b1bcac314c 100644
--- a/clang/lib/Format/UnwrappedLineFormatter.cpp
+++ b/clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -676,7 +676,7 @@ class LineJoiner {
 // { <-- current Line
 //   baz();
 // }
-if (Line.First == Line.Last &&
+if (Line.First == Line.Last && Line.First->isNot(TT_FunctionLBrace) &&
 Style.BraceWrapping.AfterControlStatement ==
 FormatStyle::BWACS_MultiLine)
   return 0;

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 8c8d7a465c795..096d6a32ecfce 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -2860,6 +2860,19 @@ TEST_F(FormatTest, MultiLineControlStatements) {
 "  baz();\n"
 "}",
 format("try{foo();}catch(...){baz();}", Style));
+
+  Style.BraceWrapping.AfterFunction = true;
+  Style.BraceWrapping.AfterControlStatement = FormatStyle::BWACS_MultiLine;
+  Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_All;
+  Style.ColumnLimit = 80;
+  verifyFormat("void shortfunction() { bar(); }", Style);
+
+  Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
+  verifyFormat("void shortfunction()\n"
+   "{\n"
+   "  bar();\n"
+   "}",
+   Style);
 }
 
 TEST_F(FormatTest, BeforeWhile) {



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

[PATCH] D114521: [clang-format] [PR47936] AfterControlStatement: MultiLine breaks AllowShortFunctionsOnASingleLine

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

This revision was automatically updated to reflect the committed changes.
Closed by commit rG72e4f4a2a117: [clang-format] [PR47936] 
AfterControlStatement: MultiLine breaks… (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114521

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
@@ -2860,6 +2860,19 @@
 "  baz();\n"
 "}",
 format("try{foo();}catch(...){baz();}", Style));
+
+  Style.BraceWrapping.AfterFunction = true;
+  Style.BraceWrapping.AfterControlStatement = FormatStyle::BWACS_MultiLine;
+  Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_All;
+  Style.ColumnLimit = 80;
+  verifyFormat("void shortfunction() { bar(); }", Style);
+
+  Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
+  verifyFormat("void shortfunction()\n"
+   "{\n"
+   "  bar();\n"
+   "}",
+   Style);
 }
 
 TEST_F(FormatTest, BeforeWhile) {
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -676,7 +676,7 @@
 // { <-- current Line
 //   baz();
 // }
-if (Line.First == Line.Last &&
+if (Line.First == Line.Last && Line.First->isNot(TT_FunctionLBrace) &&
 Style.BraceWrapping.AfterControlStatement ==
 FormatStyle::BWACS_MultiLine)
   return 0;


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -2860,6 +2860,19 @@
 "  baz();\n"
 "}",
 format("try{foo();}catch(...){baz();}", Style));
+
+  Style.BraceWrapping.AfterFunction = true;
+  Style.BraceWrapping.AfterControlStatement = FormatStyle::BWACS_MultiLine;
+  Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_All;
+  Style.ColumnLimit = 80;
+  verifyFormat("void shortfunction() { bar(); }", Style);
+
+  Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
+  verifyFormat("void shortfunction()\n"
+   "{\n"
+   "  bar();\n"
+   "}",
+   Style);
 }
 
 TEST_F(FormatTest, BeforeWhile) {
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -676,7 +676,7 @@
 // { <-- current Line
 //   baz();
 // }
-if (Line.First == Line.Last &&
+if (Line.First == Line.Last && Line.First->isNot(TT_FunctionLBrace) &&
 Style.BraceWrapping.AfterControlStatement ==
 FormatStyle::BWACS_MultiLine)
   return 0;
___
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 updated this revision to Diff 389678.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114326

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
@@ -127,7 +127,8 @@
   SmallVector Candidates;
 
   // In decreasing order so we prefer newer versions to older versions.
-  std::initializer_list Versions = {"8.0", "7.5", "7.0"};
+  std::initializer_list Versions = {
+  "11.5", "11.4", "11.3", "11.2", "11.1", "11.0", "10.2", "10.1", "10.0"};
   auto &FS = D.getVFS();
 
   if (Args.hasArg(clang::driver::options::OPT_cuda_path_EQ)) {


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -127,7 +127,8 @@
   SmallVector Candidates;
 
   // In decreasing order so we prefer newer versions to older versions.
-  std::initializer_list Versions = {"8.0", "7.5", "7.0"};
+  std::initializer_list Versions = {
+  "11.5", "11.4", "11.3", "11.2", "11.1", "11.0", "10.2", "10.1", "10.0"};
   auto &FS = D.getVFS();
 
   if (Args.hasArg(clang::driver::options::OPT_cuda_path_EQ)) {
___
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

MyDeveloperDay updated this revision to Diff 389679.
MyDeveloperDay marked 3 inline comments as done.
MyDeveloperDay added a comment.

Add more test combinations


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 @@
   verifyFormat("Foo::operator&(void&);", Style);
   verifyFormat("Foo::operator&();", Style);
   verifyFormat("operator

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

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

MyDeveloperDay updated this revision to Diff 389682.
MyDeveloperDay marked 3 inline comments as done.
MyDeveloperDay added a comment.

Address review comments, guard against eof


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
@@ -22610,6 +22610,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 @@
 addUnwrappedLine();
 return;
   }
+  if (Style.isCpp()) {
+

[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 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

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.


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] D114519: [clang-format] [PR52595] clang-format does not recognize rvalue references to array

2021-11-25 Thread Marek Kurdej via Phabricator via cfe-commits

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

LGTM.


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

https://reviews.llvm.org/D114519

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

[PATCH] D114080: [SYCL] Diagnose uses of zero length arrays

2021-11-25 Thread Alexey Bader via Phabricator via cfe-commits

bader added a comment.

LGTM, with a couple of minor suggestions.




Comment at: clang/lib/Sema/SemaSYCL.cpp:68-75
+bool ErrorFound = false;
+if (isZeroSizedArray(*this, TypeToCheck)) {
+  SYCLDiagIfDeviceCode(UsedAt, diag::err_sycl_zero_array_size);
+  ErrorFound = true;
+}
+// Checks for other types can also be done here.
+if (ErrorFound) {





Comment at: clang/lib/Sema/SemaSYCL.cpp:125
+
+// In case pointer/array/reference type is met get pointeetype, then 
proceed
+// with that type.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114080

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

[PATCH] D113251: [analyzer][doc] Add user documenation for taint analysis

2021-11-25 Thread Endre Fülöp via Phabricator via cfe-commits

gamesh411 updated this revision to Diff 389684.
gamesh411 added a comment.

update with `arc diff $(git merge-base HEAD upstream) --update D113251`
in order to satisfy workflow `pre-merge checks`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113251

Files:
  clang/docs/analyzer/checkers.rst
  clang/docs/analyzer/user-docs.rst
  clang/docs/analyzer/user-docs/TaintAnalysisConfiguration.rst

Index: clang/docs/analyzer/user-docs/TaintAnalysisConfiguration.rst
===
--- /dev/null
+++ clang/docs/analyzer/user-docs/TaintAnalysisConfiguration.rst
@@ -0,0 +1,170 @@
+
+Taint Analysis Configuration
+
+
+The Clang Static Analyzer uses taint analysis to detect security-related issues in code.
+The backbone of taint analysis in the Clang SA is the `GenericTaintChecker`, which the user can access via the :ref:`alpha-security-taint-TaintPropagation` checker alias and this checker has a default taint-related configuration.
+The built-in default settings are defined in code, and they are always in effect once the checker is enabled, either directly or via the alias.
+The checker also provides a configuration interface for extending the default settings by providing a configuration file in `YAML `_ format.
+This documentation describes the syntax of the configuration file and gives the informal semantics of the configuration options.
+
+.. contents::
+   :local:
+
+.. _clangsa-taint-configuration-overview:
+
+Overview
+
+
+Taint analysis works by checking for the occurrence of special operations during the symbolic execution of the program.
+Taint analysis defines sources, sinks, and propagation rules. It identifies errors by detecting a flow of information that originates from a taint source, reaches a taint sink, and propagates through the program paths via propagation rules.
+A source, sink, or an operation that propagates taint is mainly domain-specific knowledge, but there are some built-in defaults provided by :ref:`alpha-security-taint-TaintPropagation`.
+It is possible to express that a statement sanitizes tainted values by providing a ``Filters`` section in the external configuration (see :ref:`clangsa-taint-configuration-example` and :ref:`clangsa-taint-filter-details`).
+There are no default filters defined in the built-in settings.
+The checker's documentation also specifies how to provide a custom taint configuration with command-line options.
+
+.. _clangsa-taint-configuration-example:
+
+Example configuration file
+__
+
+.. code-block:: yaml
+
+  # The entries that specify arguments use 0-based indexing when specifying
+  # input arguments, and -1 is used to denote the return value.
+
+  Filters:
+# Filter functions
+# Taint is sanitized when tainted variables are pass arguments to filters.
+
+# Filter function
+#   void cleanse_first_arg(int* arg)
+#
+# Result example:
+#   int x; // x is tainted
+#   cleanse_first_arg(&x); // x is not tainted after the call
+- Name: cleanse_first_arg
+  Args: [0]
+
+  Propagations:
+# Source functions
+# The omission of SrcArgs key indicates unconditional taint propagation,
+# which is conceptually what a source does.
+
+# Source function
+#   size_t fread(void *ptr, size_t size, size_t nmemb, FILE * stream)
+#
+# Result example:
+#   FILE* f = fopen("file.txt");
+#   char buf[1024];
+#   size_t read = fread(buf, sizeof(buf[0]), sizeof(buf)/sizeof(buf[0]), f);
+#   // both read and buf are tainted
+- Name: fread
+  DstArgs: [0, -1]
+
+# Propagation functions
+# The presence of SrcArgs key indicates conditional taint propagation,
+# which is conceptually what a propagator does.
+
+# Propagation function
+#   char *dirname(char *path)
+#
+# Result example:
+#   char* path = read_path();
+#   char* dir = dirname(path);
+#   // dir is tainted if path was tainted
+- Name: dirname
+  SrcArgs: [0]
+  DstArgs: [-1]
+
+  Sinks:
+# Sink functions
+# If taint reaches any of the arguments specified, a warning is emitted.
+
+# Sink function
+#   int system(const char* command)
+#
+# Result example:
+#   const char* command = read_command();
+#   system(command); // emit diagnostic if command is tainted
+- Name: system
+  Args: [0]
+
+In the example file above, the entries under the `Propagation` key implement the conceptual sources and propagations, and sinks have their dedicated `Sinks` key.
+The user can define operations (function calls) where the tainted values should be cleansed by listing entries under the `Filters` key.
+Filters model the sanitization of values done by the programmer, and providing these is key t

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

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

carlosgalvezp accepted this revision.
carlosgalvezp added a comment.

LGTM but I think @tra should have the final word.




Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:131
+  std::initializer_list Versions = {
+  "11.5", "11.4", "11.3", "11.2", "11.1", "11.0", "10.2", "10.1",
+  "10.0", "9.2",  "9.1",  "9.0",  "8.0",  "7.5",  "7.0"};

tra wrote:
> carlosgalvezp wrote:
> > mojca wrote:
> > > tra wrote:
> > > > tra wrote:
> > > > > mojca wrote:
> > > > > > carlosgalvezp wrote:
> > > > > > > mojca wrote:
> > > > > > > > tra wrote:
> > > > > > > > > tra wrote:
> > > > > > > > > > mojca wrote:
> > > > > > > > > > > kadircet wrote:
> > > > > > > > > > > > looks like the list is getting big and hard to 
> > > > > > > > > > > > maintain. considering that this is done only once per 
> > > > > > > > > > > > compiler invocation (and we check for existence of 
> > > > > > > > > > > > directories down in the loop anyway). what about 
> > > > > > > > > > > > throwing in an extra directory listing to 
> > > > > > > > > > > > base-directories mentioned down below and populate 
> > > > > > > > > > > > `Candidates` while preserving the newest-version-first 
> > > > > > > > > > > > order?
> > > > > > > > > > > I totally agree with the sentiment, and that was my 
> > > > > > > > > > > initial thought as well, but with zero experience I was 
> > > > > > > > > > > too scared to make any more significant changes.
> > > > > > > > > > > 
> > > > > > > > > > > I can try to come up with a new patch (that doesn't need 
> > > > > > > > > > > further maintenance whenever a new CUDA version gets 
> > > > > > > > > > > released) if that's what you are suggesting. I would 
> > > > > > > > > > > nevertheless merge this one, and prepare a new more 
> > > > > > > > > > > advanced patch separately, but that's finally your call.
> > > > > > > > > > > 
> > > > > > > > > > > What's your suggestion about D.SysRoot + "Program 
> > > > > > > > > > > Files/..."? At the time when this function gets called it 
> > > > > > > > > > > looks like D.SysRoot is empty (or at least my debugger 
> > > > > > > > > > > says so) and in my case it resolves to D: while the CUDA 
> > > > > > > > > > > support is installed under C:.
> > > > > > > > > > > 
> > > > > > > > > > > Is there any special LLVM-specific/preferrable way to 
> > > > > > > > > > > iterate through directories?
> > > > > > > > > > > 
> > > > > > > > > > > (What I also miss a bit in the whole process in an option 
> > > > > > > > > > > to simply say "I want CUDA 11.1" without the need to 
> > > > > > > > > > > explicitly spell out the full path.)
> > > > > > > > > > > 
> > > > > > > > > > > If you provide me give some general guidelines, I'll 
> > > > > > > > > > > prepare another, hopefully more future-proof patch.
> > > > > > > > > > > 
> > > > > > > > > > > (Side note: I'm not sure if I'm calling clang-format 
> > > > > > > > > > > correctly, but if I call it, it keeps reformatting the 
> > > > > > > > > > > rest of this file.)
> > > > > > > > > > This whole list may no longer be particularly useful. The 
> > > > > > > > > > most common use case on Linux, AFAICT, is to install only 
> > > > > > > > > > one CUDA version using system-provided package manager.
> > > > > > > > > > E.g. 
> > > > > > > > > > https://packages.ubuntu.com/focal/amd64/nvidia-cuda-toolkit/filelist
> > > > > > > > > > 
> > > > > > > > > > TBH, I'm tempted to limit autodetection to only that one 
> > > > > > > > > > system-default version and require user to use --cuda-path 
> > > > > > > > > > if they need something else.
> > > > > > > > > I think on windows (I mean the windows environment itself, 
> > > > > > > > > not WSL), CUDA installer sets an environment variable which 
> > > > > > > > > could be used to detect the default CUDA version, so it may 
> > > > > > > > > warrant a windows-specific way to find it. 
> > > > > > > > On Windows this is certainly not the case. Unless the 
> > > > > > > > installation is changed manually, one always gets the new 
> > > > > > > > version installed into a new directory.
> > > > > > > > 
> > > > > > > > I really do need multiple versions on Windows (and the ability 
> > > > > > > > to pick an older one) if I want to compile a binary that works 
> > > > > > > > on someone else's computer (if I compile against the latest 
> > > > > > > > CUDA, users need "the latest" drivers that may sometimes not 
> > > > > > > > even be available for their machine).
> > > > > > > > 
> > > > > > > > (That said, at least when using CMake, the selection needs to 
> > > > > > > > be done by CMake anyway, and maybe CMake could be forced to 
> > > > > > > > specify the correct flag automatically.)
> > > > > > > > 
> > > > > > > > So even if the functionality gets removed from non-Windows 
> > > > > > > > platforms, it would be really nice to keep it for Windows.
> > > > > > > > 
> > > > > > > > Now, there are three "conflicting" feedbacks/suggestions above. 
>

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

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

lichray added inline comments.



Comment at: clang/lib/Format/TokenAnnotator.cpp:317
 // void (&FunctionReference)(void);
 // void (^ObjCBlock)(void);
 bool MightBeFunctionType = !Contexts[Contexts.size() - 2].IsExpression;

Code does not match comment.


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

https://reviews.llvm.org/D114519

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

[PATCH] D114539: [clang-tidy] performance-unnecessary-copy-initialization: handle pointer containers.

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

courbet updated this revision to Diff 389690.
courbet marked an inline comment as done.
courbet added a comment.

address comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114539

Files:
  clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
  clang-tools-extra/clang-tidy/utils/DeclRefExprUtils.cpp
  
clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-copy-initialization.cpp
  clang-tools-extra/unittests/clang-tidy/DeclRefExprUtilsTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/DeclRefExprUtilsTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/DeclRefExprUtilsTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/DeclRefExprUtilsTest.cpp
@@ -101,23 +101,23 @@
 void f(const S target) {
   useVal(/*const*/target);
   useConstRef(/*const*/target);
-  useConstPtr(&target);
-  useConstPtrConstRef(&target);
+  useConstPtr(&/*const*/target);
+  useConstPtrConstRef(&/*const*/target);
   /*const*/target.constMethod();
   /*const*/target(ConstTag{});
   /*const*/target[42];
   useConstRef((/*const*/target));
   (/*const*/target).constMethod();
   (void)(/*const*/target == /*const*/target);
-  (void)target;
-  (void)⌖
-  (void)*⌖
+  (void)/*const*/target;
+  (void)&/*const*/target;
+  (void)*&/*const*/target;
   S copy1 = /*const*/target;
   S copy2(/*const*/target);
-  useInt(target.int_member);
-  useIntConstRef(target.int_member);
+  useInt(/*const*/target.int_member);
+  useIntConstRef(/*const*/target.int_member);
   useIntPtr(target.ptr_member);
-  useIntConstPtr(&target.int_member);
+  useIntConstPtr(&/*const*/target.int_member);
 }
 )");
 }
@@ -127,23 +127,23 @@
 void f(const S& target) {
   useVal(/*const*/target);
   useConstRef(/*const*/target);
-  useConstPtr(&target);
-  useConstPtrConstRef(&target);
+  useConstPtr(&/*const*/target);
+  useConstPtrConstRef(&/*const*/target);
   /*const*/target.constMethod();
   /*const*/target(ConstTag{});
   /*const*/target[42];
   useConstRef((/*const*/target));
   (/*const*/target).constMethod();
   (void)(/*const*/target == /*const*/target);
-  (void)target;
-  (void)⌖
-  (void)*⌖
+  (void)/*const*/target;
+  (void)&/*const*/target;
+  (void)*&/*const*/target;
   S copy1 = /*const*/target;
   S copy2(/*const*/target);
-  useInt(target.int_member);
-  useIntConstRef(target.int_member);
+  useInt(/*const*/target.int_member);
+  useIntConstRef(/*const*/target.int_member);
   useIntPtr(target.ptr_member);
-  useIntConstPtr(&target.int_member);
+  useIntConstPtr(&/*const*/target.int_member);
 }
 )");
 }
@@ -153,8 +153,8 @@
 void f(S target, const S& other) {
   useConstRef(/*const*/target);
   useVal(/*const*/target);
-  useConstPtr(&target);
-  useConstPtrConstRef(&target);
+  useConstPtr(&/*const*/target);
+  useConstPtrConstRef(&/*const*/target);
   /*const*/target.constMethod();
   target.nonConstMethod();
   /*const*/target(ConstTag{});
@@ -167,15 +167,15 @@
   (/*const*/target).constMethod();
   (void)(/*const*/target == /*const*/target);
   (void)(/*const*/target == other);
-  (void)target;
-  (void)⌖
-  (void)*⌖
+  (void)/*const*/target;
+  (void)&/*const*/target;
+  (void)*&/*const*/target;
   S copy1 = /*const*/target;
   S copy2(/*const*/target);
-  useInt(target.int_member);
-  useIntConstRef(target.int_member);
+  useInt(/*const*/target.int_member);
+  useIntConstRef(/*const*/target.int_member);
   useIntPtr(target.ptr_member);
-  useIntConstPtr(&target.int_member);
+  useIntConstPtr(&/*const*/target.int_member);
 }
 )");
 }
@@ -185,8 +185,8 @@
 void f(S& target) {
   useVal(/*const*/target);
   useConstRef(/*const*/target);
-  useConstPtr(&target);
-  useConstPtrConstRef(&target);
+  useConstPtr(&/*const*/target);
+  useConstPtrConstRef(&/*const*/target);
   /*const*/target.constMethod();
   target.nonConstMethod();
   /*const*/target(ConstTag{});
@@ -194,15 +194,15 @@
   useConstRef((/*const*/target));
   (/*const*/target).constMethod();
   (void)(/*const*/target == /*const*/target);
-  (void)target;
-  (void)⌖
-  (void)*⌖
+  (void)/*const*/target;
+  (void)&/*const*/target;
+  (void)*&/*const*/target;
   S copy1 = /*const*/target;
   S copy2(/*const*/target);
-  useInt(target.int_member);
-  useIntConstRef(target.int_member);
+  useInt(/*const*/target.int_member);
+  useIntConstRef(/*const*/target.int_member);
   useIntPtr(target.ptr_member);
-  useIntConstPtr(&target.int_member);
+  useIntConstPtr(&/*cons

[clang-tools-extra] cdd37e2 - [clangd] Disable hicpp-invalid-access-moved inside clangd

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


Author: Kadir Cetinkaya
Date: 2021-11-25T10:27:45+01:00
New Revision: cdd37e2e47f757d2130f741d8e720098bf920c40

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

LOG: [clangd] Disable hicpp-invalid-access-moved inside clangd

Added: 


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

Removed: 




diff  --git a/clang-tools-extra/clangd/TidyProvider.cpp 
b/clang-tools-extra/clangd/TidyProvider.cpp
index 7573645eeefd4..eea5b062b849b 100644
--- a/clang-tools-extra/clangd/TidyProvider.cpp
+++ b/clang-tools-extra/clangd/TidyProvider.cpp
@@ -213,7 +213,9 @@ TidyProvider 
disableUnusableChecks(llvm::ArrayRef ExtraBadChecks) {
// Check can choke on invalid (intermediate) c++
// code, which is often the case when clangd
// tries to build an AST.
-   "-bugprone-use-after-move");
+   "-bugprone-use-after-move",
+   // Alias for bugprone-use-after-moe.
+   "-hicpp-invalid-access-moved");
 
   size_t Size = BadChecks.size();
   for (const std::string &Str : ExtraBadChecks) {



___
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 added a comment.

Yes, I think the new approach is what we want. The comments also make it much 
clearer.




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

Can you add a test with:

```

void takesInt(int);

...

takesInt(x.id);
```

I think this suffers from the same problem currently.


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] 3e67cf2 - [clang][driver] Add -fplugin-arg- to pass arguments to plugins

2021-11-25 Thread Timm Bäder via cfe-commits


Author: Timm Bäder
Date: 2021-11-25T10:47:55+01:00
New Revision: 3e67cf21a19a0e8917bdbab6f0cecd4880f3fbe2

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

LOG: [clang][driver] Add -fplugin-arg- to pass arguments to plugins

From GCC's manpage:
-fplugin-arg-name-key=value
   Define an argument called key with a value of value for the
   plugin called name.

Since we don't have a key-value pair similar to gcc's plugin_argument
struct, simply accept key=value here anyway and pass it along as-is to
plugins.

This translates to the already existing '-plugin-arg-pluginname arg'
that clang cc1 accepts.

There is an ambiguity here because in clang, both the plugin name
as well as the option name can contain dashes, so when e.g. passing

 -fplugin-arg-foo-bar-foo

it is not clear whether the plugin is foo-bar and the option is foo,
or the plugin is foo and the option is bar-foo. GCC solves this by
interpreting all dashes as part of the option name. So dashes can't be
part of the plugin name in this case.

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

Added: 
clang/test/Driver/plugin-driver-args.cpp

Modified: 
clang/docs/ClangPlugins.rst
clang/docs/ReleaseNotes.rst
clang/examples/CallSuperAttribute/CallSuperAttrInfo.cpp
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Frontend/plugin-call-super.cpp

Removed: 




diff  --git a/clang/docs/ClangPlugins.rst b/clang/docs/ClangPlugins.rst
index 3183eec1823d6..cf2c8721c12ae 100644
--- a/clang/docs/ClangPlugins.rst
+++ b/clang/docs/ClangPlugins.rst
@@ -125,6 +125,28 @@ Running the plugin
 ==
 
 
+Using the compiler driver
+--
+
+The Clang driver accepts the `-fplugin` option to load a plugin.
+Clang plugins can receive arguments from the compiler driver command
+line via the `fplugin-arg--` option. Using this
+method, the plugin name cannot contain dashes itself, but the argument
+passed to the plugin can.
+
+
+.. code-block:: console
+
+  $ export BD=/path/to/build/directory
+  $ make -C $BD CallSuperAttr
+  $ clang++ -fplugin=$BD/lib/CallSuperAttr.so \
+-fplugin-arg-call_super_plugin-help \
+test.cpp
+
+If your plugin name contains dashes, either rename the plugin or used the
+cc1 command line options listed below.
+
+
 Using the cc1 command line
 --
 

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 104d2e908d809..df2a6e71c534b 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -62,7 +62,8 @@ Non-comprehensive list of changes in this release
 New Compiler Flags
 --
 
-- ...
+- Clang plugin arguments can now be passed through the compiler driver via
+  ``-fplugin-arg-pluginname-arg``, similar to GCC's ``-fplugin-arg``.
 
 Deprecated Compiler Flags
 -

diff  --git a/clang/examples/CallSuperAttribute/CallSuperAttrInfo.cpp 
b/clang/examples/CallSuperAttribute/CallSuperAttrInfo.cpp
index 331f63508045b..21460e4f6bd06 100644
--- a/clang/examples/CallSuperAttribute/CallSuperAttrInfo.cpp
+++ b/clang/examples/CallSuperAttribute/CallSuperAttrInfo.cpp
@@ -145,6 +145,8 @@ class CallSuperAction : public PluginASTAction {
 
   bool ParseArgs(const CompilerInstance &CI,
  const std::vector &args) override {
+if (!args.empty() && args[0] == "help")
+  llvm::errs() << "Help for the CallSuperAttr plugin goes here\n";
 return true;
   }
 

diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index ff8c36910e13e..74dbb3d98a864 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -189,6 +189,12 @@ def err_drv_invalid_mtp : Error<
   "invalid thread pointer reading mode '%0'">;
 def err_drv_missing_arg_mtp : Error<
   "missing argument to '%0'">;
+def warn_drv_missing_plugin_name : Warning<
+  "missing plugin name in %0">,
+  InGroup;
+def warn_drv_missing_plugin_arg : Warning<
+  "missing plugin argument for plugin %0 in %1">,
+  InGroup;
 def err_drv_invalid_libcxx_deployment : Error<
   "invalid deployment target for -stdlib=libc++ (requires %0 or later)">;
 def err_drv_invalid_argument_to_option : Error<

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 7730b7d1915e4..cf314bc73bf31 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2504,6 +2504,9 @@ defm rwpi : BoolFOption<"rwpi",
   NegFlag>;
 def fplugin_EQ : Joined<["-"], "fplugin=">, Group, 
Flags<[NoXarchOption]>, MetaVarName<"">,
   HelpText

[PATCH] D113250: [clang][driver] Add -fplugin-arg- to pass arguments to plugins

2021-11-25 Thread Timm Bäder via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3e67cf21a19a: [clang][driver] Add -fplugin-arg- to pass 
arguments to plugins (authored by tbaeder).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113250

Files:
  clang/docs/ClangPlugins.rst
  clang/docs/ReleaseNotes.rst
  clang/examples/CallSuperAttribute/CallSuperAttrInfo.cpp
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/plugin-driver-args.cpp
  clang/test/Frontend/plugin-call-super.cpp

Index: clang/test/Frontend/plugin-call-super.cpp
===
--- clang/test/Frontend/plugin-call-super.cpp
+++ clang/test/Frontend/plugin-call-super.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang -fplugin=%llvmshlibdir/CallSuperAttr%pluginext -fsyntax-only -Xclang -verify=callsuper %s
-// RUN: %clang -fplugin=%llvmshlibdir/CallSuperAttr%pluginext -DBAD_CALLSUPER -fsyntax-only -Xclang -verify=badcallsuper %s
+// RUN: %clang_cc1 -load %llvmshlibdir/CallSuperAttr%pluginext -fsyntax-only -verify=callsuper %s
+// RUN: %clang_cc1 -load %llvmshlibdir/CallSuperAttr%pluginext -DBAD_CALLSUPER -fsyntax-only -verify=badcallsuper %s
 // REQUIRES: plugins, examples
 
 // callsuper-no-diagnostics
Index: clang/test/Driver/plugin-driver-args.cpp
===
--- /dev/null
+++ clang/test/Driver/plugin-driver-args.cpp
@@ -0,0 +1,22 @@
+/// Test passing args to plugins via the clang driver and -fplugin-arg
+// RUN: %clang -fplugin=%llvmshlibdir/CallSuperAttr%pluginext -fplugin-arg-call_super_plugin-help -fsyntax-only -### %s 2>&1 | FileCheck %s
+
+// CHECK: "-load"
+// CHECK-SAME: CallSuperAttr
+// CHECK-SAME: "-plugin-arg-call_super_plugin"
+// CHECK-SAME: "help"
+
+/// Check that dashed-args get forwarded like this to the plugin.
+/// Dashes cannot be part of the plugin name here
+// RUN: %clang -fplugin=%llvmshlibdir/CallSuperAttr%pluginext -fplugin-arg-call_super_plugin-help-long -fsyntax-only %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CMD
+// CHECK-CMD: "-plugin-arg-call_super_plugin" "help-long"
+
+/// Error handling for -fplugin-arg-
+// RUN: %clang -fplugin=%llvmshlibdir/CallSuperAttr%pluginext -fplugin-arg- -fsyntax-only %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-PLUGIN-NAME
+// CHECK-NO-PLUGIN-NAME: missing plugin name in -fplugin-arg-
+
+// RUN: %clang -fplugin=%llvmshlibdir/CallSuperAttr%pluginext -fplugin-arg-testname -fsyntax-only %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-PLUGIN-ARG1
+// CHECK-NO-PLUGIN-ARG1: missing plugin argument for plugin testname in -fplugin-arg-testname
+
+// RUN: %clang -fplugin=%llvmshlibdir/CallSuperAttr%pluginext -fplugin-arg-testname- -fsyntax-only %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-PLUGIN-ARG2
+// CHECK-NO-PLUGIN-ARG2: missing plugin argument for plugin testname in -fplugin-arg-testname-
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6659,6 +6659,35 @@
 A->claim();
   }
 
+  // Turn -fplugin-arg-pluginname-key=value into
+  // -plugin-arg-pluginname key=value
+  // GCC has an actual plugin_argument struct with key/value pairs that it
+  // passes to its plugins, but we don't, so just pass it on as-is.
+  //
+  // The syntax for -fplugin-arg- is ambiguous if both plugin name and
+  // argument key are allowed to contain dashes. GCC therefore only
+  // allows dashes in the key. We do the same.
+  for (const Arg *A : Args.filtered(options::OPT_fplugin_arg)) {
+auto ArgValue = StringRef(A->getValue());
+auto FirstDashIndex = ArgValue.find('-');
+StringRef PluginName = ArgValue.substr(0, FirstDashIndex);
+StringRef Arg = ArgValue.substr(FirstDashIndex + 1);
+
+A->claim();
+if (FirstDashIndex == StringRef::npos || Arg.empty()) {
+  if (PluginName.empty()) {
+D.Diag(diag::warn_drv_missing_plugin_name) << A->getAsString(Args);
+  } else {
+D.Diag(diag::warn_drv_missing_plugin_arg)
+<< PluginName << A->getAsString(Args);
+  }
+  continue;
+}
+
+CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-arg-") + PluginName));
+CmdArgs.push_back(Args.MakeArgString(Arg));
+  }
+
   // Forward -fpass-plugin=name.so to -cc1.
   for (const Arg *A : Args.filtered(options::OPT_fpass_plugin_EQ)) {
 CmdArgs.push_back(
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2504,6 +2504,9 @@
   NegFlag>;
 def fplugin_EQ : Joined<["-"], "fplugin=">, Group, Flags<[NoXarchOption]>, MetaVarName<"">,
   HelpText<"Load the name

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

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

zero9178 created this revision.
zero9178 added reviewers: rnk, CaseyCarter, hans, thakis.
zero9178 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Since VS 2022 17.1 MSVC predefines _MSVC_EXECUTION_CHARACTER_SET to inform the 
users of the execution character set defined at compile time. The value the 
macro expands to is a Windows Code Page Identifier which are documented here: 
https://docs.microsoft.com/en-us/windows/win32/intl/code-page-identifiers

As clang currently only supports UTF-8 it is defined as 65001. If clang-cl were 
to support a different execution character set in the future we'd have to 
change the value.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D114576

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/cl-execution-character-set.c


Index: clang/test/Driver/cl-execution-character-set.c
===
--- /dev/null
+++ clang/test/Driver/cl-execution-character-set.c
@@ -0,0 +1,7 @@
+// Note: %s must be preceded by --, otherwise it may be interpreted as a
+// command-line option, e.g. on Mac where %s is commonly under /Users.
+
+// Only UTF-8 is currently supported, which has the Windows Code
+// Page Identifier 65001
+// RUN: %clang_cl -### -- %s 2>&1 | FileCheck %s
+// CHECK: -D_MSVC_EXECUTION_CHARACTER_SET=65001
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -7327,6 +7327,14 @@
 CmdArgs.push_back("--dependent-lib=oldnames");
   }
 
+  // Starting with VS 2022 17.1, MSVC predefines the below macro to inform
+  // users of the execution character set defined at compile time.
+  // The value given is the Windows Code Page Identifier:
+  // https://docs.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
+  //
+  // Clang currently only supports UTF-8, so we'll use 65001
+  CmdArgs.push_back("-D_MSVC_EXECUTION_CHARACTER_SET=65001");
+
   if (Arg *ShowIncludes =
   Args.getLastArg(options::OPT__SLASH_showIncludes,
   options::OPT__SLASH_showIncludes_user)) {


Index: clang/test/Driver/cl-execution-character-set.c
===
--- /dev/null
+++ clang/test/Driver/cl-execution-character-set.c
@@ -0,0 +1,7 @@
+// Note: %s must be preceded by --, otherwise it may be interpreted as a
+// command-line option, e.g. on Mac where %s is commonly under /Users.
+
+// Only UTF-8 is currently supported, which has the Windows Code
+// Page Identifier 65001
+// RUN: %clang_cl -### -- %s 2>&1 | FileCheck %s
+// CHECK: -D_MSVC_EXECUTION_CHARACTER_SET=65001
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -7327,6 +7327,14 @@
 CmdArgs.push_back("--dependent-lib=oldnames");
   }
 
+  // Starting with VS 2022 17.1, MSVC predefines the below macro to inform
+  // users of the execution character set defined at compile time.
+  // The value given is the Windows Code Page Identifier:
+  // https://docs.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
+  //
+  // Clang currently only supports UTF-8, so we'll use 65001
+  CmdArgs.push_back("-D_MSVC_EXECUTION_CHARACTER_SET=65001");
+
   if (Arg *ShowIncludes =
   Args.getLastArg(options::OPT__SLASH_showIncludes,
   options::OPT__SLASH_showIncludes_user)) {
___
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 added a comment.

This looks reasonable to me (some nits included).




Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:4513
 Scope.addPrivate(Pair.first, [Replacement]() { return Replacement; });
+if (auto *DI = CGF.getDebugInfo()) {
+  DI->EmitDeclareOfAutoVariable(Pair.first, Pair.second.getPointer(),

I think we can get rid of curly brackets.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:4515
+  DI->EmitDeclareOfAutoVariable(Pair.first, Pair.second.getPointer(),
+CGF.Builder, true);
+}




Repository:
  rG LLVM Github Monorepo

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

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

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

mstorsjo added a comment.

Would it be possible to move setting of this flag to somewhere else (e.g. 
somewhere in Driver/ToolChains/MSVC.cpp), so that it would be picked up also 
when building with the gcc-style driver with `--target=*-windows-msvc`? Overall 
in earlier discussions, there's been mostly positive reception to making that 
mode more usable even if it isn't quite as supported as actually invoking 
`clang-cl`. (For some things, like the equivalent of the cl level `-MD`/`-MT` 
options, there's currently nothing available in the gcc style driver - but for 
a feature like this, I don't see any reason why it shouldn't be available 
everywhere.)


Repository:
  rG LLVM Github Monorepo

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] D114505: [clang][unittests] Fix a clang unittest linking issue

2021-11-25 Thread Lu Weining via Phabricator via cfe-commits

SixWeining updated this revision to Diff 389696.
SixWeining added a comment.

diff1 and diff2 are the same, but diff1 build pass while diff2 build fail. So 
weird. Just reupload the patch to have a try. Sorry for the noise.


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

https://reviews.llvm.org/D114505

Files:
  clang/unittests/Basic/CMakeLists.txt


Index: clang/unittests/Basic/CMakeLists.txt
===
--- clang/unittests/Basic/CMakeLists.txt
+++ clang/unittests/Basic/CMakeLists.txt
@@ -18,5 +18,9 @@
   clangAST
   clangBasic
   clangLex
-  LLVMTestingSupport
   )
+
+target_link_libraries(BasicTests
+  PRIVATE
+  LLVMTestingSupport
+)


Index: clang/unittests/Basic/CMakeLists.txt
===
--- clang/unittests/Basic/CMakeLists.txt
+++ clang/unittests/Basic/CMakeLists.txt
@@ -18,5 +18,9 @@
   clangAST
   clangBasic
   clangLex
-  LLVMTestingSupport
   )
+
+target_link_libraries(BasicTests
+  PRIVATE
+  LLVMTestingSupport
+)
___
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

alok added inline comments.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:4513
 Scope.addPrivate(Pair.first, [Replacement]() { return Replacement; });
+if (auto *DI = CGF.getDebugInfo()) {
+  DI->EmitDeclareOfAutoVariable(Pair.first, Pair.second.getPointer(),

djtodoro wrote:
> I think we can get rid of curly brackets.
Sure, I am doing it.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:4515
+  DI->EmitDeclareOfAutoVariable(Pair.first, Pair.second.getPointer(),
+CGF.Builder, true);
+}

djtodoro wrote:
> 
Thanks. I am updating it.


Repository:
  rG LLVM Github Monorepo

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

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

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

zero9178 updated this revision to Diff 389698.
zero9178 added a comment.

Enable the macro for all MSVC targets, regardless of driver in use.


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

https://reviews.llvm.org/D114576

Files:
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/test/Driver/cl-execution-character-set.c


Index: clang/test/Driver/cl-execution-character-set.c
===
--- /dev/null
+++ clang/test/Driver/cl-execution-character-set.c
@@ -0,0 +1,14 @@
+// Note: %s must be preceded by --, otherwise it may be interpreted as a
+// command-line option, e.g. on Mac where %s is commonly under /Users.
+
+// Only UTF-8 is currently supported, which has the Windows Code
+// Page Identifier 65001
+
+// Check this works with the clang-cl driver as well as with the GNU clang 
driver
+// RUN: %clang_cl -### -- %s 2>&1 | FileCheck -check-prefix=CHECK-MSVC %s
+// RUN: %clang --target=x86_64-pc-windows-msvc -### %s 2>&1 | FileCheck 
-check-prefix=CHECK-MSVC %s
+// CHECK-MSVC: -D_MSVC_EXECUTION_CHARACTER_SET=65001
+
+// It shouldn't be defined for any non MSVC targets
+// RUN: %clang --target=x86_64-pc-windows-gnu -### %s 2>&1 | FileCheck 
-check-prefix=CHECK-NON-MSVC %s
+// CHECK-NON-MSVC-NOT: -D_MSVC_EXECUTION_CHARACTER_SET
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -1609,4 +1609,12 @@
   if (DriverArgs.hasArg(options::OPT_fno_rtti, options::OPT_frtti,
 /*Default=*/false))
 CC1Args.push_back("-D_HAS_STATIC_RTTI=0");
+
+  // Starting with VS 2022 17.1, MSVC predefines the below macro to inform
+  // users of the execution character set defined at compile time.
+  // The value given is the Windows Code Page Identifier:
+  // https://docs.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
+  //
+  // Clang currently only supports UTF-8, so we'll use 65001
+  CC1Args.push_back("-D_MSVC_EXECUTION_CHARACTER_SET=65001");
 }


Index: clang/test/Driver/cl-execution-character-set.c
===
--- /dev/null
+++ clang/test/Driver/cl-execution-character-set.c
@@ -0,0 +1,14 @@
+// Note: %s must be preceded by --, otherwise it may be interpreted as a
+// command-line option, e.g. on Mac where %s is commonly under /Users.
+
+// Only UTF-8 is currently supported, which has the Windows Code
+// Page Identifier 65001
+
+// Check this works with the clang-cl driver as well as with the GNU clang driver
+// RUN: %clang_cl -### -- %s 2>&1 | FileCheck -check-prefix=CHECK-MSVC %s
+// RUN: %clang --target=x86_64-pc-windows-msvc -### %s 2>&1 | FileCheck -check-prefix=CHECK-MSVC %s
+// CHECK-MSVC: -D_MSVC_EXECUTION_CHARACTER_SET=65001
+
+// It shouldn't be defined for any non MSVC targets
+// RUN: %clang --target=x86_64-pc-windows-gnu -### %s 2>&1 | FileCheck -check-prefix=CHECK-NON-MSVC %s
+// CHECK-NON-MSVC-NOT: -D_MSVC_EXECUTION_CHARACTER_SET
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -1609,4 +1609,12 @@
   if (DriverArgs.hasArg(options::OPT_fno_rtti, options::OPT_frtti,
 /*Default=*/false))
 CC1Args.push_back("-D_HAS_STATIC_RTTI=0");
+
+  // Starting with VS 2022 17.1, MSVC predefines the below macro to inform
+  // users of the execution character set defined at compile time.
+  // The value given is the Windows Code Page Identifier:
+  // https://docs.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
+  //
+  // Clang currently only supports UTF-8, so we'll use 65001
+  CC1Args.push_back("-D_MSVC_EXECUTION_CHARACTER_SET=65001");
 }
___
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

alok updated this revision to Diff 389699.
alok added a comment.

Re-based and incorporated comments from @djtodoro


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 Replacement; });
+if (auto *DI = CGF.getDebugInfo())
+  DI->EmitDeclareOfAutoVariable(Pair.first, Pair.second.getPointer(),
+CGF.Builder, /*U

[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

alok added a comment.

Thanks @djtodoro . I have incorporated all your comments.


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] e2cad4d - [clangd] Add ObjC method support to prepareCallHierarchy

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


Author: Sheldon Neuberger
Date: 2021-11-25T11:23:24+01:00
New Revision: e2cad4df22a6a411e7f7fcbc9bff0bd789545136

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

LOG: [clangd] Add ObjC method support to prepareCallHierarchy

This fixes "textDocument/prepareCallHierarchy" in clangd for ObjC methods. 
Details at https://github.com/clangd/vscode-clangd/issues/247.

clangd uses Decl::isFunctionOrFunctionTemplate to check if the decl given in a 
prepareCallHierarchy request is eligible for prepareCallHierarchy. We change to 
use isFunctionOrMethod which includes functions and ObjC methods.

Reviewed By: kadircet

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

Added: 


Modified: 
clang-tools-extra/clangd/XRefs.cpp
clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/XRefs.cpp 
b/clang-tools-extra/clangd/XRefs.cpp
index 452067a90a9c..b46d2c0043dc 100644
--- a/clang-tools-extra/clangd/XRefs.cpp
+++ b/clang-tools-extra/clangd/XRefs.cpp
@@ -1906,7 +1906,9 @@ prepareCallHierarchy(ParsedAST &AST, Position Pos, 
PathRef TUPath) {
 return Result;
   }
   for (const NamedDecl *Decl : getDeclAtPosition(AST, *Loc, {})) {
-if (!Decl->isFunctionOrFunctionTemplate())
+if (!(isa(Decl) &&
+  cast(Decl)->isFunctionOrMethod()) &&
+Decl->getKind() != Decl::Kind::FunctionTemplate)
   continue;
 if (auto CHI = declToCallHierarchyItem(*Decl))
   Result.emplace_back(std::move(*CHI));

diff  --git a/clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp 
b/clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
index 6f63ea2bc18b..a9d0385654dd 100644
--- a/clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
+++ b/clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
@@ -65,7 +65,7 @@ ::testing::Matcher 
FromRanges(RangeMatchers... M) {
UnorderedElementsAre(M...));
 }
 
-TEST(CallHierarchy, IncomingOneFile) {
+TEST(CallHierarchy, IncomingOneFileCpp) {
   Annotations Source(R"cpp(
 void call^ee(int);
 void caller1() {
@@ -91,7 +91,51 @@ TEST(CallHierarchy, IncomingOneFile) {
   ASSERT_THAT(IncomingLevel1,
   ElementsAre(AllOf(From(WithName("caller1")),
 FromRanges(Source.range("Callee");
+  auto IncomingLevel2 = incomingCalls(IncomingLevel1[0].from, Index.get());
+  ASSERT_THAT(IncomingLevel2,
+  ElementsAre(AllOf(From(WithName("caller2")),
+FromRanges(Source.range("Caller1A"),
+   Source.range("Caller1B"))),
+  AllOf(From(WithName("caller3")),
+FromRanges(Source.range("Caller1C");
 
+  auto IncomingLevel3 = incomingCalls(IncomingLevel2[0].from, Index.get());
+  ASSERT_THAT(IncomingLevel3,
+  ElementsAre(AllOf(From(WithName("caller3")),
+FromRanges(Source.range("Caller2");
+
+  auto IncomingLevel4 = incomingCalls(IncomingLevel3[0].from, Index.get());
+  EXPECT_THAT(IncomingLevel4, IsEmpty());
+}
+
+TEST(CallHierarchy, IncomingOneFileObjC) {
+  Annotations Source(R"objc(
+@implementation MyClass {}
+  +(void)call^ee {}
+  +(void) caller1 {
+[MyClass $Callee[[callee]]];
+  }
+  +(void) caller2 {
+[MyClass $Caller1A[[caller1]]];
+[MyClass $Caller1B[[caller1]]];
+  }
+  +(void) caller3 {
+[MyClass $Caller1C[[caller1]]];
+[MyClass $Caller2[[caller2]]];
+  }
+@end
+  )objc");
+  TestTU TU = TestTU::withCode(Source.code());
+  TU.Filename = "TestTU.m";
+  auto AST = TU.build();
+  auto Index = TU.index();
+  std::vector Items =
+  prepareCallHierarchy(AST, Source.point(), testPath(TU.Filename));
+  ASSERT_THAT(Items, ElementsAre(WithName("callee")));
+  auto IncomingLevel1 = incomingCalls(Items[0], Index.get());
+  ASSERT_THAT(IncomingLevel1,
+  ElementsAre(AllOf(From(WithName("caller1")),
+FromRanges(Source.range("Callee");
   auto IncomingLevel2 = incomingCalls(IncomingLevel1[0].from, Index.get());
   ASSERT_THAT(IncomingLevel2,
   ElementsAre(AllOf(From(WithName("caller2")),
@@ -172,7 +216,7 @@ TEST(CallHierarchy, IncomingQualified) {
 FromRanges(Source.range("Caller2");
 }
 
-TEST(CallHierarchy, IncomingMultiFile) {
+TEST(CallHierarchy, IncomingMultiFileCpp) {
   // The test uses a .hh suffix for header files to get clang
   // to parse them in C++ mode. .h files are parsed in C mode
   // by default, which causes problems because e.g. symbol
@@ -268,6 +312,115 @@ TEST(CallHierarchy, IncomingMultiFile) {
   CheckCallHierarchy(*AST, CalleeC.point(), test

[PATCH] D114058: [clangd] Add ObjC method support to prepareCallHierarchy

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

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe2cad4df22a6: [clangd] Add ObjC method support to 
prepareCallHierarchy (authored by sheldonneuberger-sc, committed by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114058

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp

Index: clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
===
--- clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
+++ clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
@@ -65,7 +65,7 @@
UnorderedElementsAre(M...));
 }
 
-TEST(CallHierarchy, IncomingOneFile) {
+TEST(CallHierarchy, IncomingOneFileCpp) {
   Annotations Source(R"cpp(
 void call^ee(int);
 void caller1() {
@@ -91,7 +91,51 @@
   ASSERT_THAT(IncomingLevel1,
   ElementsAre(AllOf(From(WithName("caller1")),
 FromRanges(Source.range("Callee");
+  auto IncomingLevel2 = incomingCalls(IncomingLevel1[0].from, Index.get());
+  ASSERT_THAT(IncomingLevel2,
+  ElementsAre(AllOf(From(WithName("caller2")),
+FromRanges(Source.range("Caller1A"),
+   Source.range("Caller1B"))),
+  AllOf(From(WithName("caller3")),
+FromRanges(Source.range("Caller1C");
 
+  auto IncomingLevel3 = incomingCalls(IncomingLevel2[0].from, Index.get());
+  ASSERT_THAT(IncomingLevel3,
+  ElementsAre(AllOf(From(WithName("caller3")),
+FromRanges(Source.range("Caller2");
+
+  auto IncomingLevel4 = incomingCalls(IncomingLevel3[0].from, Index.get());
+  EXPECT_THAT(IncomingLevel4, IsEmpty());
+}
+
+TEST(CallHierarchy, IncomingOneFileObjC) {
+  Annotations Source(R"objc(
+@implementation MyClass {}
+  +(void)call^ee {}
+  +(void) caller1 {
+[MyClass $Callee[[callee]]];
+  }
+  +(void) caller2 {
+[MyClass $Caller1A[[caller1]]];
+[MyClass $Caller1B[[caller1]]];
+  }
+  +(void) caller3 {
+[MyClass $Caller1C[[caller1]]];
+[MyClass $Caller2[[caller2]]];
+  }
+@end
+  )objc");
+  TestTU TU = TestTU::withCode(Source.code());
+  TU.Filename = "TestTU.m";
+  auto AST = TU.build();
+  auto Index = TU.index();
+  std::vector Items =
+  prepareCallHierarchy(AST, Source.point(), testPath(TU.Filename));
+  ASSERT_THAT(Items, ElementsAre(WithName("callee")));
+  auto IncomingLevel1 = incomingCalls(Items[0], Index.get());
+  ASSERT_THAT(IncomingLevel1,
+  ElementsAre(AllOf(From(WithName("caller1")),
+FromRanges(Source.range("Callee");
   auto IncomingLevel2 = incomingCalls(IncomingLevel1[0].from, Index.get());
   ASSERT_THAT(IncomingLevel2,
   ElementsAre(AllOf(From(WithName("caller2")),
@@ -172,7 +216,7 @@
 FromRanges(Source.range("Caller2");
 }
 
-TEST(CallHierarchy, IncomingMultiFile) {
+TEST(CallHierarchy, IncomingMultiFileCpp) {
   // The test uses a .hh suffix for header files to get clang
   // to parse them in C++ mode. .h files are parsed in C mode
   // by default, which causes problems because e.g. symbol
@@ -268,6 +312,115 @@
   CheckCallHierarchy(*AST, CalleeC.point(), testPath("callee.cc"));
 }
 
+TEST(CallHierarchy, IncomingMultiFileObjC) {
+  // The test uses a .mi suffix for header files to get clang
+  // to parse them in ObjC mode. .h files are parsed in C mode
+  // by default, which causes problems because e.g. symbol
+  // USRs are different in C mode (do not include function signatures).
+
+  Annotations CalleeH(R"objc(
+@interface CalleeClass
+  +(void)call^ee;
+@end
+  )objc");
+  Annotations CalleeC(R"objc(
+#import "callee.mi"
+@implementation CalleeClass {}
+  +(void)call^ee {}
+@end
+  )objc");
+  Annotations Caller1H(R"objc(
+@interface Caller1Class
+  +(void)caller1;
+@end
+  )objc");
+  Annotations Caller1C(R"objc(
+#import "callee.mi"
+#import "caller1.mi"
+@implementation Caller1Class {}
+  +(void)caller1 {
+[CalleeClass [[calle^e]]];
+  }
+@end
+  )objc");
+  Annotations Caller2H(R"objc(
+@interface Caller2Class
+  +(void)caller2;
+@end
+  )objc");
+  Annotations Caller2C(R"objc(
+#import "caller1.mi"
+#import "caller2.mi"
+@implementation Caller2Class {}
+  +(void)caller2 {
+[Caller1Class $A[[caller1]]];
+[Caller1Class $B[[caller1]]];
+  }
+@end
+  )objc");
+  Annotations Caller3C(R"objc(
+#import "caller1.mi"
+#import "caller2.mi"
+@implementation Caller3Class {}
+  +(void)caller3 {
+[Caller1Class $Caller1[[caller1]]];
+[Caller2Class $Caller2[[

[PATCH] D110618: [HIPSPV][2/4] Add HIPSPV tool chain

2021-11-25 Thread Henry Linjamäki via Phabricator via cfe-commits

linjamaki updated this revision to Diff 389702.
linjamaki added a comment.

Disable debug info generation for device code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110618

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/HIPSPV.cpp
  clang/lib/Driver/ToolChains/HIPSPV.h

Index: clang/lib/Driver/ToolChains/HIPSPV.h
===
--- /dev/null
+++ clang/lib/Driver/ToolChains/HIPSPV.h
@@ -0,0 +1,103 @@
+//===--- HIPSPV.h - HIP ToolChain Implementations ---*- 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
+//
+//===--===//
+
+#ifndef LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_HIPSPV_H
+#define LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_HIPSPV_H
+
+#include "SPIRV.h"
+#include "clang/Driver/Tool.h"
+#include "clang/Driver/ToolChain.h"
+
+namespace clang {
+namespace driver {
+namespace tools {
+namespace HIPSPV {
+
+// Runs llvm-link/opt/llc/lld, which links multiple LLVM bitcode, together with
+// device library, then compiles it to SPIR-V in a shared object.
+class LLVM_LIBRARY_VISIBILITY Linker : public Tool {
+public:
+  Linker(const ToolChain &TC) : Tool("HIPSPV::Linker", "hipspv-link", TC) {}
+
+  bool hasIntegratedCPP() const override { return false; }
+
+  void ConstructJob(Compilation &C, const JobAction &JA,
+const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::opt::ArgList &TCArgs,
+const char *LinkingOutput) const override;
+
+private:
+  void constructLinkAndEmitSpirvCommand(Compilation &C, const JobAction &JA,
+const InputInfoList &Inputs,
+const InputInfo &Output,
+const llvm::opt::ArgList &Args) const;
+};
+
+} // namespace HIPSPV
+} // namespace tools
+
+namespace toolchains {
+
+class LLVM_LIBRARY_VISIBILITY HIPSPVToolChain final : public ToolChain {
+public:
+  HIPSPVToolChain(const Driver &D, const llvm::Triple &Triple,
+  const ToolChain &HostTC, const llvm::opt::ArgList &Args);
+
+  const llvm::Triple *getAuxTriple() const override {
+return &HostTC.getTriple();
+  }
+
+  void
+  addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringList &CC1Args,
+Action::OffloadKind DeviceOffloadKind) const override;
+  void addClangWarningOptions(llvm::opt::ArgStringList &CC1Args) const override;
+  CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList &Args) const override;
+  void
+  AddClangSystemIncludeArgs(const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringList &CC1Args) const override;
+  void AddClangCXXStdlibIncludeArgs(
+  const llvm::opt::ArgList &Args,
+  llvm::opt::ArgStringList &CC1Args) const override;
+  void AddIAMCUIncludeArgs(const llvm::opt::ArgList &DriverArgs,
+   llvm::opt::ArgStringList &CC1Args) const override;
+  void AddHIPIncludeArgs(const llvm::opt::ArgList &DriverArgs,
+ llvm::opt::ArgStringList &CC1Args) const override;
+  llvm::SmallVector
+  getHIPDeviceLibs(const llvm::opt::ArgList &Args) const override;
+
+  SanitizerMask getSupportedSanitizers() const override;
+
+  VersionTuple
+  computeMSVCVersion(const Driver *D,
+ const llvm::opt::ArgList &Args) const override;
+
+  void adjustDebugInfoKind(codegenoptions::DebugInfoKind &DebugInfoKind,
+   const llvm::opt::ArgList &Args) const override;
+  bool IsIntegratedAssemblerDefault() const override { return true; }
+  bool IsMathErrnoDefault() const override { return false; }
+  bool useIntegratedAs() const override { return true; }
+  bool isCrossCompiling() const override { return true; }
+  bool isPICDefault() const override { return false; }
+  bool isPIEDefault(const llvm::opt::ArgList &Args) const override {
+return false;
+  }
+  bool isPICDefaultForced() const override { return false; }
+  bool SupportsProfiling() const override { return false; }
+
+  const ToolChain &HostTC;
+
+protected:
+  Tool *buildLinker() const override;
+};
+
+} // end namespace toolchains
+} // end namespace driver
+} // end namespace clang
+
+#endif // LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_HIPSPV_H
Index: clang/lib/Driver/ToolChains/HIPSPV.cpp
===
--- /dev/null
+++ clang/lib/Driver/ToolChains/HIPSPV.cpp
@@ -0,0 +1,292 @@
+//===---

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

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.

Thanks! This LGTM - but maybe wait a while if someone else has something to 
say. (Although I guess americans are on holiday today, so there's probably not 
many that will see and care today.)


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 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

[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, StructDefinitionInPrototypeDifferen

[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] 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

[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] 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 @@
   verifyFormat("Foo::opera

[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] 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 (&FunctionReference)(void);
+// void (&&FunctionReference)(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] 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] 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 &Line,
   auto HasExistingWhitespace = [&Right]() {
 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 &Line,
 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

[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 
couldn't 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 @@
 addU

[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

[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 &AST) {
 
 std::vector issueUnusedIncludesDiagnostics(ParsedAST &AST,
  llvm::StringRef Code) {
-  trace::Span Tracer("IncludeCleaner::issueUnusedIncludesDiagnostics");
   const Config &Cfg = 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] 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

[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] 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] 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] 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] 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 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

[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] 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 Replacemen

[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] 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] 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] 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 &Cfg, DataflowAnalysisDynamic &Analysis,
+   const Environment &InitEnv) {
+  // 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] 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 &Cfg, DataflowAnalysisDynamic &Analysis,
+   const Environment &InitEnv) {
+  // 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] 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] 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
+; CHECK-LE-

[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] 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 dif

[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] 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] 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] 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] 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] 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] 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] 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] 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] 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 &Cfg, DataflowAnalysisDynamic &Analysis,
+const Environment &InitEnv) {
+  // 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] 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] 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] 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 &SM);
+  std::unique_ptr collect(const SourceManager &SM,
+   HeaderSearch &HeaderInfo);

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] 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] 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] 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] 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
https://lists.llvm.org/cgi-bin/mailman/listin

[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] 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 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] 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] 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] 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] 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 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] 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 --check-prefix=CHECK-FAST-MAT

[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 (FormatTok-

[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 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] 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] 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] 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, __HIP_MEMO

[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, __HIP_MEMORY_SCOPE_SINGLET

[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] 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] 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] 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

1 2 >

1 - 100 of 131 matches

Mail list logo