[PATCH] D96347: Include function return type in JSON AST dumps.

[Rokas Kupstys via Phabricator via cfe-commits]

rokups added a comment.

This seems to not be good enough, however. Somehow desugared version of type is 
not added anywhere.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96347

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

[clang] df1a17c - [clang-check] Add tokens-dump in clang-check.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2021-02-11T09:40:47+01:00
New Revision: df1a17c219c073427f9d00eb042057bb3a4a3c64

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

LOG: [clang-check] Add tokens-dump in clang-check.

It is useful for syntax-tree developement.

Reviewed By: kbobyrev

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

Added: 


Modified: 
clang/tools/clang-check/ClangCheck.cpp

Removed: 




diff  --git a/clang/tools/clang-check/ClangCheck.cpp 
b/clang/tools/clang-check/ClangCheck.cpp
index 4be3ce980c81..11fdeb71fd9e 100644
--- a/clang/tools/clang-check/ClangCheck.cpp
+++ b/clang/tools/clang-check/ClangCheck.cpp
@@ -88,6 +88,9 @@ static cl::opt FixWhatYouCan(
 static cl::opt SyntaxTreeDump("syntax-tree-dump",
 cl::desc("dump the syntax tree"),
 cl::cat(ClangCheckCategory));
+static cl::opt TokensDump("tokens-dump",
+cl::desc("dump the preprocessed tokens"),
+cl::cat(ClangCheckCategory));
 
 namespace {
 
@@ -148,6 +151,8 @@ class DumpSyntaxTree : public clang::ASTFrontendAction {
 
   void HandleTranslationUnit(clang::ASTContext &AST) override {
 clang::syntax::TokenBuffer TB = std::move(Collector).consume();
+if (TokensDump)
+  llvm::outs() << TB.dumpForTests();
 clang::syntax::Arena A(AST.getSourceManager(), AST.getLangOpts(), TB);
 llvm::outs() << clang::syntax::buildSyntaxTree(A, AST)->dump(
 AST.getSourceManager());
@@ -217,7 +222,7 @@ int main(int argc, const char **argv) {
 FrontendFactory = newFrontendActionFactory();
   else if (Fixit)
 FrontendFactory = newFrontendActionFactory();
-  else if (SyntaxTreeDump)
+  else if (SyntaxTreeDump || TokensDump)
 FrontendFactory = newFrontendActionFactory();
   else
 FrontendFactory = newFrontendActionFactory(&CheckFactory);



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

[PATCH] D96017: [clang-check] Add tokens-dump in clang-check.

[Haojian Wu 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 rGdf1a17c219c0: [clang-check] Add tokens-dump in clang-check. 
(authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96017

Files:
  clang/tools/clang-check/ClangCheck.cpp


Index: clang/tools/clang-check/ClangCheck.cpp
===
--- clang/tools/clang-check/ClangCheck.cpp
+++ clang/tools/clang-check/ClangCheck.cpp
@@ -88,6 +88,9 @@
 static cl::opt SyntaxTreeDump("syntax-tree-dump",
 cl::desc("dump the syntax tree"),
 cl::cat(ClangCheckCategory));
+static cl::opt TokensDump("tokens-dump",
+cl::desc("dump the preprocessed tokens"),
+cl::cat(ClangCheckCategory));
 
 namespace {
 
@@ -148,6 +151,8 @@
 
   void HandleTranslationUnit(clang::ASTContext &AST) override {
 clang::syntax::TokenBuffer TB = std::move(Collector).consume();
+if (TokensDump)
+  llvm::outs() << TB.dumpForTests();
 clang::syntax::Arena A(AST.getSourceManager(), AST.getLangOpts(), TB);
 llvm::outs() << clang::syntax::buildSyntaxTree(A, AST)->dump(
 AST.getSourceManager());
@@ -217,7 +222,7 @@
 FrontendFactory = newFrontendActionFactory();
   else if (Fixit)
 FrontendFactory = newFrontendActionFactory();
-  else if (SyntaxTreeDump)
+  else if (SyntaxTreeDump || TokensDump)
 FrontendFactory = newFrontendActionFactory();
   else
 FrontendFactory = newFrontendActionFactory(&CheckFactory);


Index: clang/tools/clang-check/ClangCheck.cpp
===
--- clang/tools/clang-check/ClangCheck.cpp
+++ clang/tools/clang-check/ClangCheck.cpp
@@ -88,6 +88,9 @@
 static cl::opt SyntaxTreeDump("syntax-tree-dump",
 cl::desc("dump the syntax tree"),
 cl::cat(ClangCheckCategory));
+static cl::opt TokensDump("tokens-dump",
+cl::desc("dump the preprocessed tokens"),
+cl::cat(ClangCheckCategory));
 
 namespace {
 
@@ -148,6 +151,8 @@
 
   void HandleTranslationUnit(clang::ASTContext &AST) override {
 clang::syntax::TokenBuffer TB = std::move(Collector).consume();
+if (TokensDump)
+  llvm::outs() << TB.dumpForTests();
 clang::syntax::Arena A(AST.getSourceManager(), AST.getLangOpts(), TB);
 llvm::outs() << clang::syntax::buildSyntaxTree(A, AST)->dump(
 AST.getSourceManager());
@@ -217,7 +222,7 @@
 FrontendFactory = newFrontendActionFactory();
   else if (Fixit)
 FrontendFactory = newFrontendActionFactory();
-  else if (SyntaxTreeDump)
+  else if (SyntaxTreeDump || TokensDump)
 FrontendFactory = newFrontendActionFactory();
   else
 FrontendFactory = newFrontendActionFactory(&CheckFactory);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90691: [analyzer] Add new checker for unchecked return value.

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

Great job!
I'd like to see more tests with the following cases:

- more expressions with function calls - ternary expression, arithmetic, array 
literals, initializer lists, etc.
- using/not using it in `if` statement with initializer
- using/not using it in different parts of GNU statement expressions
- calls in different parts of exception handling (both C++ and Obj-C)
- calls in lambdas/blocks/coroutines
- calls in different parts of C++ range-for loop
- calls in different parts of Obj-C for loop over collections
- calls under labels
- calls in attributed statements (e.g. `[[clang::nomerge]] foo()`)
- calls in goto statements
- calls in Obj-C `@synchronized` and `@autoreleasepool` statements


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90691

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

[clang] 35a5e88 - [Syntax] NFC, Simplify a test with annotations

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2021-02-11T09:49:06+01:00
New Revision: 35a5e883906f11b63b60574d8737791448dd478f

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

LOG: [Syntax] NFC, Simplify a test with annotations

Added: 


Modified: 
clang/unittests/Tooling/Syntax/BuildTreeTest.cpp

Removed: 




diff  --git a/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp 
b/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
index 1f950b05e3f1..a76557dcf803 100644
--- a/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ b/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -4768,67 +4768,43 @@ TranslationUnit Detached
 }
 
 TEST_P(BuildSyntaxTreeTest, ParametersAndQualifiers_InFreeFunctions_Named) {
-  EXPECT_TRUE(treeDumpEqual(
+  EXPECT_TRUE(treeDumpEqualOnAnnotations(
   R"cpp(
-int func1(int a);
-int func2(int *ap);
-int func3(int a, float b);
-)cpp",
-  R"txt(
-TranslationUnit Detached
-|-SimpleDeclaration
-| |-'int'
-| |-DeclaratorList Declarators
-| | `-SimpleDeclarator ListElement
-| |   |-'func1'
-| |   `-ParametersAndQualifiers
-| | |-'(' OpenParen
-| | |-ParameterDeclarationList Parameters
-| | | `-SimpleDeclaration ListElement
-| | |   |-'int'
-| | |   `-DeclaratorList Declarators
-| | | `-SimpleDeclarator ListElement
-| | |   `-'a'
-| | `-')' CloseParen
-| `-';'
-|-SimpleDeclaration
-| |-'int'
-| |-DeclaratorList Declarators
-| | `-SimpleDeclarator ListElement
-| |   |-'func2'
-| |   `-ParametersAndQualifiers
-| | |-'(' OpenParen
-| | |-ParameterDeclarationList Parameters
-| | | `-SimpleDeclaration ListElement
-| | |   |-'int'
-| | |   `-DeclaratorList Declarators
-| | | `-SimpleDeclarator ListElement
-| | |   |-'*'
-| | |   `-'ap'
-| | `-')' CloseParen
-| `-';'
-`-SimpleDeclaration
+ int func1([[int a]]);
+ int func2([[int *ap]]);
+ int func3([[int a, float b]]);
+   )cpp",
+  {R"txt(
+ParameterDeclarationList Parameters
+`-SimpleDeclaration ListElement
   |-'int'
-  |-DeclaratorList Declarators
-  | `-SimpleDeclarator ListElement
-  |   |-'func3'
-  |   `-ParametersAndQualifiers
-  | |-'(' OpenParen
-  | |-ParameterDeclarationList Parameters
-  | | |-SimpleDeclaration ListElement
-  | | | |-'int'
-  | | | `-DeclaratorList Declarators
-  | | |   `-SimpleDeclarator ListElement
-  | | | `-'a'
-  | | |-',' ListDelimiter
-  | | `-SimpleDeclaration ListElement
-  | |   |-'float'
-  | |   `-DeclaratorList Declarators
-  | | `-SimpleDeclarator ListElement
-  | |   `-'b'
-  | `-')' CloseParen
-  `-';'
-)txt"));
+  `-DeclaratorList Declarators
+`-SimpleDeclarator ListElement
+  `-'a'
+)txt",
+   R"txt(
+ParameterDeclarationList Parameters
+`-SimpleDeclaration ListElement
+  |-'int'
+  `-DeclaratorList Declarators
+`-SimpleDeclarator ListElement
+  |-'*'
+  `-'ap'
+)txt",
+   R"txt(
+ParameterDeclarationList Parameters
+|-SimpleDeclaration ListElement
+| |-'int'
+| `-DeclaratorList Declarators
+|   `-SimpleDeclarator ListElement
+| `-'a'
+|-',' ListDelimiter
+`-SimpleDeclaration ListElement
+  |-'float'
+  `-DeclaratorList Declarators
+`-SimpleDeclarator ListElement
+  `-'b'
+)txt"}));
 }
 
 TEST_P(BuildSyntaxTreeTest, ParametersAndQualifiers_InFreeFunctions_Unnamed) {



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

[clang] e159a3c - [Syntax] Remove a strict valid source location assertion for TypeLoc.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2021-02-11T09:53:52+01:00
New Revision: e159a3ced4c54b539c165b1cc26424fa0b34d53e

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

LOG: [Syntax] Remove a strict valid source location assertion for TypeLoc.

The EndLoc of a type loc can be invalid for broken code.

Also extend the existing test to support error code with `error-ok`
annotation.

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

Added: 


Modified: 
clang/lib/Tooling/Syntax/BuildTree.cpp
clang/unittests/Tooling/Syntax/BuildTreeTest.cpp

Removed: 




diff  --git a/clang/lib/Tooling/Syntax/BuildTree.cpp 
b/clang/lib/Tooling/Syntax/BuildTree.cpp
index 62573b6c95b2..a5cb293832d9 100644
--- a/clang/lib/Tooling/Syntax/BuildTree.cpp
+++ b/clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -294,11 +294,12 @@ static SourceRange getDeclaratorRange(const SourceManager 
&SM, TypeLoc T,
   SourceRange Initializer) {
   SourceLocation Start = GetStartLoc().Visit(T);
   SourceLocation End = T.getEndLoc();
-  assert(End.isValid());
   if (Name.isValid()) {
 if (Start.isInvalid())
   Start = Name;
-if (SM.isBeforeInTranslationUnit(End, Name))
+// End of TypeLoc could be invalid if the type is invalid, fallback to the
+// NameLoc.
+if (End.isInvalid() || SM.isBeforeInTranslationUnit(End, Name))
   End = Name;
   }
   if (Initializer.isValid()) {

diff  --git a/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp 
b/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
index a76557dcf803..299a2c320a4c 100644
--- a/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ b/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -23,11 +23,9 @@ class BuildSyntaxTreeTest : public SyntaxTreeTest {
 SCOPED_TRACE(llvm::join(GetParam().getCommandLineArgs(), " "));
 
 auto *Root = buildTree(Code, GetParam());
-if (Diags->getClient()->getNumErrors() != 0) {
-  return ::testing::AssertionFailure()
- << "Source file has syntax errors, they were printed to the test "
-"log";
-}
+auto ErrorOK = errorOK(Code);
+if (!ErrorOK)
+  return ErrorOK;
 auto Actual = 
StringRef(Root->dump(Arena->getSourceManager())).trim().str();
 // EXPECT_EQ shows the 
diff  between the two strings if they are 
diff erent.
 EXPECT_EQ(Tree.trim().str(), Actual);
@@ -45,11 +43,9 @@ class BuildSyntaxTreeTest : public SyntaxTreeTest {
 auto AnnotatedCode = llvm::Annotations(CodeWithAnnotations);
 auto *Root = buildTree(AnnotatedCode.code(), GetParam());
 
-if (Diags->getClient()->getNumErrors() != 0) {
-  return ::testing::AssertionFailure()
- << "Source file has syntax errors, they were printed to the test "
-"log";
-}
+auto ErrorOK = errorOK(AnnotatedCode.code());
+if (!ErrorOK)
+  return ErrorOK;
 
 auto AnnotatedRanges = AnnotatedCode.ranges();
 if (AnnotatedRanges.size() != TreeDumps.size()) {
@@ -77,6 +73,19 @@ class BuildSyntaxTreeTest : public SyntaxTreeTest {
 return Failed ? ::testing::AssertionFailure()
   : ::testing::AssertionSuccess();
   }
+
+private:
+  ::testing::AssertionResult errorOK(StringRef RawCode) {
+if (!RawCode.contains("error-ok")) {
+  if (Diags->getClient()->getNumErrors() != 0) {
+return ::testing::AssertionFailure()
+   << "Source file has syntax errors (suppress with /*error-ok*/), 
"
+  "they were printed to the "
+  "test log";
+  }
+}
+return ::testing::AssertionSuccess();
+  }
 };
 
 INSTANTIATE_TEST_CASE_P(SyntaxTreeTests, BuildSyntaxTreeTest,
@@ -4773,6 +4782,7 @@ TEST_P(BuildSyntaxTreeTest, 
ParametersAndQualifiers_InFreeFunctions_Named) {
  int func1([[int a]]);
  int func2([[int *ap]]);
  int func3([[int a, float b]]);
+ int func4([[undef a]]); // error-ok: no crash on invalid type
)cpp",
   {R"txt(
 ParameterDeclarationList Parameters
@@ -4804,6 +4814,14 @@ ParameterDeclarationList Parameters
   `-DeclaratorList Declarators
 `-SimpleDeclarator ListElement
   `-'b'
+)txt",
+   R"txt(
+ParameterDeclarationList Parameters
+`-SimpleDeclaration ListElement
+  |-'undef'
+  `-DeclaratorList Declarators
+`-SimpleDeclarator ListElement
+  `-'a'
 )txt"}));
 }
 



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

[PATCH] D96261: [Syntax] Remove a strict valid source location assertion for TypeLoc.

[Haojian Wu 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 rGe159a3ced4c5: [Syntax] Remove a strict valid source location 
assertion for TypeLoc. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96261

Files:
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/unittests/Tooling/Syntax/BuildTreeTest.cpp


Index: clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -23,11 +23,9 @@
 SCOPED_TRACE(llvm::join(GetParam().getCommandLineArgs(), " "));
 
 auto *Root = buildTree(Code, GetParam());
-if (Diags->getClient()->getNumErrors() != 0) {
-  return ::testing::AssertionFailure()
- << "Source file has syntax errors, they were printed to the test "
-"log";
-}
+auto ErrorOK = errorOK(Code);
+if (!ErrorOK)
+  return ErrorOK;
 auto Actual = 
StringRef(Root->dump(Arena->getSourceManager())).trim().str();
 // EXPECT_EQ shows the diff between the two strings if they are different.
 EXPECT_EQ(Tree.trim().str(), Actual);
@@ -45,11 +43,9 @@
 auto AnnotatedCode = llvm::Annotations(CodeWithAnnotations);
 auto *Root = buildTree(AnnotatedCode.code(), GetParam());
 
-if (Diags->getClient()->getNumErrors() != 0) {
-  return ::testing::AssertionFailure()
- << "Source file has syntax errors, they were printed to the test "
-"log";
-}
+auto ErrorOK = errorOK(AnnotatedCode.code());
+if (!ErrorOK)
+  return ErrorOK;
 
 auto AnnotatedRanges = AnnotatedCode.ranges();
 if (AnnotatedRanges.size() != TreeDumps.size()) {
@@ -77,6 +73,19 @@
 return Failed ? ::testing::AssertionFailure()
   : ::testing::AssertionSuccess();
   }
+
+private:
+  ::testing::AssertionResult errorOK(StringRef RawCode) {
+if (!RawCode.contains("error-ok")) {
+  if (Diags->getClient()->getNumErrors() != 0) {
+return ::testing::AssertionFailure()
+   << "Source file has syntax errors (suppress with /*error-ok*/), 
"
+  "they were printed to the "
+  "test log";
+  }
+}
+return ::testing::AssertionSuccess();
+  }
 };
 
 INSTANTIATE_TEST_CASE_P(SyntaxTreeTests, BuildSyntaxTreeTest,
@@ -4773,6 +4782,7 @@
  int func1([[int a]]);
  int func2([[int *ap]]);
  int func3([[int a, float b]]);
+ int func4([[undef a]]); // error-ok: no crash on invalid type
)cpp",
   {R"txt(
 ParameterDeclarationList Parameters
@@ -4804,6 +4814,14 @@
   `-DeclaratorList Declarators
 `-SimpleDeclarator ListElement
   `-'b'
+)txt",
+   R"txt(
+ParameterDeclarationList Parameters
+`-SimpleDeclaration ListElement
+  |-'undef'
+  `-DeclaratorList Declarators
+`-SimpleDeclarator ListElement
+  `-'a'
 )txt"}));
 }
 
Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -294,11 +294,12 @@
   SourceRange Initializer) {
   SourceLocation Start = GetStartLoc().Visit(T);
   SourceLocation End = T.getEndLoc();
-  assert(End.isValid());
   if (Name.isValid()) {
 if (Start.isInvalid())
   Start = Name;
-if (SM.isBeforeInTranslationUnit(End, Name))
+// End of TypeLoc could be invalid if the type is invalid, fallback to the
+// NameLoc.
+if (End.isInvalid() || SM.isBeforeInTranslationUnit(End, Name))
   End = Name;
   }
   if (Initializer.isValid()) {


Index: clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -23,11 +23,9 @@
 SCOPED_TRACE(llvm::join(GetParam().getCommandLineArgs(), " "));
 
 auto *Root = buildTree(Code, GetParam());
-if (Diags->getClient()->getNumErrors() != 0) {
-  return ::testing::AssertionFailure()
- << "Source file has syntax errors, they were printed to the test "
-"log";
-}
+auto ErrorOK = errorOK(Code);
+if (!ErrorOK)
+  return ErrorOK;
 auto Actual = StringRef(Root->dump(Arena->getSourceManager())).trim().str();
 // EXPECT_EQ shows the diff between the two strings if they are different.
 EXPECT_EQ(Tree.trim().str(), Actual);
@@ -45,11 +43,9 @@
 auto AnnotatedCode = llvm::Annotations(CodeWithAnnotations);
 auto *Root = buildTree(AnnotatedCode.code(), GetParam());
 
-if (Diags->getClient()->getNumErrors() != 0) {
-  return ::testing::AssertionFailure()
- << "Source file has syntax e

[PATCH] D96285: [clang][Arm] Fix handling of -Wa,-implicit-it=

[David Spickett via Phabricator via cfe-commits]

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

LGTM




Comment at: clang/test/Driver/arm-target-as-mimplicit-it.s:26
+/// assembler flag appearing last (latter wins).
+// RUN: %clang -target arm-linux-gnueabi -### -mimplicit-it=never 
-Wa,-mimplicit-it=always %S/Inputs/wildcard1.c 2>&1 | FileCheck %s 
--check-prefix=NEVER_ALWAYS
+// RUN: %clang -target arm-linux-gnueabi -### -mimplicit-it=always 
-Wa,-mimplicit-it=never %S/Inputs/wildcard1.c 2>&1 | FileCheck %s 
--check-prefix=ALWAYS_NEVER

nickdesaulniers wrote:
> DavidSpickett wrote:
> > I'm confused why this generates two `-arm-implicit-it`.
> > 
> > I'd expect that:
> > A c file only uses the compiler's argument
> > An assembler file uses the compiler and assembler argument, with the 
> > assembler argument last
> > 
> > Are we calling CollectArgsForIntegratedAssembler even for a C file?
> I don't think this is an issue.
> 
> > I'm confused why this generates two -arm-implicit-it.
> 
> If you check the implementation of `CollectArgsForIntegratedAssembler`, it 
> will call my added helper (`AddARMImplicitITArgs`) for `-mimplicit-it=`, then 
> check for `-Wa,-implicit-it=`.  If both are present, then both will be 
> generated for the assembler, with the latter taking preference.
> 
> > Are we calling CollectArgsForIntegratedAssembler even for a C file?
> 
> Yes.  Unless `-no-integrated-as` or `-S` was used, we need to be able to 
> modify how assembler is handled both in generating it from C code, but also 
> for inline assembly that may be in a C source.
Right, I forgot about the inline assembly scenario.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96285

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

[clang] 0b44885 - [OpenCL] Add cl_khr_subgroup_extended_types to TableGen BIFs

[Sven van Haastregt via cfe-commits]

Author: Sven van Haastregt
Date: 2021-02-11T09:32:42Z
New Revision: 0b448854daffd57869254089ebb1bf69e8449823

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

LOG: [OpenCL] Add cl_khr_subgroup_extended_types to TableGen BIFs

Add the builtin functions brought by the
cl_khr_subgroup_extended_types extension to
`-fdeclare-opencl-builtins`.

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

Added: 


Modified: 
clang/lib/Sema/OpenCLBuiltins.td
clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl

Removed: 




diff  --git a/clang/lib/Sema/OpenCLBuiltins.td 
b/clang/lib/Sema/OpenCLBuiltins.td
index 0e10722eee34..b78a1812748b 100644
--- a/clang/lib/Sema/OpenCLBuiltins.td
+++ b/clang/lib/Sema/OpenCLBuiltins.td
@@ -53,6 +53,7 @@ class FunctionExtension : 
AbstractExtension<_Ext>;
 // FunctionExtension definitions.
 def FuncExtNone  : FunctionExtension<"">;
 def FuncExtKhrSubgroups  : 
FunctionExtension<"cl_khr_subgroups">;
+def FuncExtKhrSubgroupExtendedTypes  : 
FunctionExtension<"cl_khr_subgroup_extended_types">;
 def FuncExtKhrSubgroupNonUniformVote : 
FunctionExtension<"cl_khr_subgroup_non_uniform_vote">;
 def FuncExtKhrSubgroupBallot : 
FunctionExtension<"cl_khr_subgroup_ballot">;
 def FuncExtKhrSubgroupNonUniformArithmetic: 
FunctionExtension<"cl_khr_subgroup_non_uniform_arithmetic">;
@@ -367,6 +368,9 @@ def UGenTypeN  : GenericType<"UGenTypeN", 
TLUnsignedInts, VecAndScal
 def FGenTypeN  : GenericType<"FGenTypeN", TLFloat, VecAndScalar>;
 // (u)int, (u)long, and all floats
 def IntLongFloatGenType1   : GenericType<"IntLongFloatGenType1", 
TLIntLongFloats, Vec1>;
+// (u)char and (u)short
+def CharShortGenType1  : GenericType<"CharShortGenType1",
+ TypeList<[Char, UChar, Short, UShort]>, Vec1>;
 
 // GenType definitions for every single base type (e.g. fp32 only).
 // Names are like: GenTypeFloatVecAndScalar.
@@ -1496,7 +1500,19 @@ let Extension = FuncExtKhrSubgroups in {
 // OpenCL Extension v3.0 s38 - Extended Subgroup Functions
 
 // Section 38.4.1 - cl_khr_subgroup_extended_types
-// TODO
+let Extension = FuncExtKhrSubgroupExtendedTypes in {
+  // For sub_group_broadcast, add scalar char, uchar, short, and ushort 
support,
+  def : Builtin<"sub_group_broadcast", [CharShortGenType1, CharShortGenType1, 
UInt], Attr.Convergent>;
+  // gentype may additionally be one of the supported built-in vector data 
types.
+  def : Builtin<"sub_group_broadcast", [AGenTypeNNoScalar, AGenTypeNNoScalar, 
UInt], Attr.Convergent>;
+
+  foreach name = ["sub_group_reduce_", "sub_group_scan_exclusive_",
+  "sub_group_scan_inclusive_"] in {
+foreach op = ["add", "min", "max"] in {
+  def : Builtin;
+}
+  }
+}
 
 // Section 38.5.1 - cl_khr_subgroup_non_uniform_vote
 let Extension = FuncExtKhrSubgroupNonUniformVote in {

diff  --git a/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl 
b/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
index 6b9be37eadaf..6fa428125ce1 100644
--- a/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ b/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -36,6 +36,7 @@ typedef long long2 __attribute__((ext_vector_type(2)));
 
 // Enable extensions that are enabled in opencl-c-base.h.
 #if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 200)
+#define cl_khr_subgroup_extended_types 1
 #define cl_khr_subgroup_ballot 1
 #define cl_khr_subgroup_non_uniform_arithmetic 1
 #define cl_khr_subgroup_clustered_reduce 1
@@ -142,15 +143,18 @@ kernel void basic_subgroup(global uint *out) {
 #endif
 }
 
-kernel void extended_subgroup(global uint4 *out, global int *scalar) {
+kernel void extended_subgroup(global uint4 *out, global int *scalar, global 
char2 *c2) {
   out[0] = get_sub_group_eq_mask();
   scalar[0] = sub_group_non_uniform_scan_inclusive_or(3);
   scalar[1] = sub_group_clustered_reduce_logical_xor(2, 4);
+  *c2 = sub_group_broadcast(*c2, 2);
 #if __OPENCL_C_VERSION__ < CL_VERSION_2_0 && !defined(__OPENCL_CPP_VERSION__)
-  // expected-error@-4{{implicit declaration of function 
'get_sub_group_eq_mask' is invalid in OpenCL}}
-  // expected-error@-5{{implicit conversion changes signedness}}
-  // expected-error@-5{{implicit declaration of function 
'sub_group_non_uniform_scan_inclusive_or' is invalid in OpenCL}}
-  // expected-error@-5{{implicit declaration of function 
'sub_group_clustered_reduce_logical_xor' is invalid in OpenCL}}
+  // expected-error@-5{{implicit declaration of function 
'get_sub_group_eq_mask' is invalid in OpenCL}}
+  // expected-error@-6{{implicit conversion changes signedness}}
+  // expected-error@-6{{implicit declaration of function 
'sub_group_non_uniform_scan_inclusive_or' is invali

[PATCH] D96279: [OpenCL] Add cl_khr_subgroup_extended_types to TableGen BIFs

[Sven van Haastregt 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 rG0b448854daff: [OpenCL] Add cl_khr_subgroup_extended_types to 
TableGen BIFs (authored by svenvh).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96279

Files:
  clang/lib/Sema/OpenCLBuiltins.td
  clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -36,6 +36,7 @@
 
 // Enable extensions that are enabled in opencl-c-base.h.
 #if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 200)
+#define cl_khr_subgroup_extended_types 1
 #define cl_khr_subgroup_ballot 1
 #define cl_khr_subgroup_non_uniform_arithmetic 1
 #define cl_khr_subgroup_clustered_reduce 1
@@ -142,15 +143,18 @@
 #endif
 }
 
-kernel void extended_subgroup(global uint4 *out, global int *scalar) {
+kernel void extended_subgroup(global uint4 *out, global int *scalar, global 
char2 *c2) {
   out[0] = get_sub_group_eq_mask();
   scalar[0] = sub_group_non_uniform_scan_inclusive_or(3);
   scalar[1] = sub_group_clustered_reduce_logical_xor(2, 4);
+  *c2 = sub_group_broadcast(*c2, 2);
 #if __OPENCL_C_VERSION__ < CL_VERSION_2_0 && !defined(__OPENCL_CPP_VERSION__)
-  // expected-error@-4{{implicit declaration of function 
'get_sub_group_eq_mask' is invalid in OpenCL}}
-  // expected-error@-5{{implicit conversion changes signedness}}
-  // expected-error@-5{{implicit declaration of function 
'sub_group_non_uniform_scan_inclusive_or' is invalid in OpenCL}}
-  // expected-error@-5{{implicit declaration of function 
'sub_group_clustered_reduce_logical_xor' is invalid in OpenCL}}
+  // expected-error@-5{{implicit declaration of function 
'get_sub_group_eq_mask' is invalid in OpenCL}}
+  // expected-error@-6{{implicit conversion changes signedness}}
+  // expected-error@-6{{implicit declaration of function 
'sub_group_non_uniform_scan_inclusive_or' is invalid in OpenCL}}
+  // expected-error@-6{{implicit declaration of function 
'sub_group_clustered_reduce_logical_xor' is invalid in OpenCL}}
+  // expected-error@-6{{implicit declaration of function 'sub_group_broadcast' 
is invalid in OpenCL}}
+  // expected-error@-7{{implicit conversion loses integer precision}}
 #endif
 }
 
Index: clang/lib/Sema/OpenCLBuiltins.td
===
--- clang/lib/Sema/OpenCLBuiltins.td
+++ clang/lib/Sema/OpenCLBuiltins.td
@@ -53,6 +53,7 @@
 // FunctionExtension definitions.
 def FuncExtNone  : FunctionExtension<"">;
 def FuncExtKhrSubgroups  : 
FunctionExtension<"cl_khr_subgroups">;
+def FuncExtKhrSubgroupExtendedTypes  : 
FunctionExtension<"cl_khr_subgroup_extended_types">;
 def FuncExtKhrSubgroupNonUniformVote : 
FunctionExtension<"cl_khr_subgroup_non_uniform_vote">;
 def FuncExtKhrSubgroupBallot : 
FunctionExtension<"cl_khr_subgroup_ballot">;
 def FuncExtKhrSubgroupNonUniformArithmetic: 
FunctionExtension<"cl_khr_subgroup_non_uniform_arithmetic">;
@@ -367,6 +368,9 @@
 def FGenTypeN  : GenericType<"FGenTypeN", TLFloat, VecAndScalar>;
 // (u)int, (u)long, and all floats
 def IntLongFloatGenType1   : GenericType<"IntLongFloatGenType1", 
TLIntLongFloats, Vec1>;
+// (u)char and (u)short
+def CharShortGenType1  : GenericType<"CharShortGenType1",
+ TypeList<[Char, UChar, Short, UShort]>, Vec1>;
 
 // GenType definitions for every single base type (e.g. fp32 only).
 // Names are like: GenTypeFloatVecAndScalar.
@@ -1496,7 +1500,19 @@
 // OpenCL Extension v3.0 s38 - Extended Subgroup Functions
 
 // Section 38.4.1 - cl_khr_subgroup_extended_types
-// TODO
+let Extension = FuncExtKhrSubgroupExtendedTypes in {
+  // For sub_group_broadcast, add scalar char, uchar, short, and ushort 
support,
+  def : Builtin<"sub_group_broadcast", [CharShortGenType1, CharShortGenType1, 
UInt], Attr.Convergent>;
+  // gentype may additionally be one of the supported built-in vector data 
types.
+  def : Builtin<"sub_group_broadcast", [AGenTypeNNoScalar, AGenTypeNNoScalar, 
UInt], Attr.Convergent>;
+
+  foreach name = ["sub_group_reduce_", "sub_group_scan_exclusive_",
+  "sub_group_scan_inclusive_"] in {
+foreach op = ["add", "min", "max"] in {
+  def : Builtin;
+}
+  }
+}
 
 // Section 38.5.1 - cl_khr_subgroup_non_uniform_vote
 let Extension = FuncExtKhrSubgroupNonUniformVote in {


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -36,6 +36,7 @@
 
 // Enable extensions tha

[PATCH] D96281: [clang-tidy] Add options to flag individual core increments and to ignore macros to readability-function-cognitive-complexity check.

[Jens Massberg via Phabricator via cfe-commits]

massberg updated this revision to Diff 322921.
massberg added a comment.

Clarified option FlagBasicIncrements and removed base default constructor from 
class initializer list of FunctionASTVisitor.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96281

Files:
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity-flags.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity-flags.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity-flags.cpp
@@ -0,0 +1,64 @@
+// RUN: %check_clang_tidy %s readability-function-cognitive-complexity %t -- \
+// RUN:   -config='{CheckOptions: \
+// RUN: [{key: readability-function-cognitive-complexity.Threshold, \
+// RUN:   value: 0}, \
+// RUN:  {key: readability-function-cognitive-complexity.FlagBasicIncrements, \
+// RUN:   value: "false"} ]}'
+// RUN: %check_clang_tidy -check-suffix=THRESHOLD5 %s readability-function-cognitive-complexity %t -- \
+// RUN:   -config='{CheckOptions: \
+// RUN: [{key: readability-function-cognitive-complexity.Threshold, \
+// RUN:   value: 5}, \
+// RUN:  {key: readability-function-cognitive-complexity.FlagBasicIncrements, \
+// RUN:   value: "false"} ]}'
+// RUN: %check_clang_tidy -check-suffix=IGNORE-MACROS %s readability-function-cognitive-complexity %t -- \
+// RUN:   -config='{CheckOptions: \
+// RUN: [{key: readability-function-cognitive-complexity.Threshold, \
+// RUN:   value: 0}, \
+// RUN:  {key: readability-function-cognitive-complexity.IgnoreMacros, \
+// RUN:   value: "true"}, \
+// RUN:  {key: readability-function-cognitive-complexity.FlagBasicIncrements, \
+// RUN:   value: "false"} ]}'
+
+void func_of_complexity_4() {
+  // CHECK-NOTES: :[[@LINE-1]]:6: warning: function 'func_of_complexity_4' has cognitive complexity of 4 (threshold 0) [readability-function-cognitive-complexity]
+  // CHECK-NOTES-IGNORE-MACROS: :[[@LINE-2]]:6: warning: function 'func_of_complexity_4' has cognitive complexity of 4 (threshold 0) [readability-function-cognitive-complexity]
+  if (1) {
+if (1) {
+}
+  }
+  if (1) {
+  }
+}
+
+#define MacroOfComplexity10 \
+  if (1) {  \
+if (1) {\
+  if (1) {  \
+if (1) {\
+}   \
+  } \
+}   \
+  }
+
+void function_with_macro() {
+  // CHECK-NOTES: :[[@LINE-1]]:6: warning: function 'function_with_macro' has cognitive complexity of 11 (threshold 0) [readability-function-cognitive-complexity]
+  // CHECK-NOTES-THRESHOLD5: :[[@LINE-2]]:6: warning: function 'function_with_macro' has cognitive complexity of 11 (threshold 5) [readability-function-cognitive-complexity]
+  // CHECK-NOTES-IGNORE-MACROS: :[[@LINE-3]]:6: warning: function 'function_with_macro' has cognitive complexity of 1 (threshold 0) [readability-function-cognitive-complexity]
+
+  MacroOfComplexity10
+
+  if (1) {
+  }
+}
+
+#define uglyfunctionmacro(name) \
+  void name() { \
+if (true) { \
+  try { \
+  } catch (...) {   \
+  } \
+}   \
+  }
+
+uglyfunctionmacro(MacroFunction)
+// CHECK-NOTES: :[[@LINE-1]]:19: warning: function 'MacroFunction' has cognitive complexity of 3 (threshold 0) [readability-function-cognitive-complexity]
Index: clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst
+++ clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst
@@ -17,6 +17,17 @@
Flag functions with Cognitive Complexity exceeding this number.
The default is `25`.
 
+.. option:: FlagBasicIncrements
+
+   If set to `true`, additional to flagging functions exceeding the threshold
+   also every piece of code (loops, if statements, ...) which contributes to
+   that complexity is flagged. Default is `true`.
+
+.. option:: IgnoreMacros
+
+   If set to `true`, the check will ignore code inside macros. Default is
+   `false`.
+
 Building blocks
 ---
 
Index: clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.h
==

[PATCH] D96353: [clangd] Use ML Code completion ranking as default.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 updated this revision to Diff 322922.
usaxena95 marked 2 inline comments as done.
usaxena95 added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96353

Files:
  clang-tools-extra/clangd/CodeComplete.h
  clang-tools-extra/clangd/Quality.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -647,13 +647,13 @@
 }
 
 TEST(CompletionTest, ReferencesAffectRanking) {
-  auto Results = completions("int main() { abs^ }", {ns("absl"), 
func("absb")});
-  EXPECT_THAT(Results.Completions,
-  HasSubsequence(Named("absb"), Named("absl")));
-  Results = completions("int main() { abs^ }",
-{withReferences(1, ns("absl")), func("absb")});
-  EXPECT_THAT(Results.Completions,
-  HasSubsequence(Named("absl"), Named("absb")));
+  EXPECT_THAT(completions("int main() { abs^ }", {func("absA"), func("absB")})
+  .Completions,
+  HasSubsequence(Named("absA"), Named("absB")));
+  EXPECT_THAT(completions("int main() { abs^ }",
+  {func("absA"), withReferences(1000, func("absB"))})
+  .Completions,
+  HasSubsequence(Named("absB"), Named("absA")));
 }
 
 TEST(CompletionTest, ContextWords) {
Index: clang-tools-extra/clangd/Quality.cpp
===
--- clang-tools-extra/clangd/Quality.cpp
+++ clang-tools-extra/clangd/Quality.cpp
@@ -580,12 +580,16 @@
   // multiplciative boost (like NameMatch). This allows us to weigh the
   // prediciton score and NameMatch appropriately.
   Scores.ExcludingName = pow(Base, Evaluate(E));
-  // NeedsFixIts is not part of the DecisionForest as generating training
-  // data that needs fixits is not-feasible.
+  // Following cases are not part of the generated training dataset:
+  //  - Symbols with `NeedsFixIts`.
+  //  - Forbidden symbols.
+  //  - Keywords: Dataset contains only macros and decls.
   if (Relevance.NeedsFixIts)
 Scores.ExcludingName *= 0.5;
   if (Relevance.Forbidden)
 Scores.ExcludingName *= 0;
+  if (Quality.Category == SymbolQualitySignals::Keyword)
+Scores.ExcludingName *= 4;
 
   // NameMatch should be a multiplier on total score to support rescoring.
   Scores.Total = Relevance.NameMatch * Scores.ExcludingName;
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -133,7 +133,7 @@
   enum CodeCompletionRankingModel {
 Heuristics,
 DecisionForest,
-  } RankingModel = Heuristics;
+  } RankingModel = DecisionForest;
 
   /// Callback used to score a CompletionCandidate if DecisionForest ranking
   /// model is enabled.


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -647,13 +647,13 @@
 }
 
 TEST(CompletionTest, ReferencesAffectRanking) {
-  auto Results = completions("int main() { abs^ }", {ns("absl"), func("absb")});
-  EXPECT_THAT(Results.Completions,
-  HasSubsequence(Named("absb"), Named("absl")));
-  Results = completions("int main() { abs^ }",
-{withReferences(1, ns("absl")), func("absb")});
-  EXPECT_THAT(Results.Completions,
-  HasSubsequence(Named("absl"), Named("absb")));
+  EXPECT_THAT(completions("int main() { abs^ }", {func("absA"), func("absB")})
+  .Completions,
+  HasSubsequence(Named("absA"), Named("absB")));
+  EXPECT_THAT(completions("int main() { abs^ }",
+  {func("absA"), withReferences(1000, func("absB"))})
+  .Completions,
+  HasSubsequence(Named("absB"), Named("absA")));
 }
 
 TEST(CompletionTest, ContextWords) {
Index: clang-tools-extra/clangd/Quality.cpp
===
--- clang-tools-extra/clangd/Quality.cpp
+++ clang-tools-extra/clangd/Quality.cpp
@@ -580,12 +580,16 @@
   // multiplciative boost (like NameMatch). This allows us to weigh the
   // prediciton score and NameMatch appropriately.
   Scores.ExcludingName = pow(Base, Evaluate(E));
-  // NeedsFixIts is not part of the DecisionForest as generating training
-  // data that needs fixits is not-feasible.
+  // Following cases are not part of the generated training dataset:
+  //  - Symbols with `NeedsFixIts`.
+  //  - Forbidden symbols.
+  //  - Keywords: Dataset contains onl

[PATCH] D96353: [clangd] Use ML Code completion ranking as default.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 added inline comments.



Comment at: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp:651
+  auto Results =
+  completions("int main() { abs^ }", {func("absl"), func("absb")});
   EXPECT_THAT(Results.Completions,

hokein wrote:
> sorry, I didn't infer the motivation of this change func->ns from this patch, 
> could you explain?
Sorry about not highlighting this.
The ML model doesn't rank the function before the namespace. I removed this and 
made both of these as functions to independently validate the effect of 
references.



Comment at: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp:655
   Results = completions("int main() { abs^ }",
-{withReferences(1, ns("absl")), func("absb")});
-  EXPECT_THAT(Results.Completions,
-  HasSubsequence(Named("absl"), Named("absb")));
+{withReferences(100, func("absl")), func("absb")});
 }

hokein wrote:
> looks like the Results here is not verified, as you remove the line below, is 
> it intentional?
Oops. Thanks!.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96353

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

[PATCH] D96481: [NFC] Extract function which registers sanitizer passes

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka created this revision.
vitalybuka added reviewers: aeubanks, tejohnson.
vitalybuka 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/D96481

Files:
  clang/lib/CodeGen/BackendUtil.cpp

Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1058,6 +1058,70 @@
   }
 }
 
+static void addSanitizers(const Triple &TargetTriple,
+  const CodeGenOptions &CodeGenOpts,
+  const LangOptions &LangOpts, PassBuilder &PB) {
+  PB.registerOptimizerLastEPCallback([&](ModulePassManager &MPM,
+ PassBuilder::OptimizationLevel Level) {
+if (CodeGenOpts.SanitizeCoverageType ||
+CodeGenOpts.SanitizeCoverageIndirectCalls ||
+CodeGenOpts.SanitizeCoverageTraceCmp) {
+  auto SancovOpts = getSancovOptsFromCGOpts(CodeGenOpts);
+  MPM.addPass(ModuleSanitizerCoveragePass(
+  SancovOpts, CodeGenOpts.SanitizeCoverageAllowlistFiles,
+  CodeGenOpts.SanitizeCoverageBlocklistFiles));
+}
+
+auto MSanPass = [&](SanitizerMask Mask, bool CompileKernel) {
+  if (LangOpts.Sanitize.has(Mask)) {
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
+
+MPM.addPass(
+MemorySanitizerPass({TrackOrigins, Recover, CompileKernel}));
+MPM.addPass(createModuleToFunctionPassAdaptor(
+MemorySanitizerPass({TrackOrigins, Recover, CompileKernel})));
+  }
+};
+MSanPass(SanitizerKind::Memory, false);
+MSanPass(SanitizerKind::KernelMemory, true);
+
+if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
+  MPM.addPass(ThreadSanitizerPass());
+  MPM.addPass(createModuleToFunctionPassAdaptor(ThreadSanitizerPass()));
+}
+
+auto ASanPass = [&](SanitizerMask Mask, bool CompileKernel) {
+  if (LangOpts.Sanitize.has(Mask)) {
+bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
+bool UseAfterScope = CodeGenOpts.SanitizeAddressUseAfterScope;
+bool ModuleUseAfterScope = asanUseGlobalsGC(TargetTriple, CodeGenOpts);
+bool UseOdrIndicator = CodeGenOpts.SanitizeAddressUseOdrIndicator;
+MPM.addPass(RequireAnalysisPass());
+MPM.addPass(ModuleAddressSanitizerPass(
+CompileKernel, Recover, ModuleUseAfterScope, UseOdrIndicator));
+MPM.addPass(createModuleToFunctionPassAdaptor(
+AddressSanitizerPass(CompileKernel, Recover, UseAfterScope)));
+  }
+};
+ASanPass(SanitizerKind::Address, false);
+ASanPass(SanitizerKind::KernelAddress, true);
+
+auto HWASanPass = [&](SanitizerMask Mask, bool CompileKernel) {
+  if (LangOpts.Sanitize.has(Mask)) {
+bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
+MPM.addPass(HWAddressSanitizerPass(CompileKernel, Recover));
+  }
+};
+HWASanPass(SanitizerKind::HWAddress, false);
+HWASanPass(SanitizerKind::KernelHWAddress, true);
+
+if (LangOpts.Sanitize.has(SanitizerKind::DataFlow)) {
+  MPM.addPass(DataFlowSanitizerPass(LangOpts.SanitizerBlacklistFiles));
+}
+  });
+}
+
 /// A clean version of `EmitAssembly` that uses the new pass manager.
 ///
 /// Not all features are currently supported in this system, but where
@@ -1249,87 +1313,7 @@
 FPM.addPass(BoundsCheckingPass());
   });
 
-if (CodeGenOpts.SanitizeCoverageType ||
-CodeGenOpts.SanitizeCoverageIndirectCalls ||
-CodeGenOpts.SanitizeCoverageTraceCmp) {
-  PB.registerOptimizerLastEPCallback(
-  [this](ModulePassManager &MPM, PassBuilder::OptimizationLevel Level) {
-auto SancovOpts = getSancovOptsFromCGOpts(CodeGenOpts);
-MPM.addPass(ModuleSanitizerCoveragePass(
-SancovOpts, CodeGenOpts.SanitizeCoverageAllowlistFiles,
-CodeGenOpts.SanitizeCoverageBlocklistFiles));
-  });
-}
-
-auto MSanPass = [&](SanitizerMask Mask, bool CompileKernel) {
-  if (LangOpts.Sanitize.has(Mask)) {
-int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
-bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
-PB.registerOptimizerLastEPCallback(
-[CompileKernel, TrackOrigins, Recover](
-ModulePassManager &MPM, PassBuilder::OptimizationLevel Level) {
-  MPM.addPass(
-  MemorySanitizerPass({TrackOrigins, Recover, CompileKernel}));
-  MPM.addPass(createModuleToFunctionPassAdaptor(
-  MemorySanitizerPass({TrackOrigins, Recover, CompileKernel})));
-});
-  }
-};
-MSanPass(SanitizerKind::Memory, false);
-MSanPass(SanitizerKind::KernelMemory, true);
-
-if (LangOpts.Sani

[PATCH] D96456: [ThinLTO, NewPM] Add Config::OptPassBuilderHook

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka updated this revision to Diff 322924.
vitalybuka marked an inline comment as done.
vitalybuka added a comment.

update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96456

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/LTO/Config.h
  llvm/lib/LTO/LTOBackend.cpp

Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -253,6 +253,9 @@
   PB.registerLoopAnalyses(LAM);
   PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);
 
+  if (Conf.OptimizerLastPassBuilderHook)
+Conf.OptimizerLastPassBuilderHook(PB);
+
   ModulePassManager MPM(Conf.DebugPassManager);
 
   if (!Conf.DisableVerify)
Index: llvm/include/llvm/LTO/Config.h
===
--- llvm/include/llvm/LTO/Config.h
+++ llvm/include/llvm/LTO/Config.h
@@ -48,7 +48,9 @@
   TargetOptions Options;
   std::vector MAttrs;
   std::vector PassPlugins;
-  /// For adding passes that run right before codegen.
+  /// For adding passes that run by optimizer.
+  std::function OptimizerLastPassBuilderHook;
+  /// For adding passes that run right before codegen (NewPM only).
   std::function PreCodeGenPassesHook;
   Optional RelocModel = Reloc::PIC_;
   Optional CodeModel = None;
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1063,63 +1063,80 @@
   const LangOptions &LangOpts, PassBuilder &PB) {
   PB.registerOptimizerLastEPCallback([&](ModulePassManager &MPM,
  PassBuilder::OptimizationLevel Level) {
-if (CodeGenOpts.SanitizeCoverageType ||
-CodeGenOpts.SanitizeCoverageIndirectCalls ||
-CodeGenOpts.SanitizeCoverageTraceCmp) {
-  auto SancovOpts = getSancovOptsFromCGOpts(CodeGenOpts);
-  MPM.addPass(ModuleSanitizerCoveragePass(
-  SancovOpts, CodeGenOpts.SanitizeCoverageAllowlistFiles,
-  CodeGenOpts.SanitizeCoverageBlocklistFiles));
-}
-
-auto MSanPass = [&](SanitizerMask Mask, bool CompileKernel) {
-  if (LangOpts.Sanitize.has(Mask)) {
-int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
-bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
-
-MPM.addPass(
-MemorySanitizerPass({TrackOrigins, Recover, CompileKernel}));
-MPM.addPass(createModuleToFunctionPassAdaptor(
-MemorySanitizerPass({TrackOrigins, Recover, CompileKernel})));
-  }
-};
-MSanPass(SanitizerKind::Memory, false);
-MSanPass(SanitizerKind::KernelMemory, true);
-
-if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
-  MPM.addPass(ThreadSanitizerPass());
-  MPM.addPass(createModuleToFunctionPassAdaptor(ThreadSanitizerPass()));
-}
-
-auto ASanPass = [&](SanitizerMask Mask, bool CompileKernel) {
-  if (LangOpts.Sanitize.has(Mask)) {
-bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
-bool UseAfterScope = CodeGenOpts.SanitizeAddressUseAfterScope;
-bool ModuleUseAfterScope = asanUseGlobalsGC(TargetTriple, CodeGenOpts);
-bool UseOdrIndicator = CodeGenOpts.SanitizeAddressUseOdrIndicator;
-MPM.addPass(RequireAnalysisPass());
-MPM.addPass(ModuleAddressSanitizerPass(
-CompileKernel, Recover, ModuleUseAfterScope, UseOdrIndicator));
-MPM.addPass(createModuleToFunctionPassAdaptor(
-AddressSanitizerPass(CompileKernel, Recover, UseAfterScope)));
-  }
-};
-ASanPass(SanitizerKind::Address, false);
-ASanPass(SanitizerKind::KernelAddress, true);
+PB.registerOptimizerLastEPCallback(
+[&](ModulePassManager &MPM, PassBuilder::OptimizationLevel Level) {
+  if (CodeGenOpts.OptimizationLevel == 0) {
+if (!CodeGenOpts.ThinLTOIndexFile.empty())
+  llvm::report_fatal_error(
+  "Unexpected optimizer in non-optimized ThinLTO PostLink");
+  } else {
+if (CodeGenOpts.PrepareForThinLTO)
+  llvm::report_fatal_error(
+  "Unexpected optimizer in optimized ThinLTO PreLink");
+  }
+
+  if (CodeGenOpts.SanitizeCoverageType ||
+  CodeGenOpts.SanitizeCoverageIndirectCalls ||
+  CodeGenOpts.SanitizeCoverageTraceCmp) {
+auto SancovOpts = getSancovOptsFromCGOpts(CodeGenOpts);
+MPM.addPass(ModuleSanitizerCoveragePass(
+SancovOpts, CodeGenOpts.SanitizeCoverageAllowlistFiles,
+CodeGenOpts.SanitizeCoverageBlocklistFiles));
+  }
+
+  auto MSanPass = [&](SanitizerMask Mask, bool CompileKernel) {
+if (LangOpts.Sanitize.has(Mask)) {
+  int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOri

[PATCH] D96281: [clang-tidy] Add options to flag individual core increments and to ignore macros to readability-function-cognitive-complexity check.

[Jens Massberg via Phabricator via cfe-commits]

massberg marked 2 inline comments as done.
massberg added a comment.

Thanks for the comments!




Comment at: 
clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:230
+  explicit FunctionASTVisitor(const bool IgnoreMacros)
+  : RecursiveASTVisitor(), 
IgnoreMacros(IgnoreMacros){};
+

alexfh wrote:
> Is a default base class constructor entry necessary in the class initializer 
> list?
You are right, that wasn't needed.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst:22
+
+   If set to `true`, the check will flag every basic increment. Default
+   is `true`.

alexfh wrote:
> What does "flag every basic increment" mean? Can you explain in more detail 
> and maybe add an example?
I hope the new description explains now the flag sufficiently.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96281

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

[PATCH] D96353: [clangd] Use ML Code completion ranking as default.

[Haojian Wu via Phabricator via cfe-commits]

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

maybe add some data (improvement DecisionForest vs heuristic) in the patch 
description.




Comment at: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp:651
+  auto Results =
+  completions("int main() { abs^ }", {func("absl"), func("absb")});
   EXPECT_THAT(Results.Completions,

usaxena95 wrote:
> hokein wrote:
> > sorry, I didn't infer the motivation of this change func->ns from this 
> > patch, could you explain?
> Sorry about not highlighting this.
> The ML model doesn't rank the function before the namespace. I removed this 
> and made both of these as functions to independently validate the effect of 
> references.
ah, I see, that makes sense, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96353

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

[PATCH] D96376: [CodeComplete] Member completion: heuristically resolve some dependent base exprs

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang/test/CodeCompletion/member-access.cpp:88
+  TemplateClass &relatedField;
+  BaseTemplate &relatedFunction();
+

hokein wrote:
> hmm, inserting new code here will shift all offsets of below code, I would 
> append a new test in this file to keep a clearer history. but up to you. 
I see your point about history, but I find myself navigating these tests by 
semantics more often than by history, and this seems closely related to the 
existing completeDependentMembers cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96376

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

[clang] 5c55d37 - [CodeComplete] Member completion: heuristically resolve some dependent base exprs

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2021-02-11T11:03:40+01:00
New Revision: 5c55d3747b0cab17aaa07729cf90a49dbda71bbe

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

LOG: [CodeComplete] Member completion: heuristically resolve some dependent 
base exprs

Today, inside a template, you can get completion for:

Foo t;
t.^

t has dependent type Foo, and we use the primary template to find its 
members.
However we also want this to work:

t.foo.bar().^

The type of t.foo.bar() is DependentTy, so we attempt to resolve using similar
heuristics (e.g. primary template).

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

Added: 


Modified: 
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
clang/lib/Sema/SemaCodeComplete.cpp
clang/test/CodeCompletion/member-access.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp 
b/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
index 5e8e242086ba..9403cda57cfe 100644
--- a/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ b/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -1098,6 +1098,20 @@ template  class TT> int foo() {
   EXPECT_THAT(Completions, Contains(Named("TT")));
 }
 
+TEST(CompletionTest, NestedTemplateHeuristics) {
+  auto Completions = completions(R"cpp(
+struct Plain { int xxx; };
+template  class Templ { Plain ppp; };
+template  void foo(Templ &t) {
+  // Formally ppp has DependentTy, because Templ may be specialized.
+  // However we sholud be able to see into it using the primary template.
+  t.ppp.^
+}
+)cpp")
+ .Completions;
+  EXPECT_THAT(Completions, Contains(Named("xxx")));
+}
+
 TEST(CompletionTest, RecordCCResultCallback) {
   std::vector RecordedCompletions;
   CodeCompleteOptions Opts;

diff  --git a/clang/lib/Sema/SemaCodeComplete.cpp 
b/clang/lib/Sema/SemaCodeComplete.cpp
index 2f5a28e132b3..1e4d5dd62aa0 100644
--- a/clang/lib/Sema/SemaCodeComplete.cpp
+++ b/clang/lib/Sema/SemaCodeComplete.cpp
@@ -5176,6 +5176,75 @@ class ConceptInfo {
 
   llvm::DenseMap Results;
 };
+
+// Returns a type for E that yields acceptable member completions.
+// In particular, when E->getType() is DependentTy, try to guess a likely type.
+// We accept some lossiness (like dropping parameters).
+// We only try to handle common expressions on the LHS of MemberExpr.
+QualType getApproximateType(const Expr *E) {
+  QualType Unresolved = E->getType();
+  if (Unresolved.isNull() ||
+  !Unresolved->isSpecificBuiltinType(BuiltinType::Dependent))
+return Unresolved;
+  E = E->IgnoreParens();
+  // A call: approximate-resolve callee to a function type, get its return type
+  if (const CallExpr *CE = llvm::dyn_cast(E)) {
+QualType Callee = getApproximateType(CE->getCallee());
+if (Callee.isNull() ||
+Callee->isSpecificPlaceholderType(BuiltinType::BoundMember))
+  Callee = Expr::findBoundMemberType(CE->getCallee());
+if (Callee.isNull())
+  return Unresolved;
+
+if (const auto *FnTypePtr = Callee->getAs()) {
+  Callee = FnTypePtr->getPointeeType();
+} else if (const auto *BPT = Callee->getAs()) {
+  Callee = BPT->getPointeeType();
+}
+if (const FunctionType *FnType = Callee->getAs())
+  return FnType->getReturnType().getNonReferenceType();
+
+// Unresolved call: try to guess the return type.
+if (const auto *OE = llvm::dyn_cast(CE->getCallee())) {
+  // If all candidates have the same approximate return type, use it.
+  // Discard references and const to allow more to be "the same".
+  // (In particular, if there's one candidate + ADL, resolve it).
+  const Type *Common = nullptr;
+  for (const auto *D : OE->decls()) {
+QualType ReturnType;
+if (const auto *FD = llvm::dyn_cast(D))
+  ReturnType = FD->getReturnType();
+else if (const auto *FTD = llvm::dyn_cast(D))
+  ReturnType = FTD->getTemplatedDecl()->getReturnType();
+if (ReturnType.isNull())
+  continue;
+const Type *Candidate =
+ReturnType.getNonReferenceType().getCanonicalType().getTypePtr();
+if (Common && Common != Candidate)
+  return Unresolved; // Multiple candidates.
+Common = Candidate;
+  }
+  if (Common != nullptr)
+return QualType(Common, 0);
+}
+  }
+  // A dependent member: approximate-resolve the base, then lookup.
+  if (const auto *CDSME = llvm::dyn_cast(E)) {
+QualType Base = CDSME->isImplicitAccess()
+? CDSME->getBaseType()
+: getApproximateType(CDSME->getBase());
+if (CDSME->isArrow() && !Base.isNull())
+  Base = Base->getPointeeType(); // could handle unique_ptr etc here?
+RecordDecl *RD = Base.isNull() ? n

[PATCH] D96376: [CodeComplete] Member completion: heuristically resolve some dependent base exprs

[Sam McCall 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 rG5c55d3747b0c: [CodeComplete] Member completion: 
heuristically resolve some dependent base… (authored by sammccall).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96376

Files:
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/test/CodeCompletion/member-access.cpp

Index: clang/test/CodeCompletion/member-access.cpp
===
--- clang/test/CodeCompletion/member-access.cpp
+++ clang/test/CodeCompletion/member-access.cpp
@@ -84,6 +84,9 @@
   T function() { }
   T field;
 
+  TemplateClass &relatedField;
+  BaseTemplate &relatedFunction();
+
   void overload1(const T &);
   void overload1(const S &);
 };
@@ -102,8 +105,12 @@
 // CHECK-CC2: overload1 : [#void#]overload1(<#const T &#>)
 // CHECK-CC2: overload1 : [#void#]overload1(<#const S &#>)
 
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:94:10 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:95:12 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:97:10 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:98:12 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
+
+  object.relatedField.relatedFunction().baseTemplateField;
+// CHECK-DEP-CHAIN: baseTemplateField : [#T#]baseTemplateField
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:111:41 %s -o - | FileCheck -check-prefix=CHECK-DEP-CHAIN %s
 }
 
 
@@ -120,8 +127,8 @@
 // CHECK-CC3: overload1 : [#void#]overload1(<#const int &#>)
 // CHECK-CC3: overload1 : [#void#]overload1(<#const double &#>)
 
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:112:10 %s -o - | FileCheck -check-prefix=CHECK-CC3 %s
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:113:12 %s -o - | FileCheck -check-prefix=CHECK-CC3 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:119:10 %s -o - | FileCheck -check-prefix=CHECK-CC3 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:120:12 %s -o - | FileCheck -check-prefix=CHECK-CC3 %s
 }
 
 template 
@@ -135,17 +142,17 @@
 // CHECK-CC4: BaseTemplate : BaseTemplate::
 // CHECK-CC4: baseTemplateField : [#int#]baseTemplateField
 // CHECK-CC4: baseTemplateFunction : [#int#]baseTemplateFunction()
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:134:8 %s -o - | FileCheck -check-prefix=CHECK-CC4 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:141:8 %s -o - | FileCheck -check-prefix=CHECK-CC4 %s
 o2.baseTemplateField;
 // CHECK-CC5: BaseTemplate : BaseTemplate::
 // CHECK-CC5: baseTemplateField : [#T#]baseTemplateField
 // CHECK-CC5: baseTemplateFunction : [#T#]baseTemplateFunction()
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:139:8 %s -o - | FileCheck -check-prefix=CHECK-CC5 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:146:8 %s -o - | FileCheck -check-prefix=CHECK-CC5 %s
 this->o1;
 // CHECK-CC6: [#void#]function()
 // CHECK-CC6: o1 : [#BaseTemplate#]o1
 // CHECK-CC6: o2 : [#BaseTemplate#]o2
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:144:11 %s -o - | FileCheck -check-prefix=CHECK-CC6 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:151:11 %s -o - | FileCheck -check-prefix=CHECK-CC6 %s
   }
 
   static void staticFn(T &obj);
@@ -162,9 +169,9 @@
 // CHECK-CC7: o2 : [#BaseTemplate#]o2
 // CHECK-CC7: staticFn : [#void#]staticFn(<#T &obj#>)
 // CHECK-CC7: Template : Template
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:158:16 %s -o - | FileCheck -check-prefix=CHECK-CC7 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:165:16 %s -o - | FileCheck -check-prefix=CHECK-CC7 %s
   typename Template::Nested m;
-// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:166:25 %s -o - | FileCheck -check-prefix=CHECK-CC7 %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:173:25 %s -o - | FileCheck -check-prefix=CHECK-CC7 %s
 }
 
 class Proxy2 {
@@ -181,34 +188,34 @@
   p.
 }
 
-// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits -code-completion-at=%s:177:6 %s -o - | FileCheck -check-prefix=CHECK-CC8 --implicit-check-not="Derived : Derived(" %s
+// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits -code-completion-at=%s:184:6 %s -o - | FileCheck -check-prefix=CHECK-CC8 --implicit-check-not="Derived : Derived(" %s
 // CHECK-CC8: Base1 (InBase) : Base1::
 // CHECK-CC8: member1 (InBase) : [#int#][#Base1::#]member1
 // CHECK-CC8: member1 (InBase) : [#int#][#Base2::#]member1
 // CHECK-CC8: member2 (InBase) : [#float#][#Base1::#]member2
 // CHECK-CC8: member3 (InBase) : [#double#][#Base2::#]member3
 // CHECK-CC8: member4 : [#int#]member4
-// CHECK-CC8:

[PATCH] D96262: [clang][index] report references from unreslovedLookupExpr.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 322927.
hokein added a comment.

address comment, add more tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96262

Files:
  clang-tools-extra/clangd/unittests/XRefsTests.cpp
  clang/lib/Index/IndexBody.cpp
  clang/test/Index/Core/index-dependent-source.cpp


Index: clang/test/Index/Core/index-dependent-source.cpp
===
--- clang/test/Index/Core/index-dependent-source.cpp
+++ clang/test/Index/Core/index-dependent-source.cpp
@@ -224,3 +224,10 @@
 // CHECK: [[@LINE+1]]:9 | struct(Gen)/C++ | UsingD | c:@ST>1#T@UsingD | 
 | Ref,RelCont | rel: 1
   using UsingD::foo;
 };
+
+template  void foo();
+// CHECK: [[@LINE-1]]:28 | function/C | foo | c:@FT@>1#Tfoo#v# |  | 
Decl | rel: 0
+template  void bar() {
+  foo();
+// CHECK: [[@LINE-1]]:3 | function/C | foo | c:@FT@>1#Tfoo#v# |  | 
Ref,Call,RelCall,RelCont | rel: 1
+}
Index: clang/lib/Index/IndexBody.cpp
===
--- clang/lib/Index/IndexBody.cpp
+++ clang/lib/Index/IndexBody.cpp
@@ -466,6 +466,15 @@
 }
 return true;
   }
+
+  bool VisitUnresolvedLookupExpr(UnresolvedLookupExpr *E) {
+SmallVector Relations;
+SymbolRoleSet Roles = getRolesForRef(E, Relations);
+for (auto *D : E->decls())
+  IndexCtx.handleReference(D, E->getNameLoc(), Parent, ParentDC, Roles,
+   Relations, E);
+return true;
+  }
 };
 
 } // anonymous namespace
Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -1863,6 +1863,26 @@
 Vector x2;
 Vector y;
   )cpp",
+  R"cpp(// Dependent code
+template  void $decl[[foo]](T t);
+template  void bar(T t) { [[foo]](t); } // foo in bar is 
uninstantiated.
+void baz(int x) { [[f^oo]](x); }
+  )cpp",
+  R"cpp(
+namespace ns {
+struct S{};
+void $decl[[foo]](S s);
+} // namespace ns
+template  void foo(T t);
+// FIXME: Maybe report this foo as a ref to ns::foo (because of ADL)
+// when bar is instantiated?
+template  void bar(T t) { foo(t); }
+void baz(int x) {
+  ns::S s;
+  bar(s);
+  [[f^oo]](s);
+}
+  )cpp",
   };
   for (const char *Test : Tests)
 checkFindRefs(Test);


Index: clang/test/Index/Core/index-dependent-source.cpp
===
--- clang/test/Index/Core/index-dependent-source.cpp
+++ clang/test/Index/Core/index-dependent-source.cpp
@@ -224,3 +224,10 @@
 // CHECK: [[@LINE+1]]:9 | struct(Gen)/C++ | UsingD | c:@ST>1#T@UsingD |  | Ref,RelCont | rel: 1
   using UsingD::foo;
 };
+
+template  void foo();
+// CHECK: [[@LINE-1]]:28 | function/C | foo | c:@FT@>1#Tfoo#v# |  | Decl | rel: 0
+template  void bar() {
+  foo();
+// CHECK: [[@LINE-1]]:3 | function/C | foo | c:@FT@>1#Tfoo#v# |  | Ref,Call,RelCall,RelCont | rel: 1
+}
Index: clang/lib/Index/IndexBody.cpp
===
--- clang/lib/Index/IndexBody.cpp
+++ clang/lib/Index/IndexBody.cpp
@@ -466,6 +466,15 @@
 }
 return true;
   }
+
+  bool VisitUnresolvedLookupExpr(UnresolvedLookupExpr *E) {
+SmallVector Relations;
+SymbolRoleSet Roles = getRolesForRef(E, Relations);
+for (auto *D : E->decls())
+  IndexCtx.handleReference(D, E->getNameLoc(), Parent, ParentDC, Roles,
+   Relations, E);
+return true;
+  }
 };
 
 } // anonymous namespace
Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -1863,6 +1863,26 @@
 Vector x2;
 Vector y;
   )cpp",
+  R"cpp(// Dependent code
+template  void $decl[[foo]](T t);
+template  void bar(T t) { [[foo]](t); } // foo in bar is uninstantiated.
+void baz(int x) { [[f^oo]](x); }
+  )cpp",
+  R"cpp(
+namespace ns {
+struct S{};
+void $decl[[foo]](S s);
+} // namespace ns
+template  void foo(T t);
+// FIXME: Maybe report this foo as a ref to ns::foo (because of ADL)
+// when bar is instantiated?
+template  void bar(T t) { foo(t); }
+void baz(int x) {
+  ns::S s;
+  bar(s);
+  [[f^oo]](s);
+}
+  )cpp",
   };
   for (const char *Test : Tests)
 checkFindRefs(Test);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 6c47eaf - [clang][index] report references from unreslovedLookupExpr.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2021-02-11T11:08:26+01:00
New Revision: 6c47eafb3973a8e3f7455c9655ed666883e7b513

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

LOG: [clang][index] report references from unreslovedLookupExpr.

Fix https://github.com/clangd/clangd/issues/675

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

Added: 


Modified: 
clang-tools-extra/clangd/unittests/XRefsTests.cpp
clang/lib/Index/IndexBody.cpp
clang/test/Index/Core/index-dependent-source.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/XRefsTests.cpp 
b/clang-tools-extra/clangd/unittests/XRefsTests.cpp
index a7715900ab97..9d77e0fb291a 100644
--- a/clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ b/clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -1863,6 +1863,26 @@ TEST(FindReferences, WithinAST) {
 Vector x2;
 Vector y;
   )cpp",
+  R"cpp(// Dependent code
+template  void $decl[[foo]](T t);
+template  void bar(T t) { [[foo]](t); } // foo in bar is 
uninstantiated.
+void baz(int x) { [[f^oo]](x); }
+  )cpp",
+  R"cpp(
+namespace ns {
+struct S{};
+void $decl[[foo]](S s);
+} // namespace ns
+template  void foo(T t);
+// FIXME: Maybe report this foo as a ref to ns::foo (because of ADL)
+// when bar is instantiated?
+template  void bar(T t) { foo(t); }
+void baz(int x) {
+  ns::S s;
+  bar(s);
+  [[f^oo]](s);
+}
+  )cpp",
   };
   for (const char *Test : Tests)
 checkFindRefs(Test);

diff  --git a/clang/lib/Index/IndexBody.cpp b/clang/lib/Index/IndexBody.cpp
index e4944fd0fc3b..7279e3b53c81 100644
--- a/clang/lib/Index/IndexBody.cpp
+++ b/clang/lib/Index/IndexBody.cpp
@@ -466,6 +466,15 @@ class BodyIndexer : public 
RecursiveASTVisitor {
 }
 return true;
   }
+
+  bool VisitUnresolvedLookupExpr(UnresolvedLookupExpr *E) {
+SmallVector Relations;
+SymbolRoleSet Roles = getRolesForRef(E, Relations);
+for (auto *D : E->decls())
+  IndexCtx.handleReference(D, E->getNameLoc(), Parent, ParentDC, Roles,
+   Relations, E);
+return true;
+  }
 };
 
 } // anonymous namespace

diff  --git a/clang/test/Index/Core/index-dependent-source.cpp 
b/clang/test/Index/Core/index-dependent-source.cpp
index 2e111339af61..8832edefd5bf 100644
--- a/clang/test/Index/Core/index-dependent-source.cpp
+++ b/clang/test/Index/Core/index-dependent-source.cpp
@@ -224,3 +224,10 @@ struct UsingE : public UsingD, public UsingD {
 // CHECK: [[@LINE+1]]:9 | struct(Gen)/C++ | UsingD | c:@ST>1#T@UsingD | 
 | Ref,RelCont | rel: 1
   using UsingD::foo;
 };
+
+template  void foo();
+// CHECK: [[@LINE-1]]:28 | function/C | foo | c:@FT@>1#Tfoo#v# |  | 
Decl | rel: 0
+template  void bar() {
+  foo();
+// CHECK: [[@LINE-1]]:3 | function/C | foo | c:@FT@>1#Tfoo#v# |  | 
Ref,Call,RelCall,RelCont | rel: 1
+}



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

[PATCH] D96262: [clang][index] report references from unreslovedLookupExpr.

[Haojian Wu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
hokein marked an inline comment as done.
Closed by commit rG6c47eafb3973: [clang][index] report references from 
unreslovedLookupExpr. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96262

Files:
  clang-tools-extra/clangd/unittests/XRefsTests.cpp
  clang/lib/Index/IndexBody.cpp
  clang/test/Index/Core/index-dependent-source.cpp


Index: clang/test/Index/Core/index-dependent-source.cpp
===
--- clang/test/Index/Core/index-dependent-source.cpp
+++ clang/test/Index/Core/index-dependent-source.cpp
@@ -224,3 +224,10 @@
 // CHECK: [[@LINE+1]]:9 | struct(Gen)/C++ | UsingD | c:@ST>1#T@UsingD | 
 | Ref,RelCont | rel: 1
   using UsingD::foo;
 };
+
+template  void foo();
+// CHECK: [[@LINE-1]]:28 | function/C | foo | c:@FT@>1#Tfoo#v# |  | 
Decl | rel: 0
+template  void bar() {
+  foo();
+// CHECK: [[@LINE-1]]:3 | function/C | foo | c:@FT@>1#Tfoo#v# |  | 
Ref,Call,RelCall,RelCont | rel: 1
+}
Index: clang/lib/Index/IndexBody.cpp
===
--- clang/lib/Index/IndexBody.cpp
+++ clang/lib/Index/IndexBody.cpp
@@ -466,6 +466,15 @@
 }
 return true;
   }
+
+  bool VisitUnresolvedLookupExpr(UnresolvedLookupExpr *E) {
+SmallVector Relations;
+SymbolRoleSet Roles = getRolesForRef(E, Relations);
+for (auto *D : E->decls())
+  IndexCtx.handleReference(D, E->getNameLoc(), Parent, ParentDC, Roles,
+   Relations, E);
+return true;
+  }
 };
 
 } // anonymous namespace
Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -1863,6 +1863,26 @@
 Vector x2;
 Vector y;
   )cpp",
+  R"cpp(// Dependent code
+template  void $decl[[foo]](T t);
+template  void bar(T t) { [[foo]](t); } // foo in bar is 
uninstantiated.
+void baz(int x) { [[f^oo]](x); }
+  )cpp",
+  R"cpp(
+namespace ns {
+struct S{};
+void $decl[[foo]](S s);
+} // namespace ns
+template  void foo(T t);
+// FIXME: Maybe report this foo as a ref to ns::foo (because of ADL)
+// when bar is instantiated?
+template  void bar(T t) { foo(t); }
+void baz(int x) {
+  ns::S s;
+  bar(s);
+  [[f^oo]](s);
+}
+  )cpp",
   };
   for (const char *Test : Tests)
 checkFindRefs(Test);


Index: clang/test/Index/Core/index-dependent-source.cpp
===
--- clang/test/Index/Core/index-dependent-source.cpp
+++ clang/test/Index/Core/index-dependent-source.cpp
@@ -224,3 +224,10 @@
 // CHECK: [[@LINE+1]]:9 | struct(Gen)/C++ | UsingD | c:@ST>1#T@UsingD |  | Ref,RelCont | rel: 1
   using UsingD::foo;
 };
+
+template  void foo();
+// CHECK: [[@LINE-1]]:28 | function/C | foo | c:@FT@>1#Tfoo#v# |  | Decl | rel: 0
+template  void bar() {
+  foo();
+// CHECK: [[@LINE-1]]:3 | function/C | foo | c:@FT@>1#Tfoo#v# |  | Ref,Call,RelCall,RelCont | rel: 1
+}
Index: clang/lib/Index/IndexBody.cpp
===
--- clang/lib/Index/IndexBody.cpp
+++ clang/lib/Index/IndexBody.cpp
@@ -466,6 +466,15 @@
 }
 return true;
   }
+
+  bool VisitUnresolvedLookupExpr(UnresolvedLookupExpr *E) {
+SmallVector Relations;
+SymbolRoleSet Roles = getRolesForRef(E, Relations);
+for (auto *D : E->decls())
+  IndexCtx.handleReference(D, E->getNameLoc(), Parent, ParentDC, Roles,
+   Relations, E);
+return true;
+  }
 };
 
 } // anonymous namespace
Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -1863,6 +1863,26 @@
 Vector x2;
 Vector y;
   )cpp",
+  R"cpp(// Dependent code
+template  void $decl[[foo]](T t);
+template  void bar(T t) { [[foo]](t); } // foo in bar is uninstantiated.
+void baz(int x) { [[f^oo]](x); }
+  )cpp",
+  R"cpp(
+namespace ns {
+struct S{};
+void $decl[[foo]](S s);
+} // namespace ns
+template  void foo(T t);
+// FIXME: Maybe report this foo as a ref to ns::foo (because of ADL)
+// when bar is instantiated?
+template  void bar(T t) { foo(t); }
+void baz(int x) {
+  ns::S s;
+  bar(s);
+  [[f^oo]](s);
+}
+  )cpp",
   };
   for (const char *Test : Tests)
 chec

[PATCH] D94779: [Clang] Ensure vector predication pragma is ignored only when vectorization width is 1.

[Dave Green via Phabricator via cfe-commits]

dmgreen added a comment.

This makes sense to me. If the user specifies the pragma then we send that 
through to the vectorizer, whatever it is. As much as `vectorize_width(1) 
interleave_count(4) vectorize_predicate(enable)` doesn't make a lot of sense, 
it's still something that should work. And if the user asks for it, that's what 
should be done.




Comment at: clang/test/CodeGenCXX/pragma-loop-predicate.cpp:88
+
+#pragma clang loop vectorize_predicate(enable) vectorize_width(1)
+  for (int i = 0; i < Length; i++)

Can you add another test for `#pragma clang loop vectorize(disable) 
vectorize_predicate(enable)`. My understanding is that it will produce the same 
as `vectorize_predicate(enable) vectorize_width(1)`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94779

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

[PATCH] D96178: [OpenCL] Create VoidPtrTy with generic AS in C++ for OpenCL mode

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

> Do I understand correctly that this means void pointer is not necessarily 
> points to generic AS?

This is an internal Clang pointer type that is used in very few places as a 
pointer to anything, so it makes sense to add generic.

I agree this change actually fixes a bug i.e. missing generic address space for 
C++ mode. We should go ahead and commit it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96178

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

[PATCH] D94779: [Clang] Ensure vector predication pragma is ignored only when vectorization width is 1.

[Malhar via Phabricator via cfe-commits]

malharJ added inline comments.



Comment at: clang/test/CodeGenCXX/pragma-loop-predicate.cpp:88
+
+#pragma clang loop vectorize_predicate(enable) vectorize_width(1)
+  for (int i = 0; i < Length; i++)

dmgreen wrote:
> Can you add another test for `#pragma clang loop vectorize(disable) 
> vectorize_predicate(enable)`. My understanding is that it will produce the 
> same as `vectorize_predicate(enable) vectorize_width(1)`
I believe test5( ) above takes care of this ? 

comparing the output of the two (test8 and test5), test8 produces an extra 
metadata : 

```
{!"llvm.loop.vectorize.scalable.enable", i1 false}
```



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94779

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

[PATCH] D96178: [OpenCL] Create VoidPtrTy with generic AS in C++ for OpenCL mode

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

PS, I will create a PR to follow up on the issue I have discovered.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96178

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

[PATCH] D96483: [flang][driver] Add options for unparsing

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski created this revision.
Herald added subscribers: dang, mgorny.
Herald added a reviewer: sscalpone.
Herald added a reviewer: jansvoboda11.
awarzynski requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch adds the following compiler frontend driver options:

- -fdebug-unparse (f18 spelling: -funparse)
- -fdebug-unparse-with-symbols (f18 spelling: -funparse-with-symbols)

The new driver will only accept the new spelling. `f18` will accept both
the original and the new spelling.

A new base class for frontend actions is added: `PrescanAndSemaAction`.
This is added to reduce code duplication that otherwise these new
options would lead to. Implementation from

- `ParseSyntaxOnlyAction::ExecutionAction`

is moved to:

- `PrescanAndSemaAction::BeginSourceFileAction`

This implementation is now shared between:

- PrescanAndSemaAction
- ParseSyntaxOnlyAction
- DebugUnparseAction
- DebugUnparseWithSymbolsAction

All tests that don't require other yet unimplemented options are
updated. This way `flang-new -fc1` is used instead of `f18` when
`FLANG_BUILD_NEW_DRIVER` is set to `On`. In order to facilitate this,
`%flang_fc1` is added in the LIT configuration (lit.cfg.py).

`asFortran` from f18.cpp is duplicated as `getBasicAsFortran` in
FrontendOptions.cpp. At this stage it's hard to find a good place to
share this method. I suggest that we revisit this once a switch from
`f18` to `flang-new` is complete.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96483

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/FrontendActions.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CMakeLists.txt
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/Frontend/FrontendOptions.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/lib/Parser/CMakeLists.txt
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Parser/continuation-in-if.f
  flang/test/Parser/pp-dir-comments.f90
  flang/test/Semantics/canondo01.f90
  flang/test/Semantics/canondo02.f90
  flang/test/Semantics/canondo03.f90
  flang/test/Semantics/canondo04.f90
  flang/test/Semantics/canondo05.f90
  flang/test/Semantics/critical04.f90
  flang/test/Semantics/defined-ops.f90
  flang/test/Semantics/doconcurrent02.f90
  flang/test/Semantics/doconcurrent03.f90
  flang/test/Semantics/doconcurrent04.f90
  flang/test/Semantics/doconcurrent07.f90
  flang/test/Semantics/label02.f90
  flang/test/Semantics/label03.f90
  flang/test/Semantics/label04.f90
  flang/test/Semantics/label05.f90
  flang/test/Semantics/label06.f90
  flang/test/Semantics/label07.f90
  flang/test/Semantics/label08.f90
  flang/test/Semantics/label09.f90
  flang/test/Semantics/label10.f90
  flang/test/Semantics/label12.f90
  flang/test/Semantics/label13.f90
  flang/test/Semantics/label15.f90
  flang/test/lit.cfg.py
  flang/tools/f18/f18.cpp

Index: flang/tools/f18/f18.cpp
===
--- flang/tools/f18/f18.cpp
+++ flang/tools/f18/f18.cpp
@@ -538,9 +538,10 @@
   options.instrumentedParse = true;
 } else if (arg == "-fdebug-no-semantics") {
   driver.debugNoSemantics = true;
-} else if (arg == "-funparse") {
+} else if (arg == "-funparse" || arg == "-fdebug_unparse") {
   driver.dumpUnparse = true;
-} else if (arg == "-funparse-with-symbols") {
+} else if (arg == "-funparse-with-symbols" ||
+arg == "-fdebug-unparse-with-symbols") {
   driver.dumpUnparseWithSymbols = true;
 } else if (arg == "-funparse-typed-exprs-to-f18-fc") {
   driver.unparseTypedExprsToF18_FC = true;
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -79,6 +79,14 @@
 extra_args=["-intrinsic-module-directory "+config.flang_intrinsic_modules_dir],
 unresolved='fatal'))
 
+if config.include_flang_new_driver_test:
+   tools.append(ToolSubst('%flang_fc1', command=FindTool('flang-new'),
+   extra_args=['-fc1'], unresolved='fatal'))
+else:
+   tools.append(ToolSubst('%flang_fc1', command=FindTool('f18'),
+extra_args=["-intrinsic-module-directory "+config.flang_intrinsic_modules_dir],
+unresolved='fatal'))
+
 if config.flang_standalone_build:
 llvm_config.add_tool_substitutions(tools, [config.flang_llvm_tools_dir])
 else:
Index: flang/test/Semantics/label15.f90
===
--- flang/test/Semantics/label15.f90
+++ flang/test/Semantics/label15.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -funparse %s 2>&1 | FileCheck %s
+! RUN: %flang_fc1 -fdebug-unparse %s 2>&1 | FileCheck %s
 
 !CHECK-NOT: error:
 module mm
Index: flang/test/Semantics/label13.f90
===
--- flang/test/Semantics/label13.f90
+++ flang/test/Semantics/label13.f90
@@ -

[PATCH] D86533: (Urgent!) [release][docs][analyzer] Add 11.0.0. release notes

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:453
+  equal or known to be non-equal.
+
+- Added :ref:`on-demand parsing ` capability to Cross 
Translation

Szelethus wrote:
> ASDenysPetrov wrote:
> > I've added the patch "Reasoning about comparison expressions in 
> > RangeConstraintManager". You can mention that as well.
> I added the line you mentioned -- do you like how the notes look now?
Yes, it's quite good enough.

P.S. Sorry for the late response.


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

https://reviews.llvm.org/D86533

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

[PATCH] D96456: [ThinLTO, NewPM] Add Config::OptPassBuilderHook

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka updated this revision to Diff 322934.
vitalybuka added a comment.

update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96456

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/thinlto-distributed-sanitizers.ll
  clang/test/Driver/asan.c
  clang/test/Driver/dfsan.c
  clang/test/Driver/msan.c
  clang/test/Driver/sancov.c
  clang/test/Driver/tsan.c
  llvm/include/llvm/LTO/Config.h
  llvm/lib/LTO/LTOBackend.cpp

Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -253,6 +253,9 @@
   PB.registerLoopAnalyses(LAM);
   PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);
 
+  if (Conf.OptimizerLastPassBuilderHook)
+Conf.OptimizerLastPassBuilderHook(PB);
+
   ModulePassManager MPM(Conf.DebugPassManager);
 
   if (!Conf.DisableVerify)
Index: llvm/include/llvm/LTO/Config.h
===
--- llvm/include/llvm/LTO/Config.h
+++ llvm/include/llvm/LTO/Config.h
@@ -48,7 +48,9 @@
   TargetOptions Options;
   std::vector MAttrs;
   std::vector PassPlugins;
-  /// For adding passes that run right before codegen.
+  /// For adding passes that run by optimizer.
+  std::function OptimizerLastPassBuilderHook;
+  /// For adding passes that run right before codegen (NewPM only).
   std::function PreCodeGenPassesHook;
   Optional RelocModel = Reloc::PIC_;
   Optional CodeModel = None;
Index: clang/test/Driver/tsan.c
===
--- clang/test/Driver/tsan.c
+++ clang/test/Driver/tsan.c
@@ -19,9 +19,10 @@
 // RUN: %clang -O3 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -o - | FileCheck %s
 // RUN: %clang -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -o - | FileCheck %s
 // RUN: %clang -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -flto=thin -o - | FileCheck %s
-// FIX: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -flto=thin -o - | FileCheck %s
+// RUN: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -flto=thin -o - | FileCheck %s --check-prefixes=NOTSAN
 // RUN: %clang -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -flto -o - | FileCheck %s
 // RUN: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -flto -o - | FileCheck %s
 
 int foo(int *a) { return *a; }
 // CHECK: __tsan_init
+// NOTSAN-NOT: __tsan
Index: clang/test/Driver/sancov.c
===
--- clang/test/Driver/sancov.c
+++ clang/test/Driver/sancov.c
@@ -3,7 +3,7 @@
 // RUN: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -o - | FileCheck %s
 // RUN: %clang -O3 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -o - | FileCheck %s
 // RUN: %clang -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -flto=thin -o - | FileCheck %s
-// FIX: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -flto=thin -o - | FileCheck %s
+// RUN: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -flto=thin -o - | FileCheck %s --check-prefixes=NOSANCOV
 // RUN: %clang -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -flto -o - | FileCheck %s
 // RUN: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -flto -o - | FileCheck %s
 
@@ -20,3 +20,4 @@
 
 int foo(int *a) { return *a; }
 // CHECK: _sancov_
+// NOSANCOV-NOT: _sancov
\ No newline at end of file
Index: clang/test/Driver/msan.c
===
--- clang/test/Driver/msan.c
+++ clang/test/Driver/msan.c
@@ -1,49 +1,50 @@
 // REQUIRES: x86-registered-target
 
-// RUN: %clang -fno-experimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=memory %s -S -emit-llvm -o - | FileCheck %s --check-prefixes=CHECK
-// RUN: %clang -O1 -fno-experimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=memory %s -S -emit-llvm -o - | FileCheck %s --check-prefixes=CHECK
-// RUN: %clang -O2 -fno-experimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=memory %s -S -emit-llvm -o - | FileCheck %s --check-prefixes=CHECK
-// RUN: %

[PATCH] D96456: [ThinLTO, NewPM] Add Config::OptPassBuilderHook

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka added inline comments.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:1549
+  Conf.OptPassBuilderHook = [&](PassBuilder &PB) {
+addSanitizers(TargetTriple, CGOpts, LOpts, PB);
+  };

tejohnson wrote:
> I can't find where this is defined.
to avoid noise I extracted into a separate NFC patch, to avoid, line 1061



Comment at: llvm/include/llvm/LTO/Config.h:54
+  /// For adding passes that run by opt.
+  std::function OptPassBuilderHook;
   Optional RelocModel = Reloc::PIC_;

tejohnson wrote:
> Is this essentially the new PM equivalent to PreCodeGenPassesHook above 
> (since this new hook runs at the end of opt)?
> Also, might be good to name this like OptimizerLastPassBuilderHook or 
> something like that to indicate its position within the opt pipeline.
Kind of. PreCodeGenPassesHook is codegen and it's Legacy PM only.



Comment at: llvm/include/llvm/LTO/Config.h:54
+  /// For adding passes that run by opt.
+  std::function OptPassBuilderHook;
   Optional RelocModel = Reloc::PIC_;

aeubanks wrote:
> vitalybuka wrote:
> > tejohnson wrote:
> > > Is this essentially the new PM equivalent to PreCodeGenPassesHook above 
> > > (since this new hook runs at the end of opt)?
> > > Also, might be good to name this like OptimizerLastPassBuilderHook or 
> > > something like that to indicate its position within the opt pipeline.
> > Kind of. PreCodeGenPassesHook is codegen and it's Legacy PM only.
> I think the idea is that this callback adds PassBuilder callbacks in various 
> parts of the the pipeline. Perhaps just `PassBuilderHook`? It's weird that we 
> only allow one, but I guess we can make it a vector in the future if 
> necessary.
I guess the point of OptimizerLastPassBuilderHook name is to show that this is 
not any PassBuilder, but the one used in ::opt()


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96456

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

[PATCH] D96456: [ThinLTO, NewPM] Add Config::OptPassBuilderHook

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka updated this revision to Diff 322935.
vitalybuka added a comment.

new line


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96456

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/thinlto-distributed-sanitizers.ll
  clang/test/Driver/asan.c
  clang/test/Driver/dfsan.c
  clang/test/Driver/msan.c
  clang/test/Driver/sancov.c
  clang/test/Driver/tsan.c
  llvm/include/llvm/LTO/Config.h
  llvm/lib/LTO/LTOBackend.cpp

Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -253,6 +253,9 @@
   PB.registerLoopAnalyses(LAM);
   PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);
 
+  if (Conf.OptimizerLastPassBuilderHook)
+Conf.OptimizerLastPassBuilderHook(PB);
+
   ModulePassManager MPM(Conf.DebugPassManager);
 
   if (!Conf.DisableVerify)
Index: llvm/include/llvm/LTO/Config.h
===
--- llvm/include/llvm/LTO/Config.h
+++ llvm/include/llvm/LTO/Config.h
@@ -48,7 +48,9 @@
   TargetOptions Options;
   std::vector MAttrs;
   std::vector PassPlugins;
-  /// For adding passes that run right before codegen.
+  /// For adding passes that run by optimizer.
+  std::function OptimizerLastPassBuilderHook;
+  /// For adding passes that run right before codegen (NewPM only).
   std::function PreCodeGenPassesHook;
   Optional RelocModel = Reloc::PIC_;
   Optional CodeModel = None;
Index: clang/test/Driver/tsan.c
===
--- clang/test/Driver/tsan.c
+++ clang/test/Driver/tsan.c
@@ -19,9 +19,10 @@
 // RUN: %clang -O3 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -o - | FileCheck %s
 // RUN: %clang -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -o - | FileCheck %s
 // RUN: %clang -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -flto=thin -o - | FileCheck %s
-// FIX: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -flto=thin -o - | FileCheck %s
+// RUN: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -flto=thin -o - | FileCheck %s --check-prefixes=NOTSAN
 // RUN: %clang -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -flto -o - | FileCheck %s
 // RUN: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=thread %s -S -emit-llvm -flto -o - | FileCheck %s
 
 int foo(int *a) { return *a; }
 // CHECK: __tsan_init
+// NOTSAN-NOT: __tsan
Index: clang/test/Driver/sancov.c
===
--- clang/test/Driver/sancov.c
+++ clang/test/Driver/sancov.c
@@ -3,7 +3,7 @@
 // RUN: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -o - | FileCheck %s
 // RUN: %clang -O3 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -o - | FileCheck %s
 // RUN: %clang -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -flto=thin -o - | FileCheck %s
-// FIX: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -flto=thin -o - | FileCheck %s
+// RUN: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -flto=thin -o - | FileCheck %s --check-prefixes=NOSANCOV
 // RUN: %clang -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -flto -o - | FileCheck %s
 // RUN: %clang -O2 -fexperimental-new-pass-manager -target x86_64-unknown-linux -fsanitize-coverage=trace-pc-guard %s -S -emit-llvm -flto -o - | FileCheck %s
 
@@ -20,3 +20,4 @@
 
 int foo(int *a) { return *a; }
 // CHECK: _sancov_
+// NOSANCOV-NOT: _sancov
Index: clang/test/Driver/msan.c
===
--- clang/test/Driver/msan.c
+++ clang/test/Driver/msan.c
@@ -1,49 +1,50 @@
 // REQUIRES: x86-registered-target
 
-// RUN: %clang -fno-experimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=memory %s -S -emit-llvm -o - | FileCheck %s --check-prefixes=CHECK
-// RUN: %clang -O1 -fno-experimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=memory %s -S -emit-llvm -o - | FileCheck %s --check-prefixes=CHECK
-// RUN: %clang -O2 -fno-experimental-new-pass-manager -target x86_64-unknown-linux -fsanitize=memory %s -S -emit-llvm -o - | FileCheck %s --check-prefixes=CHECK
-// RUN: %clang -O3 -fno-experimenta

[PATCH] D96419: [clang] Add -ffinite-loops & -fno-finite-loops options.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

In D96419#213 , @xbolva00 wrote:

> Maybe we want these options in llvm 12 as well?
>
> (+ Release note)

That's a good idea. The patch currently depends on D96418 
. Not sure if we should pull that one on the 
12.x release branch though


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96419

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

[PATCH] D96419: [clang] Add -ffinite-loops & -fno-finite-loops options.

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

In D96419#2556349 , @fhahn wrote:

> In D96419#213 , @xbolva00 wrote:
>
>> Maybe we want these options in llvm 12 as well?
>>
>> (+ Release note)
>
> That's a good idea. The patch currently depends on D96418 
> . Not sure if we should pull that one on the 
> 12.x release branch though

I think we should to keep consistency with gcc and llvm 13+.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96419

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

[PATCH] D96487: Restore diagnostic handler after CodeGenAction::ExecuteAction

[Marco Antognini via Phabricator via cfe-commits]

mantognini created this revision.
Herald added a subscriber: dexonsmith.
mantognini published this revision for review.
mantognini added inline comments.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.



Comment at: llvm/include/llvm/IR/LLVMContext.h:196
+  /// argument is unique_ptr of object of type DiagnosticHandler or a derived
+  /// of that. The second argument should be set to true if the handler only
+  /// expects enabled diagnostics.

Had to run clang-format. The change is replacing "third" with "second".


Fix dangling pointer to local variable and address some typos.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96487

Files:
  clang/lib/CodeGen/CodeGenAction.cpp
  llvm/include/llvm/IR/LLVMContext.h


Index: llvm/include/llvm/IR/LLVMContext.h
===
--- llvm/include/llvm/IR/LLVMContext.h
+++ llvm/include/llvm/IR/LLVMContext.h
@@ -190,10 +190,11 @@
   DiagnosticHandler::DiagnosticHandlerTy DiagHandler,
   void *DiagContext = nullptr, bool RespectFilters = false);
 
-  /// setDiagnosticHandler - This method sets unique_ptr to object of 
DiagnosticHandler
-  /// to provide custom diagnostic handling. The first argument is unique_ptr 
of object
-  /// of type DiagnosticHandler or a derived of that.   The third argument 
should be
-  /// set to true if the handler only expects enabled diagnostics.
+  /// setDiagnosticHandler - This method sets unique_ptr to object of
+  /// DiagnosticHandler to provide custom diagnostic handling. The first
+  /// argument is unique_ptr of object of type DiagnosticHandler or a derived
+  /// of that. The second argument should be set to true if the handler only
+  /// expects enabled diagnostics.
   ///
   /// Ownership of this pointer is moved to LLVMContextImpl.
   void setDiagnosticHandler(std::unique_ptr &&DH,
@@ -211,7 +212,7 @@
   /// setDiagnosticHandler.
   const DiagnosticHandler *getDiagHandlerPtr() const;
 
-  /// getDiagnosticHandler - transfers owenership of DiagnosticHandler 
unique_ptr
+  /// getDiagnosticHandler - transfers ownership of DiagnosticHandler 
unique_ptr
   /// to caller.
   std::unique_ptr getDiagnosticHandler();
 
Index: clang/lib/CodeGen/CodeGenAction.cpp
===
--- clang/lib/CodeGen/CodeGenAction.cpp
+++ clang/lib/CodeGen/CodeGenAction.cpp
@@ -1115,6 +1115,14 @@
   LLVMContext &Ctx = TheModule->getContext();
   Ctx.setInlineAsmDiagnosticHandler(BitcodeInlineAsmDiagHandler, &Diagnostics);
 
+  // Restore any diagnostic handler previously set before returning from this
+  // function.
+  struct RAII {
+LLVMContext &Ctx;
+std::unique_ptr PrevHandler = 
Ctx.getDiagnosticHandler();
+~RAII() { Ctx.setDiagnosticHandler(std::move(PrevHandler)); }
+  } _{Ctx};
+
   // Set clang diagnostic handler. To do this we need to create a fake
   // BackendConsumer.
   BackendConsumer Result(BA, CI.getDiagnostics(), CI.getHeaderSearchOpts(),


Index: llvm/include/llvm/IR/LLVMContext.h
===
--- llvm/include/llvm/IR/LLVMContext.h
+++ llvm/include/llvm/IR/LLVMContext.h
@@ -190,10 +190,11 @@
   DiagnosticHandler::DiagnosticHandlerTy DiagHandler,
   void *DiagContext = nullptr, bool RespectFilters = false);
 
-  /// setDiagnosticHandler - This method sets unique_ptr to object of DiagnosticHandler
-  /// to provide custom diagnostic handling. The first argument is unique_ptr of object
-  /// of type DiagnosticHandler or a derived of that.   The third argument should be
-  /// set to true if the handler only expects enabled diagnostics.
+  /// setDiagnosticHandler - This method sets unique_ptr to object of
+  /// DiagnosticHandler to provide custom diagnostic handling. The first
+  /// argument is unique_ptr of object of type DiagnosticHandler or a derived
+  /// of that. The second argument should be set to true if the handler only
+  /// expects enabled diagnostics.
   ///
   /// Ownership of this pointer is moved to LLVMContextImpl.
   void setDiagnosticHandler(std::unique_ptr &&DH,
@@ -211,7 +212,7 @@
   /// setDiagnosticHandler.
   const DiagnosticHandler *getDiagHandlerPtr() const;
 
-  /// getDiagnosticHandler - transfers owenership of DiagnosticHandler unique_ptr
+  /// getDiagnosticHandler - transfers ownership of DiagnosticHandler unique_ptr
   /// to caller.
   std::unique_ptr getDiagnosticHandler();
 
Index: clang/lib/CodeGen/CodeGenAction.cpp
===
--- clang/lib/CodeGen/CodeGenAction.cpp
+++ clang/lib/CodeGen/CodeGenAction.cpp
@@ -1115,6 +1115,14 @@
   LLVMContext &Ctx = TheModule->getContext();
   Ctx.setInlineAsmDiagnosticHandler(BitcodeInlineAsmDiagHandler, &Diagnostics);
 
+  // Restore any diagnostic handler previously set before returning from this
+  // function.
+  struct RAII {

[PATCH] D81678: Introduce noundef attribute at call sites for stricter poison analysis

[Gui Andrade via Phabricator via cfe-commits]

guiand updated this revision to Diff 322899.
guiand added a comment.

Updated to use -enable-noundef-analysis


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81678

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/test/CodeGen/attr-noundef.cpp
  clang/test/CodeGen/indirect-noundef.cpp

Index: clang/test/CodeGen/indirect-noundef.cpp
===
--- /dev/null
+++ clang/test/CodeGen/indirect-noundef.cpp
@@ -0,0 +1,34 @@
+// RUN: %clang -cc1 -x c++ -triple x86_64-unknown-unknown -O0 -emit-llvm -enable-noundef-analysis -o - %s | FileCheck %s
+
+union u1 {
+  int val;
+};
+
+// CHECK: @indirect_callee_int_ptr = [[GLOBAL:(dso_local )?global]] i32 (i32)*
+int (*indirect_callee_int_ptr)(int);
+// CHECK: @indirect_callee_union_ptr = [[GLOBAL]] i32 (i32)*
+union u1 (*indirect_callee_union_ptr)(union u1);
+
+// CHECK: [[DEFINE:define( dso_local)?]] noundef i32 @{{.*}}indirect_callee_int{{.*}}(i32 noundef %
+int indirect_callee_int(int a) { return a; }
+// CHECK: [[DEFINE]] i32 @{{.*}}indirect_callee_union{{.*}}(i32 %
+union u1 indirect_callee_union(union u1 a) {
+  return a;
+}
+
+int main() {
+  // CHECK: call noundef i32 @{{.*}}indirect_callee_int{{.*}}(i32 noundef 0)
+  indirect_callee_int(0);
+  // CHECK: call i32 @{{.*}}indirect_callee_union{{.*}}(i32 %
+  indirect_callee_union((union u1){0});
+
+  indirect_callee_int_ptr = indirect_callee_int;
+  indirect_callee_union_ptr = indirect_callee_union;
+
+  // CHECK: call noundef i32 %{{.*}}(i32 noundef 0)
+  indirect_callee_int_ptr(0);
+  // CHECK: call i32 %{{.*}}(i32 %
+  indirect_callee_union_ptr((union u1){});
+
+  return 0;
+}
Index: clang/test/CodeGen/attr-noundef.cpp
===
--- /dev/null
+++ clang/test/CodeGen/attr-noundef.cpp
@@ -0,0 +1,162 @@
+// RUN: %clang -cc1 -triple x86_64-gnu-linux -x c++ -S -emit-llvm -enable-noundef-analysis %s -o - | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-INTEL
+// RUN: %clang -cc1 -triple aarch64-gnu-linux -x c++ -S -emit-llvm -enable-noundef-analysis %s -o - | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-AARCH
+
+// Passing structs by value
+// TODO: No structs may currently be marked noundef
+
+namespace check_structs {
+struct Trivial {
+  int a;
+};
+Trivial ret_trivial() { return {}; }
+void pass_trivial(Trivial e) {}
+// CHECK-INTEL: [[DEFINE:define( dso_local)?]] i32 @{{.*}}ret_trivial
+// CHECK-AARCH: [[DEFINE:define( dso_local)?]] i64 @{{.*}}ret_trivial
+// CHECK-INTEL: [[DEFINE]] void @{{.*}}pass_trivial{{.*}}(i32 %
+// CHECK-AARCH: [[DEFINE]] void @{{.*}}pass_trivial{{.*}}(i64 %
+
+struct NoCopy {
+  int a;
+  NoCopy(NoCopy &) = delete;
+};
+NoCopy ret_nocopy() { return {}; }
+void pass_nocopy(NoCopy e) {}
+// CHECK: [[DEFINE]] void @{{.*}}ret_nocopy{{.*}}(%"struct.check_structs::NoCopy"* noalias sret({{[^)]+}}) align 4 %
+// CHECK: [[DEFINE]] void @{{.*}}pass_nocopy{{.*}}(%"struct.check_structs::NoCopy"* noundef %
+
+struct Huge {
+  int a[1024];
+};
+Huge ret_huge() { return {}; }
+void pass_huge(Huge h) {}
+// CHECK: [[DEFINE]] void @{{.*}}ret_huge{{.*}}(%"struct.check_structs::Huge"* noalias sret({{[^)]+}}) align 4 %
+// CHECK: [[DEFINE]] void @{{.*}}pass_huge{{.*}}(%"struct.check_structs::Huge"* noundef
+} // namespace check_structs
+
+// Passing unions by value
+// No unions may be marked noundef
+
+namespace check_unions {
+union Trivial {
+  int a;
+};
+Trivial ret_trivial() { return {}; }
+void pass_trivial(Trivial e) {}
+// CHECK-INTEL: [[DEFINE]] i32 @{{.*}}ret_trivial
+// CHECK-AARCH: [[DEFINE]] i64 @{{.*}}ret_trivial
+// CHECK-INTEL: [[DEFINE]] void @{{.*}}pass_trivial{{.*}}(i32 %
+// CHECK-AARCH: [[DEFINE]] void @{{.*}}pass_trivial{{.*}}(i64 %
+
+union NoCopy {
+  int a;
+  NoCopy(NoCopy &) = delete;
+};
+NoCopy ret_nocopy() { return {}; }
+void pass_nocopy(NoCopy e) {}
+// CHECK: [[DEFINE]] void @{{.*}}ret_nocopy{{.*}}(%"union.check_unions::NoCopy"* noalias sret({{[^)]+}}) align 4 %
+// CHECK: [[DEFINE]] void @{{.*}}pass_nocopy{{.*}}(%"union.check_unions::NoCopy"* noundef %
+} // namespace check_unions
+
+// Passing `this` pointers
+// `this` pointer must always be defined
+
+namespace check_this {
+struct Object {
+  int data[];
+
+  Object() {
+this->data[0] = 0;
+  }
+  int getData() {
+return this->data[0];
+  }
+  Object *getThis() {
+return this;
+  }
+};
+
+void use_object() {
+  Object obj;
+  obj.getData();
+  obj.getThis();
+}
+// CHECK: define linkonce_odr void @{{.*}}Object{{.*}}(%"struct.check_this::Object"* noundef %
+// CHECK: define linkonce_odr noundef i32 @{{.*}}Object{{.*}}getData{{.*}}(%"struct.check_this::Object"* noundef %
+// CHECK: define linkonce_odr nou

[PATCH] [clang-tidy] ensure run-clang-tidy reports children killed by signals

[Ian Campbell via cfe-commits]

If a clang-tidy child process exits with a signal then run-clang-tidy will exit
with an error but there is no hint why in the output, since the clang-tidy
doesn't log anything and may not even have had the opportunity to do so
depending on the signal used.

`subprocess.CompletedProcess.returncode` is the negative signal number in this
case.

I hit this in a CI system where the parallelism used exceeded the RAM assigned
to the container causing the OOM killer to SIGKILL clang-tidy processes.

Cc: Alexander Kornienko 
---
Please Cc me, I'm not subscribed to cfe-commits
---
 clang-tools-extra/clang-tidy/tool/run-clang-tidy.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py 
b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
index 313ecd2f9571..8b2a5bf60d13 100755
--- a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -170,6 +170,9 @@ def run_tidy(args, tmpdir, build_path, queue, lock, 
failed_files):
 proc = subprocess.Popen(invocation, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE)
 output, err = proc.communicate()
 if proc.returncode != 0:
+  if proc.returncode < 0:
+msg = "%s: terminated by signal %d\n" % (name, -proc.returncode)
+err += msg.encode('utf-8')
   failed_files.append(name)
 with lock:
   sys.stdout.write(' '.join(invocation) + '\n' + output.decode('utf-8'))
-- 
2.29.2

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

[PATCH] D96418: [clang] Refactor mustprogress handling, add it to all loops in c++11+.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.h:523
 return getLangOpts().C11 || getLangOpts().C17 || getLangOpts().C2x;
   }
 

jdoerfert wrote:
> fhahn wrote:
> > jdoerfert wrote:
> > > Can you modify the documentation to talk about what loops must make 
> > > progress, this is the code below transcribed. 
> > > 
> > > Also, I don't see how this works. Should the const-ness of the condition 
> > > not be related to the standard/language to make a decision?
> > > Can you modify the documentation to talk about what loops must make 
> > > progress, this is the code below transcribed.
> > 
> > I added some comments. I hope they make things clearer.
> > 
> > > Also, I don't see how this works. Should the const-ness of the condition 
> > > not be related to the standard/language to make a decision?
> > 
> > The `functionMustProgress` call applies the C++ rules. So C++11 and above 
> > is already handled by the call.
> > 
> > Afterwards, loops with constant conditions never have to make progress (C++ 
> > before 11, any C version). Loops with non-constant conditions have to make 
> > progress in C11 and later.
> > 
> > Hopefully the comment makes that clearer.
> Now, even I understand this. Thanks :)
>  Loops with non-constant conditions have to make progress in C11 and later.

Can you point me to the part of the C11 (or later) standards that state this? I 
don't see wording like http://eel.is/c++draft/intro.progress#1 in 5.1.2.4 in 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96418

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

[clang] 81bc136 - Correct swift_bridge duplicate attribute warning logic

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2021-02-11T07:11:27-05:00
New Revision: 81bc1365d8f85a125a6db6a5a1acff3ceddcbe9e

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

LOG: Correct swift_bridge duplicate attribute warning logic

The swift_bridge attribute warns when the attribute is applied multiple
times to the same declaration. However, it warns about the arguments
being different to the attribute without ever checking if the arguments
actually are different. If the arguments are different, diagnose,
otherwise silently accept the code. Either way, drop the duplicated
attribute.

Added: 


Modified: 
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/SemaObjC/attr-swift_bridge.m

Removed: 




diff  --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index fcb8c20f406d..b343eb9d10de 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -5751,9 +5751,11 @@ static void handleSwiftBridge(Sema &S, Decl *D, const 
ParsedAttr &AL) {
   if (!S.checkStringLiteralArgumentAttr(AL, 0, BT))
 return;
 
-  // Don't duplicate annotations that are already set.
-  if (D->hasAttr()) {
-S.Diag(AL.getLoc(), diag::warn_duplicate_attribute) << AL;
+  // Warn about duplicate attributes if they have 
diff erent arguments, but drop
+  // any duplicate attributes regardless.
+  if (const auto *Other = D->getAttr()) {
+if (Other->getSwiftType() != BT)
+  S.Diag(AL.getLoc(), diag::warn_duplicate_attribute) << AL;
 return;
   }
 

diff  --git a/clang/test/SemaObjC/attr-swift_bridge.m 
b/clang/test/SemaObjC/attr-swift_bridge.m
index 1c8259a6a2e7..8f53ed815458 100644
--- a/clang/test/SemaObjC/attr-swift_bridge.m
+++ b/clang/test/SemaObjC/attr-swift_bridge.m
@@ -31,3 +31,8 @@ @protocol P
 typedef NSArray *NSArrayAlias __attribute__((__swift_bridge__("ArrayAlias")));
 
 struct __attribute__((__swift_bridge__("StructT"))) T {};
+
+// Duplicate attributes with the same arguments are fine.
+struct __attribute__((swift_bridge("foo"), swift_bridge("foo"))) S;
+// Duplicate attributes with 
diff erent arguments are not.
+struct __attribute__((swift_bridge("foo"), swift_bridge("bar"))) S; // 
expected-warning {{attribute 'swift_bridge' is already applied with 
diff erent arguments}}



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

[PATCH] D96130: Correct swift_bridge duplicate attribute warning logic

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman closed this revision.
aaron.ballman added a comment.

Thanks for the review! I've committed in 
81bc1365d8f85a125a6db6a5a1acff3ceddcbe9e 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96130

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

[PATCH] D96418: [clang] Refactor mustprogress handling, add it to all loops in c++11+.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.h:523
 return getLangOpts().C11 || getLangOpts().C17 || getLangOpts().C2x;
   }
 

aaron.ballman wrote:
> jdoerfert wrote:
> > fhahn wrote:
> > > jdoerfert wrote:
> > > > Can you modify the documentation to talk about what loops must make 
> > > > progress, this is the code below transcribed. 
> > > > 
> > > > Also, I don't see how this works. Should the const-ness of the 
> > > > condition not be related to the standard/language to make a decision?
> > > > Can you modify the documentation to talk about what loops must make 
> > > > progress, this is the code below transcribed.
> > > 
> > > I added some comments. I hope they make things clearer.
> > > 
> > > > Also, I don't see how this works. Should the const-ness of the 
> > > > condition not be related to the standard/language to make a decision?
> > > 
> > > The `functionMustProgress` call applies the C++ rules. So C++11 and above 
> > > is already handled by the call.
> > > 
> > > Afterwards, loops with constant conditions never have to make progress 
> > > (C++ before 11, any C version). Loops with non-constant conditions have 
> > > to make progress in C11 and later.
> > > 
> > > Hopefully the comment makes that clearer.
> > Now, even I understand this. Thanks :)
> >  Loops with non-constant conditions have to make progress in C11 and later.
> 
> Can you point me to the part of the C11 (or later) standards that state this? 
> I don't see wording like http://eel.is/c++draft/intro.progress#1 in 5.1.2.4 
> in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
For C11 and later, it should be 6.8.5.6, which says:

```
An iteration statement may be assumed by the implementation to terminate if its 
controlling expression is not a constant expression,171) and none of the 
following operations are performed in its body, controlling expression or (in 
the case of a for statement) its expression-3:172)
— input/output operations
— accessing a volatile object
— synchronization or atomic operations.
```

It would probably be good to refer to C11 6.8.5.6 here, and the equivalent for 
C++ (6.9.2.3.1)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96418

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

[PATCH] D94779: [Clang] Ensure vector predication pragma is ignored only when vectorization width is 1.

[Dave Green via Phabricator via cfe-commits]

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

OK Thanks. LGTM




Comment at: clang/test/CodeGenCXX/pragma-loop-predicate.cpp:88
+
+#pragma clang loop vectorize_predicate(enable) vectorize_width(1)
+  for (int i = 0; i < Length; i++)

malharJ wrote:
> dmgreen wrote:
> > Can you add another test for `#pragma clang loop vectorize(disable) 
> > vectorize_predicate(enable)`. My understanding is that it will produce the 
> > same as `vectorize_predicate(enable) vectorize_width(1)`
> I believe test5( ) above takes care of this ? 
> 
> comparing the output of the two (test8 and test5), test8 produces an extra 
> metadata : 
> 
> ```
> {!"llvm.loop.vectorize.scalable.enable", i1 false}
> ```
> 
Oh yeah. I didn't see the existing checks. Strange that it would not emit 
scalable then, but still doing the expected thing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94779

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

[PATCH] D96418: [clang] Refactor mustprogress handling, add it to all loops in c++11+.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.h:523
 return getLangOpts().C11 || getLangOpts().C17 || getLangOpts().C2x;
   }
 

fhahn wrote:
> aaron.ballman wrote:
> > jdoerfert wrote:
> > > fhahn wrote:
> > > > jdoerfert wrote:
> > > > > Can you modify the documentation to talk about what loops must make 
> > > > > progress, this is the code below transcribed. 
> > > > > 
> > > > > Also, I don't see how this works. Should the const-ness of the 
> > > > > condition not be related to the standard/language to make a decision?
> > > > > Can you modify the documentation to talk about what loops must make 
> > > > > progress, this is the code below transcribed.
> > > > 
> > > > I added some comments. I hope they make things clearer.
> > > > 
> > > > > Also, I don't see how this works. Should the const-ness of the 
> > > > > condition not be related to the standard/language to make a decision?
> > > > 
> > > > The `functionMustProgress` call applies the C++ rules. So C++11 and 
> > > > above is already handled by the call.
> > > > 
> > > > Afterwards, loops with constant conditions never have to make progress 
> > > > (C++ before 11, any C version). Loops with non-constant conditions have 
> > > > to make progress in C11 and later.
> > > > 
> > > > Hopefully the comment makes that clearer.
> > > Now, even I understand this. Thanks :)
> > >  Loops with non-constant conditions have to make progress in C11 and 
> > > later.
> > 
> > Can you point me to the part of the C11 (or later) standards that state 
> > this? I don't see wording like http://eel.is/c++draft/intro.progress#1 in 
> > 5.1.2.4 in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
> For C11 and later, it should be 6.8.5.6, which says:
> 
> ```
> An iteration statement may be assumed by the implementation to terminate if 
> its controlling expression is not a constant expression,171) and none of the 
> following operations are performed in its body, controlling expression or (in 
> the case of a for statement) its expression-3:172)
> — input/output operations
> — accessing a volatile object
> — synchronization or atomic operations.
> ```
> 
> It would probably be good to refer to C11 6.8.5.6 here, and the equivalent 
> for C++ (6.9.2.3.1)?
Ah, thank you for that -- my brain was hung up on the atomic progress 
guarantees not the loop ones specifically. Having a standards reference in the 
comments would be handy, but I don't insist.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96418

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

[PATCH] D87587: [clang-format][PR47290] Add ShortNamespaceLines format option

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added a comment.

Almost there. I hope I'm clear this time on what I'd like to see.
Thanks for the release notes update.




Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:1162
+
+  EXPECT_EQ(DefaultUnwrappedLines, Style.ShortNamespaceLines);
+  EXPECT_EQ("namespace ShortNamespace {\n"

Nit.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:1201-1206
+}
+
+TEST_F(ShortNamespaceLinesTest,
+   MultipleUnwrappedLine_AddsEndCommentForLongNamespace) {
+  auto Style = getLLVMStyle();
+  Style.ShortNamespaceLines = 2u;

What I meant by "merging the tests together" is just writing:
```
TEST_F(ShortNamespaceLinesTest,
   MultipleUnwrappedLine) {
  auto Style = getLLVMStyle();
  Style.ShortNamespaceLines = 2u;

  EXPECT_EQ(...);

  EXPECT_EQ(...);
}
```
This will get rid of duplicated setup (even if small), and, what's more 
important, show the behaviour with the same style on different cases.

Or even, but I'm not forcing you to do so, having a single test case for all 
`ShortNamespaceLinesTest.*` tests. It groups the test for the same feature 
together.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87587

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

[clang] 3a29ac2 - [OpenCL] Fix missing const attributes for get_image_ builtins

[Sven van Haastregt via cfe-commits]

Author: Sven van Haastregt
Date: 2021-02-11T13:05:26Z
New Revision: 3a29ac2a61f78aae049a46369203757ece315e23

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

LOG: [OpenCL] Fix missing const attributes for get_image_ builtins

Various get_image builtin function declarations did not have the const
attribute.  Bring the const attributes of `-fdeclare-opencl-builtins`
more in sync with `opencl-c.h`.

Added: 


Modified: 
clang/lib/Sema/OpenCLBuiltins.td

Removed: 




diff  --git a/clang/lib/Sema/OpenCLBuiltins.td 
b/clang/lib/Sema/OpenCLBuiltins.td
index b78a1812748b..7f32be6cc8e8 100644
--- a/clang/lib/Sema/OpenCLBuiltins.td
+++ b/clang/lib/Sema/OpenCLBuiltins.td
@@ -1163,21 +1163,21 @@ foreach aQual = ["RO", "WO", "RW"] in {
Image2dArrayDepth] in {
 foreach name = ["get_image_width", "get_image_channel_data_type",
 "get_image_channel_order"] in {
-  def : Builtin]>;
+  def : Builtin], Attr.Const>;
 }
   }
   foreach imgTy = [Image2d, Image3d, Image2dArray, Image2dDepth,
Image2dArrayDepth] in {
-def : Builtin<"get_image_height", [Int, ImageType]>;
+def : Builtin<"get_image_height", [Int, ImageType], 
Attr.Const>;
   }
-  def : Builtin<"get_image_depth", [Int, ImageType]>;
+  def : Builtin<"get_image_depth", [Int, ImageType], 
Attr.Const>;
   foreach imgTy = [Image2d, Image2dArray, Image2dDepth,
Image2dArrayDepth] in {
-def : Builtin<"get_image_dim", [VectorType, ImageType]>;
+def : Builtin<"get_image_dim", [VectorType, ImageType], Attr.Const>;
   }
-  def : Builtin<"get_image_dim", [VectorType, ImageType]>;
+  def : Builtin<"get_image_dim", [VectorType, ImageType], Attr.Const>;
   foreach imgTy = [Image1dArray, Image2dArray, Image2dArrayDepth] in {
-def : Builtin<"get_image_array_size", [Size, ImageType]>;
+def : Builtin<"get_image_array_size", [Size, ImageType], 
Attr.Const>;
   }
 }
 



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

[PATCH] D92808: [ObjC][ARC] Use operand bundle 'clang.arc.rv' instead of explicitly emitting retainRV or claimRV calls in the IR

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.



In D92808#2555868 , @ahatanak wrote:

> In D92808#2555737 , @dexonsmith 
> wrote:
>
>> In D92808#2552354 , @rjmccall wrote:
>>
>>> The ultimate code-generation consequences of this feature aren't very 
>>> generic, so we shouldn't let ourselves get caught up designing an extremely 
>>> general feature that ultimately either doesn't do what we need it to do or 
>>> doesn't actually work for any of the generalizations.
>>
>> Sure, those are two bad potential outcomes.
>>
>> Stepping back, the goal of this patch is to encode ARC's code generation 
>> invariants in the IR so that maintainers don't inadvertently break them. I 
>> think the IR should describe those invariants as clearly and precisely as is 
>> reasonable.
>>
>> Besides idle / misplaced optimism about reuse, I was trying to make the 
>> following points along those lines, so I'll restate them more directly:
>>
>> - Explicitly adding a use of the call avoids having to teach transformations 
>> / analyses about it. It might be simpler to add a self-reference carve-out 
>> for this operand bundle (or operand bundles in general) than to teach all 
>> the passes that this operand bundle implies a use of the callsite (but I'm 
>> not sure; maybe there are lots of assumptions about self-references not 
>> existing outside of PHIs...).
>> - Passing the function that's implicitly called into the operand bundle is 
>> simpler to reason about than an opaque table index.
>> - Naming the operand bundle after its code generation consequences makes it 
>> simpler reason about. (A few generic names that make some sense to me 
>> (besides what I listed yesterday) include "callafter", "callimmediately", 
>> "forwardto", and "attachedcall". If it's important to make this ARC only, it 
>> could be (e.g.) "clang.arc.attachedcall".)
>
> The second and third suggestions seem like an improvement over the bundle 
> used in this patch.

+1, especially passing the function to call as argument to the bundle would 
make the lowering slightly easier; at the moment we may need to inject a new 
declaration during codegen.

> I'm not sure about the first one though as it seems to me that you'll still 
> have to teach at least some of the passes about the self-reference.

The patch already tries to do that, by adding calls to 
`llvm.objc.clang.arc.noop.use`, to make it explicit that there is a use of the 
returned value. This ensures most optimizations are aware of the fact that the 
return value is used. The problem Akira is that regular uses can be updated and 
are not enough to block the problematic transformation in SCCP.

If the use is directly at the bundle,  I think we could somehow teach to 
lowering to use the referenced value and pass that to the ObjC runtime. But it 
would disable the runtime optimization.

I think in the short-term it would be OK to update `SCCP` as done in this 
patch, if we specify the `arc` bundle implicitly uses the return value, which 
does not refer to any ObjC specifics. We already do something similar for 
function with certain attributes.

I think it would be good to consider generalizing this 'implicitly used return 
value bundle' concept as a follow up, if there are other potential users. We 
then already laid the ground-work and updated the existing passes to work for 
the `arc` bundle and only have to update the checks.

@dexonsmith  @rjmccall What do you think? Would you be happy with iterating on 
the suggestions in tree?




Comment at: llvm/docs/LangRef.rst:2335
+``@objc_retainAutoreleasedReturnValue`` is called. If 1 is passed,
+``@objc_unsafeClaimAutoreleasedReturnValue`` is called.
+

Can you add a sentence making it explicit that calls with that bundle 
implicitly use the returned value?



Comment at: llvm/lib/Transforms/Scalar/SCCP.cpp:148
+  /// A list of functions whose return values cannot be zapped.
+  SmallPtrSet DontZapReturnFunctions;
 

I think it would be slightly simpler to have a positive name for the set, e.g. 
`MustPreserveReturnsInFn`. What do you think? IMO that's more general than 
referring to 'not zapping'.



Comment at: llvm/lib/Transforms/Scalar/SCCP.cpp:1643
+  // unless the call itself can be removed.
+  // If the call has operand bundle "clang.arc.rv", don't replace the call 
value
+  // with a constant. Doing so would enable dead argument elimination to change

I'd keep things generic and say something like `Calls with "clang.arc.rv" 
implicitly use the return value and those uses cannot be updated with a 
constant.`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92808

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li

[PATCH] D96281: [clang-tidy] Add options to flag individual core increments and to ignore macros to readability-function-cognitive-complexity check.

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

How does this handle a macro where the argument has complex code.

  MACRO(if (...) {});

In this case the macro code is definitely increasing the complexity.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96281

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

[PATCH] D90448: [clang] Add type check for explicit instantiation of static data members

[Chuyang Chen via Phabricator via cfe-commits]

nomanous added a comment.

Ping @rsmith @dblaikie @MaskRay @haowei @Xiangling_L @lebedev.ri


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90448

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

[clang] 81a9707 - [Attr] Apply GNU-style attributes to expression statements

[Valeriy Savchenko via cfe-commits]

Author: Valeriy Savchenko
Date: 2021-02-11T16:44:41+03:00
New Revision: 81a9707723845a5b880245da24633c519493205c

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

LOG: [Attr] Apply GNU-style attributes to expression statements

Before this commit, expression statements could not be annotated
with statement attributes.  Whenever parser found attribute, it
unconditionally assumed that it was followed by a declaration.
This not only doesn't allow expression attributes to have attributes,
but also produces spurious error diagnostics.

In order to maintain all previously compiled code, we still assume
that GNU attributes are followed by declarations unless ALL of those
are statement attributes.  And even in this case we are not forcing
the parser to think that it should parse a statement, but rather
let it proceed as if no attributes were found.

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

Added: 
clang/test/Parser/stmt-attributes.c
clang/test/Parser/stmt-attributes.cpp
clang/test/Parser/stmt-attributes.m

Modified: 
clang/include/clang/Basic/Features.def
clang/lib/Parse/ParseStmt.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Features.def 
b/clang/include/clang/Basic/Features.def
index 5424da67b62da..32830a3a532cc 100644
--- a/clang/include/clang/Basic/Features.def
+++ b/clang/include/clang/Basic/Features.def
@@ -253,6 +253,7 @@ EXTENSION(cxx_variable_templates, LangOpts.CPlusPlus)
 EXTENSION(overloadable_unmarked, true)
 EXTENSION(pragma_clang_attribute_namespaces, true)
 EXTENSION(pragma_clang_attribute_external_declaration, true)
+EXTENSION(statement_attributes_with_gnu_syntax, true)
 EXTENSION(gnu_asm, LangOpts.GNUAsm)
 EXTENSION(gnu_asm_goto_with_outputs, LangOpts.GNUAsm)
 EXTENSION(matrix_types, LangOpts.MatrixTypes)

diff  --git a/clang/lib/Parse/ParseStmt.cpp b/clang/lib/Parse/ParseStmt.cpp
index 71344ff101552..f59271c458488 100644
--- a/clang/lib/Parse/ParseStmt.cpp
+++ b/clang/lib/Parse/ParseStmt.cpp
@@ -20,6 +20,8 @@
 #include "clang/Sema/DeclSpec.h"
 #include "clang/Sema/Scope.h"
 #include "clang/Sema/TypoCorrection.h"
+#include "llvm/ADT/STLExtras.h"
+
 using namespace clang;
 
 
//===--===//
@@ -215,7 +217,11 @@ StmtResult 
Parser::ParseStatementOrDeclarationAfterAttributes(
 if ((getLangOpts().CPlusPlus || getLangOpts().MicrosoftExt ||
  (StmtCtx & ParsedStmtContext::AllowDeclarationsInC) !=
  ParsedStmtContext()) &&
-(GNUAttributeLoc.isValid() || isDeclarationStatement())) {
+((GNUAttributeLoc.isValid() &&
+  !(!Attrs.empty() &&
+llvm::all_of(
+Attrs, [](ParsedAttr &Attr) { return Attr.isStmtAttr(); }))) ||
+ isDeclarationStatement())) {
   SourceLocation DeclStart = Tok.getLocation(), DeclEnd;
   DeclGroupPtrTy Decl;
   if (GNUAttributeLoc.isValid()) {

diff  --git a/clang/test/Parser/stmt-attributes.c 
b/clang/test/Parser/stmt-attributes.c
new file mode 100644
index 0..d142ce1b5b954
--- /dev/null
+++ b/clang/test/Parser/stmt-attributes.c
@@ -0,0 +1,90 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+#if !__has_extension(statement_attributes_with_gnu_syntax)
+#error "We should have statement attributes with GNU syntax support"
+#endif
+
+void foo(int i) {
+
+  __attribute__((unknown_attribute)); // expected-warning {{unknown attribute 
'unknown_attribute' ignored}}
+  __attribute__(()) {}
+  __attribute__(()) if (0) {}
+  __attribute__(()) for (;;);
+  __attribute__(()) do {
+__attribute__(()) continue;
+  }
+  while (0)
+;
+  __attribute__(()) while (0);
+
+  __attribute__(()) switch (i) {
+__attribute__(()) case 0 :
+__attribute__(()) default :
+__attribute__(()) break;
+  }
+
+  __attribute__(()) goto here;
+  __attribute__(()) here :
+
+  __attribute__(()) return;
+
+  __attribute__((noreturn)) {} // expected-error {{'noreturn' 
attribute cannot be applied to a statement}}
+  __attribute__((noreturn)) if (0) {}  // expected-error {{'noreturn' 
attribute cannot be applied to a statement}}
+  __attribute__((noreturn)) for (;;);  // expected-error {{'noreturn' 
attribute cannot be applied to a statement}}
+  __attribute__((noreturn)) do {   // expected-error {{'noreturn' 
attribute cannot be applied to a statement}}
+__attribute__((unavailable)) continue; // expected-error {{'unavailable' 
attribute cannot be applied to a statement}}
+  }
+  while (0)
+;
+  __attribute__((unknown_attribute)) while (0); // expected-warning {{unknown 
attribute 'unknown_attribute' ignored}}
+
+  __attribute__((unused)) switch (i) { // expected-error {{'unused' 
attribute cannot be applied to a statement}}
+  _

[PATCH] D93630: [Attr] Apply GNU-style attributes to expression statements

[Valeriy Savchenko via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG81a970772384: [Attr] Apply GNU-style attributes to 
expression statements (authored by vsavchenko).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93630

Files:
  clang/include/clang/Basic/Features.def
  clang/lib/Parse/ParseStmt.cpp
  clang/test/Parser/stmt-attributes.c
  clang/test/Parser/stmt-attributes.cpp
  clang/test/Parser/stmt-attributes.m

Index: clang/test/Parser/stmt-attributes.m
===
--- /dev/null
+++ clang/test/Parser/stmt-attributes.m
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -verify %s \
+// RUN:   -fblocks -fobjc-exceptions -fexceptions -fsyntax-only \
+// RUN:   -Wno-unused-value -Wno-unused-getter-return-value
+
+#if !__has_extension(statement_attributes_with_gnu_syntax)
+#error "We should have statement attributes with GNU syntax support"
+#endif
+
+@interface Base
+@end
+
+@interface Test : Base
+@property(getter=hasFoobar) int foobar;
+- (void)foo;
+- (void)bar;
+@end
+
+Test *getTest();
+
+@implementation Test
+- (void)foo __attribute__((nomerge)) {
+  // expected-error@-1 {{'nomerge' attribute only applies to functions and statements}}
+}
+
+- (void)bar {
+  __attribute__(()) [self foo];
+  // expected-error@-1 {{missing '[' at start of message send expression}}
+  // expected-error@-2 {{expected ']'}}
+  // expected-error@-3 {{expected identifier or '('}}
+  // expected-note@-4 {{to match this '['}}
+  __attribute__((nomerge)) [self foo];
+  // expected-warning@-1 {{nomerge attribute is ignored because there exists no call expression inside the statement}}
+  __attribute__((nomerge)) [getTest() foo];
+
+  __attribute__(()) ^{};
+  // expected-error@-1 {{expected identifier or '('}}
+  __attribute__((nomerge)) ^{};
+  // expected-warning@-1 {{nomerge attribute is ignored because there exists no call expression inside the statement}}
+  __attribute__((nomerge)) ^{ [self foo]; }();
+
+  __attribute__(()) @try {
+[self foo];
+  } @finally {
+  }
+
+  __attribute__((nomerge)) @try {
+[getTest() foo];
+  } @finally {
+  }
+
+  __attribute__((nomerge)) (__bridge void *)self;
+  // expected-warning@-1 {{nomerge attribute is ignored because there exists no call expression inside the statement}}
+
+  __attribute__((nomerge)) self.hasFoobar;
+  // expected-warning@-1 {{nomerge attribute is ignored because there exists no call expression inside the statement}}
+}
+@end
Index: clang/test/Parser/stmt-attributes.cpp
===
--- /dev/null
+++ clang/test/Parser/stmt-attributes.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -std=c++11 -fcxx-exceptions -fexceptions -fsyntax-only -verify %s
+
+#if !__has_extension(statement_attributes_with_gnu_syntax)
+#error "We should have statement attributes with GNU syntax support"
+#endif
+
+template 
+class __attribute__((nomerge)) A {
+  // expected-error@-1 {{'nomerge' attribute only applies to functions and statements}}
+};
+
+class B : public A<> {
+public:
+  void bar();
+};
+
+void bar();
+
+void foo(A<> *obj) {
+  __attribute__((nomerge)) static_cast(obj)->bar();
+  __attribute__((nomerge))[obj]() { static_cast(obj)->bar(); }
+  ();
+  __attribute__(()) try {
+bar();
+  } catch (...) {
+  }
+}
Index: clang/test/Parser/stmt-attributes.c
===
--- /dev/null
+++ clang/test/Parser/stmt-attributes.c
@@ -0,0 +1,90 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+#if !__has_extension(statement_attributes_with_gnu_syntax)
+#error "We should have statement attributes with GNU syntax support"
+#endif
+
+void foo(int i) {
+
+  __attribute__((unknown_attribute)); // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+  __attribute__(()) {}
+  __attribute__(()) if (0) {}
+  __attribute__(()) for (;;);
+  __attribute__(()) do {
+__attribute__(()) continue;
+  }
+  while (0)
+;
+  __attribute__(()) while (0);
+
+  __attribute__(()) switch (i) {
+__attribute__(()) case 0 :
+__attribute__(()) default :
+__attribute__(()) break;
+  }
+
+  __attribute__(()) goto here;
+  __attribute__(()) here :
+
+  __attribute__(()) return;
+
+  __attribute__((noreturn)) {} // expected-error {{'noreturn' attribute cannot be applied to a statement}}
+  __attribute__((noreturn)) if (0) {}  // expected-error {{'noreturn' attribute cannot be applied to a statement}}
+  __attribute__((noreturn)) for (;;);  // expected-error {{'noreturn' attribute cannot be applied to a statement}}
+  __attribute__((noreturn)) do {   // expected-error {{'noreturn' attribute cannot be applied to a statement}}
+__attribute__((unavailable)) continue; // expected-error {{'unavailable' attribute cannot be applied to a statement}}
+  }
+  while (0)
+;
+  __attribute__((unknown_attribute)

[PATCH] D94622: [clang-tidy] add concurrency-async-no-new-threads

[Vasily Kulikov via Phabricator via cfe-commits]

segoon added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.cpp:22
+/* C++ std */
+"::std::async", //
+

aaron.ballman wrote:
> The trailing comment markers don't really add much.
it's a hack for clang-format, otherwise it contatenates the lines, creating 
unmaintainable mess of strings. "One line - one name" is much more suitable.



Comment at: 
clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.cpp:33
+
+/* Linux */
+"::fork", //

aaron.ballman wrote:
> If we're going to add these, we should probably also add ones for Win32 and 
> Mac OS as well, like `CreateThread`, `CreateRemoteThread`, `_beginthread`, 
> `_beginthreadex`, etc.
I don't mind, but I'm not an expert in WinAPI or Windows programming. So, this 
part should be by someone with expertise of Windows in separate patches.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/concurrency-async-no-new-threads.rst:8-10
+functions and types. E.g. if the code uses C++ coroutines, it is expected
+that only new coroutines or coroutine-based primitives are created
+instead of heavy system threads.

aaron.ballman wrote:
> FWIW, this suggests to me that what you really want is a way for APIs to opt 
> into this behavior. There's no reason why you wouldn't have a complex system 
> that has both threads and coroutines in it, but it does stand to reason that 
> you may want to say "this function, and everything called within this 
> function, should not create any system threads" in some situations.
> 
> The note below helps call out the expectations from the check, but it 
> requires the developer to restructure the way they write code pretty 
> drastically in order to make the checking behavior more reasonable, which 
> does not seem ideal.
I think it is a complex problem, so it should be separated into smaller tasks.

Step one - checks with hardcoded functions/types with user-guided enabling on a 
per-file basis. A semi-automated check.

Step two - try to solve other parts of the puzzle. Maybe try to add 
[clang:coroutine_safe] tag and teach clang static analyzer to deduce coroutine 
safety property and use it for enabling/disabling the cheks. Maybe reuse other 
(not yet implemented) heuristics from static analyzer (or other tools) to 
identify coroutine functions and check only these functions. I'm not an expert 
in static analyzer, so other LLVM developers might find a clever heuristics 
when to enable/disable these checks or maybe how to deduce 
blacklisted/whitelisted functions/types lists (e.g. for 
concurrency-async-{fs,blocking}).

Indeed, the current approach has its own limitations. But it may be a first 
step in the right direction.


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

https://reviews.llvm.org/D94622

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

[PATCH] D96495: [clangd] Retire the cross-file-rename command-line flag.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added a reviewer: sammccall.
Herald added subscribers: usaxena95, kadircet, arphaman.
hokein requested review of this revision.
Herald added subscribers: MaskRay, ilya-biryukov.
Herald added a project: clang.

This patch only focuses on the flag. Removing actual single-file mode
(and the flag in RenameOption) will come in a follow-up.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96495

Files:
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/tool/ClangdMain.cpp


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -286,6 +286,7 @@
 RetiredFlag RecoveryASTType("recovery-ast-type");
 RetiredFlag AsyncPreamble("async-preamble");
 RetiredFlag CollectMainFileRefs("collect-main-file-refs");
+RetiredFlag CrossFileRename("cross-file-rename");
 
 opt LimitResults{
 "limit-results",
@@ -295,7 +296,6 @@
 init(100),
 };
 
-
 list TweakList{
 "tweaks",
 cat(Features),
@@ -304,13 +304,6 @@
 CommaSeparated,
 };
 
-opt CrossFileRename{
-"cross-file-rename",
-cat(Features),
-desc("Enable cross-file rename feature."),
-init(true),
-};
-
 opt FoldingRanges{
 "folding-ranges",
 cat(Features),
@@ -852,9 +845,6 @@
   if (ForceOffsetEncoding != OffsetEncoding::UnsupportedEncoding)
 Opts.Encoding = ForceOffsetEncoding;
 
-  // Shall we allow to customize the file limit?
-  Opts.Rename.AllowCrossFile = CrossFileRename;
-
   if (CheckFile.getNumOccurrences()) {
 llvm::SmallString<256> Path;
 llvm::sys::fs::real_path(CheckFile, Path, /*expand_tilde=*/true);
Index: clang-tools-extra/clangd/refactor/Rename.h
===
--- clang-tools-extra/clangd/refactor/Rename.h
+++ clang-tools-extra/clangd/refactor/Rename.h
@@ -29,7 +29,7 @@
 struct RenameOptions {
   /// If true, enable cross-file rename; otherwise, only allows to rename a
   /// symbol that's only used in the current file.
-  bool AllowCrossFile = false;
+  bool AllowCrossFile = true;
   /// The maximum number of affected files (0 means no limit), only meaningful
   /// when AllowCrossFile = true.
   /// If the actual number exceeds the limit, rename is forbidden.


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -286,6 +286,7 @@
 RetiredFlag RecoveryASTType("recovery-ast-type");
 RetiredFlag AsyncPreamble("async-preamble");
 RetiredFlag CollectMainFileRefs("collect-main-file-refs");
+RetiredFlag CrossFileRename("cross-file-rename");
 
 opt LimitResults{
 "limit-results",
@@ -295,7 +296,6 @@
 init(100),
 };
 
-
 list TweakList{
 "tweaks",
 cat(Features),
@@ -304,13 +304,6 @@
 CommaSeparated,
 };
 
-opt CrossFileRename{
-"cross-file-rename",
-cat(Features),
-desc("Enable cross-file rename feature."),
-init(true),
-};
-
 opt FoldingRanges{
 "folding-ranges",
 cat(Features),
@@ -852,9 +845,6 @@
   if (ForceOffsetEncoding != OffsetEncoding::UnsupportedEncoding)
 Opts.Encoding = ForceOffsetEncoding;
 
-  // Shall we allow to customize the file limit?
-  Opts.Rename.AllowCrossFile = CrossFileRename;
-
   if (CheckFile.getNumOccurrences()) {
 llvm::SmallString<256> Path;
 llvm::sys::fs::real_path(CheckFile, Path, /*expand_tilde=*/true);
Index: clang-tools-extra/clangd/refactor/Rename.h
===
--- clang-tools-extra/clangd/refactor/Rename.h
+++ clang-tools-extra/clangd/refactor/Rename.h
@@ -29,7 +29,7 @@
 struct RenameOptions {
   /// If true, enable cross-file rename; otherwise, only allows to rename a
   /// symbol that's only used in the current file.
-  bool AllowCrossFile = false;
+  bool AllowCrossFile = true;
   /// The maximum number of affected files (0 means no limit), only meaningful
   /// when AllowCrossFile = true.
   /// If the actual number exceeds the limit, rename is forbidden.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93023: Replace deprecated %T in 2 tests.

[Hafiz Abid Qadeer via Phabricator via cfe-commits]

abidh updated this revision to Diff 322970.
abidh added a comment.

Changes in this version.

1. Added an explicit --sysroot argument.
2. Shortened "testroot-riscv{len}-baremetal-nogcc" string

As pointed out by @MaskRay  that some tests were failing when 
gcc-10-riscv64-linux-gnu was installed. This was happening because the test was 
checking a case when --gcc-toolchain is not provided. In this case, code does 
check the path alongside clang installation. But it also checks for a system 
wide installation in /usr. It prefers a higher version number too. So to make 
the test more robust, I have provided an explicit --sysroot argument. Its value 
has been chosen to match the existing pattern.


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

https://reviews.llvm.org/D93023

Files:
  clang/test/Driver/riscv32-toolchain-extra.c
  clang/test/Driver/riscv64-toolchain-extra.c


Index: clang/test/Driver/riscv64-toolchain-extra.c
===
--- clang/test/Driver/riscv64-toolchain-extra.c
+++ clang/test/Driver/riscv64-toolchain-extra.c
@@ -11,25 +11,26 @@
 // The test below checks that the driver correctly finds the linker and
 // runtime if and only if they exist.
 //
-// RUN: rm -rf %T/testroot-riscv64-baremetal-nogcc
-// RUN: mkdir -p %T/testroot-riscv64-baremetal-nogcc/bin
-// RUN: ln -s %clang %T/testroot-riscv64-baremetal-nogcc/bin/clang
-// RUN: ln -s %S/Inputs/basic_riscv64_nogcc_tree/bin/riscv64-unknown-elf-ld 
%T/testroot-riscv64-baremetal-nogcc/bin/riscv64-unknown-elf-ld
-// RUN: ln -s %S/Inputs/basic_riscv64_nogcc_tree/riscv64-unknown-elf 
%T/testroot-riscv64-baremetal-nogcc/riscv64-unknown-elf
-// RUN: %T/testroot-riscv64-baremetal-nogcc/bin/clang %s -### 
-no-canonical-prefixes \
-// RUN:--gcc-toolchain=%T/testroot-riscv64-baremetal-nogcc/invalid \
+// RUN: rm -rf %t
+// RUN: mkdir -p %t/riscv64-nogcc/bin
+// RUN: ln -s %clang %t/riscv64-nogcc/bin/clang
+// RUN: ln -s %S/Inputs/basic_riscv64_nogcc_tree/bin/riscv64-unknown-elf-ld 
%t/riscv64-nogcc/bin/riscv64-unknown-elf-ld
+// RUN: ln -s %S/Inputs/basic_riscv64_nogcc_tree/riscv64-unknown-elf 
%t/riscv64-nogcc/riscv64-unknown-elf
+// RUN: %t/riscv64-nogcc/bin/clang %s -### -no-canonical-prefixes \
+// RUN:--gcc-toolchain=%t/riscv64-nogcc/invalid \
 // RUN:-target riscv64-unknown-elf --rtlib=platform -fuse-ld= 2>&1 \
 // RUN:| FileCheck -check-prefix=C-RV64-BAREMETAL-LP64-NOGCC %s
 
-// RUN: %T/testroot-riscv64-baremetal-nogcc/bin/clang %s -### 
-no-canonical-prefixes \
+// RUN: %t/riscv64-nogcc/bin/clang %s -### -no-canonical-prefixes \
+// RUN:--sysroot=%t/riscv64-nogcc/bin/../riscv64-unknown-elf \
 // RUN:-target riscv64-unknown-elf --rtlib=platform -fuse-ld= 2>&1 \
 // RUN:| FileCheck -check-prefix=C-RV64-BAREMETAL-LP64-NOGCC %s
 
-// C-RV64-BAREMETAL-LP64-NOGCC: "-internal-isystem" 
"{{.*}}Output/testroot-riscv64-baremetal-nogcc/bin/../riscv64-unknown-elf/include"
-// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}Output/testroot-riscv64-baremetal-nogcc/bin/riscv64-unknown-elf-ld"
-// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}Output/testroot-riscv64-baremetal-nogcc/bin/../riscv64-unknown-elf/lib/crt0.o"
-// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}Output/testroot-riscv64-baremetal-nogcc/{{.*}}/lib/clang_rt.crtbegin-riscv64.o"
-// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}Output/testroot-riscv64-baremetal-nogcc/bin/../riscv64-unknown-elf/lib"
+// C-RV64-BAREMETAL-LP64-NOGCC: "-internal-isystem" 
"{{.*}}/riscv64-nogcc/bin/../riscv64-unknown-elf/include"
+// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}/riscv64-nogcc/bin/riscv64-unknown-elf-ld"
+// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}/riscv64-nogcc/bin/../riscv64-unknown-elf/lib/crt0.o"
+// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}/riscv64-nogcc/{{.*}}/lib/clang_rt.crtbegin-riscv64.o"
+// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}/riscv64-nogcc/bin/../riscv64-unknown-elf/lib"
 // C-RV64-BAREMETAL-LP64-NOGCC: "--start-group" "-lc" "-lgloss" "--end-group"
-// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}Output/testroot-riscv64-baremetal-nogcc/{{.*}}/lib/libclang_rt.builtins-riscv64.a"
-// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}Output/testroot-riscv64-baremetal-nogcc/{{.*}}/lib/clang_rt.crtend-riscv64.o"
+// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}/riscv64-nogcc/{{.*}}/lib/libclang_rt.builtins-riscv64.a"
+// C-RV64-BAREMETAL-LP64-NOGCC: 
"{{.*}}/riscv64-nogcc/{{.*}}/lib/clang_rt.crtend-riscv64.o"
Index: clang/test/Driver/riscv32-toolchain-extra.c
===
--- clang/test/Driver/riscv32-toolchain-extra.c
+++ clang/test/Driver/riscv32-toolchain-extra.c
@@ -11,25 +11,26 @@
 // The test below checks that the driver correctly finds the linker and
 // runtime if and only if they exist.
 //
-// RUN: rm -rf %T/testroot-riscv32-baremetal-nogcc
-// RUN: mkdir -p %T/testroot-riscv32-baremetal-nogcc/bin
-// RUN: ln -s %clang %T/testroot-riscv32-baremetal-nogcc/bin/clang
-// RUN: ln -s %S/Inputs/basic_riscv32_

[PATCH] D94622: [clang-tidy] add concurrency-async-no-new-threads

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.cpp:22
+/* C++ std */
+"::std::async", //
+

segoon wrote:
> aaron.ballman wrote:
> > The trailing comment markers don't really add much.
> it's a hack for clang-format, otherwise it contatenates the lines, creating 
> unmaintainable mess of strings. "One line - one name" is much more suitable.
Ah, I didn't know that'd change the behavior of clang-format, that's neat!

FWIW, we usually don't do a whole lot of markup to avoid clang-format issues 
(such as the clang-format: on/off markers). Instead, we usually just ignore the 
LINT warnings in code review and check the code in as-is. This helps reduce 
clutter in the code base. In this case, the comments aren't adding a ton of 
clutter so maybe they're fine. But they definitely look odd as a reader of the 
code, which is a bit distracting.



Comment at: 
clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.cpp:33
+
+/* Linux */
+"::fork", //

segoon wrote:
> aaron.ballman wrote:
> > If we're going to add these, we should probably also add ones for Win32 and 
> > Mac OS as well, like `CreateThread`, `CreateRemoteThread`, `_beginthread`, 
> > `_beginthreadex`, etc.
> I don't mind, but I'm not an expert in WinAPI or Windows programming. So, 
> this part should be by someone with expertise of Windows in separate patches.
I don't think it needs to be done in separate patches. I can give you the full 
list of things I care about.
```
CreateThread 
(https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createthread)
CreateRemoteThread 
(https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createremotethread)
CreateRemoteThreadEx 
(https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createremotethreadex)
_beginthread
_beginthreadex 
(https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-160)
```



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/concurrency-async-no-new-threads.rst:8-10
+functions and types. E.g. if the code uses C++ coroutines, it is expected
+that only new coroutines or coroutine-based primitives are created
+instead of heavy system threads.

segoon wrote:
> aaron.ballman wrote:
> > FWIW, this suggests to me that what you really want is a way for APIs to 
> > opt into this behavior. There's no reason why you wouldn't have a complex 
> > system that has both threads and coroutines in it, but it does stand to 
> > reason that you may want to say "this function, and everything called 
> > within this function, should not create any system threads" in some 
> > situations.
> > 
> > The note below helps call out the expectations from the check, but it 
> > requires the developer to restructure the way they write code pretty 
> > drastically in order to make the checking behavior more reasonable, which 
> > does not seem ideal.
> I think it is a complex problem, so it should be separated into smaller tasks.
> 
> Step one - checks with hardcoded functions/types with user-guided enabling on 
> a per-file basis. A semi-automated check.
> 
> Step two - try to solve other parts of the puzzle. Maybe try to add 
> [clang:coroutine_safe] tag and teach clang static analyzer to deduce 
> coroutine safety property and use it for enabling/disabling the cheks. Maybe 
> reuse other (not yet implemented) heuristics from static analyzer (or other 
> tools) to identify coroutine functions and check only these functions. I'm 
> not an expert in static analyzer, so other LLVM developers might find a 
> clever heuristics when to enable/disable these checks or maybe how to deduce 
> blacklisted/whitelisted functions/types lists (e.g. for 
> concurrency-async-{fs,blocking}).
> 
> Indeed, the current approach has its own limitations. But it may be a first 
> step in the right direction.
My fear with the current approach is that I don't think projects usually split 
their code in the way this check requires, and so the check will not be very 
useful in practice because it will be too chatty. Have you tried running this 
check over some large projects that use coroutines to see what the diagnostic 
results look like?


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

https://reviews.llvm.org/D94622

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

[PATCH] D90691: [analyzer] Add new checker for unchecked return value.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

> but it is planned that the checker takes use of the planned new attributes to 
> determine if a function should be checked

This is literally `__attribute__((warn_unused_result))` for which there already 
is a compiler warning.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90691

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

[PATCH] D94779: [Clang] Ensure vector predication loop metadata is always emitted when pragma is specified.

[Malhar via Phabricator via cfe-commits]

malharJ added inline comments.



Comment at: clang/test/CodeGenCXX/pragma-loop-predicate.cpp:88
+
+#pragma clang loop vectorize_predicate(enable) vectorize_width(1)
+  for (int i = 0; i < Length; i++)

dmgreen wrote:
> malharJ wrote:
> > dmgreen wrote:
> > > Can you add another test for `#pragma clang loop vectorize(disable) 
> > > vectorize_predicate(enable)`. My understanding is that it will produce 
> > > the same as `vectorize_predicate(enable) vectorize_width(1)`
> > I believe test5( ) above takes care of this ? 
> > 
> > comparing the output of the two (test8 and test5), test8 produces an extra 
> > metadata : 
> > 
> > ```
> > {!"llvm.loop.vectorize.scalable.enable", i1 false}
> > ```
> > 
> Oh yeah. I didn't see the existing checks. Strange that it would not emit 
> scalable then, but still doing the expected thing.
I had a quick look at the logic for scalable, and it seems like it's only 
emitted when a fixed/scalable vectorization width has been specified.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94779

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

[PATCH] D96265: [PowerPC] Change target data layout for 16-byte stack alignment

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

Can you please merge the tests into one file. There is no compelling reason to 
split them up and it is more difficult to review and make sense of what is 
going on. The test case should have:

1. A function that allocates a 32-byte vector (i.e. defined with 
`__attribute__((vector_size(32)))`)
2. A function that allocates a 32-byte aligned vector (i.e. defined with 
`__attribute__((aligned(32)))`)
3. A function that allocates an array that wouldn't be aligned to something in 
excess of stack alignment but gets over-aligned due to vectorization

You can achieve 3. above with something like this:

  $ cat t.c
  char Arr1[64];
  void test(short *);
  void cpy() {
short Arr2[64];
for (int i = 0; i < 64; i++)
  Arr2[i] = Arr1[i];
test(Arr2);
  }
  
  clang -O3 -S t.c -emit-llvm -Xclang -disable-llvm-passes

Then the test case should run something like the following:
`opt --passes=sroa,loop-vectorize,loop-unroll,instcombine t.ll -S -o t.opt.ll 
-vectorizer-maximize-bandwidth --mtriple=powerpc64le--`
And check the alignment of the `alloca` and vector store. They should be 16 and 
not 32 even though the vector is 32 bytes wide.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96265

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

[PATCH] D96495: [clangd] Retire the cross-file-rename command-line flag.

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

Those test failures look related.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96495

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

[PATCH] D94779: [Clang] Ensure vector predication loop metadata is always emitted when pragma is specified.

[Malhar via Phabricator via cfe-commits]

malharJ added a comment.

I do not have commit access. Can someone with commit access please commit this 
patch ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94779

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

[clang] 059a335 - Store the calculated constant expression value into the ConstantExpr object

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2021-02-11T10:18:16-05:00
New Revision: 059a335ee99e9c50442d8caa35c1b31b5cf47e9c

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

LOG: Store the calculated constant expression value into the ConstantExpr object

With https://reviews.llvm.org/D63376, we began storing the APValue
directly into the ConstantExpr object so that we could reuse the
calculated value later. However, it missed a case when not in C++11
mode but the expression is known to be constant.

Added: 


Modified: 
clang/lib/Sema/SemaExpr.cpp
clang/test/AST/ast-dump-c-attr.c
clang/test/AST/ast-dump-decl-json.c
clang/test/AST/ast-dump-decl.c
clang/test/AST/ast-dump-openmp-distribute-parallel-for-simd.c
clang/test/AST/ast-dump-openmp-distribute-parallel-for.c
clang/test/AST/ast-dump-openmp-distribute-simd.c
clang/test/AST/ast-dump-openmp-distribute.c
clang/test/AST/ast-dump-openmp-for-simd.c
clang/test/AST/ast-dump-openmp-for.c
clang/test/AST/ast-dump-openmp-ordered.c
clang/test/AST/ast-dump-openmp-parallel-for-simd.c
clang/test/AST/ast-dump-openmp-parallel-for.c
clang/test/AST/ast-dump-openmp-simd.c
clang/test/AST/ast-dump-openmp-target-parallel-for-simd.c
clang/test/AST/ast-dump-openmp-target-parallel-for.c
clang/test/AST/ast-dump-openmp-target-simd.c
clang/test/AST/ast-dump-openmp-target-teams-distribute-parallel-for-simd.c
clang/test/AST/ast-dump-openmp-target-teams-distribute-parallel-for.c
clang/test/AST/ast-dump-openmp-target-teams-distribute-simd.c
clang/test/AST/ast-dump-openmp-target-teams-distribute.c
clang/test/AST/ast-dump-openmp-taskloop-simd.c
clang/test/AST/ast-dump-openmp-taskloop.c
clang/test/AST/ast-dump-openmp-teams-distribute-parallel-for-simd.c
clang/test/AST/ast-dump-openmp-teams-distribute-parallel-for.c
clang/test/AST/ast-dump-openmp-teams-distribute-simd.c
clang/test/AST/ast-dump-openmp-teams-distribute.c
clang/test/AST/ast-dump-records.c

Removed: 




diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 45616dadcbee..1f20ee7f7c7a 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -16138,7 +16138,8 @@ Sema::VerifyIntegerConstantExpression(Expr *E, 
llvm::APSInt *Result,
 if (Result)
   *Result = E->EvaluateKnownConstIntCheckOverflow(Context);
 if (!isa(E))
-  E = ConstantExpr::Create(Context, E);
+  E = Result ? ConstantExpr::Create(Context, E, APValue(*Result))
+ : ConstantExpr::Create(Context, E);
 return E;
   }
 

diff  --git a/clang/test/AST/ast-dump-c-attr.c 
b/clang/test/AST/ast-dump-c-attr.c
index c40a2332090c..7d18f0cdc9f1 100644
--- a/clang/test/AST/ast-dump-c-attr.c
+++ b/clang/test/AST/ast-dump-c-attr.c
@@ -34,8 +34,9 @@ struct [[deprecated]] Test4 {
 // CHECK-NEXT:   FieldDecl{{.*}}Test6
 // CHECK-NEXT: DeprecatedAttr 0x{{[^ ]*}}  "Frobble" ""
 // CHECK-NEXT:   FieldDecl{{.*}}Test7
-// CHECK-NEXT: Constant{{.*}}'int'
-// CHECK-NEXT:   IntegerLiteral{{.*}}'int' 12
+// CHECK-NEXT: ConstantExpr{{.*}}'int'
+// CHECK-NEXT:   value: Int 12
+// CHECK-NEXT: IntegerLiteral{{.*}}'int' 12
 // CHECK-NEXT: DeprecatedAttr 0x{{[^ ]*}}  "" ""
 
 struct [[deprecated]] Test8;

diff  --git a/clang/test/AST/ast-dump-decl-json.c 
b/clang/test/AST/ast-dump-decl-json.c
index 8d8f8149666d..5bcd4f1e5e11 100644
--- a/clang/test/AST/ast-dump-decl-json.c
+++ b/clang/test/AST/ast-dump-decl-json.c
@@ -948,6 +948,7 @@ void testParmVarDecl(int TestParmVarDecl);
 // CHECK-NEXT: "qualType": "int"
 // CHECK-NEXT:},
 // CHECK-NEXT:"valueCategory": "rvalue",
+// CHECK-NEXT:"value": "1",
 // CHECK-NEXT:"inner": [
 // CHECK-NEXT: {
 // CHECK-NEXT:  "id": "0x{{.*}}",
@@ -1668,6 +1669,7 @@ void testParmVarDecl(int TestParmVarDecl);
 // CHECK-NEXT: "qualType": "int"
 // CHECK-NEXT:},
 // CHECK-NEXT:"valueCategory": "rvalue",
+// CHECK-NEXT:"value": "1",
 // CHECK-NEXT:"inner": [
 // CHECK-NEXT: {
 // CHECK-NEXT:  "id": "0x{{.*}}",

diff  --git a/clang/test/AST/ast-dump-decl.c b/clang/test/AST/ast-dump-decl.c
index 0b5a8e93a86d..4380877a410b 100644
--- a/clang/test/AST/ast-dump-decl.c
+++ b/clang/test/AST/ast-dump-decl.c
@@ -112,7 +112,8 @@ enum testEnumConstantDecl {
 // CHECK:  EnumConstantDecl{{.*}} TestEnumConstantDecl 'int'
 // CHECK:  EnumConstantDecl{{.*}} TestEnumConstantDeclInit 'int'
 // CHECK-NEXT:   ConstantExpr
-// CHECK-NEXT: IntegerLiteral
+// CHECK-NEXT: value: Int 1
+// CHECK-NEXT:   IntegerLiteral
 
 struct testIndirectFieldDecl {
   struct {
@@ -160,7 +161,8 @@ struct testFieldDecl {
 // CHECK:  FieldDecl{{.*}} TestFieldDecl 'int'
 // CHECK:  FieldDecl{{.*}} Test

[PATCH] D94627: [PowerPC][PC Rel] Implement option to omit Power10 instructions from stubs

[Albion Fung via Phabricator via cfe-commits]

Conanap updated this revision to Diff 323000.
Conanap marked 6 inline comments as done.
Conanap added a comment.

Fixed up a few comments


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

https://reviews.llvm.org/D94627

Files:
  lld/ELF/Config.h
  lld/ELF/Driver.cpp
  lld/ELF/Options.td
  lld/ELF/Thunks.cpp
  lld/ELF/Thunks.h
  lld/test/ELF/ppc64-call-reach.s
  lld/test/ELF/ppc64-long-branch-localentry-offset.s
  lld/test/ELF/ppc64-long-branch-pi.s
  lld/test/ELF/ppc64-long-branch-rel14.s
  lld/test/ELF/ppc64-long-branch.s
  lld/test/ELF/ppc64-pcrel-call-to-extern.s
  lld/test/ELF/ppc64-pcrel-call-to-toc.s
  lld/test/ELF/ppc64-plt-stub-compatible.s
  lld/test/ELF/ppc64-tls-pcrel-gd.s
  lld/test/ELF/ppc64-toc-call-to-pcrel-long-jump.s
  lld/test/ELF/ppc64-toc-call-to-pcrel.s
  llvm/include/llvm/Object/ELF.h

Index: llvm/include/llvm/Object/ELF.h
===
--- llvm/include/llvm/Object/ELF.h
+++ llvm/include/llvm/Object/ELF.h
@@ -87,6 +87,9 @@
 
 enum PPCInstrMasks : uint64_t {
   PADDI_R12_NO_DISP = 0x06103980,
+  ADDIS_R12_TO_R2_NO_DISP = 0x3D82,
+  ADDI_R12_TO_R2_NO_DISP = 0x3982,
+  ADDI_R12_TO_R12_NO_DISP = 0x398C,
   PLD_R12_NO_DISP = 0x0410E580,
   MTCTR_R12 = 0x7D8903A6,
   BCTR = 0x4E800420,
Index: lld/test/ELF/ppc64-toc-call-to-pcrel.s
===
--- lld/test/ELF/ppc64-toc-call-to-pcrel.s
+++ lld/test/ELF/ppc64-toc-call-to-pcrel.s
@@ -14,6 +14,12 @@
 # RUN: llvm-readelf -s %t | FileCheck %s --check-prefix=SYMBOL
 # RUN: llvm-objdump -d --no-show-raw-insn --mcpu=future %t | FileCheck %s
 
+# RUN: llvm-mc -filetype=obj -triple=powerpc64 %s -o %t.o
+# RUN: ld.lld -T %t.script %t.o -o %t --no-power10-stubs
+# RUN: llvm-readelf -s %t | FileCheck %s --check-prefix=SYMBOL
+# RUN: llvm-objdump -d --no-show-raw-insn --mcpu=future %t \
+# RUN: | FileCheck %s
+
 # The point of this test is to make sure that when a function with TOC access
 # a local function with st_other=1, a TOC save stub is inserted.
 
Index: lld/test/ELF/ppc64-toc-call-to-pcrel-long-jump.s
===
--- lld/test/ELF/ppc64-toc-call-to-pcrel-long-jump.s
+++ lld/test/ELF/ppc64-toc-call-to-pcrel-long-jump.s
@@ -11,15 +11,20 @@
 # RUN: llvm-objdump --mcpu=pwr10 --no-show-raw-insn -d %t_be | FileCheck %s
 # RUN: llvm-readelf -s %t_be | FileCheck %s --check-prefix=SYM
 
+# RUN: llvm-mc -filetype=obj -triple=powerpc64le %t/asm -o %t.o
+# RUN: ld.lld -T %t/lts %t.o -o %t_le --no-power10-stubs
+# RUN: llvm-objdump --mcpu=pwr10 --no-show-raw-insn -d %t_le | FileCheck %s --check-prefix=NoP10
+# RUN: llvm-readelf -s %t_le | FileCheck %s --check-prefix=SYM
+
 # SYM:  Symbol table '.symtab' contains 9 entries:
 # SYM:  1: 1001 0 NOTYPE  LOCAL  DEFAULT []   1 callee
 # SYM-NEXT: 2: 10020008 0 NOTYPE  LOCAL  DEFAULT  2 caller_close
 # SYM-NEXT: 3: 20020008 0 NOTYPE  LOCAL  DEFAULT []   3 caller
 # SYM-NEXT: 4: 000520020008 0 NOTYPE  LOCAL  DEFAULT  4 caller_far
-# SYM-NEXT: 5: 000520028038 0 NOTYPE  LOCAL  HIDDEN   6 .TOC.
+# SYM-NEXT: 5: 000520028040 0 NOTYPE  LOCAL  HIDDEN   6 .TOC.
 # SYM-NEXT: 6: 10020020 8 FUNCLOCAL  DEFAULT  2 __toc_save_callee
-# SYM-NEXT: 7: 2002002020 FUNCLOCAL  DEFAULT  3 __toc_save_callee
-# SYM-NEXT: 8: 00052002002020 FUNCLOCAL  DEFAULT  4 __toc_save_callee
+# SYM-NEXT: 7: 2002002032 FUNCLOCAL  DEFAULT  3 __toc_save_callee
+# SYM-NEXT: 8: 00052002002032 FUNCLOCAL  DEFAULT  4 __toc_save_callee
 
 #--- lts
 PHDRS {
@@ -72,6 +77,17 @@
 # CHECK-NEXT:paddi 12, 0, -268501028, 1
 # CHECK-NEXT:mtctr 12
 # CHECK-NEXT:bctr
+
+# NoP10-LABEL: :
+# NoP10: bl 0x20020020
+# NoP10-NEXT:ld 2, 24(1)
+# NoP10-NEXT:blr
+# NoP10-LABEL: <__toc_save_callee>:
+# NoP10-NEXT: std 2, 24(1)
+# NoP10-NEXT:addis 12, 2, -4098
+# NoP10-NEXT:addi 12, 12, 32704
+# NoP10-NEXT:mtctr 12
+# NoP10-NEXT:bctr
 .section .text_caller, "ax", %progbits
 .Lfunc_toc2:
   .quad .TOC.-.Lfunc_gep2
Index: lld/test/ELF/ppc64-tls-pcrel-gd.s
===
--- lld/test/ELF/ppc64-tls-pcrel-gd.s
+++ lld/test/ELF/ppc64-tls-pcrel-gd.s
@@ -42,10 +42,10 @@
 #--- asm
 
 # GD-RELOC: Relocation section '.rela.dyn' at offset 0x100b8 contains 4 entries:
-# GD-RELOC: 01001160  00020044 R_PPC64_DTPMOD64    x + 0
-# GD-RELOC: 01001168  0002004e R_PPC64_DTPREL64    x + 0
-# GD-RELOC: 01001170  00030044 R_PPC64_DTPMOD64    y + 0
-# GD-RELOC: 01001178  0003004e R_PPC64_DTPRE

[PATCH] D94622: [clang-tidy] add concurrency-async-no-new-threads

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/concurrency-async-no-new-threads.rst:14
+
+   The check doesn't identify synchronous and asynchronous code. Insead, it
+   assumes that all analyzed code is asynchronous and all blocking calls have 
to

Typo: Insead -> Instead


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

https://reviews.llvm.org/D94622

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

[PATCH] D96418: [clang] Refactor mustprogress handling, add it to all loops in c++11+.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 323003.
fhahn added a comment.

Add reference to standards.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96418

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/attr-mustprogress.c
  clang/test/CodeGenCXX/attr-mustprogress.cpp

Index: clang/test/CodeGenCXX/attr-mustprogress.cpp
===
--- clang/test/CodeGenCXX/attr-mustprogress.cpp
+++ clang/test/CodeGenCXX/attr-mustprogress.cpp
@@ -10,27 +10,27 @@
 // CHECK: datalayout
 
 // CXX98-NOT: mustprogress
-// CXX11-NOT: mustprogress
+// CXX11: mustprogress
 // CHECK-LABEL: @_Z2f0v(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:br label %for.cond
 // CHECK:   for.cond:
 // CXX98-NOT:br {{.*}} llvm.loop
-// CXX11-NOT:br {{.*}} llvm.loop
+// CXX11-NEXT:   br label %for.cond, !llvm.loop [[LOOP1:!.*]]
 void f0() {
   for (; ;) ;
 }
 
 // CXX98-NOT: mustprogress
-// CXX11-NOT: mustprogress
+// CXX11: mustprogress
 // CHECK-LABEL: @_Z2f1v(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:br label %for.cond
 // CHECK:   for.cond:
 // CHECK-NEXT:br i1 true, label %for.body, label %for.end
 // CHECK:   for.body:
-// CXX98-NOT:br {{.*}}, !llvm.loop
-// CXX11-NOT:br {{.*}}, !llvm.loop
+// CXX98-NOT: br {{.*}}, !llvm.loop
+// CXX11-NEXT:br label %for.cond, !llvm.loop [[LOOP2:!.*]]
 // CHECK:   for.end:
 // CHECK-NEXT:ret void
 //
@@ -50,8 +50,8 @@
 // CHECK-NEXT:[[CMP:%.*]] = icmp eq i32 [[TMP0]], [[TMP1]]
 // CHECK-NEXT:br i1 [[CMP]], label %for.body, label %for.end
 // CHECK:   for.body:
-// CXX98-NOT:br {{.*}}, !llvm.loop
-// CXX11:br label %for.cond, !llvm.loop [[LOOP1:!.*]]
+// CXX98-NOT: br {{.*}}, !llvm.loop
+// CXX11-NEXT:br label %for.cond, !llvm.loop [[LOOP3:!.*]]
 // CHECK:   for.end:
 // CHECK-NEXT:ret void
 //
@@ -61,7 +61,7 @@
 }
 
 // CXX98-NOT: mustprogress
-// CXX11-NOT: mustprogress
+// CXX11: mustprogress
 // CHECK-LABEL: @_Z1Fv(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:br label %for.cond
@@ -69,7 +69,7 @@
 // CHECK-NEXT:br i1 true, label %for.body, label %for.end
 // CHECK:   for.body:
 // CXX98-NOT: br {{.*}}, !llvm.loop
-// CXX11-NOT: br {{.*}}, !llvm.loop
+// CXX11-NEXT:br label %for.cond, !llvm.loop [[LOOP4:!.*]]
 // CHECK:   for.end:
 // CHECK-NEXT:br label %for.cond1
 // CHECK:   for.cond1:
@@ -78,8 +78,8 @@
 // CHECK-NEXT:[[CMP:%.*]] = icmp eq i32 [[TMP0]], [[TMP1]]
 // CHECK-NEXT:br i1 [[CMP]], label %for.body2, label %for.end3
 // CHECK:   for.body2:
-// CXX98-NOT:br {{.*}}, !llvm.loop
-// CXX11:br label %for.cond1, !llvm.loop [[LOOP2:!.*]]
+// CXX98-NOT: br {{.*}}, !llvm.loop
+// CXX11-NEXT:br label %for.cond1, !llvm.loop [[LOOP5:!.*]]
 // CHECK:   for.end3:
 // CHECK-NEXT:ret void
 //
@@ -102,14 +102,14 @@
 // CHECK-NEXT:br i1 [[CMP]], label %for.body, label %for.end
 // CHECK:   for.body:
 // CXX98_NOT: br {{.*}} !llvm.loop
-// CXX11-NEXT:br label %for.cond, !llvm.loop
+// CXX11-NEXT:br label %for.cond, !llvm.loop [[LOOP6:!.*]]
 // CHECK:   for.end:
 // CHECK-NEXT:br label %for.cond1
 // CHECK:   for.cond1:
 // CHECK-NEXT:br i1 true, label %for.body2, label %for.end3
 // CHECK:   for.body2:
 // CXX98-NOT: br {{.*}}, !llvm.loop
-// CXX11-NOT: br {{.*}}, !llvm.loop
+// CXX11-NEXT:br label %for.cond1, !llvm.loop [[LOOP7:!.*]]
 // CHECK:   for.end3:
 // CHECK-NEXT:ret void
 //
@@ -121,13 +121,13 @@
 }
 
 // CXX98-NOT: mustprogress
-// CXX11-NOT: mustprogress
+// CXX11: mustprogress
 // CHECK-LABEL: @_Z2w1v(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:br label %while.body
 // CHECK:   while.body:
 // CXX98-NOT: br {{.*}}, !llvm.loop
-// CXX11-NOT: br {{.*}}, !llvm.loop
+// CXX11-NEXT:br label %while.body, !llvm.loop [[LOOP8:!.*]]
 //
 void w1() {
   while (1)
@@ -146,7 +146,7 @@
 // CHECK-NEXT:br i1 [[CMP]], label %while.body, label %while.end
 // CHECK:   while.body:
 // CXX98-NOT: br {{.*}}, !llvm.loop
-// CXX11-NEXT:br label %while.cond, !llvm.loop [[LOOP3:!.*]]
+// CXX11-NEXT:br label %while.cond, !llvm.loop [[LOOP9:!.*]]
 // CHECK:   while.end:
 // CHECK-NEXT:ret void
 //
@@ -156,7 +156,7 @@
 }
 
 // CXX98-NOT: mustprogress
-// CXX11-NOT: mustprogress
+// CXX11: mustprogress
 // CHECK-LABEL: @_Z1Wv(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:br label %while.cond
@@ -167,12 +167,12 @@
 // CHECK-NEXT:br i1 [[CMP]], label %while.body, label %while.end
 // CHECK:   while.body:
 // CXX98-NOT: br {{.*}}, !llvm.loop
-// CXX11-NEXT:br label %while.cond, !llvm.loop [[LOOP4:!.*]]
+// CXX11-NEXT:br label %while.cond, !llvm.loop [[LOOP10:!.*]]
 // CHECK:   while.end:
 // CHECK-NEXT:br labe

[PATCH] D96507: [clangd] Move command handlers into a map in ClangdLSPServer. NFC

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: kadircet.
Herald added subscribers: usaxena95, arphaman, mgrang.
sammccall requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96507

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h

Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -913,14 +913,6 @@
 bool fromJSON(const llvm::json::Value &, TweakArgs &, llvm::json::Path);
 llvm::json::Value toJSON(const TweakArgs &A);
 
-/// Exact commands are not specified in the protocol so we define the
-/// ones supported by Clangd here. The protocol specifies the command arguments
-/// to be "any[]" but to make this safer and more manageable, each command we
-/// handle maps to a certain llvm::Optional of some struct to contain its
-/// arguments. Different commands could reuse the same llvm::Optional as
-/// arguments but a command that needs different arguments would simply add a
-/// new llvm::Optional and not use any other ones. In practice this means only
-/// one argument type will be parsed and set.
 struct ExecuteCommandParams {
   // Command to apply fix-its. Uses WorkspaceEdit as argument.
   const static llvm::StringLiteral CLANGD_APPLY_FIX_COMMAND;
@@ -930,9 +922,9 @@
   /// The command identifier, e.g. CLANGD_APPLY_FIX_COMMAND
   std::string command;
 
-  // Arguments
-  llvm::Optional workspaceEdit;
-  llvm::Optional tweakArgs;
+  // This is `arguments?: []any` in LSP.
+  // All clangd's commands accept a single argument (or none => null).
+  llvm::json::Value argument = nullptr;
 };
 bool fromJSON(const llvm::json::Value &, ExecuteCommandParams &,
   llvm::json::Path);
Index: clang-tools-extra/clangd/Protocol.cpp
===
--- clang-tools-extra/clangd/Protocol.cpp
+++ clang-tools-extra/clangd/Protocol.cpp
@@ -666,16 +666,21 @@
   if (!O || !O.map("command", R.command))
 return false;
 
-  const auto *Args = Params.getAsObject()->getArray("arguments");
-  if (R.command == ExecuteCommandParams::CLANGD_APPLY_FIX_COMMAND) {
-return Args && Args->size() == 1 &&
-   fromJSON(Args->front(), R.workspaceEdit,
-P.field("arguments").index(0));
+  const auto *Args = Params.getAsObject()->get("arguments");
+  if (!Args)
+return true; // Missing args is ok, argument is null.
+  const auto *ArgsArray = Args->getAsArray();
+  if (!ArgsArray) {
+P.field("arguments").report("expected array");
+return false;
+  }
+  if (ArgsArray->size() > 1) {
+P.field("arguments").report("Command should have 0 or 1 argument");
+return false;
+  } else if (ArgsArray->size() == 1) {
+R.argument = ArgsArray->front();
   }
-  if (R.command == ExecuteCommandParams::CLANGD_APPLY_TWEAK)
-return Args && Args->size() == 1 &&
-   fromJSON(Args->front(), R.tweakArgs, P.field("arguments").index(0));
-  return false; // Unrecognized command.
+  return true;
 }
 
 llvm::json::Value toJSON(const SymbolInformation &P) {
@@ -743,10 +748,8 @@
 
 llvm::json::Value toJSON(const Command &C) {
   auto Cmd = llvm::json::Object{{"title", C.title}, {"command", C.command}};
-  if (C.workspaceEdit)
-Cmd["arguments"] = {*C.workspaceEdit};
-  if (C.tweakArgs)
-Cmd["arguments"] = {*C.tweakArgs};
+  if (!C.argument.getAsNull())
+Cmd["arguments"] = llvm::json::Array{C.argument};
   return std::move(Cmd);
 }
 
Index: clang-tools-extra/clangd/ClangdLSPServer.h
===
--- clang-tools-extra/clangd/ClangdLSPServer.h
+++ clang-tools-extra/clangd/ClangdLSPServer.h
@@ -126,7 +126,6 @@
   void onDocumentHighlight(const TextDocumentPositionParams &,
Callback>);
   void onFileEvent(const DidChangeWatchedFilesParams &);
-  void onCommand(const ExecuteCommandParams &, Callback);
   void onWorkspaceSymbol(const WorkspaceSymbolParams &,
  Callback>);
   void onPrepareRename(const TextDocumentPositionParams &,
@@ -160,6 +159,18 @@
   /// hierarchy.
   void onMemoryUsage(Callback);
 
+  llvm::StringMap)>>
+  CommandHandlers;
+  void onCommand(const ExecuteCommandParams &, Callback);
+
+  /// Implement commands.
+  void onCommandApplyEdit(const WorkspaceEdit &, Callback);
+  void onCommandApplyTweak(const TweakArgs &, Callback);
+
+  void applyEdit(WorkspaceEdit WE, llvm::json::Value Success,
+ Callback Reply);
+
   std::vector getFixes(StringRef File, const clangd::Diagnostic &D);
 
   /// Checks if completion request should be ignored. We need this due to the
@@ -263,6 +274,19 @@
   

[PATCH] D94622: [clang-tidy] add concurrency-async-no-new-threads

[Vasily Kulikov via Phabricator via cfe-commits]

segoon added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.cpp:22
+/* C++ std */
+"::std::async", //
+

aaron.ballman wrote:
> segoon wrote:
> > aaron.ballman wrote:
> > > The trailing comment markers don't really add much.
> > it's a hack for clang-format, otherwise it contatenates the lines, creating 
> > unmaintainable mess of strings. "One line - one name" is much more suitable.
> Ah, I didn't know that'd change the behavior of clang-format, that's neat!
> 
> FWIW, we usually don't do a whole lot of markup to avoid clang-format issues 
> (such as the clang-format: on/off markers). Instead, we usually just ignore 
> the LINT warnings in code review and check the code in as-is. This helps 
> reduce clutter in the code base. In this case, the comments aren't adding a 
> ton of clutter so maybe they're fine. But they definitely look odd as a 
> reader of the code, which is a bit distracting.
IMO having an ability to run clang-format for sources is very handy. It makes 
me sad if running clang-format against the source forces me to set some markers 
or reverting a part of clang-format changes in the source parts I have never 
touched. An ability to simply rerun checks/linters is very powerful.



Comment at: 
clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.cpp:33
+
+/* Linux */
+"::fork", //

aaron.ballman wrote:
> segoon wrote:
> > aaron.ballman wrote:
> > > If we're going to add these, we should probably also add ones for Win32 
> > > and Mac OS as well, like `CreateThread`, `CreateRemoteThread`, 
> > > `_beginthread`, `_beginthreadex`, etc.
> > I don't mind, but I'm not an expert in WinAPI or Windows programming. So, 
> > this part should be by someone with expertise of Windows in separate 
> > patches.
> I don't think it needs to be done in separate patches. I can give you the 
> full list of things I care about.
> ```
> CreateThread 
> (https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createthread)
> CreateRemoteThread 
> (https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createremotethread)
> CreateRemoteThreadEx 
> (https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createremotethreadex)
> _beginthread
> _beginthreadex 
> (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-160)
> ```
Oh, great, thank you! Added.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/concurrency-async-no-new-threads.rst:8-10
+functions and types. E.g. if the code uses C++ coroutines, it is expected
+that only new coroutines or coroutine-based primitives are created
+instead of heavy system threads.

aaron.ballman wrote:
> segoon wrote:
> > aaron.ballman wrote:
> > > FWIW, this suggests to me that what you really want is a way for APIs to 
> > > opt into this behavior. There's no reason why you wouldn't have a complex 
> > > system that has both threads and coroutines in it, but it does stand to 
> > > reason that you may want to say "this function, and everything called 
> > > within this function, should not create any system threads" in some 
> > > situations.
> > > 
> > > The note below helps call out the expectations from the check, but it 
> > > requires the developer to restructure the way they write code pretty 
> > > drastically in order to make the checking behavior more reasonable, which 
> > > does not seem ideal.
> > I think it is a complex problem, so it should be separated into smaller 
> > tasks.
> > 
> > Step one - checks with hardcoded functions/types with user-guided enabling 
> > on a per-file basis. A semi-automated check.
> > 
> > Step two - try to solve other parts of the puzzle. Maybe try to add 
> > [clang:coroutine_safe] tag and teach clang static analyzer to deduce 
> > coroutine safety property and use it for enabling/disabling the cheks. 
> > Maybe reuse other (not yet implemented) heuristics from static analyzer (or 
> > other tools) to identify coroutine functions and check only these 
> > functions. I'm not an expert in static analyzer, so other LLVM developers 
> > might find a clever heuristics when to enable/disable these checks or maybe 
> > how to deduce blacklisted/whitelisted functions/types lists (e.g. for 
> > concurrency-async-{fs,blocking}).
> > 
> > Indeed, the current approach has its own limitations. But it may be a first 
> > step in the right direction.
> My fear with the current approach is that I don't think projects usually 
> split their code in the way this check requires, and so the check will not be 
> very useful in practice because it will be too chatty. Have you tried running 
> this check over some large projects that use coroutines to see what the 
> diagnostic results look like?
I haven't conducted a survey, bu

[PATCH] D94622: [clang-tidy] add concurrency-async-no-new-threads

[Vasily Kulikov via Phabricator via cfe-commits]

segoon updated this revision to Diff 323006.
segoon added a comment.

- add WinAPI support


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

https://reviews.llvm.org/D94622

Files:
  clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.cpp
  clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.h
  clang-tools-extra/clang-tidy/concurrency/CMakeLists.txt
  clang-tools-extra/clang-tidy/concurrency/ConcurrencyTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/concurrency-async-no-new-threads.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/concurrency-async-no-new-threads.c
  
clang-tools-extra/test/clang-tidy/checkers/concurrency-async-no-new-threads.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/concurrency-async-no-new-threads.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/concurrency-async-no-new-threads.cpp
@@ -0,0 +1,133 @@
+// RUN: %check_clang_tidy %s concurrency-async-no-new-threads %t -- \
+// RUN: -config='{CheckOptions: [{key: "concurrency-async-no-new-threads.FunctionsExtra", value: "::my::create_thread"},{key: "concurrency-async-no-new-threads.TypesExtra", value: "::my::thread"}]}'
+
+namespace std {
+
+class thread {
+public:
+  void join() {}
+};
+
+class jthread {};
+
+class nothread {};
+
+namespace execution {
+
+class sequenced_policy {};
+
+class parallel_policy {};
+
+class parallel_unsequenced_policy {};
+
+class unsequenced_policy {};
+
+sequenced_policy seq;
+parallel_policy par;
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: type 'parallel_policy' creates new threads [concurrency-async-no-new-threads]
+parallel_unsequenced_policy par_unseq;
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: type 'parallel_unsequenced_policy' creates new threads [concurrency-async-no-new-threads]
+unsequenced_policy unseq;
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: type 'unsequenced_policy' creates new threads [concurrency-async-no-new-threads]
+
+} // namespace execution
+
+void async(int (*)()) {
+}
+
+template 
+void sort(T1 &&, T2, T3, T4);
+
+} // namespace std
+
+int pthread_create(int *thread, const int *attr,
+   void *(*start_routine)(void *), void *arg);
+
+int thrd_create(int *thr, int func, void *arg);
+
+int fork();
+
+int vfork();
+
+int clone(int (*fn)(void *), void *child_stack,
+  int flags, void *arg);
+
+long clone3(int *cl_args, int size);
+
+namespace boost {
+
+class thread {};
+
+class scoped_thread {};
+
+void async(int (*)()) {}
+
+namespace compute {
+class device {};
+
+} // namespace compute
+
+} // namespace boost
+
+void test_threads() {
+  std::thread t;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'thread' creates new threads [concurrency-async-no-new-threads]
+
+  std::jthread j;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'jthread' creates new threads [concurrency-async-no-new-threads]
+
+  std::execution::parallel_policy pp;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'parallel_policy' creates new threads [concurrency-async-no-new-threads]
+
+  std::execution::sequenced_policy sp;
+
+  std::sort(std::execution::par, 0, 0, 0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use of 'par' creates new threads [concurrency-async-no-new-threads]
+
+  boost::thread bt;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'thread' creates new threads [concurrency-async-no-new-threads]
+  boost::scoped_thread bst;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'scoped_thread' creates new threads [concurrency-async-no-new-threads]
+
+  boost::compute::device bcd;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'device' creates new threads [concurrency-async-no-new-threads]
+
+  std::async(fork);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'async' creates new threads [concurrency-async-no-new-threads]
+
+  boost::async(fork);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'async' creates new threads [concurrency-async-no-new-threads]
+
+  pthread_create(0, 0, 0, 0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'pthread_create' creates new threads [concurrency-async-no-new-threads]
+
+  thrd_create(0, 0, 0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'thrd_create' creates new threads [concurrency-async-no-new-threads]
+
+  fork();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'fork' creates new threads [concurrency-async-no-new-threads]
+
+  vfork();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'vfork' creates new threads [concurrency-async-no-new-threads]
+
+  clone(0, 0, 0, 0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'clone' creates new threads [concurrency-async-no-new-threads]
+
+  clone3(0, 0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'clone3' creates new threads [concurrency-async-no-new-threads]
+}

[PATCH] D94622: [clang-tidy] add concurrency-async-no-new-threads

[Vasily Kulikov via Phabricator via cfe-commits]

segoon updated this revision to Diff 323008.
segoon added a comment.

-fix typo


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

https://reviews.llvm.org/D94622

Files:
  clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.cpp
  clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.h
  clang-tools-extra/clang-tidy/concurrency/CMakeLists.txt
  clang-tools-extra/clang-tidy/concurrency/ConcurrencyTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/concurrency-async-no-new-threads.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/concurrency-async-no-new-threads.c
  
clang-tools-extra/test/clang-tidy/checkers/concurrency-async-no-new-threads.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/concurrency-async-no-new-threads.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/concurrency-async-no-new-threads.cpp
@@ -0,0 +1,133 @@
+// RUN: %check_clang_tidy %s concurrency-async-no-new-threads %t -- \
+// RUN: -config='{CheckOptions: [{key: "concurrency-async-no-new-threads.FunctionsExtra", value: "::my::create_thread"},{key: "concurrency-async-no-new-threads.TypesExtra", value: "::my::thread"}]}'
+
+namespace std {
+
+class thread {
+public:
+  void join() {}
+};
+
+class jthread {};
+
+class nothread {};
+
+namespace execution {
+
+class sequenced_policy {};
+
+class parallel_policy {};
+
+class parallel_unsequenced_policy {};
+
+class unsequenced_policy {};
+
+sequenced_policy seq;
+parallel_policy par;
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: type 'parallel_policy' creates new threads [concurrency-async-no-new-threads]
+parallel_unsequenced_policy par_unseq;
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: type 'parallel_unsequenced_policy' creates new threads [concurrency-async-no-new-threads]
+unsequenced_policy unseq;
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: type 'unsequenced_policy' creates new threads [concurrency-async-no-new-threads]
+
+} // namespace execution
+
+void async(int (*)()) {
+}
+
+template 
+void sort(T1 &&, T2, T3, T4);
+
+} // namespace std
+
+int pthread_create(int *thread, const int *attr,
+   void *(*start_routine)(void *), void *arg);
+
+int thrd_create(int *thr, int func, void *arg);
+
+int fork();
+
+int vfork();
+
+int clone(int (*fn)(void *), void *child_stack,
+  int flags, void *arg);
+
+long clone3(int *cl_args, int size);
+
+namespace boost {
+
+class thread {};
+
+class scoped_thread {};
+
+void async(int (*)()) {}
+
+namespace compute {
+class device {};
+
+} // namespace compute
+
+} // namespace boost
+
+void test_threads() {
+  std::thread t;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'thread' creates new threads [concurrency-async-no-new-threads]
+
+  std::jthread j;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'jthread' creates new threads [concurrency-async-no-new-threads]
+
+  std::execution::parallel_policy pp;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'parallel_policy' creates new threads [concurrency-async-no-new-threads]
+
+  std::execution::sequenced_policy sp;
+
+  std::sort(std::execution::par, 0, 0, 0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use of 'par' creates new threads [concurrency-async-no-new-threads]
+
+  boost::thread bt;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'thread' creates new threads [concurrency-async-no-new-threads]
+  boost::scoped_thread bst;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'scoped_thread' creates new threads [concurrency-async-no-new-threads]
+
+  boost::compute::device bcd;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: type 'device' creates new threads [concurrency-async-no-new-threads]
+
+  std::async(fork);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'async' creates new threads [concurrency-async-no-new-threads]
+
+  boost::async(fork);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'async' creates new threads [concurrency-async-no-new-threads]
+
+  pthread_create(0, 0, 0, 0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'pthread_create' creates new threads [concurrency-async-no-new-threads]
+
+  thrd_create(0, 0, 0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'thrd_create' creates new threads [concurrency-async-no-new-threads]
+
+  fork();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'fork' creates new threads [concurrency-async-no-new-threads]
+
+  vfork();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'vfork' creates new threads [concurrency-async-no-new-threads]
+
+  clone(0, 0, 0, 0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'clone' creates new threads [concurrency-async-no-new-threads]
+
+  clone3(0, 0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: function 'clone3' creates new threads [concurrency-async-no-new-threads]
+}
+
+namespac

[PATCH] D96508: [clangd] Retire clang-tidy-checks flag.

[Nathan James via Phabricator via cfe-commits]

njames93 created this revision.
njames93 added a reviewer: sammccall.
Herald added subscribers: usaxena95, kadircet, arphaman.
njames93 requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang.

In clangd-12 the ability to override what clang tidy checks should run was 
moved into config.
For the 13 release its a wise progression to remove the command line option for 
this.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96508

Files:
  clang-tools-extra/clangd/tool/ClangdMain.cpp


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -172,14 +172,6 @@
 init(true),
 };
 
-opt ClangTidyChecks{
-"clang-tidy-checks",
-cat(Features),
-desc("List of clang-tidy checks to run (this will override "
- ".clang-tidy files). Only meaningful when -clang-tidy flag is on"),
-init(""),
-};
-
 opt CodeCompletionParse{
 "completion-parse",
 cat(Features),
@@ -286,6 +278,7 @@
 RetiredFlag RecoveryASTType("recovery-ast-type");
 RetiredFlag AsyncPreamble("async-preamble");
 RetiredFlag CollectMainFileRefs("collect-main-file-refs");
+RetiredFlag ClangTidyChecks("clang-tidy-checks");
 
 opt LimitResults{
 "limit-results",
@@ -833,10 +826,7 @@
 Providers.push_back(provideClangTidyFiles(TFS));
 if (EnableConfig)
   Providers.push_back(provideClangdConfig());
-if (!ClangTidyChecks.empty())
-  Providers.push_back(addTidyChecks(ClangTidyChecks));
-else
-  Providers.push_back(provideDefaultChecks());
+Providers.push_back(provideDefaultChecks());
 Providers.push_back(disableUnusableChecks());
 ClangTidyOptProvider = combine(std::move(Providers));
 Opts.ClangTidyProvider = ClangTidyOptProvider;


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -172,14 +172,6 @@
 init(true),
 };
 
-opt ClangTidyChecks{
-"clang-tidy-checks",
-cat(Features),
-desc("List of clang-tidy checks to run (this will override "
- ".clang-tidy files). Only meaningful when -clang-tidy flag is on"),
-init(""),
-};
-
 opt CodeCompletionParse{
 "completion-parse",
 cat(Features),
@@ -286,6 +278,7 @@
 RetiredFlag RecoveryASTType("recovery-ast-type");
 RetiredFlag AsyncPreamble("async-preamble");
 RetiredFlag CollectMainFileRefs("collect-main-file-refs");
+RetiredFlag ClangTidyChecks("clang-tidy-checks");
 
 opt LimitResults{
 "limit-results",
@@ -833,10 +826,7 @@
 Providers.push_back(provideClangTidyFiles(TFS));
 if (EnableConfig)
   Providers.push_back(provideClangdConfig());
-if (!ClangTidyChecks.empty())
-  Providers.push_back(addTidyChecks(ClangTidyChecks));
-else
-  Providers.push_back(provideDefaultChecks());
+Providers.push_back(provideDefaultChecks());
 Providers.push_back(disableUnusableChecks());
 ClangTidyOptProvider = combine(std::move(Providers));
 Opts.ClangTidyProvider = ClangTidyOptProvider;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D96248: [OpenMP][AMDGPU] Add support for linking libomptarget bitcode

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

Parameter to err_drv_omp_offload_target_missingbcruntime is sensible. 
@tianshilei1992? With this we can set the path for nvptx and amdgcn 
independently.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96248

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

[PATCH] D96512: [PowerPC] Add option for ROP Protection

[Stefan Pintilie via Phabricator via cfe-commits]

stefanp created this revision.
stefanp added reviewers: lei, nemanjai.
Herald added subscribers: dang, shchenz, kbarton, hiraditya.
Herald added a reviewer: jansvoboda11.
stefanp requested review of this revision.
Herald added projects: clang, LLVM.
Herald added a subscriber: cfe-commits.

Added -mrop-protection for Power PC to turn on codegen that provides some
protection from ROP attacks.

The option is off by default and can be turned on for Power 8, Power 9 and
Power 10.

This patch is for the option only. The feature will be implemented by a later
patch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96512

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Basic/Targets/PPC.h
  clang/test/Driver/ppc-mrop-protection-support-check.c
  clang/test/Preprocessor/init-ppc64.c
  llvm/lib/Target/PowerPC/PPC.td
  llvm/lib/Target/PowerPC/PPCSubtarget.cpp
  llvm/lib/Target/PowerPC/PPCSubtarget.h
  llvm/test/CodeGen/PowerPC/future-check-features.ll

Index: llvm/test/CodeGen/PowerPC/future-check-features.ll
===
--- llvm/test/CodeGen/PowerPC/future-check-features.ll
+++ llvm/test/CodeGen/PowerPC/future-check-features.ll
@@ -1,7 +1,7 @@
-; RUN: llc -mattr=pcrelative-memops,prefix-instrs,paired-vector-memops,mma \
+; RUN: llc -mattr=pcrelative-memops,prefix-instrs,paired-vector-memops,mma,rop-protection \
 ; RUN:   -verify-machineinstrs -mtriple=powerpc64le-unknown-unknown \
 ; RUN:   -ppc-asm-full-reg-names %s -o - 2>&1 | FileCheck %s
-; RUN: llc -mattr=pcrelative-memops,prefix-instrs,paired-vector-memops,mma \
+; RUN: llc -mattr=pcrelative-memops,prefix-instrs,paired-vector-memops,mma,rop-protection \
 ; RUN:   -verify-machineinstrs -mtriple=powerpc64-unknown-unknown \
 ; RUN:   -ppc-asm-full-reg-names %s -o - 2>&1 | FileCheck %s
 
Index: llvm/lib/Target/PowerPC/PPCSubtarget.h
===
--- llvm/lib/Target/PowerPC/PPCSubtarget.h
+++ llvm/lib/Target/PowerPC/PPCSubtarget.h
@@ -112,6 +112,7 @@
   bool HasPrefixInstrs;
   bool HasPCRelativeMemops;
   bool HasMMA;
+  bool HasROPProtection;
   bool HasFCPSGN;
   bool HasFSQRT;
   bool HasFRE, HasFRES, HasFRSQRTE, HasFRSQRTES;
@@ -273,6 +274,7 @@
   bool hasPrefixInstrs() const { return HasPrefixInstrs; }
   bool hasPCRelativeMemops() const { return HasPCRelativeMemops; }
   bool hasMMA() const { return HasMMA; }
+  bool hasROPProtection() const { return HasROPProtection; }
   bool pairedVectorMemops() const { return PairedVectorMemops; }
   bool hasMFOCRF() const { return HasMFOCRF; }
   bool hasISEL() const { return HasISEL; }
Index: llvm/lib/Target/PowerPC/PPCSubtarget.cpp
===
--- llvm/lib/Target/PowerPC/PPCSubtarget.cpp
+++ llvm/lib/Target/PowerPC/PPCSubtarget.cpp
@@ -87,6 +87,7 @@
   HasP9Vector = false;
   HasP9Altivec = false;
   HasMMA = false;
+  HasROPProtection = false;
   HasP10Vector = false;
   HasPrefixInstrs = false;
   HasPCRelativeMemops = false;
Index: llvm/lib/Target/PowerPC/PPC.td
===
--- llvm/lib/Target/PowerPC/PPC.td
+++ llvm/lib/Target/PowerPC/PPC.td
@@ -252,6 +252,9 @@
   "Enable MMA instructions",
   [FeatureP8Vector, FeatureP9Altivec,
FeaturePairedVectorMemops]>;
+def FeatureROPProtection :
+  SubtargetFeature<"rop-protection", "HasROPProtection", "false",
+   "Add ROP protection">;
 
 def FeaturePredictableSelectIsExpensive :
   SubtargetFeature<"predictable-select-expensive",
Index: clang/test/Preprocessor/init-ppc64.c
===
--- clang/test/Preprocessor/init-ppc64.c
+++ clang/test/Preprocessor/init-ppc64.c
@@ -566,6 +566,7 @@
 // PPCPWR8-NOT:#define _ARCH_PWR6X 1
 // PPCPWR8:#define _ARCH_PWR7 1
 // PPCPWR8:#define _ARCH_PWR8 1
+// PPCPWR8-NOT:#define __ROP_PROTECTION__ 1
 //
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-none-none -target-cpu power8 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPCPOWER8 %s
 //
@@ -583,6 +584,7 @@
 // PPCPOWER8-NOT:#define _ARCH_PWR6X 1
 // PPCPOWER8:#define _ARCH_PWR7 1
 // PPCPOWER8:#define _ARCH_PWR8 1
+// PPCPOWER8-NOT:#define __ROP_PROTECTION__ 1
 //
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-none-none -target-cpu pwr9 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPCPWR9 %s
 //
@@ -597,6 +599,7 @@
 // PPCPWR9-NOT:#define _ARCH_PWR6X 1
 // PPCPWR9:#define _ARCH_PWR7 1
 // PPCPWR9:#define _ARCH_PWR9 1
+// PPCPWR9-NOT:#define __ROP_PROTECTION__ 1
 //
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-none-none -target-cpu power9 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPCPOWER9 %s
 //
@@ -611,6 +614,7 @

[PATCH] D95396: Improve static_assert/_Static_assert diagnostics

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman marked 2 inline comments as not done.
aaron.ballman added a comment.

Ping.


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

https://reviews.llvm.org/D95396

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

[PATCH] D93223: [analyzer] Create MacroExpansionContext member in AnalysisConsumer

[Balázs Benics via Phabricator via cfe-commits]

steakhal updated this revision to Diff 323024.
steakhal added a comment.

Nothing changed.
Rebased on top of 2407eb08a5748bc2613e95fa449fc1cae6f4ff8f 
.


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

https://reviews.llvm.org/D93223

Files:
  clang/include/clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h
  clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/TextDiagnostics.cpp
  clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Index: clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -20,6 +20,7 @@
 #include "clang/Analysis/CFG.h"
 #include "clang/Analysis/CallGraph.h"
 #include "clang/Analysis/CodeInjector.h"
+#include "clang/Analysis/MacroExpansionContext.h"
 #include "clang/Analysis/PathDiagnostic.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/CrossTU/CrossTranslationUnit.h"
@@ -98,6 +99,8 @@
   /// working with a PCH file.
   SetOfDecls LocalTUDecls;
 
+  MacroExpansionContext MacroExpansions;
+
   // Set of PathDiagnosticConsumers.  Owned by AnalysisManager.
   PathDiagnosticConsumers PathConsumers;
 
@@ -122,7 +125,8 @@
CodeInjector *injector)
   : RecVisitorMode(0), RecVisitorBR(nullptr), Ctx(nullptr),
 PP(CI.getPreprocessor()), OutDir(outdir), Opts(std::move(opts)),
-Plugins(plugins), Injector(injector), CTU(CI) {
+Plugins(plugins), Injector(injector), CTU(CI),
+MacroExpansions(CI.getLangOpts()) {
 DigestAnalyzerOptions();
 if (Opts->PrintStats || Opts->ShouldSerializeStats) {
   AnalyzerTimers = std::make_unique(
@@ -136,6 +140,9 @@
   *AnalyzerTimers);
   llvm::EnableStatistics(/* PrintOnExit= */ false);
 }
+
+if (Opts->ShouldDisplayMacroExpansions)
+  MacroExpansions.registerForPreprocessor(PP);
   }
 
   ~AnalysisConsumer() override {
@@ -150,7 +157,8 @@
   break;
 #define ANALYSIS_DIAGNOSTICS(NAME, CMDFLAG, DESC, CREATEFN)\
   case PD_##NAME:  \
-CREATEFN(Opts->getDiagOpts(), PathConsumers, OutDir, PP, CTU); \
+CREATEFN(Opts->getDiagOpts(), PathConsumers, OutDir, PP, CTU,  \
+ MacroExpansions); \
 break;
 #include "clang/StaticAnalyzer/Core/Analyses.def"
 default:
Index: clang/lib/StaticAnalyzer/Core/TextDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/TextDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/TextDiagnostics.cpp
@@ -10,6 +10,7 @@
 //
 //===--===//
 
+#include "clang/Analysis/MacroExpansionContext.h"
 #include "clang/Analysis/PathDiagnostic.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Version.h"
@@ -138,8 +139,9 @@
 
 void ento::createTextPathDiagnosticConsumer(
 PathDiagnosticConsumerOptions DiagOpts, PathDiagnosticConsumers &C,
-const std::string &Prefix, const clang::Preprocessor &PP,
-const cross_tu::CrossTranslationUnitContext &CTU) {
+const std::string &Prefix, const Preprocessor &PP,
+const cross_tu::CrossTranslationUnitContext &CTU,
+const MacroExpansionContext &MacroExpansions) {
   C.emplace_back(new TextDiagnostics(std::move(DiagOpts), PP.getDiagnostics(),
  PP.getLangOpts(),
  /*ShouldDisplayPathNotes=*/true));
@@ -147,8 +149,9 @@
 
 void ento::createTextMinimalPathDiagnosticConsumer(
 PathDiagnosticConsumerOptions DiagOpts, PathDiagnosticConsumers &C,
-const std::string &Prefix, const clang::Preprocessor &PP,
-const cross_tu::CrossTranslationUnitContext &CTU) {
+const std::string &Prefix, const Preprocessor &PP,
+const cross_tu::CrossTranslationUnitContext &CTU,
+const MacroExpansionContext &MacroExpansions) {
   C.emplace_back(new TextDiagnostics(std::move(DiagOpts), PP.getDiagnostics(),
  PP.getLangOpts(),
  /*ShouldDisplayPathNotes=*/false));
Index: clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
@@ -10,6 +10,7 @@
 //
 //===--===//
 
+#include "clang/Analysis/MacroExpansionContext.h"
 #include "clang/Analysis/PathDiagnostic.h"
 #include "clang/Basic/FileManager.h"
 #include "

[PATCH] D94673: [analyzer][CTU] API for CTU macro expansions

[Balázs Benics via Phabricator via cfe-commits]

steakhal updated this revision to Diff 323025.
steakhal added a comment.

Actually, somehow I messed up something previously. Now, the diff contains the 
latest version.
Sorry for the inconvenience!

Rebased on top of 2407eb08a5748bc2613e95fa449fc1cae6f4ff8f 
.


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

https://reviews.llvm.org/D94673

Files:
  clang/include/clang/AST/ASTImporter.h
  clang/include/clang/CrossTU/CrossTranslationUnit.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/CrossTU/CrossTranslationUnit.cpp
  clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  clang/test/Analysis/plist-macros-with-expansion-ctu.c
  clang/unittests/CrossTU/CrossTranslationUnitTest.cpp

Index: clang/unittests/CrossTU/CrossTranslationUnitTest.cpp
===
--- clang/unittests/CrossTU/CrossTranslationUnitTest.cpp
+++ clang/unittests/CrossTU/CrossTranslationUnitTest.cpp
@@ -91,26 +91,6 @@
   *Success = NewFD && NewFD->hasBody() && !OrigFDHasBody;
 
   if (NewFD) {
-// Check GetImportedFromSourceLocation.
-llvm::Optional> SLocResult =
-CTU.getImportedFromSourceLocation(NewFD->getLocation());
-EXPECT_TRUE(SLocResult);
-if (SLocResult) {
-  SourceLocation OrigSLoc = (*SLocResult).first;
-  ASTUnit *OrigUnit = (*SLocResult).second;
-  // OrigUnit is created internally by CTU (is not the
-  // ASTWithDefinition).
-  TranslationUnitDecl *OrigTU =
-  OrigUnit->getASTContext().getTranslationUnitDecl();
-  const FunctionDecl *FDWithDefinition = FindFInTU(OrigTU);
-  EXPECT_TRUE(FDWithDefinition);
-  if (FDWithDefinition) {
-EXPECT_EQ(FDWithDefinition->getName(), "f");
-EXPECT_TRUE(FDWithDefinition->isThisDeclarationADefinition());
-EXPECT_EQ(OrigSLoc, FDWithDefinition->getLocation());
-  }
-}
-
 // Check parent map.
 const DynTypedNodeList ParentsAfterImport =
 Ctx.getParentMapContext().getParents(*FD);
Index: clang/test/Analysis/plist-macros-with-expansion-ctu.c
===
--- clang/test/Analysis/plist-macros-with-expansion-ctu.c
+++ clang/test/Analysis/plist-macros-with-expansion-ctu.c
@@ -2,13 +2,13 @@
 // RUN: mkdir -p %t/ctudir
 // RUN: %clang_cc1 -emit-pch -o %t/ctudir/plist-macros-ctu.c.ast %S/Inputs/plist-macros-ctu.c
 // RUN: cp %S/Inputs/plist-macros-with-expansion-ctu.c.externalDefMap.txt %t/ctudir/externalDefMap.txt
-
+//
 // RUN: %clang_analyze_cc1 -analyzer-checker=core \
 // RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
 // RUN:   -analyzer-config ctu-dir=%t/ctudir \
 // RUN:   -analyzer-config expand-macros=true \
 // RUN:   -analyzer-output=plist-multi-file -o %t.plist -verify %s
-// XFAIL: *
+//
 // Check the macro expansions from the plist output here, to make the test more
 // understandable.
 //   RUN: FileCheck --input-file=%t.plist %s
@@ -23,25 +23,30 @@
   F3(&X);
   *X = 1; // expected-warning{{Dereference of null pointer}}
 }
-// CHECK: nameM1
-// CHECK-NEXT: expansion*Z = (int *)0
-
+// FIXME: Macro expansion for other TUs should also work.
+// CHECK:  macro_expansions
+// CHECK-NEXT: 
+// CHECK-NEXT: 
 
 void test1() {
   int *X;
   F1(&X);
   *X = 1; // expected-warning{{Dereference of null pointer}}
 }
-// CHECK: nameM
-// CHECK-NEXT: expansion*X = (int *)0
+
+// CHECK:  macro_expansions
+// CHECK-NEXT: 
+// CHECK-NEXT: 
 
 void test2() {
   int *X;
   F2(&X);
   *X = 1; // expected-warning{{Dereference of null pointer}}
 }
-// CHECK: nameM
-// CHECK-NEXT: expansion*Y = (int *)0
+
+// CHECK:  macro_expansions
+// CHECK-NEXT: 
+// CHECK-NEXT: 
 
 #define M F1(&X)
 
@@ -50,10 +55,20 @@
   M;
   *X = 1; // expected-warning{{Dereference of null pointer}}
 }
-// CHECK: nameM
-// CHECK-NEXT: expansionF1(&X)
-// CHECK: nameM
-// CHECK-NEXT: expansion*X = (int *)0
+// Macro expansions for the main TU still works, even in CTU mode.
+// CHECK:  macro_expansions
+// CHECK-NEXT: 
+// CHECK-NEXT:  
+// CHECK-NEXT:   location
+// CHECK-NEXT:   
+// CHECK-NEXT:line55
+// CHECK-NEXT:col3
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:   nameM
+// CHECK-NEXT:   expansionF1 (&X )
+// CHECK-NEXT:  
+// CHECK-NEXT: 
 
 #undef M
 #define M F2(&X)
@@ -64,10 +79,19 @@
   *X = 1; // expected-warning{{Dereference of null pointer}}
 }
 
-// CHECK: nameM
-// CHECK-NEXT: expansionF2(&X)
-// CHECK: nameM
-// CHECK-NEXT: expansion*Y = (int *)0
+// CHECK:  macro_expansions
+// CHECK-NEXT: 
+// CHECK-NEXT:  
+// CHECK-NEXT:   location
+// CHECK-NEXT:   
+// CHECK-NEXT:line78
+// CHECK-NEXT:col3
+// CHECK-NEXT:file0
+// CHECK-NEXT:   
+// CHECK-NEXT:   nameM
+// CHECK-NEXT:   expansionF2 (&X )
+// CHECK-NEXT:  
+// CHECK-NEXT: 
 
 void test_h() {
   int

[PATCH] D92808: [ObjC][ARC] Use operand bundle 'clang.arc.rv' instead of explicitly emitting retainRV or claimRV calls in the IR

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

Another thing I noticed that there's verifier support missing. I think we 
should at least check that only a single `clang.arc.rv` bundle is specified 
(https://github.com/llvm/llvm-project/blob/main/llvm/lib/IR/Verifier.cpp#L3191).
 We should probably also enforce that the bundle is only provided for functions 
with an `i8*` return type. That can also be done after the main patch lands.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92808

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

[PATCH] D96515: [OpenCL] Add builtin declarations by default.

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia created this revision.
Anastasia added reviewers: svenvh, arsenm.
Herald added subscribers: dang, ebevhan, yaxunl.
Herald added a reviewer: jansvoboda11.
Anastasia requested review of this revision.
Herald added a subscriber: wdng.

See original RFC: 
https://lists.llvm.org/pipermail/cfe-dev/2021-February/067610.html

This patch enabled the Tablegen based declarations by default along with 
`opencl-c-base.h` containing complete list of OpenCL types. It also adds a new 
flag `-cl-no-stdinc` that disables extra header includes and declarations.

The next step would be to either add missing declarations into Tablegen header 
or opencl-c-base.h.


https://reviews.llvm.org/D96515

Files:
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/Types.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/Types.cpp
  clang/test/Driver/default-includes.cl
  clang/unittests/AST/MatchVerifier.h

Index: clang/unittests/AST/MatchVerifier.h
===
--- clang/unittests/AST/MatchVerifier.h
+++ clang/unittests/AST/MatchVerifier.h
@@ -117,6 +117,7 @@
 FileName = "input.cc";
 break;
   case Lang_OpenCL:
+Args.push_back("-cl-no-stdinc");
 FileName = "input.cl";
 break;
   case Lang_OBJCXX:
Index: clang/test/Driver/default-includes.cl
===
--- /dev/null
+++ clang/test/Driver/default-includes.cl
@@ -0,0 +1,13 @@
+// RUN: %clang %s -Xclang -verify -fsyntax-only
+// RUN: %clang %s -cl-no-stdinc -Xclang -verify -DNOINC -fsyntax-only
+
+#ifndef NOINC
+//expected-no-diagnostics
+#endif
+
+void test() {
+int i = get_global_id(0);
+#ifdef NOINC
+//expected-error@-2{{implicit declaration of function 'get_global_id' is invalid in OpenCL}}
+#endif
+}
Index: clang/lib/Driver/Types.cpp
===
--- clang/lib/Driver/Types.cpp
+++ clang/lib/Driver/Types.cpp
@@ -160,6 +160,8 @@
   }
 }
 
+bool types::isOpenCL(ID Id) { return Id == TY_CL; }
+
 bool types::isCXX(ID Id) {
   switch (Id) {
   default:
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3158,7 +3158,8 @@
   }
 }
 
-static void RenderOpenCLOptions(const ArgList &Args, ArgStringList &CmdArgs) {
+static void RenderOpenCLOptions(const ArgList &Args, ArgStringList &CmdArgs,
+types::ID InputType) {
   // cl-denorms-are-zero is not forwarded. It is translated into a generic flag
   // for denormal flushing handling based on the target.
   const unsigned ForwardedArguments[] = {
@@ -3183,6 +3184,13 @@
   for (const auto &Arg : ForwardedArguments)
 if (const auto *A = Args.getLastArg(Arg))
   CmdArgs.push_back(Args.MakeArgString(A->getOption().getPrefixedName()));
+
+  // Only add the default headers if we are compiling OpenCL sources.
+  if ((types::isOpenCL(InputType) || Args.hasArg(options::OPT_cl_std_EQ)) &&
+  !Args.hasArg(options::OPT_cl_no_stdinc)) {
+CmdArgs.push_back("-finclude-default-header");
+CmdArgs.push_back("-fdeclare-opencl-builtins");
+  }
 }
 
 static void RenderARCMigrateToolOptions(const Driver &D, const ArgList &Args,
@@ -5680,7 +5688,7 @@
   }
 
   // Forward -cl options to -cc1
-  RenderOpenCLOptions(Args, CmdArgs);
+  RenderOpenCLOptions(Args, CmdArgs, InputType);
 
   if (IsHIP) {
 if (Args.hasFlag(options::OPT_fhip_new_launch_api,
Index: clang/include/clang/Driver/Types.h
===
--- clang/include/clang/Driver/Types.h
+++ clang/include/clang/Driver/Types.h
@@ -81,6 +81,9 @@
   /// isObjC - Is this an "ObjC" input (Obj-C and Obj-C++ sources and headers).
   bool isObjC(ID Id);
 
+  /// isOpenCL - Is this an "OpenCL" input.
+  bool isOpenCL(ID Id);
+
   /// isFortran - Is this a Fortran input.
   bool isFortran(ID Id);
 
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -818,6 +818,8 @@
 def cl_uniform_work_group_size : Flag<["-"], "cl-uniform-work-group-size">, Group, Flags<[CC1Option]>,
   HelpText<"OpenCL only. Defines that the global work-size be a multiple of the work-group size specified to clEnqueueNDRangeKernel">,
   MarshallingInfoFlag>;
+def cl_no_stdinc : Flag<["-"], "cl-no-stdinc">, Group,
+  HelpText<"OpenCL only. Disables all standard includes containing non-native to compiler types and functions from OpenCL C.">;
 def client__name : JoinedOrSeparate<["-"], "client_name">;
 def combine : Flag<["-", "--"], "combine">, Flags<[NoXarchOption, Unsupported]>;
 def compatibility__version : JoinedOrSeparate<["-"], "compatibility_version">;
___
cfe-commits mailing list
cfe-commits@li

[PATCH] D96483: [flang][driver] Add options for unparsing

[Tim Keith via Phabricator via cfe-commits]

tskeith added inline comments.



Comment at: flang/tools/f18/f18.cpp:541
   driver.debugNoSemantics = true;
-} else if (arg == "-funparse") {
+} else if (arg == "-funparse" || arg == "-fdebug_unparse") {
   driver.dumpUnparse = true;

This should be "-fdebug-unparse" (with a hyphen). That may be why all those 
tests are failing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96483

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

[PATCH] D78979: OpenCL: Include builtin header by default

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

The new review: https://reviews.llvm.org/D96515


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

https://reviews.llvm.org/D78979

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

[PATCH] D96456: [ThinLTO, NewPM] Add Config::OptPassBuilderHook

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added inline comments.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:1066
  PassBuilder::OptimizationLevel Level) 
{
+if (CodeGenOpts.OptimizationLevel == 0) {
+  if (!CodeGenOpts.ThinLTOIndexFile.empty())

Some comments around the cases being checked in this if-then-else would be 
helpful.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:1328
+CodeGenOpts.ThinLTOIndexFile.empty()) {
+  // This is testing distributed ThinLTO PostLink. O0 called optimized in
+  // PreLink.

I don't understand what you mean by "O0 called optimized"?
Also maybe make it clear that the first sentence goes with the second check?

Also, it isn't clear to me how this is preventing the sanitizers from being 
added in the ThinLTO pre-link compiles for optimized compiles, as shown in your 
tests. Unlike regular LTO pre-link optimized builds, which are still getting 
the sanitizers.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:1541
+  Triple TargetTriple(M->getTargetTriple());
+  Conf.OptimizerLastPassBuilderHook = [&](PassBuilder &PB) {
+addSanitizers(TargetTriple, CGOpts, LOpts, PB);

This will add sanitizers for the ThinLTO post-link compiles in a distributed 
build environment. Does something need to set these up for ThinLTO post-link 
compiles in the in-process ThinLTO case? In that case thinBackend() is invoked 
via LTO.cpp through the linker.



Comment at: llvm/include/llvm/LTO/Config.h:51
   std::vector PassPlugins;
-  /// For adding passes that run right before codegen.
+  /// For adding passes that run by optimizer.
+  std::function OptimizerLastPassBuilderHook;

This one should say NewPM only.



Comment at: llvm/include/llvm/LTO/Config.h:53
+  std::function OptimizerLastPassBuilderHook;
+  /// For adding passes that run right before codegen (NewPM only).
   std::function PreCodeGenPassesHook;

This one should say legacy PM only



Comment at: llvm/include/llvm/LTO/Config.h:54
+  /// For adding passes that run by opt.
+  std::function OptPassBuilderHook;
   Optional RelocModel = Reloc::PIC_;

vitalybuka wrote:
> aeubanks wrote:
> > vitalybuka wrote:
> > > tejohnson wrote:
> > > > Is this essentially the new PM equivalent to PreCodeGenPassesHook above 
> > > > (since this new hook runs at the end of opt)?
> > > > Also, might be good to name this like OptimizerLastPassBuilderHook or 
> > > > something like that to indicate its position within the opt pipeline.
> > > Kind of. PreCodeGenPassesHook is codegen and it's Legacy PM only.
> > I think the idea is that this callback adds PassBuilder callbacks in 
> > various parts of the the pipeline. Perhaps just `PassBuilderHook`? It's 
> > weird that we only allow one, but I guess we can make it a vector in the 
> > future if necessary.
> I guess the point of OptimizerLastPassBuilderHook name is to show that this 
> is not any PassBuilder, but the one used in ::opt()
My point was just that they are effectively at the same place (the end of opt 
is pretty much the beginning of codegen), so I was wondering if it was worth 
making the legacy and new PM hooks be at the same place. But it probably 
doesn't matter much.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96456

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

[PATCH] D95536: [clang][sema] Note decl location on missing member

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D95536#2553325 , @tbaeder wrote:

> In D95536#2552258 , @aaron.ballman 
> wrote:
>
>> In D95536#2551332 , @tbaeder wrote:
>>
>>> Any update on this?
>>
>> Thank you for the patch! Do you have some motivating examples of when this 
>> would really add clarity to the diagnostic? I'm not opposed to the patch per 
>> se, but I'm a bit wary about adding an additional note because that makes 
>> the diagnostic output seem that much longer, which makes the salient 
>> diagnostics a bit harder to find (colorization in the terminal helps with 
>> this, though).
>
> I run into this a lot when looking into a larger, new code base. When adding 
> new code, I often look at surrounding code and infer how e.g. an enum member 
> is called. Take https://godbolt.org/z/Tcoxf5 for example, I could've seen 
> code using `OsType::Unix` and inferred that the OsType for Windows will be 
> called `OsType::Windows`, but it's `Win32`. The next step for me as a human 
> is of course to grep the source code for the declaration of `OsType` and 
> check the members. (On the other hand, a "Foo is not a member of enum 
> FooEnum, existing members are: Bar1, Bar2, Bar3, ..." diagnostic would 
> probably be more useful. But that has its own drawbacks).

Hmm... I feel like the diagnostic should already be sufficient to locate the 
originating location of the class or namespace and the note is adding a bit 
more (almost, but not quite) noise, but at the same time, I don't feel so 
strongly that I'd block the patch. I'd like to hear from other reviewers though.

As for some interesting test cases -- I don't think we should issue the note 
when the diagnostic already appears within the class declaration itself. e.g.,

  struct S {
void func();
  
void other(S s) {
  s.foo(); // error, but no need to point to where S is declared
}
  };

Another similar case but involving an anonymous class:

  struct S {
struct {
  void func();
} t;
  
void foo() {
  t.blech(); // Should we do anything about this?
}
  };

A pathological case for C code, which shows another case where I think the note 
is more noise than anything (not that I expect anyone to ever write this code, 
so not worth special handling for unless it's fallout from other special 
handling code that's more useful):

  int func(struct S { int a; } s) {
return s.b;
  }

Anonymous namespaces:

  namespace foo {
  namespace {
void func();
  }
  }
  
  void bar() {
foo::blarg(); // Should point to 'foo'?
  }


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

https://reviews.llvm.org/D95536

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

[clang-tools-extra] 7e3b9ab - [Timer] On macOS count number of executed instructions

[Raphael Isemann via cfe-commits]

Author: Alex Hoppen
Date: 2021-02-11T17:26:37+01:00
New Revision: 7e3b9aba609f7f6c944baa319f0a61041ccdc707

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

LOG: [Timer] On macOS count number of executed instructions

In addition to wall time etc. this should allow us to get less noisy
values for time measurements.

Reviewed By: JDevlieghere

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

Added: 


Modified: 

clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-store-check-profile-one-tu.cpp
llvm/CMakeLists.txt
llvm/include/llvm/Config/config.h.cmake
llvm/include/llvm/Support/Timer.h
llvm/lib/Support/Timer.cpp

Removed: 




diff  --git 
a/clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-store-check-profile-one-tu.cpp
 
b/clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-store-check-profile-one-tu.cpp
index 832723ba4ab5..f0939f71edc0 100644
--- 
a/clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-store-check-profile-one-tu.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-store-check-profile-one-tu.cpp
@@ -17,8 +17,9 @@
 // CHECK-FILE-NEXT:"profile": {
 // CHECK-FILE-NEXT:"time.clang-tidy.readability-function-size.wall": 
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
 // CHECK-FILE-NEXT:"time.clang-tidy.readability-function-size.user": 
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
-// CHECK-FILE-NEXT:"time.clang-tidy.readability-function-size.sys": 
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}}
-// CHECK-FILE-NEXT: }
+// CHECK-FILE-NEXT:"time.clang-tidy.readability-function-size.sys": 
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}}{{,?}}
+// If available on the platform, we also have a 
"time.clang-tidy.readability-function-size.instr" entry
+// CHECK-FILE: }
 // CHECK-FILE-NEXT: }
 
 // CHECK-FILE-NOT: {
@@ -27,7 +28,7 @@
 // CHECK-FILE-NOT: "profile": {
 // CHECK-FILE-NOT: "time.clang-tidy.readability-function-size.wall": 
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
 // CHECK-FILE-NOT: "time.clang-tidy.readability-function-size.user": 
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}},
-// CHECK-FILE-NOT: "time.clang-tidy.readability-function-size.sys": 
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}}
+// CHECK-FILE-NOT: "time.clang-tidy.readability-function-size.sys": 
{{.*}}{{[0-9]}}.{{[0-9]+}}e{{[-+]}}{{[0-9]}}{{[0-9]}}{{,?}}
 // CHECK-FILE-NOT: }
 // CHECK-FILE-NOT: }
 

diff  --git a/llvm/CMakeLists.txt b/llvm/CMakeLists.txt
index f5298de9f7ca..5d705b17f6f1 100644
--- a/llvm/CMakeLists.txt
+++ b/llvm/CMakeLists.txt
@@ -649,6 +649,12 @@ if (LLVM_BUILD_STATIC)
   endforeach()
 endif()
 
+include(CheckSymbolExists)
+check_symbol_exists(proc_pid_rusage "libproc.h" HAVE_PROC_PID_RUSAGE)
+if(HAVE_PROC_PID_RUSAGE)
+  list(APPEND CMAKE_REQUIRED_LIBRARIES proc)
+endif()
+
 # Use libtool instead of ar if you are both on an Apple host, and targeting 
Apple.
 if(CMAKE_HOST_APPLE AND APPLE)
   include(UseLibtool)

diff  --git a/llvm/include/llvm/Config/config.h.cmake 
b/llvm/include/llvm/Config/config.h.cmake
index 0783fbcfe4d4..10d16d3f1f8e 100644
--- a/llvm/include/llvm/Config/config.h.cmake
+++ b/llvm/include/llvm/Config/config.h.cmake
@@ -353,4 +353,6 @@
 /* Whether Timers signpost passes in Xcode Instruments */
 #cmakedefine01 LLVM_SUPPORT_XCODE_SIGNPOSTS
 
+#cmakedefine HAVE_PROC_PID_RUSAGE 1
+
 #endif

diff  --git a/llvm/include/llvm/Support/Timer.h 
b/llvm/include/llvm/Support/Timer.h
index 045ac448bdb4..c5874ed35698 100644
--- a/llvm/include/llvm/Support/Timer.h
+++ b/llvm/include/llvm/Support/Timer.h
@@ -24,12 +24,15 @@ class TimerGroup;
 class raw_ostream;
 
 class TimeRecord {
-  double WallTime;   ///< Wall clock time elapsed in seconds.
-  double UserTime;   ///< User time elapsed.
-  double SystemTime; ///< System time elapsed.
-  ssize_t MemUsed;   ///< Memory allocated (in bytes).
+  double WallTime;   ///< Wall clock time elapsed in seconds.
+  double UserTime;   ///< User time elapsed.
+  double SystemTime; ///< System time elapsed.
+  ssize_t MemUsed;   ///< Memory allocated (in bytes).
+  uint64_t InstructionsExecuted; ///< Number of instructions executed
 public:
-  TimeRecord() : WallTime(0), UserTime(0), SystemTime(0), MemUsed(0) {}
+  TimeRecord()
+  : WallTime(0), UserTime(0), SystemTime(0), MemUsed(0),
+InstructionsExecuted(0) {}
 
   /// Get the current time and memory usage.  If Start is true we get the 
memory
   /// usage before the time, otherwise we get time before memory usage.  This
@@ -42,6 +45,7 @@ class TimeRecord {
   double getSystemTime() const { return SystemTime; }
   double getWallTime() const { r

[PATCH] D96049: [Timer] On macOS count number of executed instructions

[Raphael Isemann 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 rG7e3b9aba609f: [Timer] On macOS count number of executed 
instructions (authored by ahoppen, committed by teemperor).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96049

Files:
  
clang-tools-extra/test/clang-tidy/infrastructure/clang-tidy-store-check-profile-one-tu.cpp
  llvm/CMakeLists.txt
  llvm/include/llvm/Config/config.h.cmake
  llvm/include/llvm/Support/Timer.h
  llvm/lib/Support/Timer.cpp

Index: llvm/lib/Support/Timer.cpp
===
--- llvm/lib/Support/Timer.cpp
+++ llvm/lib/Support/Timer.cpp
@@ -13,6 +13,7 @@
 #include "llvm/Support/Timer.h"
 #include "llvm/ADT/Statistic.h"
 #include "llvm/ADT/StringMap.h"
+#include "llvm/Config/config.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Format.h"
@@ -24,6 +25,14 @@
 #include "llvm/Support/raw_ostream.h"
 #include 
 
+#if HAVE_UNISTD_H
+#include 
+#endif
+
+#ifdef HAVE_PROC_PID_RUSAGE
+#include 
+#endif
+
 using namespace llvm;
 
 // This ugly hack is brought to you courtesy of constructor/destructor ordering
@@ -120,6 +129,17 @@
   return sys::Process::GetMallocUsage();
 }
 
+static uint64_t getCurInstructionsExecuted() {
+#if defined(HAVE_UNISTD_H) && defined(HAVE_PROC_PID_RUSAGE) && \
+defined(RUSAGE_INFO_V4)
+  struct rusage_info_v4 ru;
+  if (proc_pid_rusage(getpid(), RUSAGE_INFO_V4, (rusage_info_t *)&ru) == 0) {
+return ru.ri_instructions;
+  }
+#endif
+  return 0;
+}
+
 TimeRecord TimeRecord::getCurrentTime(bool Start) {
   using Seconds = std::chrono::duration>;
   TimeRecord Result;
@@ -128,9 +148,11 @@
 
   if (Start) {
 Result.MemUsed = getMemUsage();
+Result.InstructionsExecuted = getCurInstructionsExecuted();
 sys::Process::GetTimeUsage(now, user, sys);
   } else {
 sys::Process::GetTimeUsage(now, user, sys);
+Result.InstructionsExecuted = getCurInstructionsExecuted();
 Result.MemUsed = getMemUsage();
   }
 
@@ -180,6 +202,8 @@
 
   if (Total.getMemUsed())
 OS << format("%9" PRId64 "  ", (int64_t)getMemUsed());
+  if (Total.getInstructionsExecuted())
+OS << format("%9" PRId64 "  ", (int64_t)getInstructionsExecuted());
 }
 
 
@@ -339,6 +363,8 @@
   OS << "   ---Wall Time---";
   if (Total.getMemUsed())
 OS << "  ---Mem---";
+  if (Total.getInstructionsExecuted())
+OS << "  ---Instr---";
   OS << "  --- Name ---\n";
 
   // Loop through all of the timing data, printing it out.
@@ -433,6 +459,10 @@
   OS << delim;
   printJSONValue(OS, R, ".mem", T.getMemUsed());
 }
+if (T.getInstructionsExecuted()) {
+  OS << delim;
+  printJSONValue(OS, R, ".instr", T.getInstructionsExecuted());
+}
   }
   TimersToPrint.clear();
   return delim;
Index: llvm/include/llvm/Support/Timer.h
===
--- llvm/include/llvm/Support/Timer.h
+++ llvm/include/llvm/Support/Timer.h
@@ -24,12 +24,15 @@
 class raw_ostream;
 
 class TimeRecord {
-  double WallTime;   ///< Wall clock time elapsed in seconds.
-  double UserTime;   ///< User time elapsed.
-  double SystemTime; ///< System time elapsed.
-  ssize_t MemUsed;   ///< Memory allocated (in bytes).
+  double WallTime;   ///< Wall clock time elapsed in seconds.
+  double UserTime;   ///< User time elapsed.
+  double SystemTime; ///< System time elapsed.
+  ssize_t MemUsed;   ///< Memory allocated (in bytes).
+  uint64_t InstructionsExecuted; ///< Number of instructions executed
 public:
-  TimeRecord() : WallTime(0), UserTime(0), SystemTime(0), MemUsed(0) {}
+  TimeRecord()
+  : WallTime(0), UserTime(0), SystemTime(0), MemUsed(0),
+InstructionsExecuted(0) {}
 
   /// Get the current time and memory usage.  If Start is true we get the memory
   /// usage before the time, otherwise we get time before memory usage.  This
@@ -42,6 +45,7 @@
   double getSystemTime() const { return SystemTime; }
   double getWallTime() const { return WallTime; }
   ssize_t getMemUsed() const { return MemUsed; }
+  uint64_t getInstructionsExecuted() const { return InstructionsExecuted; }
 
   bool operator<(const TimeRecord &T) const {
 // Sort by Wall Time elapsed, as it is the only thing really accurate
@@ -49,16 +53,18 @@
   }
 
   void operator+=(const TimeRecord &RHS) {
-WallTime   += RHS.WallTime;
-UserTime   += RHS.UserTime;
+WallTime += RHS.WallTime;
+UserTime += RHS.UserTime;
 SystemTime += RHS.SystemTime;
-MemUsed+= RHS.MemUsed;
+MemUsed += RHS.MemUsed;
+InstructionsExecuted += RHS.InstructionsExecuted;
   }
   void operator-=(const TimeRecord &RHS) {
-WallTime   -= RHS.WallTime;
-UserTime   -= RHS.UserTime;
+WallT

[PATCH] D96049: [Timer] On macOS count number of executed instructions

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: llvm/include/llvm/Config/config.h.cmake:356
 
+#cmakedefine HAVE_PROC_PID_RUSAGE 1
+

Any reason to use `#cmakedefine` instead of `cmakedefine01` here? This type of 
check usually uses `#cmakedefine01` in this file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96049

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

[PATCH] D96049: [Timer] On macOS count number of executed instructions

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: llvm/CMakeLists.txt:656
+  list(APPEND CMAKE_REQUIRED_LIBRARIES proc)
+endif()
+

also, any reason to not do this in `llvm/cmake/config-ix.cmake` where all the 
other checks like this are?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96049

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

[PATCH] D96051: [OpenCL] Support enum and typedef args in TableGen BIFs

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh updated this revision to Diff 323040.
svenvh added a comment.

Add test for new diagnostic.


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

https://reviews.llvm.org/D96051

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/OpenCLBuiltins.td
  clang/lib/Sema/SemaLookup.cpp
  clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
  clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp

Index: clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
===
--- clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
+++ clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
@@ -48,7 +48,7 @@
 //Find out whether a string matches an existing OpenCL builtin function
 //name and return an index into BuiltinTable and the number of overloads.
 //
-//  * void OCL2Qual(ASTContext&, OpenCLTypeStruct, std::vector&)
+//  * void OCL2Qual(Sema&, OpenCLTypeStruct, std::vector&)
 //Convert an OpenCLTypeStruct type to a list of QualType instances.
 //One OpenCLTypeStruct can represent multiple types, primarily when using
 //GenTypes.
@@ -726,6 +726,9 @@
 void BuiltinNameEmitter::EmitQualTypeFinder() {
   OS << R"(
 
+static QualType getOpenCLEnumType(Sema &S, llvm::StringRef Name);
+static QualType getOpenCLTypedefType(Sema &S, llvm::StringRef Name);
+
 // Convert an OpenCLTypeStruct type to a list of QualTypes.
 // Generic types represent multiple types and vector sizes, thus a vector
 // is returned. The conversion is done in two steps:
@@ -734,8 +737,9 @@
 // or a single scalar type for non generic types.
 // Step 2: Qualifiers and other type properties such as vector size are
 // applied.
-static void OCL2Qual(ASTContext &Context, const OpenCLTypeStruct &Ty,
+static void OCL2Qual(Sema &S, const OpenCLTypeStruct &Ty,
  llvm::SmallVectorImpl &QT) {
+  ASTContext &Context = S.Context;
   // Number of scalar types in the GenType.
   unsigned GenTypeNumTypes;
   // Pointer to the list of vector sizes for the GenType.
Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -17,6 +17,17 @@
 #pragma OPENCL EXTENSION cl_khr_fp64 : enable
 #endif
 
+// First, test that Clang gracefully handles missing types.
+#ifdef NO_HEADER
+void test_without_header() {
+  barrier(0);
+  // expected-note@-1 0+{{candidate function not viable}}
+  // expected-error@-2 0+{{argument type 'void' is incomplete}}
+  // expected-error@-3 0+{{no matching function for call to 'barrier'}}
+  // expected-error@* {{typedef type cl_mem_fence_flags not found; include the base header with -finclude-default-header}}
+}
+#endif
+
 // Provide typedefs when invoking clang without -finclude-default-header.
 #ifdef NO_HEADER
 typedef unsigned char uchar;
@@ -34,6 +45,9 @@
 typedef uint uint4 __attribute__((ext_vector_type(4)));
 typedef long long2 __attribute__((ext_vector_type(2)));
 
+typedef uint cl_mem_fence_flags;
+#define CLK_GLOBAL_MEM_FENCE 0x02
+
 // Enable extensions that are enabled in opencl-c-base.h.
 #if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 200)
 #define cl_khr_subgroup_extended_types 1
@@ -53,6 +67,18 @@
   atom_cmpxchg((volatile __global unsigned int *)global_p, ui, ui);
 }
 
+// Only test enum arguments when the base header is included, because we need
+// the enum declarations.
+#if !defined(NO_HEADER) && (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 200)
+kernel void test_enum_args(volatile global atomic_int *global_p, global int *expected) {
+  int desired;
+  atomic_compare_exchange_strong_explicit(global_p, expected, desired,
+  memory_order_acq_rel,
+  memory_order_relaxed,
+  memory_scope_work_group);
+}
+#endif
+
 kernel void basic_conversion() {
   double d;
   float f;
@@ -184,6 +210,8 @@
 kernel void basic_work_item() {
   uint ui;
 
+  barrier(CLK_GLOBAL_MEM_FENCE);
+
   get_enqueued_local_size(ui);
 #if !defined(__OPENCL_CPP_VERSION__) && __OPENCL_C_VERSION__ < CL_VERSION_2_0
 // expected-error@-2{{implicit declaration of function 'get_enqueued_local_size' is invalid in OpenCL}}
Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -677,9 +677,43 @@
 D->dump();
 }
 
+/// Diagnose a missing builtin type.
+static QualType diagOpenCLBuiltinTypeError(Sema &S, llvm::StringRef TypeClass,
+   llvm::StringRef Name) {
+  S.Diag(SourceLocation(), diag::err_opencl_type_not_found)
+  << TypeClass << Name;
+  return S.Context.VoidTy;
+}
+
+/// Lookup an OpenCL enum type.
+static QualType getOpenCLEnumType(Sema 

[PATCH] D96049: [Timer] On macOS count number of executed instructions

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: llvm/include/llvm/Config/config.h.cmake:356
 
+#cmakedefine HAVE_PROC_PID_RUSAGE 1
+

thakis wrote:
> Any reason to use `#cmakedefine` instead of `cmakedefine01` here? This type 
> of check usually uses `#cmakedefine01` in this file.
Please ignore this, `#cmakedefine` is what most other `HAVE_` things use. I 
misremembered this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96049

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

[PATCH] D96285: [clang][Arm] Fix handling of -Wa,-implicit-it=

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers marked 2 inline comments as done.
nickdesaulniers added a comment.

Thanks for the review (here and D96304 )!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96285

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

[PATCH] D94779: [Clang] Ensure vector predication loop metadata is always emitted when pragma is specified.

[Michael Kruse via Phabricator via cfe-commits]

Meinersbur added a comment.

In D94779#2556274 , @dmgreen wrote:

> This makes sense to me. If the user specifies the pragma then we send that 
> through to the vectorizer, whatever it is. As much as `vectorize_width(1) 
> interleave_count(4) vectorize_predicate(enable)` doesn't make a lot of sense, 
> it's still something that should work. And if the user asks for it, that's 
> what should be done.

Unfortunately, it is not that simple. How vectorize metadata is emitted, how it 
is interpreted by the LoopVectorize pass, and when the 
WarnMissedTransformations pass emits a warning is non-trivial and I would not 
mess with it with no reason or if we generally wanted to clean this up. For 
instance, is implicitly enabling the vectorizer when the width is set  the 
front-end's jobs or the LoopVectorizers? The function 
`hasVectorizeTransformation` in LoopUtils.h tries to abstract from that. That 
is, there is no 1-to-1 relationship between loop hint pragmas and loop metadata 
as you seem to assume.

The summary motivates this as "This ensures better feedback for the 
user/programmer." However, the user will not see any difference since the 
LoopVectorize will just ignore it. Worse, the IR contains contradicting 
information. IMHO, it's the font-end's job to resolve semantic inconsistencies 
and potentially warn users about it.

I don't intend to block this patch because it seems to have no consequence, but 
the motivation is insufficient. If the author uses the predicate in an upstream 
pass they should mention it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94779

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

[PATCH] D94779: [Clang] Ensure vector predication loop metadata is always emitted when pragma is specified.

[Michael Kruse via Phabricator via cfe-commits]

Meinersbur added a comment.

To illustrate how complicated interpreting the vectorize pragma has become in 
the mid-end:

  TransformationMode llvm::hasVectorizeTransformation(Loop *L) {
Optional Enable =
getOptionalBoolLoopAttribute(L, "llvm.loop.vectorize.enable");
  
if (Enable == false)
  return TM_SuppressedByUser;
  
Optional VectorizeWidth =
getOptionalElementCountLoopAttribute(L);
Optional InterleaveCount =
getOptionalIntLoopAttribute(L, "llvm.loop.interleave.count");
  
// 'Forcing' vector width and interleave count to one effectively disables
// this transformation.
if (Enable == true && VectorizeWidth && VectorizeWidth->isScalar() &&
InterleaveCount == 1)
  return TM_SuppressedByUser;
  
if (getBooleanLoopAttribute(L, "llvm.loop.isvectorized"))
  return TM_Disable;
  
if (Enable == true)
  return TM_ForcedByUser;
  
if ((VectorizeWidth && VectorizeWidth->isScalar()) && InterleaveCount == 1)
  return TM_Disable;
  
if ((VectorizeWidth && VectorizeWidth->isVector()) || InterleaveCount > 1)
  return TM_Enable;
  
if (hasDisableAllTransformsHint(L))
  return TM_Disable;
  
return TM_Unspecified;
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94779

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

[PATCH] D96519: [Clang][OpenMP] Fixed an issue that `target team` is emitted incorrectly

[Shilei Tian via Phabricator via cfe-commits]

tianshilei1992 created this revision.
tianshilei1992 added reviewers: jdoerfert, JonChesterfield, ABataev, grokos.
Herald added subscribers: guansong, yaxunl.
tianshilei1992 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

This patch is trying to fix the bug 47039 
(https://bugs.llvm.org/show_bug.cgi?id=47039).
The root cause is, in clang, if `NumTeams` is not `nullptr`, it will emit call
to `target teams`, even if the value of `NumTeams` is 0. This is wrong, but at
least the team number is 0, so if the runtime can handle this correct, it should
still be fine. However, in the runtime, we only check the boolean variable
`IsTeamConstruct`, and don't check the team number. The last straw is, in CUDA
plugin, if the team number is 0, and the loop count is also 0, then it will set
the team number to a default value, which is 128 now.

In this patch, instead of emitting `TeamNum` of value 0, we emit `nullptr`
instead, which is spec conformant at least, aside from the discussion on the
weekly meeting that no team can also mean one team with one thread.

Failed tests will be fixed accordingly.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96519

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp


Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -6574,24 +6574,20 @@
 CGOpenMPRuntime::getSingleCompoundChild(CGF.getContext(), Body);
 if (const auto *NestedDir =
 dyn_cast_or_null(ChildStmt)) {
-  if (isOpenMPTeamsDirective(NestedDir->getDirectiveKind())) {
-if (NestedDir->hasClausesOfKind()) {
-  CGOpenMPInnerExprInfo CGInfo(CGF, *CS);
-  CodeGenFunction::CGCapturedStmtRAII CapInfoRAII(CGF, &CGInfo);
-  const Expr *NumTeams =
-  NestedDir->getSingleClause()->getNumTeams();
-  llvm::Value *NumTeamsVal =
-  CGF.EmitScalarExpr(NumTeams,
- /*IgnoreResultAssign*/ true);
-  return Bld.CreateIntCast(NumTeamsVal, CGF.Int32Ty,
-   /*isSigned=*/true);
-}
-return Bld.getInt32(0);
-  }
-  if (isOpenMPParallelDirective(NestedDir->getDirectiveKind()) ||
-  isOpenMPSimdDirective(NestedDir->getDirectiveKind()))
+  if (isOpenMPTeamsDirective(NestedDir->getDirectiveKind()) &&
+  NestedDir->hasClausesOfKind()) {
+CGOpenMPInnerExprInfo CGInfo(CGF, *CS);
+CodeGenFunction::CGCapturedStmtRAII CapInfoRAII(CGF, &CGInfo);
+const Expr *NumTeams =
+NestedDir->getSingleClause()->getNumTeams();
+llvm::Value *NumTeamsVal =
+CGF.EmitScalarExpr(NumTeams,
+   /*IgnoreResultAssign*/ true);
+return Bld.CreateIntCast(NumTeamsVal, CGF.Int32Ty,
+ /*isSigned=*/true);
+  } else if (isOpenMPParallelDirective(NestedDir->getDirectiveKind()) ||
+ isOpenMPSimdDirective(NestedDir->getDirectiveKind()))
 return Bld.getInt32(1);
-  return Bld.getInt32(0);
 }
 return nullptr;
   }


Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -6574,24 +6574,20 @@
 CGOpenMPRuntime::getSingleCompoundChild(CGF.getContext(), Body);
 if (const auto *NestedDir =
 dyn_cast_or_null(ChildStmt)) {
-  if (isOpenMPTeamsDirective(NestedDir->getDirectiveKind())) {
-if (NestedDir->hasClausesOfKind()) {
-  CGOpenMPInnerExprInfo CGInfo(CGF, *CS);
-  CodeGenFunction::CGCapturedStmtRAII CapInfoRAII(CGF, &CGInfo);
-  const Expr *NumTeams =
-  NestedDir->getSingleClause()->getNumTeams();
-  llvm::Value *NumTeamsVal =
-  CGF.EmitScalarExpr(NumTeams,
- /*IgnoreResultAssign*/ true);
-  return Bld.CreateIntCast(NumTeamsVal, CGF.Int32Ty,
-   /*isSigned=*/true);
-}
-return Bld.getInt32(0);
-  }
-  if (isOpenMPParallelDirective(NestedDir->getDirectiveKind()) ||
-  isOpenMPSimdDirective(NestedDir->getDirectiveKind()))
+  if (isOpenMPTeamsDirective(NestedDir->getDirectiveKind()) &&
+  NestedDir->hasClausesOfKind()) {
+CGOpenMPInnerExprInfo CGInfo(CGF, *CS);
+CodeGenFunction::CGCapturedStmtRAII CapInfoRAII(CGF, &CGInfo);
+const Expr *NumTeams =
+NestedDir->getSingleClause()->getNumTeams();
+llvm::Value *NumTeamsVal =
+CGF.EmitScalarExpr(NumTeams,
+   /*IgnoreResultAssign*/ true);
+return Bld.CreateIntCast(NumTeamsVal, CGF.Int32Ty,
+ /*isSign

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

[Louis Dionne via Phabricator via cfe-commits]

ldionne updated this revision to Diff 323047.
ldionne added a comment.

Fix segfault on GCC and a few incorrect checks in the type traits.

I reduced the GCC segfault and it appears to have been fixed on GCC trunk, so
I won't be filing a bug report.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50106

Files:
  libcxx/include/tuple
  
libcxx/test/libcxx/utilities/tuple/tuple.tuple/tuple.assign/const_array.pass.cpp
  
libcxx/test/libcxx/utilities/tuple/tuple.tuple/tuple.assign/rvalue_array.pass.cpp
  
libcxx/test/libcxx/utilities/tuple/tuple.tuple/tuple.assign/tuple_array_template_depth.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/const_pair.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/convert_copy.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/convert_move.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/copy.pass.cpp
  
libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/derived_from_tuple_like.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/laziness.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/move.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/move_pair.pass.cpp
  
libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/tuple_array_template_depth.pass.cpp
  libcxx/test/support/propagate_value_category.hpp

Index: libcxx/test/support/propagate_value_category.hpp
===
--- /dev/null
+++ libcxx/test/support/propagate_value_category.hpp
@@ -0,0 +1,153 @@
+//===--===//
+//
+// 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 TEST_SUPPORT_PROPAGATE_VALUE_CATEGORY
+#define TEST_SUPPORT_PROPAGATE_VALUE_CATEGORY
+
+#include "test_macros.h"
+#include 
+
+#if TEST_STD_VER < 11
+#error this header may only be used in C++11
+#endif
+
+using UnderlyingVCType = unsigned;
+enum ValueCategory : UnderlyingVCType {
+  VC_None = 0,
+  VC_LVal = 1 << 0,
+  VC_RVal = 1 << 1,
+  VC_Const = 1 << 2,
+  VC_Volatile = 1 << 3,
+  VC_ConstVolatile = VC_Const | VC_Volatile
+};
+
+inline constexpr ValueCategory operator&(ValueCategory LHS, ValueCategory RHS) {
+  return ValueCategory(LHS & (UnderlyingVCType)RHS);
+}
+
+inline constexpr ValueCategory operator|(ValueCategory LHS, ValueCategory RHS) {
+  return ValueCategory(LHS | (UnderlyingVCType)RHS);
+}
+
+inline constexpr ValueCategory operator^(ValueCategory LHS, ValueCategory RHS) {
+  return ValueCategory(LHS ^ (UnderlyingVCType)RHS);
+}
+
+inline constexpr bool isValidValueCategory(ValueCategory VC) {
+  return (VC & (VC_LVal | VC_RVal)) != (VC_LVal | VC_RVal);
+}
+
+inline constexpr bool hasValueCategory(ValueCategory Arg, ValueCategory Key) {
+  return Arg == Key || ((Arg & Key) == Key);
+}
+
+template 
+using UnCVRef =
+typename std::remove_cv::type>::type;
+
+template 
+constexpr ValueCategory getReferenceQuals() {
+  return std::is_lvalue_reference::value
+ ? VC_LVal
+ : (std::is_rvalue_reference::value ? VC_RVal : VC_None);
+}
+static_assert(getReferenceQuals() == VC_None, "");
+static_assert(getReferenceQuals() == VC_LVal, "");
+static_assert(getReferenceQuals() == VC_RVal, "");
+
+template 
+constexpr ValueCategory getCVQuals() {
+  using Vp = typename std::remove_reference::type;
+  return std::is_const::value && std::is_volatile::value
+ ? VC_ConstVolatile
+ : (std::is_const::value
+? VC_Const
+: (std::is_volatile::value ? VC_Volatile : VC_None));
+}
+static_assert(getCVQuals() == VC_None, "");
+static_assert(getCVQuals() == VC_Const, "");
+static_assert(getCVQuals() == VC_Volatile, "");
+static_assert(getCVQuals() == VC_ConstVolatile, "");
+static_assert(getCVQuals() == VC_None, "");
+static_assert(getCVQuals() == VC_Const, "");
+
+template 
+inline constexpr ValueCategory getValueCategory() {
+  return getReferenceQuals() | getCVQuals();
+}
+static_assert(getValueCategory() == VC_None, "");
+static_assert(getValueCategory() == (VC_LVal | VC_Const), "");
+static_assert(getValueCategory() ==
+  (VC_RVal | VC_ConstVolatile),
+  "");
+
+template 
+struct ApplyValueCategory {
+private:
+  static_assert(isValidValueCategory(VC), "");
+
+  template 
+  using CondT = typename std::conditional::type;
+
+public:
+  template >
+  using ApplyCVQuals = CondT<
+  hasValueCategory(VC, VC_ConstVolatile), typename std::add_cv::type,
+  CondT::type,
+CondT::type, Tp>>>;
+
+  template ::type>
+  using ApplyReferenceQuals =
+  CondT::ty

[PATCH] D96281: [clang-tidy] Add options to flag individual core increments and to ignore macros to readability-function-cognitive-complexity check.

[Jens Massberg via Phabricator via cfe-commits]

massberg updated this revision to Diff 323052.
massberg marked 2 inline comments as done.
massberg added a comment.

Add test cases showing that when IgnoreMacros is set to 'true', also macro 
arguments are ignored.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96281

Files:
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp
  clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/readability-function-cognitive-complexity.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity-flags.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity-flags.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability-function-cognitive-complexity-flags.cpp
@@ -0,0 +1,94 @@
+// RUN: %check_clang_tidy %s readability-function-cognitive-complexity %t -- \
+// RUN:   -config='{CheckOptions: \
+// RUN: [{key: readability-function-cognitive-complexity.Threshold, \
+// RUN:   value: 0}, \
+// RUN:  {key: readability-function-cognitive-complexity.FlagBasicIncrements, \
+// RUN:   value: "false"} ]}'
+// RUN: %check_clang_tidy -check-suffix=THRESHOLD5 %s readability-function-cognitive-complexity %t -- \
+// RUN:   -config='{CheckOptions: \
+// RUN: [{key: readability-function-cognitive-complexity.Threshold, \
+// RUN:   value: 5}, \
+// RUN:  {key: readability-function-cognitive-complexity.FlagBasicIncrements, \
+// RUN:   value: "false"} ]}'
+// RUN: %check_clang_tidy -check-suffix=IGNORE-MACROS %s readability-function-cognitive-complexity %t -- \
+// RUN:   -config='{CheckOptions: \
+// RUN: [{key: readability-function-cognitive-complexity.Threshold, \
+// RUN:   value: 0}, \
+// RUN:  {key: readability-function-cognitive-complexity.IgnoreMacros, \
+// RUN:   value: "true"}, \
+// RUN:  {key: readability-function-cognitive-complexity.FlagBasicIncrements, \
+// RUN:   value: "false"} ]}'
+
+void func_of_complexity_4() {
+  // CHECK-NOTES: :[[@LINE-1]]:6: warning: function 'func_of_complexity_4' has cognitive complexity of 4 (threshold 0) [readability-function-cognitive-complexity]
+  // CHECK-NOTES-IGNORE-MACROS: :[[@LINE-2]]:6: warning: function 'func_of_complexity_4' has cognitive complexity of 4 (threshold 0) [readability-function-cognitive-complexity]
+  if (1) {
+if (1) {
+}
+  }
+  if (1) {
+  }
+}
+
+#define MacroOfComplexity10 \
+  if (1) {  \
+if (1) {\
+  if (1) {  \
+if (1) {\
+}   \
+  } \
+}   \
+  }
+
+void function_with_macro() {
+  // CHECK-NOTES: :[[@LINE-1]]:6: warning: function 'function_with_macro' has cognitive complexity of 11 (threshold 0) [readability-function-cognitive-complexity]
+  // CHECK-NOTES-THRESHOLD5: :[[@LINE-2]]:6: warning: function 'function_with_macro' has cognitive complexity of 11 (threshold 5) [readability-function-cognitive-complexity]
+  // CHECK-NOTES-IGNORE-MACROS: :[[@LINE-3]]:6: warning: function 'function_with_macro' has cognitive complexity of 1 (threshold 0) [readability-function-cognitive-complexity]
+
+  MacroOfComplexity10
+
+  if (1) {
+  }
+}
+
+#define uglyfunctionmacro(name) \
+  void name() { \
+if (true) { \
+  try { \
+  } catch (...) {   \
+  } \
+}   \
+  }
+
+uglyfunctionmacro(MacroFunction)
+// CHECK-NOTES: :[[@LINE-1]]:19: warning: function 'MacroFunction' has cognitive complexity of 3 (threshold 0) [readability-function-cognitive-complexity]
+
+#define noop
+
+#define SomeMacro(x) \
+  if (1) {   \
+x\
+  }
+
+void func_macro_1() {
+  // CHECK-NOTES: :[[@LINE-1]]:6: warning: function 'func_macro_1' has cognitive complexity of 2 (threshold 0) [readability-function-cognitive-complexity]
+  // CHECK-NOTES-IGNORE-MACROS: :[[@LINE-2]]:6: warning: function 'func_macro_1' has cognitive complexity of 1 (threshold 0) [readability-function-cognitive-complexity]
+
+  if (1) {
+  }
+  SomeMacro(noop;)
+}
+
+void func_macro_2() {
+  // CHECK-NOTES: :[[@LINE-1]]:6: warning: function 'func_macro_2' has cognitive complexity of 4 (threshold 0) [readability-function-cognitive-complexity]
+  // CHECK-NOTES-IGNORE-MACROS: :[[@LINE-2]]:6: warning: function 'func_macro_2' has cognitive complexity of 1 (threshold 0) [readability-function-cognitive-complexity]
+
+  if (1) {
+  }
+  // Note that if the IgnoreMacro option is set to 'true', currently also macro
+  // arguments are

[PATCH] D90157: [analyzer] Rework SValBuilder::evalCast function into maintainable and clear way

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

Hi, guys!
Does anyone can review this item, except @steakhal (thanks him)? Please, look.


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

https://reviews.llvm.org/D90157

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

[PATCH] D96427: Support multi-configuration generators correctly in several config files

[Stella Stamenova via Phabricator via cfe-commits]

stella.stamenova updated this revision to Diff 323053.
stella.stamenova edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96427

Files:
  clang/test/Unit/lit.site.cfg.py.in
  lld/test/CMakeLists.txt
  lld/test/Unit/lit.site.cfg.py.in
  lld/test/lit.site.cfg.py.in
  lldb/test/API/lit.site.cfg.py.in
  llvm/cmake/modules/AddLLVM.cmake
  llvm/test/CMakeLists.txt
  llvm/test/Unit/lit.site.cfg.py.in
  llvm/test/lit.site.cfg.py.in
  mlir/examples/standalone/test/lit.site.cfg.py.in
  mlir/integration_test/lit.site.cfg.py.in
  mlir/test/Unit/lit.site.cfg.py.in
  mlir/test/lit.site.cfg.py.in

Index: mlir/test/lit.site.cfg.py.in
===
--- mlir/test/lit.site.cfg.py.in
+++ mlir/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -51,6 +51,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: mlir/test/Unit/lit.site.cfg.py.in
===
--- mlir/test/Unit/lit.site.cfg.py.in
+++ mlir/test/Unit/lit.site.cfg.py.in
@@ -17,6 +17,7 @@
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
 config.llvm_build_mode = config.llvm_build_mode % lit_config.params
+config.shlibdir = config.shlibdir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
 key, = e.args
Index: mlir/integration_test/lit.site.cfg.py.in
===
--- mlir/integration_test/lit.site.cfg.py.in
+++ mlir/integration_test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -40,6 +40,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: mlir/examples/standalone/test/lit.site.cfg.py.in
===
--- mlir/examples/standalone/test/lit.site.cfg.py.in
+++ mlir/examples/standalone/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -35,6 +35,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: llvm/test/lit.site.cfg.py.in
===
--- llvm/test/lit.site.cfg.py.in
+++ llvm/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = path(r"@LLVM_SOURCE_DIR@")
 config.llvm_obj_root = path(r"@LLVM_BINARY_DIR@")
 config.llvm_tools_dir = path(r"@LLVM_TOOLS_DIR@")
-config.llvm_lib_dir = path(r"@LLVM_LIBRARY_DIR@")
+config.llvm_lib_dir = path(r"@LLVM_LIBS_DIR@")
 config.llvm_shlib_dir = path(r"@SHLIBDIR@")
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -56,6 +56,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: llvm/test/Unit/lit.site.cfg.py.in
===
--- llvm/test/Unit/lit.site.cfg.py.in
+++ llvm/test/Unit/lit.site.cfg.py.in
@@ -14,6 +14,7 @@
 try:
 config.llvm_tools_dir = co

[PATCH] D96483: [flang][driver] Add options for unparsing

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski updated this revision to Diff 323054.
awarzynski added a comment.

Fix typo in f18.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96483

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/FrontendActions.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CMakeLists.txt
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/Frontend/FrontendOptions.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/lib/Parser/CMakeLists.txt
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Parser/continuation-in-if.f
  flang/test/Parser/pp-dir-comments.f90
  flang/test/Semantics/canondo01.f90
  flang/test/Semantics/canondo02.f90
  flang/test/Semantics/canondo03.f90
  flang/test/Semantics/canondo04.f90
  flang/test/Semantics/canondo05.f90
  flang/test/Semantics/critical04.f90
  flang/test/Semantics/defined-ops.f90
  flang/test/Semantics/doconcurrent02.f90
  flang/test/Semantics/doconcurrent03.f90
  flang/test/Semantics/doconcurrent04.f90
  flang/test/Semantics/doconcurrent07.f90
  flang/test/Semantics/label02.f90
  flang/test/Semantics/label03.f90
  flang/test/Semantics/label04.f90
  flang/test/Semantics/label05.f90
  flang/test/Semantics/label06.f90
  flang/test/Semantics/label07.f90
  flang/test/Semantics/label08.f90
  flang/test/Semantics/label09.f90
  flang/test/Semantics/label10.f90
  flang/test/Semantics/label12.f90
  flang/test/Semantics/label13.f90
  flang/test/Semantics/label15.f90
  flang/test/lit.cfg.py
  flang/tools/f18/f18.cpp

Index: flang/tools/f18/f18.cpp
===
--- flang/tools/f18/f18.cpp
+++ flang/tools/f18/f18.cpp
@@ -538,9 +538,10 @@
   options.instrumentedParse = true;
 } else if (arg == "-fdebug-no-semantics") {
   driver.debugNoSemantics = true;
-} else if (arg == "-funparse") {
+} else if (arg == "-funparse" || arg == "-fdebug-unparse") {
   driver.dumpUnparse = true;
-} else if (arg == "-funparse-with-symbols") {
+} else if (arg == "-funparse-with-symbols" ||
+arg == "-fdebug-unparse-with-symbols") {
   driver.dumpUnparseWithSymbols = true;
 } else if (arg == "-funparse-typed-exprs-to-f18-fc") {
   driver.unparseTypedExprsToF18_FC = true;
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -79,6 +79,14 @@
 extra_args=["-intrinsic-module-directory "+config.flang_intrinsic_modules_dir],
 unresolved='fatal'))
 
+if config.include_flang_new_driver_test:
+   tools.append(ToolSubst('%flang_fc1', command=FindTool('flang-new'),
+   extra_args=['-fc1'], unresolved='fatal'))
+else:
+   tools.append(ToolSubst('%flang_fc1', command=FindTool('f18'),
+extra_args=["-intrinsic-module-directory "+config.flang_intrinsic_modules_dir],
+unresolved='fatal'))
+
 if config.flang_standalone_build:
 llvm_config.add_tool_substitutions(tools, [config.flang_llvm_tools_dir])
 else:
Index: flang/test/Semantics/label15.f90
===
--- flang/test/Semantics/label15.f90
+++ flang/test/Semantics/label15.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -funparse %s 2>&1 | FileCheck %s
+! RUN: %flang_fc1 -fdebug-unparse %s 2>&1 | FileCheck %s
 
 !CHECK-NOT: error:
 module mm
Index: flang/test/Semantics/label13.f90
===
--- flang/test/Semantics/label13.f90
+++ flang/test/Semantics/label13.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -funparse-with-symbols %s 2>&1 | FileCheck %s
+! RUN: %flang_fc1 -fdebug-unparse-with-symbols %s 2>&1 | FileCheck %s
 ! CHECK: branch into loop body from outside
 ! CHECK: the loop branched into
 
Index: flang/test/Semantics/label12.f90
===
--- flang/test/Semantics/label12.f90
+++ flang/test/Semantics/label12.f90
@@ -1,4 +1,4 @@
-! RUN: not %f18 -funparse-with-symbols %s 2>&1 | FileCheck %s
+! RUN: not %flang_fc1 -fdebug-unparse-with-symbols %s 2>&1 | FileCheck %s
 ! CHECK: expected end of statement
 
 subroutine s
Index: flang/test/Semantics/label10.f90
===
--- flang/test/Semantics/label10.f90
+++ flang/test/Semantics/label10.f90
@@ -1,4 +1,4 @@
-! RUN: not %f18 -funparse-with-symbols %s 2>&1 | FileCheck %s
+! RUN: not %flang_fc1 -fdebug-unparse-with-symbols %s 2>&1 | FileCheck %s
 ! CHECK: '60' not a FORMAT
 ! CHECK: data transfer use of '60'
 
Index: flang/test/Semantics/label09.f90
===
--- flang/test/Semantics/label09.f90
+++ flang/test/Semantics/label09.f90
@@ -1,4 +1,4 @@
-! RUN: not %f18 -funparse-with-symbols %s 2>&1 | FileCheck %s
+! RUN: not %flang_fc1 -fdebug-unparse-with-symbols 

[clang] ed98676 - Support multi-configuration generators correctly in several config files

[Stella Stamenova via cfe-commits]

Author: Stella Stamenova
Date: 2021-02-11T09:32:20-08:00
New Revision: ed98676fa4833bb80632fc7c9db10c3328d78485

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

LOG: Support multi-configuration generators correctly in several config files

Multi-configuration generators (such as Visual Studio and Xcode) allow the 
specification of a build flavor at build time instead of config time, so the 
lit configuration files need to support that - and they do for the most part. 
There are several places that had one of two issues (or both!):

1) Paths had %(build_mode)s set up, but then not configured, resulting in 
values that would not work correctly e.g. 
D:/llvm-build/%(build_mode)s/bin/dsymutil.exe
2) Paths did not have %(build_mode)s set up, but instead contained 
$(Configuration) (which is the value for Visual Studio at configuration time, 
for Xcode they would have had the equivalent) e.g. 
"D:/llvm-build/$(Configuration)/lib".

This seems to indicate that we still have a lot of fragility in the 
configurations, but also that a number of these paths are never used (at least 
on Windows) since the errors appear to have been there a while.

This patch fixes the configurations and it has been tested with Ninja and 
Visual Studio to generate the correct paths. We should consider removing some 
of these settings altogether.

Reviewed By: JDevlieghere, mehdi_amini

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

Added: 


Modified: 
clang/test/Unit/lit.site.cfg.py.in
lld/test/CMakeLists.txt
lld/test/Unit/lit.site.cfg.py.in
lld/test/lit.site.cfg.py.in
lldb/test/API/lit.site.cfg.py.in
llvm/cmake/modules/AddLLVM.cmake
llvm/test/CMakeLists.txt
llvm/test/Unit/lit.site.cfg.py.in
llvm/test/lit.site.cfg.py.in
mlir/examples/standalone/test/lit.site.cfg.py.in
mlir/integration_test/lit.site.cfg.py.in
mlir/test/Unit/lit.site.cfg.py.in
mlir/test/lit.site.cfg.py.in

Removed: 




diff  --git a/clang/test/Unit/lit.site.cfg.py.in 
b/clang/test/Unit/lit.site.cfg.py.in
index ad5e6d0c8b2a..3edab4473dc4 100644
--- a/clang/test/Unit/lit.site.cfg.py.in
+++ b/clang/test/Unit/lit.site.cfg.py.in
@@ -19,6 +19,7 @@ try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
 config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
 config.llvm_build_mode = config.llvm_build_mode % lit_config.params
+config.shlibdir = config.shlibdir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
 key, = e.args

diff  --git a/lld/test/CMakeLists.txt b/lld/test/CMakeLists.txt
index ce0bcaa9203d..b2543901b757 100644
--- a/lld/test/CMakeLists.txt
+++ b/lld/test/CMakeLists.txt
@@ -1,8 +1,11 @@
-set(LLVM_SOURCE_DIR "${LLVM_MAIN_SRC_DIR}")
-set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}")
-set(LLVM_BUILD_MODE "%(build_mode)s")
-set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}/%(build_config)s")
-set(LLVM_LIBS_DIR 
"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/%(build_config)s")
+if (CMAKE_CFG_INTDIR STREQUAL ".")
+  set(LLVM_BUILD_MODE ".")
+else ()
+  set(LLVM_BUILD_MODE "%(build_mode)s")
+endif ()
+
+string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" LLD_LIBS_DIR 
"${LLVM_LIBRARY_OUTPUT_INTDIR}")
+string(REPLACE "${CMAKE_CFG_INTDIR}" "${LLVM_BUILD_MODE}" LLD_TOOLS_DIR 
"${LLVM_RUNTIME_OUTPUT_INTDIR}")
 
 llvm_canonicalize_cmake_booleans(
   LLVM_ENABLE_ZLIB

diff  --git a/lld/test/Unit/lit.site.cfg.py.in 
b/lld/test/Unit/lit.site.cfg.py.in
index d96e20f11d0a..65d9f9d85935 100644
--- a/lld/test/Unit/lit.site.cfg.py.in
+++ b/lld/test/Unit/lit.site.cfg.py.in
@@ -8,8 +8,8 @@ config.llvm_build_mode = "@LLVM_BUILD_MODE@"
 config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
 config.lld_obj_root = "@LLD_BINARY_DIR@"
 config.lld_src_root = "@LLD_SOURCE_DIR@"
-config.lld_libs_dir = "@LLVM_LIBRARY_OUTPUT_INTDIR@"
-config.lld_tools_dir = "@LLVM_RUNTIME_OUTPUT_INTDIR@"
+config.lld_libs_dir = "@LLD_LIBS_DIR@"
+config.lld_tools_dir = "@LLD_TOOLS_DIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.python_executable = "@Python3_EXECUTABLE@"
 
@@ -19,6 +19,8 @@ try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
 config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
 config.llvm_build_mode = config.llvm_build_mode % lit_config.params
+config.lld_libs_dir = config.lld_libs_dir % lit_config.params
+config.lld_tools_dir = config.lld_tools_dir % lit_config.params
 except KeyError as e:
 key, = e.args
 lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" % 
(key,key))

diff  --git a/lld/test/lit.site.cfg.py.in b/lld/test/lit.site.cfg.py.in
index a4e00b9dac93..a140284e0ded 100644
--- a/lld/test/lit.site.cfg.py.in
+++ b/lld/test/lit.site.cfg.py.in
@@ -9,8 +9,8 @@ config.llvm_tool

[PATCH] D96427: Support multi-configuration generators correctly in several config files

[Stella Stamenova 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 rGed98676fa483: Support multi-configuration generators 
correctly in several config files (authored by stella.stamenova).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96427

Files:
  clang/test/Unit/lit.site.cfg.py.in
  lld/test/CMakeLists.txt
  lld/test/Unit/lit.site.cfg.py.in
  lld/test/lit.site.cfg.py.in
  lldb/test/API/lit.site.cfg.py.in
  llvm/cmake/modules/AddLLVM.cmake
  llvm/test/CMakeLists.txt
  llvm/test/Unit/lit.site.cfg.py.in
  llvm/test/lit.site.cfg.py.in
  mlir/examples/standalone/test/lit.site.cfg.py.in
  mlir/integration_test/lit.site.cfg.py.in
  mlir/test/Unit/lit.site.cfg.py.in
  mlir/test/lit.site.cfg.py.in

Index: mlir/test/lit.site.cfg.py.in
===
--- mlir/test/lit.site.cfg.py.in
+++ mlir/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -51,6 +51,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: mlir/test/Unit/lit.site.cfg.py.in
===
--- mlir/test/Unit/lit.site.cfg.py.in
+++ mlir/test/Unit/lit.site.cfg.py.in
@@ -17,6 +17,7 @@
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
 config.llvm_build_mode = config.llvm_build_mode % lit_config.params
+config.shlibdir = config.shlibdir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
 key, = e.args
Index: mlir/integration_test/lit.site.cfg.py.in
===
--- mlir/integration_test/lit.site.cfg.py.in
+++ mlir/integration_test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -40,6 +40,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: mlir/examples/standalone/test/lit.site.cfg.py.in
===
--- mlir/examples/standalone/test/lit.site.cfg.py.in
+++ mlir/examples/standalone/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
-config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
+config.llvm_lib_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -35,6 +35,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: llvm/test/lit.site.cfg.py.in
===
--- llvm/test/lit.site.cfg.py.in
+++ llvm/test/lit.site.cfg.py.in
@@ -7,7 +7,7 @@
 config.llvm_src_root = path(r"@LLVM_SOURCE_DIR@")
 config.llvm_obj_root = path(r"@LLVM_BINARY_DIR@")
 config.llvm_tools_dir = path(r"@LLVM_TOOLS_DIR@")
-config.llvm_lib_dir = path(r"@LLVM_LIBRARY_DIR@")
+config.llvm_lib_dir = path(r"@LLVM_LIBS_DIR@")
 config.llvm_shlib_dir = path(r"@SHLIBDIR@")
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
@@ -56,6 +56,7 @@
 # used when we can't determine the tool dir at configuration time.
 try:
 config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
+config.llvm_lib_dir = config.llvm_lib_dir % lit_config.params
 config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
 except KeyError:
 e = sys.exc_info()[1]
Index: llvm/test/Unit/lit.site.cfg.py.in
===

[PATCH] D96483: [flang][driver] Add options for unparsing

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added inline comments.



Comment at: flang/tools/f18/f18.cpp:541
   driver.debugNoSemantics = true;
-} else if (arg == "-funparse") {
+} else if (arg == "-funparse" || arg == "-fdebug_unparse") {
   driver.dumpUnparse = true;

tskeith wrote:
> This should be "-fdebug-unparse" (with a hyphen). That may be why all those 
> tests are failing.
Fixed, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96483

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

[PATCH] D96090: [analyzer] Replace StoreManager::CastRetrievedVal with SValBuilder::evalCast

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

In D96090#2551664 , @ASDenysPetrov 
wrote:

> Updated. Unlinked parent revision D95799  
> from the stack. Made corresponding changes in this patch.
> @steakhal I did it. The changes should be safer now.

In the upcoming days, I'm gonna schedule this on our CI. We will see the 
results.


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

https://reviews.llvm.org/D96090

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

[PATCH] D94622: [clang-tidy] add concurrency-async-no-new-threads

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.cpp:41
+/* WinAPI */
+"CreateThread", //
+"CreateRemoteThread",   //

Missing the `::` in front of all of these identifiers.



Comment at: 
clang-tools-extra/clang-tidy/concurrency/AsyncNoNewThreadsCheck.cpp:22
+/* C++ std */
+"::std::async", //
+

segoon wrote:
> aaron.ballman wrote:
> > segoon wrote:
> > > aaron.ballman wrote:
> > > > The trailing comment markers don't really add much.
> > > it's a hack for clang-format, otherwise it contatenates the lines, 
> > > creating unmaintainable mess of strings. "One line - one name" is much 
> > > more suitable.
> > Ah, I didn't know that'd change the behavior of clang-format, that's neat!
> > 
> > FWIW, we usually don't do a whole lot of markup to avoid clang-format 
> > issues (such as the clang-format: on/off markers). Instead, we usually just 
> > ignore the LINT warnings in code review and check the code in as-is. This 
> > helps reduce clutter in the code base. In this case, the comments aren't 
> > adding a ton of clutter so maybe they're fine. But they definitely look odd 
> > as a reader of the code, which is a bit distracting.
> IMO having an ability to run clang-format for sources is very handy. It makes 
> me sad if running clang-format against the source forces me to set some 
> markers or reverting a part of clang-format changes in the source parts I 
> have never touched. An ability to simply rerun checks/linters is very 
> powerful.
I empathize, but clang-format is a moving target that hasn't existed as long as 
the rest of the project, so the project has a mismatch of formats. This is why 
the usual rule of thumb is: clang-format a full file and accept what it 
produces (on new files, like this one) or clang-format your diff (on existing 
files). If you don't like what clang-format produces in either situation, we 
typically format it by hand and then don't worry about it until the next time 
someone touches that code. Of course, I notice that we don't mention 
clang-format anywhere in the style guide at all. :-(

I won't insist on a change here, but I also would not be surprised if the 
useless comment markers were removed by someone during a "cleanup" either.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/concurrency-async-no-new-threads.rst:8-10
+functions and types. E.g. if the code uses C++ coroutines, it is expected
+that only new coroutines or coroutine-based primitives are created
+instead of heavy system threads.

segoon wrote:
> aaron.ballman wrote:
> > segoon wrote:
> > > aaron.ballman wrote:
> > > > FWIW, this suggests to me that what you really want is a way for APIs 
> > > > to opt into this behavior. There's no reason why you wouldn't have a 
> > > > complex system that has both threads and coroutines in it, but it does 
> > > > stand to reason that you may want to say "this function, and everything 
> > > > called within this function, should not create any system threads" in 
> > > > some situations.
> > > > 
> > > > The note below helps call out the expectations from the check, but it 
> > > > requires the developer to restructure the way they write code pretty 
> > > > drastically in order to make the checking behavior more reasonable, 
> > > > which does not seem ideal.
> > > I think it is a complex problem, so it should be separated into smaller 
> > > tasks.
> > > 
> > > Step one - checks with hardcoded functions/types with user-guided 
> > > enabling on a per-file basis. A semi-automated check.
> > > 
> > > Step two - try to solve other parts of the puzzle. Maybe try to add 
> > > [clang:coroutine_safe] tag and teach clang static analyzer to deduce 
> > > coroutine safety property and use it for enabling/disabling the cheks. 
> > > Maybe reuse other (not yet implemented) heuristics from static analyzer 
> > > (or other tools) to identify coroutine functions and check only these 
> > > functions. I'm not an expert in static analyzer, so other LLVM developers 
> > > might find a clever heuristics when to enable/disable these checks or 
> > > maybe how to deduce blacklisted/whitelisted functions/types lists (e.g. 
> > > for concurrency-async-{fs,blocking}).
> > > 
> > > Indeed, the current approach has its own limitations. But it may be a 
> > > first step in the right direction.
> > My fear with the current approach is that I don't think projects usually 
> > split their code in the way this check requires, and so the check will not 
> > be very useful in practice because it will be too chatty. Have you tried 
> > running this check over some large projects that use coroutines to see what 
> > the diagnostic results look like?
> I haven't conducted a survey, but I can say for Yandex.Taxi where the patch 
> has originated. The codebase is ~350KLOC. The main parts are:
> 1) a co

[PATCH] D96281: [clang-tidy] Add options to flag individual core increments and to ignore macros to readability-function-cognitive-complexity check.

[Jens Massberg via Phabricator via cfe-commits]

massberg added a comment.



In D96281#2556586 , @njames93 wrote:

> How does this handle a macro where the argument has complex code.
>
>   MACRO(if (...) {});

I agree that macro arguments should account to the complexity.

However, with this change macro arguments are ignored.
Unfortunately, I do not see an easy way how to ignore the macro code, but 
consider the arguments during analysis.

Optimally, macro calls should be considered like function calls in code. 
Consider the following example:

  #define noop
  
  #define SomeMacro(x)  \
if (1) {\
  x \
}
  
  void f() {
SomeMacro(if (1) { noop; })
  }

With IgnoreMacros='false' the check gives the function `f()` a complexity of 3, 
while with IgnoreMacro='true' the check gives it at complexity of 0.
IMO the complexity should be 1 (and maybe the macro definition itself should be 
flagged to have a complexity of 1).

So there is still room for improvements. However, from the code that I have 
seen it is more likely that there is complexity in the macros itself and not in 
their arguments when being used.
So I would tend to use the option IgnoreMacros='true'. However, as this isn't 
perfect and others might not agree with it I decided to add the option and also 
default it to
the old implementation.

I have added test cases that show this problem of ignoring macro arguments and 
added a comment to the documentation of the option.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96281

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