[PATCH] D86591: [SyntaxTree] Fix C++ versions on tests of `BuildTreeTest.cpp`

2020-08-26 Thread Eduardo Caldas 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 rG3b75f65e6ba4: [SyntaxTree] Fix C++ versions on tests of 
`BuildTreeTest.cpp` (authored by eduucaldas).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86591

Files:
  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
@@ -2870,20 +2870,32 @@
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
 namespace a { namespace b {} }
+)cpp",
+  R"txt(
+TranslationUnit Detached
+`-NamespaceDefinition
+  |-'namespace'
+  |-'a'
+  |-'{'
+  |-NamespaceDefinition
+  | |-'namespace'
+  | |-'b'
+  | |-'{'
+  | `-'}'
+  `-'}'
+)txt"));
+}
+
+TEST_P(SyntaxTreeTest, Namespace_NestedDefinition) {
+  if (!GetParam().isCXX17OrLater()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
 namespace a::b {}
 )cpp",
   R"txt(
 TranslationUnit Detached
-|-NamespaceDefinition
-| |-'namespace'
-| |-'a'
-| |-'{'
-| |-NamespaceDefinition
-| | |-'namespace'
-| | |-'b'
-| | |-'{'
-| | `-'}'
-| `-'}'
 `-NamespaceDefinition
   |-'namespace'
   |-'a'
@@ -3006,7 +3018,7 @@
 }
 
 TEST_P(SyntaxTreeTest, UsingTypeAlias) {
-  if (!GetParam().isCXX()) {
+  if (!GetParam().isCXX11OrLater()) {
 return;
   }
   EXPECT_TRUE(treeDumpEqual(
@@ -3307,7 +3319,7 @@
 }
 
 TEST_P(SyntaxTreeTest, VariableTemplateDeclaration) {
-  if (!GetParam().isCXX()) {
+  if (!GetParam().isCXX14OrLater()) {
 return;
   }
   EXPECT_TRUE(treeDumpEqual(
@@ -3616,20 +3628,32 @@
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
 static_assert(true, "message");
+)cpp",
+  R"txt(
+TranslationUnit Detached
+`-StaticAssertDeclaration
+  |-'static_assert'
+  |-'('
+  |-BoolLiteralExpression StaticAssertDeclaration_condition
+  | `-'true' LiteralToken
+  |-','
+  |-StringLiteralExpression StaticAssertDeclaration_message
+  | `-'"message"' LiteralToken
+  |-')'
+  `-';'
+)txt"));
+}
+
+TEST_P(SyntaxTreeTest, StaticAssert_WithoutMessage) {
+  if (!GetParam().isCXX17OrLater()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
 static_assert(true);
 )cpp",
   R"txt(
 TranslationUnit Detached
-|-StaticAssertDeclaration
-| |-'static_assert'
-| |-'('
-| |-BoolLiteralExpression StaticAssertDeclaration_condition
-| | `-'true' LiteralToken
-| |-','
-| |-StringLiteralExpression StaticAssertDeclaration_message
-| | `-'"message"' LiteralToken
-| |-')'
-| `-';'
 `-StaticAssertDeclaration
   |-'static_assert'
   |-'('
@@ -4165,7 +4189,7 @@
 }
 
 TEST_P(SyntaxTreeTest, ParametersAndQualifiers_InMemberFunctions_Ref) {
-  if (!GetParam().isCXX()) {
+  if (!GetParam().isCXX11OrLater()) {
 return;
   }
   EXPECT_TRUE(treeDumpEqualOnAnnotations(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 3b75f65 - [SyntaxTree] Fix C++ versions on tests of `BuildTreeTest.cpp`

2020-08-26 Thread Eduardo Caldas via cfe-commits

Author: Eduardo Caldas
Date: 2020-08-26T07:19:49Z
New Revision: 3b75f65e6ba4862977fd193ddb4918c4fc380fa5

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

LOG: [SyntaxTree] Fix C++ versions on tests of `BuildTreeTest.cpp`

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

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 6ab01e8f65f0..e386646ee667 100644
--- a/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ b/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -2870,20 +2870,32 @@ TEST_P(SyntaxTreeTest, Namespace_Nested) {
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
 namespace a { namespace b {} }
+)cpp",
+  R"txt(
+TranslationUnit Detached
+`-NamespaceDefinition
+  |-'namespace'
+  |-'a'
+  |-'{'
+  |-NamespaceDefinition
+  | |-'namespace'
+  | |-'b'
+  | |-'{'
+  | `-'}'
+  `-'}'
+)txt"));
+}
+
+TEST_P(SyntaxTreeTest, Namespace_NestedDefinition) {
+  if (!GetParam().isCXX17OrLater()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
 namespace a::b {}
 )cpp",
   R"txt(
 TranslationUnit Detached
-|-NamespaceDefinition
-| |-'namespace'
-| |-'a'
-| |-'{'
-| |-NamespaceDefinition
-| | |-'namespace'
-| | |-'b'
-| | |-'{'
-| | `-'}'
-| `-'}'
 `-NamespaceDefinition
   |-'namespace'
   |-'a'
@@ -3006,7 +3018,7 @@ UsingDeclaration
 }
 
 TEST_P(SyntaxTreeTest, UsingTypeAlias) {
-  if (!GetParam().isCXX()) {
+  if (!GetParam().isCXX11OrLater()) {
 return;
   }
   EXPECT_TRUE(treeDumpEqual(
@@ -3307,7 +3319,7 @@ TranslationUnit Detached
 }
 
 TEST_P(SyntaxTreeTest, VariableTemplateDeclaration) {
-  if (!GetParam().isCXX()) {
+  if (!GetParam().isCXX14OrLater()) {
 return;
   }
   EXPECT_TRUE(treeDumpEqual(
@@ -3616,20 +3628,32 @@ TEST_P(SyntaxTreeTest, StaticAssert) {
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
 static_assert(true, "message");
+)cpp",
+  R"txt(
+TranslationUnit Detached
+`-StaticAssertDeclaration
+  |-'static_assert'
+  |-'('
+  |-BoolLiteralExpression StaticAssertDeclaration_condition
+  | `-'true' LiteralToken
+  |-','
+  |-StringLiteralExpression StaticAssertDeclaration_message
+  | `-'"message"' LiteralToken
+  |-')'
+  `-';'
+)txt"));
+}
+
+TEST_P(SyntaxTreeTest, StaticAssert_WithoutMessage) {
+  if (!GetParam().isCXX17OrLater()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
 static_assert(true);
 )cpp",
   R"txt(
 TranslationUnit Detached
-|-StaticAssertDeclaration
-| |-'static_assert'
-| |-'('
-| |-BoolLiteralExpression StaticAssertDeclaration_condition
-| | `-'true' LiteralToken
-| |-','
-| |-StringLiteralExpression StaticAssertDeclaration_message
-| | `-'"message"' LiteralToken
-| |-')'
-| `-';'
 `-StaticAssertDeclaration
   |-'static_assert'
   |-'('
@@ -4165,7 +4189,7 @@ SimpleDeclaration
 }
 
 TEST_P(SyntaxTreeTest, ParametersAndQualifiers_InMemberFunctions_Ref) {
-  if (!GetParam().isCXX()) {
+  if (!GetParam().isCXX11OrLater()) {
 return;
   }
   EXPECT_TRUE(treeDumpEqualOnAnnotations(



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


[PATCH] D86544: [SyntaxTree] Add support for call expressions

2020-08-26 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas updated this revision to Diff 287842.
eduucaldas marked 8 inline comments as done.
eduucaldas added a comment.

Answer code review, squash commits


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86544

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Nodes.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
@@ -316,12 +316,12 @@
   `-CompoundStatement
 |-'{' OpenParen
 |-ExpressionStatement CompoundStatement_statement
-| |-UnknownExpression ExpressionStatement_expression
-| | |-IdExpression
+| |-CallExpression ExpressionStatement_expression
+| | |-IdExpression CallExpression_callee
 | | | `-UnqualifiedId IdExpression_id
 | | |   `-'test'
-| | |-'('
-| | `-')'
+| | |-'(' OpenParen
+| | `-')' CloseParen
 | `-';'
 |-IfStatement CompoundStatement_statement
 | |-'if' IntroducerKeyword
@@ -330,21 +330,21 @@
 | | `-'1' LiteralToken
 | |-')'
 | |-ExpressionStatement IfStatement_thenStatement
-| | |-UnknownExpression ExpressionStatement_expression
-| | | |-IdExpression
+| | |-CallExpression ExpressionStatement_expression
+| | | |-IdExpression CallExpression_callee
 | | | | `-UnqualifiedId IdExpression_id
 | | | |   `-'test'
-| | | |-'('
-| | | `-')'
+| | | |-'(' OpenParen
+| | | `-')' CloseParen
 | | `-';'
 | |-'else' IfStatement_elseKeyword
 | `-ExpressionStatement IfStatement_elseStatement
-|   |-UnknownExpression ExpressionStatement_expression
-|   | |-IdExpression
+|   |-CallExpression ExpressionStatement_expression
+|   | |-IdExpression CallExpression_callee
 |   | | `-UnqualifiedId IdExpression_id
 |   | |   `-'test'
-|   | |-'('
-|   | `-')'
+|   | |-'(' OpenParen
+|   | `-')' CloseParen
 |   `-';'
 `-'}' CloseParen
 )txt"));
@@ -378,20 +378,21 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-IdExpression
+CallExpression ExpressionStatement_expression
+|-IdExpression CallExpression_callee
 | `-UnqualifiedId IdExpression_id
 |   |-'operator'
 |   `-'+'
-|-'('
-|-IdExpression
-| `-UnqualifiedId IdExpression_id
-|   `-'x'
-|-','
-|-IdExpression
-| `-UnqualifiedId IdExpression_id
-|   `-'x'
-`-')'
+|-'(' OpenParen
+|-CallArguments CallExpression_arguments
+| |-IdExpression List_element
+| | `-UnqualifiedId IdExpression_id
+| |   `-'x'
+| |-',' List_delimiter
+| `-IdExpression List_element
+|   `-UnqualifiedId IdExpression_id
+| `-'x'
+`-')' CloseParen
 )txt"}));
 }
 
@@ -409,8 +410,8 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-MemberExpression
+CallExpression ExpressionStatement_expression
+|-MemberExpression CallExpression_callee
 | |-IdExpression MemberExpression_object
 | | `-UnqualifiedId IdExpression_id
 | |   `-'x'
@@ -419,8 +420,8 @@
 |   `-UnqualifiedId IdExpression_id
 | |-'operator'
 | `-'int'
-|-'('
-`-')'
+|-'(' OpenParen
+`-')' CloseParen
 )txt"}));
 }
 
@@ -436,16 +437,17 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-IdExpression
+CallExpression ExpressionStatement_expression
+|-IdExpression CallExpression_callee
 | `-UnqualifiedId IdExpression_id
 |   |-'operator'
 |   |-'""'
 |   `-'_w'
-|-'('
-|-CharacterLiteralExpression
-| `-''1'' LiteralToken
-`-')'
+|-'(' OpenParen
+|-CallArguments CallExpression_arguments
+| `-CharacterLiteralExpression List_element
+|   `-''1'' LiteralToken
+`-')' CloseParen
 )txt"}));
 }
 
@@ -461,8 +463,8 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-MemberExpression
+CallExpression ExpressionStatement_expression
+|-MemberExpression CallExpression_callee
 | |-IdExpression MemberExpression_object
 | | `-UnqualifiedId IdExpression_id
 | |   `-'x'
@@ -471,8 +473,8 @@
 |   `-UnqualifiedId IdExpression_id
 | |-'~'
 | `-'X'
-|-'('
-`-')'
+|-'(' OpenParen
+`-')' CloseParen
 )txt"}));
 }
 
@@ -492,8 +494,8 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-MemberExpression
+CallExpression ExpressionStatement_expression
+|-MemberExpression CallExpression_callee
 | |-IdExpression MemberExpression_object
 | | `-UnqualifiedId IdExpression_id
 | |   `-'x'
@@ -506,7 +508,7 @@
 |-'x'
 |-')'
 |-'('
-`-')'
+`-')' CloseParen
 )txt"}));
 }
 
@@ -523,15 +525,15 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-IdExpression
+CallExpression ExpressionStatement_expression
+|-IdExpression CallExpression_callee
 | `-UnqualifiedId IdExpression_id
 |   |-'f'
 |   |-'<'
 |   |-'int'
 |   `-'>'
-|-'('
-`-')'
+|-'(' 

[PATCH] D86544: [SyntaxTree] Add support for call expressions

2020-08-26 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas added inline comments.



Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:1070
+Builder.markChildToken(
+std::next(Builder.findToken(S->getCallee()->getEndLoc())),
+syntax::NodeRole::OpenParen);

gribozavr2 wrote:
> Could you add an assertion that it is indeed an open paren?
> 
> Or, rather, due to the decltype test, it has to be a check, and a FIXME that 
> says that the check should become an assertion.
Thanks! It is indeed what I should've done :) 



Comment at: clang/lib/Tooling/Syntax/BuildTree.cpp:1159
 case syntax::NodeKind::UnknownExpression:
-  return RecursiveASTVisitor::WalkUpFromCXXOperatorCallExpr(S);
+  return WalkUpFromExpr(S);
 default:

gribozavr2 wrote:
> I don't understand this change to the unknown case, could you explain?
CXXOperatorCallExpr <- CallExpr <- Expr

In this change we added an overload for `WalkUpFromCallExpr`, so we started 
intercepting the `WalkUp` at `CallExpr` instead of `Expr`, this works around 
that.




Comment at: clang/unittests/Tooling/Syntax/BuildTreeTest.cpp:2734
+|   |   `-'args'
+|   `-'...'
+`-')' CloseParen

gribozavr2 wrote:
> eduucaldas wrote:
> > Here there is a divergence between the grammar and the ClangAST. 
> > According to the [[ https://eel.is/c++draft/expr.post#nt:expression-list | 
> > grammar ]]  `...` would an optional element of `CallArguments`, but here 
> > `...` is part of an expression.
> > 
> > Perhaps I have used the wrong kind of `...`
> > `...` would an optional element of CallArguments
> 
> I don't think so. Note that every element of initializer-list can have a 
> `...` in it.
True! I hadn't seen it correctly!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86544

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


[PATCH] D86544: [SyntaxTree] Add support for call expressions

2020-08-26 Thread Eduardo Caldas 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 rG2de2ca348dfa: [SyntaxTree] Add support for `CallExpression` 
(authored by eduucaldas).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86544

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Nodes.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
@@ -316,12 +316,12 @@
   `-CompoundStatement
 |-'{' OpenParen
 |-ExpressionStatement CompoundStatement_statement
-| |-UnknownExpression ExpressionStatement_expression
-| | |-IdExpression
+| |-CallExpression ExpressionStatement_expression
+| | |-IdExpression CallExpression_callee
 | | | `-UnqualifiedId IdExpression_id
 | | |   `-'test'
-| | |-'('
-| | `-')'
+| | |-'(' OpenParen
+| | `-')' CloseParen
 | `-';'
 |-IfStatement CompoundStatement_statement
 | |-'if' IntroducerKeyword
@@ -330,21 +330,21 @@
 | | `-'1' LiteralToken
 | |-')'
 | |-ExpressionStatement IfStatement_thenStatement
-| | |-UnknownExpression ExpressionStatement_expression
-| | | |-IdExpression
+| | |-CallExpression ExpressionStatement_expression
+| | | |-IdExpression CallExpression_callee
 | | | | `-UnqualifiedId IdExpression_id
 | | | |   `-'test'
-| | | |-'('
-| | | `-')'
+| | | |-'(' OpenParen
+| | | `-')' CloseParen
 | | `-';'
 | |-'else' IfStatement_elseKeyword
 | `-ExpressionStatement IfStatement_elseStatement
-|   |-UnknownExpression ExpressionStatement_expression
-|   | |-IdExpression
+|   |-CallExpression ExpressionStatement_expression
+|   | |-IdExpression CallExpression_callee
 |   | | `-UnqualifiedId IdExpression_id
 |   | |   `-'test'
-|   | |-'('
-|   | `-')'
+|   | |-'(' OpenParen
+|   | `-')' CloseParen
 |   `-';'
 `-'}' CloseParen
 )txt"));
@@ -378,20 +378,21 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-IdExpression
+CallExpression ExpressionStatement_expression
+|-IdExpression CallExpression_callee
 | `-UnqualifiedId IdExpression_id
 |   |-'operator'
 |   `-'+'
-|-'('
-|-IdExpression
-| `-UnqualifiedId IdExpression_id
-|   `-'x'
-|-','
-|-IdExpression
-| `-UnqualifiedId IdExpression_id
-|   `-'x'
-`-')'
+|-'(' OpenParen
+|-CallArguments CallExpression_arguments
+| |-IdExpression List_element
+| | `-UnqualifiedId IdExpression_id
+| |   `-'x'
+| |-',' List_delimiter
+| `-IdExpression List_element
+|   `-UnqualifiedId IdExpression_id
+| `-'x'
+`-')' CloseParen
 )txt"}));
 }
 
@@ -409,8 +410,8 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-MemberExpression
+CallExpression ExpressionStatement_expression
+|-MemberExpression CallExpression_callee
 | |-IdExpression MemberExpression_object
 | | `-UnqualifiedId IdExpression_id
 | |   `-'x'
@@ -419,8 +420,8 @@
 |   `-UnqualifiedId IdExpression_id
 | |-'operator'
 | `-'int'
-|-'('
-`-')'
+|-'(' OpenParen
+`-')' CloseParen
 )txt"}));
 }
 
@@ -436,16 +437,17 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-IdExpression
+CallExpression ExpressionStatement_expression
+|-IdExpression CallExpression_callee
 | `-UnqualifiedId IdExpression_id
 |   |-'operator'
 |   |-'""'
 |   `-'_w'
-|-'('
-|-CharacterLiteralExpression
-| `-''1'' LiteralToken
-`-')'
+|-'(' OpenParen
+|-CallArguments CallExpression_arguments
+| `-CharacterLiteralExpression List_element
+|   `-''1'' LiteralToken
+`-')' CloseParen
 )txt"}));
 }
 
@@ -461,8 +463,8 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-MemberExpression
+CallExpression ExpressionStatement_expression
+|-MemberExpression CallExpression_callee
 | |-IdExpression MemberExpression_object
 | | `-UnqualifiedId IdExpression_id
 | |   `-'x'
@@ -471,8 +473,8 @@
 |   `-UnqualifiedId IdExpression_id
 | |-'~'
 | `-'X'
-|-'('
-`-')'
+|-'(' OpenParen
+`-')' CloseParen
 )txt"}));
 }
 
@@ -492,8 +494,8 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-MemberExpression
+CallExpression ExpressionStatement_expression
+|-MemberExpression CallExpression_callee
 | |-IdExpression MemberExpression_object
 | | `-UnqualifiedId IdExpression_id
 | |   `-'x'
@@ -506,7 +508,7 @@
 |-'x'
 |-')'
 |-'('
-`-')'
+`-')' CloseParen
 )txt"}));
 }
 
@@ -523,15 +525,15 @@
 }
 )cpp",
   {R"txt(
-UnknownExpression ExpressionStatement_expression
-|-IdExpression
+CallExpression ExpressionStatement_expression
+|-IdExpression CallExpression_callee
 | `-UnqualifiedId 

[clang] 2de2ca3 - [SyntaxTree] Add support for `CallExpression`

2020-08-26 Thread Eduardo Caldas via cfe-commits

Author: Eduardo Caldas
Date: 2020-08-26T07:03:49Z
New Revision: 2de2ca348dfa09963eb33ddf71c9cbb59612c16a

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

LOG: [SyntaxTree] Add support for `CallExpression`

* Generate `CallExpression` syntax node for all semantic nodes inheriting from
`CallExpr` with call-expression syntax - except `CUDAKernelCallExpr`.
* Implement all the accessors
* Arguments of `CallExpression` have their own syntax node which is based on
the `List` base API

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

Added: 


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

Removed: 




diff  --git a/clang/include/clang/Tooling/Syntax/Nodes.h 
b/clang/include/clang/Tooling/Syntax/Nodes.h
index 0b3991768008..9a14aac130b4 100644
--- a/clang/include/clang/Tooling/Syntax/Nodes.h
+++ b/clang/include/clang/Tooling/Syntax/Nodes.h
@@ -57,6 +57,7 @@ enum class NodeKind : uint16_t {
   IdExpression,
   MemberExpression,
   ThisExpression,
+  CallExpression,
 
   // Statements.
   UnknownStatement,
@@ -103,7 +104,8 @@ enum class NodeKind : uint16_t {
   GlobalNameSpecifier,
   DecltypeNameSpecifier,
   IdentifierNameSpecifier,
-  SimpleTemplateNameSpecifier
+  SimpleTemplateNameSpecifier,
+  CallArguments
 };
 /// For debugging purposes.
 raw_ostream <<(raw_ostream , NodeKind K);
@@ -179,6 +181,8 @@ enum class NodeRole : uint8_t {
   MemberExpression_object,
   MemberExpression_accessToken,
   MemberExpression_member,
+  CallExpression_callee,
+  CallExpression_arguments,
 };
 /// For debugging purposes.
 raw_ostream <<(raw_ostream , NodeRole R);
@@ -324,6 +328,37 @@ class ThisExpression final : public Expression {
   Leaf *thisKeyword();
 };
 
+/// Models arguments of a function call.
+///   call-arguments:
+/// delimited_list(expression, ',')
+/// Note: This construct is a simplification of the grammar rule for
+/// `expression-list`, that is used in the definition of `call-expression`
+class CallArguments final : public List {
+public:
+  CallArguments() : List(NodeKind::CallArguments) {}
+  static bool classof(const Node *N) {
+return N->kind() <= NodeKind::CallArguments;
+  }
+  std::vector arguments();
+  std::vector> argumentsAndCommas();
+};
+
+/// A function call. C++ [expr.call]
+/// call-expression:
+///   expression '(' call-arguments ')'
+/// e.g `f(1, '2')` or `this->Base::f()`
+class CallExpression final : public Expression {
+public:
+  CallExpression() : Expression(NodeKind::CallExpression) {}
+  static bool classof(const Node *N) {
+return N->kind() == NodeKind::CallExpression;
+  }
+  Expression *callee();
+  Leaf *openParen();
+  CallArguments *arguments();
+  Leaf *closeParen();
+};
+
 /// Models a parenthesized expression `(E)`. C++ [expr.prim.paren]
 /// e.g. `(3 + 2)` in `a = 1 + (3 + 2);`
 class ParenExpression final : public Expression {

diff  --git a/clang/lib/Tooling/Syntax/BuildTree.cpp 
b/clang/lib/Tooling/Syntax/BuildTree.cpp
index f027a60030b7..2e3dbc6c6fbd 100644
--- a/clang/lib/Tooling/Syntax/BuildTree.cpp
+++ b/clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -184,10 +184,11 @@ static syntax::NodeKind getOperatorNodeKind(const 
CXXOperatorCallExpr ) {
   case OO_Array_New:
   case OO_Array_Delete:
   case OO_Coawait:
-  case OO_Call:
   case OO_Subscript:
   case OO_Arrow:
 return syntax::NodeKind::UnknownExpression;
+  case OO_Call:
+return syntax::NodeKind::CallExpression;
   case OO_Conditional: // not overloadable
   case NUM_OVERLOADED_OPERATORS:
   case OO_None:
@@ -1042,6 +1043,46 @@ class BuildTreeVisitor : public 
RecursiveASTVisitor {
 return true;
   }
 
+  syntax::CallArguments *buildCallArguments(CallExpr::arg_range Args) {
+for (const auto  : Args) {
+  Builder.markExprChild(Arg, syntax::NodeRole::List_element);
+  const auto *DelimiterToken =
+  std::next(Builder.findToken(Arg->getEndLoc()));
+  if (DelimiterToken->kind() == clang::tok::TokenKind::comma)
+Builder.markChildToken(DelimiterToken,
+   syntax::NodeRole::List_delimiter);
+}
+
+auto *Arguments = new (allocator()) syntax::CallArguments;
+if (!Args.empty())
+  Builder.foldNode(Builder.getRange((*Args.begin())->getBeginLoc(),
+(*(Args.end() - 1))->getEndLoc()),
+   Arguments, nullptr);
+
+return Arguments;
+  }
+
+  bool WalkUpFromCallExpr(CallExpr *S) {
+Builder.markExprChild(S->getCallee(),
+  syntax::NodeRole::CallExpression_callee);
+
+const auto *LParenToken =
+std::next(Builder.findToken(S->getCallee()->getEndLoc()));
+

[PATCH] D86591: [SyntaxTree] Fix C++ versions on tests of `BuildTreeTest.cpp`

2020-08-26 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
eduucaldas requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86591

Files:
  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
@@ -2870,20 +2870,32 @@
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
 namespace a { namespace b {} }
+)cpp",
+  R"txt(
+TranslationUnit Detached
+`-NamespaceDefinition
+  |-'namespace'
+  |-'a'
+  |-'{'
+  |-NamespaceDefinition
+  | |-'namespace'
+  | |-'b'
+  | |-'{'
+  | `-'}'
+  `-'}'
+)txt"));
+}
+
+TEST_P(SyntaxTreeTest, Namespace_NestedDefinition) {
+  if (!GetParam().isCXX17OrLater()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
 namespace a::b {}
 )cpp",
   R"txt(
 TranslationUnit Detached
-|-NamespaceDefinition
-| |-'namespace'
-| |-'a'
-| |-'{'
-| |-NamespaceDefinition
-| | |-'namespace'
-| | |-'b'
-| | |-'{'
-| | `-'}'
-| `-'}'
 `-NamespaceDefinition
   |-'namespace'
   |-'a'
@@ -3006,7 +3018,7 @@
 }
 
 TEST_P(SyntaxTreeTest, UsingTypeAlias) {
-  if (!GetParam().isCXX()) {
+  if (!GetParam().isCXX11OrLater()) {
 return;
   }
   EXPECT_TRUE(treeDumpEqual(
@@ -3307,7 +3319,7 @@
 }
 
 TEST_P(SyntaxTreeTest, VariableTemplateDeclaration) {
-  if (!GetParam().isCXX()) {
+  if (!GetParam().isCXX14OrLater()) {
 return;
   }
   EXPECT_TRUE(treeDumpEqual(
@@ -3616,20 +3628,32 @@
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
 static_assert(true, "message");
+)cpp",
+  R"txt(
+TranslationUnit Detached
+`-StaticAssertDeclaration
+  |-'static_assert'
+  |-'('
+  |-BoolLiteralExpression StaticAssertDeclaration_condition
+  | `-'true' LiteralToken
+  |-','
+  |-StringLiteralExpression StaticAssertDeclaration_message
+  | `-'"message"' LiteralToken
+  |-')'
+  `-';'
+)txt"));
+}
+
+TEST_P(SyntaxTreeTest, StaticAssert_WithoutMessage) {
+  if (!GetParam().isCXX17OrLater()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
 static_assert(true);
 )cpp",
   R"txt(
 TranslationUnit Detached
-|-StaticAssertDeclaration
-| |-'static_assert'
-| |-'('
-| |-BoolLiteralExpression StaticAssertDeclaration_condition
-| | `-'true' LiteralToken
-| |-','
-| |-StringLiteralExpression StaticAssertDeclaration_message
-| | `-'"message"' LiteralToken
-| |-')'
-| `-';'
 `-StaticAssertDeclaration
   |-'static_assert'
   |-'('
@@ -4165,7 +4189,7 @@
 }
 
 TEST_P(SyntaxTreeTest, ParametersAndQualifiers_InMemberFunctions_Ref) {
-  if (!GetParam().isCXX()) {
+  if (!GetParam().isCXX11OrLater()) {
 return;
   }
   EXPECT_TRUE(treeDumpEqualOnAnnotations(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D85984: [analyzer] Add a new checker alpha.cplusplus.CPlusPlus11Lock

2020-08-26 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.

@NoQ

> That's completely different checker logic.

I think, I got the message. The real recursive logic can be caught here:

  std::recursive_mutex rm;
  void recur1() {
recur2();
  }
  void recur2() {
rm.lock();
recur1(); // here we can ignore the meet of twice lock, can't we? 
  }


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

https://reviews.llvm.org/D85984

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


[PATCH] D85948: [HeapProf] Clang and LLVM support for heap profiling instrumentation

2020-08-26 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson updated this revision to Diff 287832.
tejohnson marked 2 inline comments as done.
tejohnson added a comment.

Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85948

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/fmemprof.cpp
  llvm/include/llvm/InitializePasses.h
  llvm/include/llvm/Transforms/Instrumentation/HeapProfiler.h
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Passes/PassRegistry.def
  llvm/lib/Transforms/Instrumentation/CMakeLists.txt
  llvm/lib/Transforms/Instrumentation/HeapProfiler.cpp
  llvm/lib/Transforms/Instrumentation/Instrumentation.cpp
  llvm/test/Instrumentation/HeapProfiler/basic.ll
  llvm/test/Instrumentation/HeapProfiler/instrumentation-use-callbacks.ll
  llvm/test/Instrumentation/HeapProfiler/masked-load-store.ll
  llvm/test/Instrumentation/HeapProfiler/scale-granularity.ll
  llvm/test/Instrumentation/HeapProfiler/version-mismatch-check.ll

Index: llvm/test/Instrumentation/HeapProfiler/version-mismatch-check.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/HeapProfiler/version-mismatch-check.ll
@@ -0,0 +1,12 @@
+; Check that the HeapProf module constructor guards against compiler/runtime version
+; mismatch.
+
+; RUN: opt < %s -heapprof-module -S | FileCheck %s
+; RUN: opt < %s -heapprof-module -heapprof-guard-against-version-mismatch=0 -S | FileCheck %s --check-prefix=NOGUARD
+
+target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
+target triple = "x86_64-unknown-linux-gnu"
+
+; CHECK-LABEL: define internal void @heapprof.module_ctor()
+; CHECK: call void @__heapprof_version_mismatch_check_v1
+; NOGUARD-NOT:   call void @__heapprof_version_mismatch_check_
Index: llvm/test/Instrumentation/HeapProfiler/scale-granularity.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/HeapProfiler/scale-granularity.ll
@@ -0,0 +1,29 @@
+; Test that the scale (-heapprof-mapping-scale) and granularity (-heapprof-mapping-granularity) command-line options work as expected
+;
+; RUN: opt < %s -heapprof -heapprof-module -heapprof-mapping-granularity 32 -S | FileCheck --check-prefix=CHECK-GRAN %s
+; RUN: opt < %s -heapprof -heapprof-module -heapprof-mapping-scale 1 -S | FileCheck --check-prefix=CHECK-SCALE %s
+; RUN: opt < %s -heapprof -heapprof-module -heapprof-mapping-granularity 16 -heapprof-mapping-scale 0 -S | FileCheck --check-prefix=CHECK-BOTH %s
+target triple = "x86_64-unknown-linux-gnu"
+
+define i32 @read(i32* %a) {
+entry:
+  %tmp1 = load i32, i32* %a, align 4
+  ret i32 %tmp1
+}
+; CHECK-GRAN-LABEL: @read
+; CHECK-GRAN-NOT: ret
+; CHECK-GRAN: and {{.*}} -32
+; CHECK-GRAN-NEXT:lshr {{.*}} 3
+; CHECK-GRAN: ret
+
+; CHECK-SCALE-LABEL: @read
+; CHECK-SCALE-NOT: ret
+; CHECK-SCALE: and {{.*}} -64
+; CHECK-SCALE-NEXT:lshr {{.*}} 1
+; CHECK-SCALE: ret
+
+; CHECK-BOTH-LABEL: @read
+; CHECK-BOTH-NOT: ret
+; CHECK-BOTH: and {{.*}} -16
+; CHECK-BOTH-NEXT:lshr {{.*}} 0
+; CHECK-BOTH: ret
Index: llvm/test/Instrumentation/HeapProfiler/masked-load-store.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/HeapProfiler/masked-load-store.ll
@@ -0,0 +1,246 @@
+; RUN: opt < %s -heapprof -heapprof-use-callbacks -S \
+; RUN: | FileCheck %s -check-prefix=LOAD -check-prefix=STORE -check-prefix=ALL
+; RUN: opt < %s -heapprof -heapprof-use-callbacks -heapprof-instrument-reads=0 -S \
+; RUN: | FileCheck %s -check-prefix=NOLOAD -check-prefix=STORE -check-prefix=ALL
+; RUN: opt < %s -heapprof -heapprof-use-callbacks -heapprof-instrument-writes=0 -S \
+; RUN: | FileCheck %s -check-prefix=LOAD -check-prefix=NOSTORE -check-prefix=ALL
+; RUN: opt < %s -heapprof -heapprof-use-callbacks -heapprof-instrument-reads=0 -heapprof-instrument-writes=0 -S \
+; RUN: | FileCheck %s -check-prefix=NOLOAD -check-prefix=NOSTORE -check-prefix=ALL
+; Support heap profiling instrumentation for constant-mask llvm.masked.{load,store}
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+
+@v4f32 = global <4 x float>* zeroinitializer, align 8
+@v8i32 = global <8 x i32>* zeroinitializer, align 8
+@v4i64 = global <4 x i32*>* zeroinitializer, align 8
+
+ STORE
+declare void @llvm.masked.store.v4f32.p0v4f32(<4 x float>, <4 x float>*, i32, <4 x i1>) argmemonly nounwind
+declare void 

[PATCH] D85948: [HeapProf] Clang and LLVM support for heap profiling instrumentation

2020-08-26 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson marked 18 inline comments as done.
tejohnson added a comment.

I think I've addressed all the comments.




Comment at: llvm/lib/Transforms/Instrumentation/HeapProfiler.cpp:48
+// Size of memory mapped to a single shadow location.
+static const uint64_t DefaultShadowGranularity = 64;
+

MaskRay wrote:
> For a constant in the source file, consider `constexpr uint64_t 
> DefaultShadowGranularity = 64;` (constexpr implies const, which means 
> internal linkage in a namespace scope, so you can avoid `static`)
changed all of them.



Comment at: llvm/lib/Transforms/Instrumentation/HeapProfiler.cpp:203
+
+class HeapProfilerLegacyPass : public FunctionPass {
+public:

MaskRay wrote:
> Since this is new. Perhaps not deal with legacy pass manager at all?
> 
> For example, recently there has been objection on porting CGProfile to the 
> legacy pass manager. For an entirely new thing, not handling legacy pass 
> managers can avoid many tests.
Since the legacy pass manager is still the default, and adding the support was 
trivial, it makes sense to add the support there too.



Comment at: llvm/test/Instrumentation/HeapProfiling/basic.ll:61
+; Exactly one shadow update for store access.
+; CHECK-COUNT-1: %[[NEW_ST_SHADOW:[^ ]*]] = add i64 %{{.*}}, 1
+; CHECK-COUNT-1: store i64 %[[NEW_ST_SHADOW]]

MaskRay wrote:
> `CHECK-COUNT-1` here is actually identical to a `CHECK`. If there are two 
> repeated lines, the pattern will still match.
> 
> Suggest deleting `-COUNT-1`. Change the next `CHECK` to a `CHECK-NEXT: store 
> x86_fp80 0xK3FFF8000, x86_fp80* %a`
That doesn't work as that store x86_64 (the original store) is not NEXT. I just 
want to make sure that we have one shadow store, which was where the COUNT-1 
came from. I've change that to a regular CHECK and added a CHECK-NOT store i64 
before and after that sequence. Ditto elsewhere.




Comment at: 
llvm/test/Instrumentation/HeapProfiling/instrumentation-use-callbacks.ll:16
+; CHECK-CALL-COUNT-4: call void @__heapprof_load
+; CHECK-CALL-NOT: call void @__heapprof_load
+; CHECK-CUSTOM-PREFIX-COUNT-4: call void @__foo_load

MaskRay wrote:
> With appropriate `-NEXT:` patterns, `-NOT` is not really needed.
> 
> It is also important to test the argument passed to `__heapprof_load`
The -NOT is needed to ensure there are no additional calls, without matching 
the full IR. I've expanded the testing to test the arguments though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85948

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


[PATCH] D86369: [Sema][MSVC] warn at dynamic_cast when /GR- is given

2020-08-26 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu updated this revision to Diff 287835.
zequanwu added a comment.

address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86369

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/SemaCXX/ms_no_dynamic_cast.cpp
  clang/test/SemaCXX/no_dynamic_cast.cpp

Index: clang/test/SemaCXX/no_dynamic_cast.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/no_dynamic_cast.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 %s -fno-rtti-data -fsyntax-only -verify
+
+namespace std {
+struct type_info {};
+} // namespace std
+class B {
+public:
+  virtual ~B() = default;
+};
+
+class D1 : public B {
+public:
+  ~D1() = default;
+};
+
+void f() {
+  B *b = new D1();
+  auto d = dynamic_cast(b); // expected-warning{{dynamic_cast will not work since RTTI data is disabled by -fno-rtti-data}}
+  (void)typeid(int);  // expected-warning{{typeid will not work since RTTI data is disabled by -fno-rtti-data}}
+}
\ No newline at end of file
Index: clang/test/SemaCXX/ms_no_dynamic_cast.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/ms_no_dynamic_cast.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cl %s /GR- -fsyntax-only 2>&1 | FileCheck %s
+
+namespace std {
+struct type_info {};
+} // namespace std
+class B {
+public:
+  virtual ~B() = default;
+};
+
+class D1 : public B {
+public:
+  ~D1() = default;
+};
+
+void f() {
+  B *b = new D1();
+  auto d = dynamic_cast(b); // CHECK: warning: dynamic_cast will not work since RTTI data is disabled by /GR-
+  (void)typeid(int);  // CHECK: warning: typeid will not work since RTTI data is disabled by /GR-
+}
\ No newline at end of file
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -646,6 +646,13 @@
 return ExprError(Diag(OpLoc, diag::err_no_typeid_with_fno_rtti));
   }
 
+  // Warns when typeid is used with RTTI disabled.
+  if (!getLangOpts().RTTIData &&
+  !getDiagnostics().isIgnored(diag::warn_no_typeid_with_RTTI_disabled,
+  OpLoc))
+Diag(OpLoc, diag::warn_no_typeid_with_RTTI_disabled)
+<< getLangOpts().MSVCCompat;
+
   QualType TypeInfoType = Context.getTypeDeclType(CXXTypeInfoDecl);
 
   if (isType) {
Index: clang/lib/Sema/SemaCast.cpp
===
--- clang/lib/Sema/SemaCast.cpp
+++ clang/lib/Sema/SemaCast.cpp
@@ -890,6 +890,16 @@
 return;
   }
 
+  // Warns when dynamic_cast is used with RTTI disabled.
+  if (!Self.getLangOpts().RTTIData &&
+  !Self.getDiagnostics().isIgnored(diag::warn_no_typeid_with_RTTI_disabled,
+   OpRange.getBegin())) {
+if (Self.getLangOpts().MSVCCompat || !DestPointee->isVoidType())
+  Self.Diag(OpRange.getBegin(),
+diag::warn_no_dynamic_cast_with_RTTI_disabled)
+  << Self.getLangOpts().MSVCCompat;
+  }
+
   // Done. Everything else is run-time checks.
   Kind = CK_Dynamic;
 }
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -7433,6 +7433,12 @@
   "use of typeid requires -frtti">;
 def err_no_dynamic_cast_with_fno_rtti : Error<
   "use of dynamic_cast requires -frtti">;
+def warn_no_dynamic_cast_with_RTTI_disabled: Warning<
+  "dynamic_cast will not work since RTTI data is disabled by " 
+  "%select{-fno-rtti-data|/GR-}0">, InGroup;
+def warn_no_typeid_with_RTTI_disabled: Warning<
+  "typeid will not work since RTTI data is disabled by "
+  "%select{-fno-rtti-data|/GR-}0">, InGroup;
 
 def err_cannot_form_pointer_to_member_of_reference_type : Error<
   "cannot form a pointer-to-member to member %0 of reference type %1">;
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -1229,3 +1229,5 @@
 }
 
 def WebAssemblyExceptionSpec : DiagGroup<"wasm-exception-spec">;
+
+def RTTI : DiagGroup<"rtti">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 20676ca - [analyzer] Add modeling of assignment operator in smart ptr

2020-08-26 Thread Nithin Vadukkumchery Rajendrakumar via cfe-commits

Author: Nithin Vadukkumchery Rajendrakumar
Date: 2020-08-26T11:22:55+02:00
New Revision: 20676cab1168c2c60982af85f42725955cbcd7b5

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

LOG: [analyzer] Add modeling of assignment operator in smart ptr

Summary: Support for 'std::unique_ptr>::operator=' in SmartPtrModeling

Reviewers: NoQ, Szelethus, vsavchenko, xazax.hun

Reviewed By: NoQ, vsavchenko, xazax.hun

Subscribers: martong, cfe-commits
Tags: #clang

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
clang/test/Analysis/Inputs/system-header-simulator-cxx.h
clang/test/Analysis/smart-ptr-text-output.cpp
clang/test/Analysis/smart-ptr.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp 
b/clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
index 0b084accbfbe..c405ef12433a 100644
--- a/clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
@@ -37,7 +37,7 @@ namespace {
 class SmartPtrModeling
 : public Checker {
 
-  bool isNullAfterMoveMethod(const CallEvent ) const;
+  bool isAssignOpMethod(const CallEvent ) const;
 
 public:
   // Whether the checker should model for null dereferences of smart pointers.
@@ -57,6 +57,7 @@ class SmartPtrModeling
   void handleRelease(const CallEvent , CheckerContext ) const;
   void handleSwap(const CallEvent , CheckerContext ) const;
   void handleGet(const CallEvent , CheckerContext ) const;
+  bool handleAssignOp(const CallEvent , CheckerContext ) const;
 
   using SmartPtrMethodHandlerFn =
   void (SmartPtrModeling::*)(const CallEvent , CheckerContext &) 
const;
@@ -123,7 +124,7 @@ static ProgramStateRef updateSwappedRegion(ProgramStateRef 
State,
   return State;
 }
 
-bool SmartPtrModeling::isNullAfterMoveMethod(const CallEvent ) const {
+bool SmartPtrModeling::isAssignOpMethod(const CallEvent ) const {
   // TODO: Update CallDescription to support anonymous calls?
   // TODO: Handle other methods, such as .get() or .release().
   // But once we do, we'd need a visitor to explain null dereferences
@@ -134,12 +135,11 @@ bool SmartPtrModeling::isNullAfterMoveMethod(const 
CallEvent ) const {
 
 bool SmartPtrModeling::evalCall(const CallEvent ,
 CheckerContext ) const {
-
   ProgramStateRef State = C.getState();
   if (!smartptr::isStdSmartPtrCall(Call))
 return false;
 
-  if (isNullAfterMoveMethod(Call)) {
+  if (isAssignOpMethod(Call)) {
 const MemRegion *ThisR =
 cast()->getCXXThisVal().getAsRegion();
 
@@ -206,6 +206,9 @@ bool SmartPtrModeling::evalCall(const CallEvent ,
 return true;
   }
 
+  if (handleAssignOp(Call, C))
+return true;
+
   const SmartPtrMethodHandlerFn *Handler = SmartPtrMethodHandlers.lookup(Call);
   if (!Handler)
 return false;
@@ -374,6 +377,87 @@ void SmartPtrModeling::handleGet(const CallEvent ,
   C.addTransition(State);
 }
 
+bool SmartPtrModeling::handleAssignOp(const CallEvent ,
+  CheckerContext ) const {
+  ProgramStateRef State = C.getState();
+  const auto *OC = dyn_cast();
+  if (!OC)
+return false;
+  OverloadedOperatorKind OOK = OC->getOverloadedOperator();
+  if (OOK != OO_Equal)
+return false;
+  const MemRegion *ThisRegion = OC->getCXXThisVal().getAsRegion();
+  if (!ThisRegion)
+return false;
+
+  const MemRegion *OtherSmartPtrRegion = OC->getArgSVal(0).getAsRegion();
+  // In case of 'nullptr' or '0' assigned
+  if (!OtherSmartPtrRegion) {
+bool AssignedNull = Call.getArgSVal(0).isZeroConstant();
+if (!AssignedNull)
+  return false;
+auto NullVal = C.getSValBuilder().makeNull();
+State = State->set(ThisRegion, NullVal);
+C.addTransition(State, C.getNoteTag([ThisRegion](PathSensitiveBugReport 
,
+ llvm::raw_ostream ) {
+  if (() != smartptr::getNullDereferenceBugType() ||
+  !BR.isInteresting(ThisRegion))
+return;
+  OS << "Smart pointer ";
+  ThisRegion->printPretty(OS);
+  OS << " is assigned to null";
+}));
+return true;
+  }
+
+  const auto *OtherInnerPtr = 
State->get(OtherSmartPtrRegion);
+  if (OtherInnerPtr) {
+State = State->set(ThisRegion, *OtherInnerPtr);
+auto NullVal = C.getSValBuilder().makeNull();
+State = State->set(OtherSmartPtrRegion, NullVal);
+bool IsArgValNull = OtherInnerPtr->isZeroConstant();
+
+C.addTransition(
+State,
+C.getNoteTag([ThisRegion, OtherSmartPtrRegion, IsArgValNull](
+ PathSensitiveBugReport , llvm::raw_ostream ) {
+  if (() != smartptr::getNullDereferenceBugType())
+   

[PATCH] D86293: [analyzer] Add modeling of Eq operator in smart ptr

2020-08-26 Thread Nithin VR via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG20676cab1168: [analyzer] Add modeling of assignment operator 
in smart ptr (authored by vrnithinkumar).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86293

Files:
  clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
  clang/test/Analysis/Inputs/system-header-simulator-cxx.h
  clang/test/Analysis/smart-ptr-text-output.cpp
  clang/test/Analysis/smart-ptr.cpp

Index: clang/test/Analysis/smart-ptr.cpp
===
--- clang/test/Analysis/smart-ptr.cpp
+++ clang/test/Analysis/smart-ptr.cpp
@@ -216,8 +216,7 @@
 std::unique_ptr P;
 std::unique_ptr Q;
 Q = std::move(P);
-// TODO: Fix test with expecting warning after '=' operator overloading modeling.
-Q->foo(); // no-warning
+Q->foo(); // expected-warning {{Dereference of null smart pointer 'Q' [alpha.cplusplus.SmartPtr]}}
   }
 }
 
@@ -276,3 +275,61 @@
 Y->foo(); // expected-warning {{Called C++ object pointer is null [core.CallAndMessage]}}
   }
 }
+
+void derefOnMovedFromValidPtr() {
+  std::unique_ptr PToMove(new A());
+  std::unique_ptr P;
+  P = std::move(PToMove);
+  PToMove->foo(); // expected-warning {{Dereference of null smart pointer 'PToMove' [alpha.cplusplus.SmartPtr]}}
+}
+
+void derefOnMovedToNullPtr() {
+  std::unique_ptr PToMove(new A());
+  std::unique_ptr P;
+  P = std::move(PToMove); // No note.
+  P->foo(); // No warning.
+}
+
+void derefOnNullPtrGotMovedFromValidPtr() {
+  std::unique_ptr P(new A());
+  std::unique_ptr PToMove;
+  P = std::move(PToMove);
+  P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
+}
+
+void derefOnMovedFromUnknownPtr(std::unique_ptr PToMove) {
+  std::unique_ptr P;
+  P = std::move(PToMove);
+  P->foo(); // No warning.
+}
+
+void derefOnMovedUnknownPtr(std::unique_ptr PToMove) {
+  std::unique_ptr P;
+  P = std::move(PToMove);
+  PToMove->foo(); // expected-warning {{Dereference of null smart pointer 'PToMove' [alpha.cplusplus.SmartPtr]}}
+}
+
+void derefOnAssignedNullPtrToNullSmartPtr() {
+  std::unique_ptr P;
+  P = nullptr;
+  P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
+}
+
+void derefOnAssignedZeroToNullSmartPtr() {
+  std::unique_ptr P(new A());
+  P = 0;
+  P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
+}
+
+void derefOnAssignedNullToUnknowSmartPtr(std::unique_ptr P) {
+  P = nullptr;
+  P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
+}
+
+std::unique_ptr &();
+
+void drefOnAssignedNullFromMethodPtrValidSmartPtr() {
+  std::unique_ptr P(new A());
+  P = returnRValRefOfUniquePtr();
+  P->foo(); // No warning. 
+}
Index: clang/test/Analysis/smart-ptr-text-output.cpp
===
--- clang/test/Analysis/smart-ptr-text-output.cpp
+++ clang/test/Analysis/smart-ptr-text-output.cpp
@@ -80,7 +80,7 @@
 void derefOnStdSwappedNullPtr() {
   std::unique_ptr P; // expected-note {{Default constructed smart pointer 'P' is null}}
   std::unique_ptr PNull; // expected-note {{Default constructed smart pointer 'PNull' is null}}
-  std::swap(P, PNull); // expected-note@Inputs/system-header-simulator-cxx.h:978 {{Swapped null smart pointer 'PNull' with smart pointer 'P'}}
+  std::swap(P, PNull); // expected-note@Inputs/system-header-simulator-cxx.h:979 {{Swapped null smart pointer 'PNull' with smart pointer 'P'}}
   // expected-note@-1 {{Calling 'swap'}}
   // expected-note@-2 {{Returning from 'swap'}}
   P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
@@ -109,14 +109,6 @@
   // expected-note@-1{{Dereference of null smart pointer 'P'}}
 }
 
-void noNoteTagsForNonMatchingBugType() {
-  std::unique_ptr P; // No note.
-  std::unique_ptr P1; // No note.
-  P1 = std::move(P); // expected-note {{Smart pointer 'P' of type 'std::unique_ptr' is reset to null when moved from}}
-  P->foo(); // expected-warning {{Dereference of null smart pointer 'P' of type 'std::unique_ptr' [cplusplus.Move]}}
-  // expected-note@-1 {{Dereference of null smart pointer 'P' of type 'std::unique_ptr'}}
-}
-
 void derefOnRawPtrFromGetOnNullPtr() {
   std::unique_ptr P; // FIXME: add note "Default constructed smart pointer 'P' is null"
   P.get()->foo(); // expected-warning {{Called C++ object pointer is null [core.CallAndMessage]}}
@@ -131,3 +123,50 @@
 void derefOnRawPtrFromGetOnUnknownPtr(std::unique_ptr P) {
   P.get()->foo(); // No warning.
 }
+
+void derefOnMovedFromValidPtr() {
+  std::unique_ptr PToMove(new A());  // expected-note {{Smart pointer 'PToMove' is constructed}}
+  // FIXME: above note should go away once we fix marking region not interested. 
+  std::unique_ptr P;
+  P = 

[PATCH] D81254: [analyzer] Produce symbolic values for C-array elements

2020-08-26 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

In D81254#2218196 , @ASDenysPetrov 
wrote:

>> We know where it points to (aka. the pointer's value is conjured), but we 
>> don't know what the value if there.
>
> Absolutely right. I looked at this patch after a while and don't currently 
> see a proper solution.
>
>> I feel like this problem should be handled by some sort of invalidation 
>> mechanism.
>
> Definitely it should be some criteria/mark/flag about the region 
> invalidation. Maybe someone more confident could prompt us how to.

How about using the mistical `SymbolDerived`?
The clang-analyzer-guide 

 says:

> Another atomic symbol, closely related to SymbolRegionValue, is 
> **SymbolDerived**. **It represents a value of a region after another symbol 
> was written into a direct or indirect super-region.** SymbolDerived contains 
> a reference to both the parent symbol and the parent region. This symbol is 
> mostly a technical hack. Usually SymbolDerived appears after invalidation: 
> the whole structure of a certain type gets smashed with a single 
> SymbolConjured, and then values of its fields become represented with the 
> help of SymbolDerived of that conjured symbol and the region of the field. In 
> any case, SymbolDerived is similar to SymbolRegionValue, just refers to a 
> value after a certain event during analysis rather than at start of analysis.

Could we use that here @NoQ?

---

In D81254#2218613 , @ASDenysPetrov 
wrote:

> Should this revision be //closed //or //rejected //somehow?

I'm not sure about that.
I think it still has some value. Especially these two test-cases:

  int index_sym(const int *a, int index) {
int var;
int ret = 0;
if (a[index] < 2)
  var = 1;
  
// Since we did not write through a pointer, we can be sure that the values 
bound to 'a' are still valid.
// (We should also take strict-aliasing into account if 
-fno-strict-aliasing is not enabled.)
//
// We should take this branch if it was taken previously.
if (a[index] < 2) {
  // FIXME: We should not warn here.
  ret = var; // expected-warning{{Assigned value is garbage or undefined 
[core.uninitialized.Assign]}}
}
return ret;
  }
  
  int index_sym_invalidated(const int *a, int index, int index2) {
int var;
int ret = 0;
if (a[index] < 2)
  var = 1;
  
a[index2] = 42; // Store a value to //somewhere// in 'a'.
// A store happens through a pointer which //may// alias with the region 
'a'.
// So this store might overwrite the value of 'a[index]'
// Thus, we should invalidate all the bindings to the region 'a'.
// Except the binding to 'a[index2]' which is known to be 42.
if (a[index] < 2) {
  // This warning is reasonable.
  ret = var; // expected-warning{{Assigned value is garbage or undefined 
[core.uninitialized.Assign]}}
}
return ret;
  }


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

https://reviews.llvm.org/D81254

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


[PATCH] D86600: [SyntaxTree] Migrate `ParamatersAndQualifiers` to use the new List API

2020-08-26 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas updated this revision to Diff 287889.
eduucaldas added a comment.

nits


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86600

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Nodes.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
@@ -85,15 +85,16 @@
   | |-'foo'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'a'
-  |   |-','
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'b'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | |-SimpleDeclaration List_element
+  |   | | |-'int'
+  |   | | `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | |   `-'a'
+  |   | |-',' List_delimiter
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'int'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | `-'b'
   |   `-')' CloseParen
   `-CompoundStatement
 |-'{' OpenParen
@@ -3162,8 +3163,9 @@
   | |-'_c'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | `-'char'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | `-SimpleDeclaration List_element
+  |   |   `-'char'
   |   `-')' CloseParen
   `-';'
 )txt"));
@@ -3219,11 +3221,12 @@
 | |-'='
 | `-ParametersAndQualifiers
 |   |-'(' OpenParen
-|   |-SimpleDeclaration ParametersAndQualifiers_parameter
-|   | |-'const'
-|   | |-'X'
-|   | `-SimpleDeclarator SimpleDeclaration_declarator
-|   |   `-'&'
+|   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+|   | `-SimpleDeclaration List_element
+|   |   |-'const'
+|   |   |-'X'
+|   |   `-SimpleDeclarator SimpleDeclaration_declarator
+|   | `-'&'
 |   `-')' CloseParen
 `-';'
 )txt"}));
@@ -3249,14 +3252,15 @@
   | |-'+'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | `-'X'
-  |   |-','
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'const'
-  |   | |-'X'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'&'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | |-SimpleDeclaration List_element
+  |   | | `-'X'
+  |   | |-',' List_delimiter
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'const'
+  |   |   |-'X'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | `-'&'
   |   `-')' CloseParen
   `-';'
 )txt"}));
@@ -3885,16 +3889,17 @@
   | |-'f'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   |-'xs'
-  |   |   `-ArraySubscript
-  |   | |-'[' OpenParen
-  |   | |-'static'
-  |   | |-IntegerLiteralExpression ArraySubscript_sizeExpression
-  |   | | `-'10' LiteralToken
-  |   | `-']' CloseParen
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'int'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | |-'xs'
+  |   | `-ArraySubscript
+  |   |   |-'[' OpenParen
+  |   |   |-'static'
+  |   |   |-IntegerLiteralExpression ArraySubscript_sizeExpression
+  |   |   | `-'10' LiteralToken
+  |   |   `-']' CloseParen
   |   `-')' CloseParen
   `-';'
 )txt"));
@@ -3933,10 +3938,11 @@
 | | |-'func1'
 | | `-ParametersAndQualifiers
 | |   |-'(' OpenParen
-| |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-| |   | |-'int'
-| |   | `-SimpleDeclarator SimpleDeclaration_declarator
-| |   |   `-'a'
+| |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+| |   | `-SimpleDeclaration List_element
+| |   |   |-'int'
+| |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+| |   | `-'a'
 | |   `-')' CloseParen
 | `-';'
 |-SimpleDeclaration
@@ -3945,11 +3951,12 @@
 | | |-'func2'
 | | `-ParametersAndQualifiers
 | |   |-'(' OpenParen
-| |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-| |   | |-'int'
-| |   | `-SimpleDeclarator SimpleDeclaration_declarator
-| |   |   |-'*'
-| |   |   `-'ap'
+| |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+| |   | `-SimpleDeclaration List_element
+| |   |   |-'int'
+| |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+| |   | |-'*'
+| |   | `-'ap'
 | |   `-')' CloseParen
 | `-';'
 

[PATCH] D77062: [analyzer] Improve zero assumption in CStringChecke::assumeZero

2020-08-26 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.

One more ping


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

https://reviews.llvm.org/D77062

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


[PATCH] D86531: [analyzer][StdLibraryFunctionsChecker][NFC] Use Optionals throughout the summary API

2020-08-26 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:851
+  } getPointerTy(ACtx);
+  class {
+  public:

Why has this class different layout than `GetPointerTy` and `GetRestrictTy` 
(beneath that here is no `ASTContext`)? It would be better if all these classes 
look the same way: First is the operator with `QualType`, then operator with 
`Optional` that calls the other version of the operator. And all of these can 
be "unnamed" classes?



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:890
 
-  const QualType VoidPtrTy = ACtx.VoidPtrTy; // void *
-  const QualType IntPtrTy = ACtx.getPointerType(IntTy); // int *
+  const QualType VoidPtrTy = getPointerTy(VoidTy); // void *
+  const QualType IntPtrTy = getPointerTy(IntTy);   // int *

Is it better to use `ACtx.VoidPtrTy`? 



Comment at: 
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:1321
 
-Optional Mode_tTy = lookupType("mode_t", ACtx);
+Optional Mode_tTy = lookupTy("mode_t");
 

It is better to get every type at the start before adding functions, or group 
the functions and get some types at the start of these groups but mark the 
groups at least with comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86531

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


[PATCH] D86465: [analyzer][solver] Redesign constraint ranges data structure

2020-08-26 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added a comment.

Here are some benchmarking results. 
In docker:
F12777445: tiny.png 
F12777444: small.png 
Natively on my Mac (no memory measurements due to this issue 
 during `psutil` installation):
F12777471: tiny-native.png 
F12777472: small-native.png 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86465

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


[PATCH] D86445: [analyzer][RFC] Simplify MetadataSymbol representation and resolve a CStringChecker FIXME

2020-08-26 Thread Balázs Benics via Phabricator via cfe-commits
steakhal marked an inline comment as done.
steakhal added inline comments.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h:441
+  const SymbolMetadata *getMetadataSymbol(const MemRegion *R, QualType T,
   const void *SymbolTag = nullptr);
 

NoQ wrote:
> steakhal wrote:
> > Why do we even need the tag?
> > Why is it defaulted to `nullptr` if it asserts later that the `tag` must 
> > not be `null`.
> > I'm confused, somebody help me out :D
> The tag is necessary so that different checkers could attach different 
> metadata to the same region (possibly even of the same type). A null value 
> indeed makes no sense here.
Thanks.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h:516-522
   /// Unconditionally marks a symbol as live.
   ///
   /// This should never be
   /// used by checkers, only by the state infrastructure such as the store and
   /// environment. Checkers should instead use metadata symbols and markInUse.
+  /// TODO: update this comment!!!
   void markLive(SymbolRef sym);

NoQ wrote:
> steakhal wrote:
> > Is it true for modeling checkers too?
> This comment is much older than the concept of a "modeling checker" and it 
> has never been true. Checkers need to mark things live. It's part of life! 
> (no pun intended) Like, i agree that non-modeling checkers probably don't 
> need to use this method, but that wasn't what the author was trying to say :) 
> And also there's nothing special about `SymbolMetadata`; any data that the 
> checker helps keep track of may need to be marked live by the checker, so 
> `markInUse()` is insufficient.
Ok, I will rephrase the comment expressing that this should be used only in 
modeling checkers.



Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:2417
 
 void CStringChecker::checkDeadSymbols(SymbolReaper ,
 CheckerContext ) const {

NoQ wrote:
> martong wrote:
> > Seems like `checkDeadSymbols` could have a generic implementation. Perhaps 
> > in the following form:
> > ```
> > class CStringChecker : public Checker<
> >  check::DeadSymbols
> > ```
> > But this should be done in a separate patch.
> > 
> > Maybe it would make sense to have a generic default 
> > check::LiveSymbols implementation as well. In that 
> > implementation we could iterate over the GDM entries and could mark the 
> > dependent (sub)symbols live.
> > 
> > (Note, this is a reminder from our verbal discussion with @steakhal.)
> Nope, there can't be a generic implementation. It depends a lot on the data 
> structure tracked by the checker (the checker's technically allowed to track 
> "a map from regions to maps from lists of expressions to sets of SVals", good 
> luck coming up with a generic `checkLiveSymbols()` for that) and it most 
> likely isn't uniquely determined by the data structure either.
> 
> But what we can do is provide half-baked implementations for the common 
> situations such as "a map from regions to symbols" (eg. this checker, smart 
> pointer checker) or "a map from symbols to an enum of states the object 
> associated with the symbol is in" (malloc checker, stream checker). And even 
> better, we could provide half-baked implementations of entire state traits, 
> not just `checkDeadSymbols`
> /`checkLiveSymbols()`.
I think we can postprone the experiments with the generic 
`checkDeadSymbols`/`checkLiveSymbols` implementations.
This patch does not aim to solve that.



Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:2429
 if (SymbolRef Sym = Len.getAsSymbol()) {
   if (SR.isDead(Sym))
+Entries = F.remove(Entries, MR);

NoQ wrote:
> Ok, this doesn't look correct (looks like it never was). It's liveness of the 
> region that's important to us, not liveness of the symbol. Because it's the 
> liveness of the region that causes the program to be able to access the map 
> entry.
Let's say we have this:
```lang=C++
void foo() {
  char *p = malloc(12);
  // strlen(p); // no-leak if strlen called, leak warning otherwise...
} // expected-warning {{leak}}
```
If we were marking the region live here, we would miss the `leak` warning. That 
warning is only triggered if the region of the `p` becomes dead. Which will 
never become dead if we have a cstring length symbol associated to that region.
I came to this conclusion after implementing your suggested edit above 
(checking regions instead of symbols).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86445

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


[PATCH] D86597: [Tooling][Format] Treat compound extensions (foo.bar.cc) as matching foo.h

2020-08-26 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added reviewers: krasimir, MyDeveloperDay.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
sammccall requested review of this revision.

Motivating use case is ".cu.cc" extensions used in some bazel projects.

Alternative is to work around this with IncludeIsMainRegex in styles.
I proposed this approach because it seems like a better default.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86597

Files:
  clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
  clang/unittests/Tooling/HeaderIncludesTest.cpp


Index: clang/unittests/Tooling/HeaderIncludesTest.cpp
===
--- clang/unittests/Tooling/HeaderIncludesTest.cpp
+++ clang/unittests/Tooling/HeaderIncludesTest.cpp
@@ -40,7 +40,7 @@
 return *Result;
   }
 
-  const std::string FileName = "fix.cpp";
+  std::string FileName = "fix.cpp";
   IncludeStyle Style = format::getLLVMStyle().IncludeStyle;
 };
 
@@ -102,6 +102,15 @@
   Style = format::getGoogleStyle(format::FormatStyle::LanguageKind::LK_Cpp)
   .IncludeStyle;
   EXPECT_EQ(Expected, insert(Code, ""));
+
+  FileName = "fix.cu.cpp";
+  EXPECT_EQ(Expected, insert(Code, ""));
+
+  FileName = "fix_test.cu.cpp";
+  EXPECT_EQ(Expected, insert(Code, ""));
+
+  FileName = "bar.cpp";
+  EXPECT_NE(Expected, insert(Code, "")) << "Not main header";
 }
 
 TEST_F(HeaderIncludesTest, InsertBeforeSystemHeaderLLVM) {
Index: clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
===
--- clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
+++ clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
@@ -12,6 +12,7 @@
 #include "clang/Lex/Lexer.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/Path.h"
 
 namespace clang {
 namespace tooling {
@@ -174,12 +175,22 @@
 const char IncludeRegexPattern[] =
 R"(^[\t\ ]*#[\t\ ]*(import|include)[^"<]*(["<][^">]*[">]))";
 
+// The filename of Path excluding extension.
+// Used to match implementation with headers, this differs from 
sys::path::stem:
+//  - in names with multiple dots (foo.cu.cc) it terminates at the *first*
+//  - an empty stem is never returned: /foo/.bar.x => .bar
+//  - we don't bother to handle . and .. specially
+StringRef matchingStem(llvm::StringRef Path) {
+  StringRef Name = llvm::sys::path::filename(Path);
+  return Name.substr(0, Name.find('.', 1));
+}
+
 } // anonymous namespace
 
 IncludeCategoryManager::IncludeCategoryManager(const IncludeStyle ,
StringRef FileName)
 : Style(Style), FileName(FileName) {
-  FileStem = llvm::sys::path::stem(FileName);
+  FileStem = matchingStem(FileName);
   for (const auto  : Style.IncludeCategories)
 CategoryRegexs.emplace_back(Category.Regex, llvm::Regex::IgnoreCase);
   IsMainFile = FileName.endswith(".c") || FileName.endswith(".cc") ||
@@ -222,8 +233,7 @@
 bool IncludeCategoryManager::isMainHeader(StringRef IncludeName) const {
   if (!IncludeName.startswith("\""))
 return false;
-  StringRef HeaderStem =
-  llvm::sys::path::stem(IncludeName.drop_front(1).drop_back(1));
+  StringRef HeaderStem = matchingStem(IncludeName.drop_front(1).drop_back(1));
   if (FileStem.startswith(HeaderStem) ||
   FileStem.startswith_lower(HeaderStem)) {
 llvm::Regex MainIncludeRegex(HeaderStem.str() + Style.IncludeIsMainRegex,


Index: clang/unittests/Tooling/HeaderIncludesTest.cpp
===
--- clang/unittests/Tooling/HeaderIncludesTest.cpp
+++ clang/unittests/Tooling/HeaderIncludesTest.cpp
@@ -40,7 +40,7 @@
 return *Result;
   }
 
-  const std::string FileName = "fix.cpp";
+  std::string FileName = "fix.cpp";
   IncludeStyle Style = format::getLLVMStyle().IncludeStyle;
 };
 
@@ -102,6 +102,15 @@
   Style = format::getGoogleStyle(format::FormatStyle::LanguageKind::LK_Cpp)
   .IncludeStyle;
   EXPECT_EQ(Expected, insert(Code, ""));
+
+  FileName = "fix.cu.cpp";
+  EXPECT_EQ(Expected, insert(Code, ""));
+
+  FileName = "fix_test.cu.cpp";
+  EXPECT_EQ(Expected, insert(Code, ""));
+
+  FileName = "bar.cpp";
+  EXPECT_NE(Expected, insert(Code, "")) << "Not main header";
 }
 
 TEST_F(HeaderIncludesTest, InsertBeforeSystemHeaderLLVM) {
Index: clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
===
--- clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
+++ clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
@@ -12,6 +12,7 @@
 #include "clang/Lex/Lexer.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/Path.h"
 
 namespace clang {
 namespace tooling {
@@ -174,12 +175,22 @@
 const char IncludeRegexPattern[] =
 R"(^[\t\ ]*#[\t\ ]*(import|include)[^"<]*(["<][^">]*[">]))";
 
+// The filename of Path excluding extension.
+// Used to match 

[PATCH] D86465: [analyzer][solver] Redesign constraint ranges data structure

2020-08-26 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added inline comments.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:110
+  iterator end() const { return Impl->end(); }
+  size_t size() const { return Impl->size(); }
+

steakhal wrote:
> I think it should be `std::size_t`.
Yeah, I didn't see a unified stand of the community on this matter.  It looks 
like both options are pretty widespread.  I mimicked `SmallVector.h`, but I can 
easily change it.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:118-123
+/// Create a new set with all ranges from both LHS and RHS.
+/// Possible intersections are not checked here.
+///
+/// Complexity: O(N + M)
+/// where N = size(LHS), M = size(RHS)
+RangeSet add(RangeSet LHS, RangeSet RHS);

steakhal wrote:
> What about `merge` or `combine`? I know that `union` is a keyword thus we can 
> not use.
Maybe, but the real `union` function is not present.  And I think that in the 
original code it is `add` to hint that it's not really a union and nothing 
complex is done here.  Maybe something like `mergeUnchecked` would work.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:149-160
+/// Intersect the given set with the closed range [Lower, Upper].
+///
+/// Unlike the Range type, this range uses modular arithmetic, 
corresponding
+/// to the common treatment of C integer overflow. Thus, if the Lower bound
+/// is greater than the Upper bound, the range is taken to wrap around. 
This
+/// is equivalent to taking the intersection with the two ranges [Min,
+/// Upper] and [Lower, Max], or, alternatively, /removing/ all integers

steakhal wrote:
> I think an example would be awesome here.
Agree, I simply copy-pasted the comment, but it would be better to expand it a 
bit because it might be confusing.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:170-174
+/// Delete the given point from the range set.
+///
+/// Complexity: O(N)
+/// where N = size(From)
+RangeSet deletePoint(const llvm::APSInt , RangeSet From);

steakhal wrote:
> Why does this operation take `O(N)` time? Shouldn't be `O(logN)` instead?
We still create a copy of an old vector to maintain persistence, that's why 
it's `O(N)`.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:190-193
+/// And it makes us to separate the range
+/// like [MIN, N] to [MIN, MIN] U [-N, MAX].
+/// For instance, whole range is {-128..127} and subrange is [-128,-126],
+/// thus [-128,-127,-126,...] negates to [-128,...,126,127].

steakhal wrote:
> 
The same thing with this comment, I think I'll rework it even more



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:195-196
+///
+/// Negate restores disrupted ranges on bounds,
+/// e.g. [MIN, B] => [MIN, MIN] U [-B, MAX] => [MIN, B].
+///

steakhal wrote:
> 
+1



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:203
+  private:
+RangeSet makePersistent(ContainerType &);
+ContainerType *construct(ContainerType &);

steakhal wrote:
> As commented later, this function worth to be documented.
I didn't think that it's necessary because of the fact that it's `private`, but 
it's pretty important, so I'll do it.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:207-208
+
+RangeSet intersect(const RangeSet::ContainerType ,
+   const RangeSet::ContainerType );
+

steakhal wrote:
> Why do we need to explicitly spell the  `RangeSet` here?
Good point!



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:210-211
+
+// Many operations inlcude producing new APSInt values and that's why
+// we need this factory.
+BasicValueFactory 

steakhal wrote:
> 
+1



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:213-215
+// Allocator for all the created containers.
+// Containers might own their own memory and that's why it is specific
+// for the type, so it calls containter destructors upon deletion.

steakhal wrote:
> 
+1



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:225-228
+  RangeSet(const RangeSet &) = default;
+  RangeSet =(const RangeSet &) = default;
+  RangeSet(RangeSet &&) = default;
+  RangeSet =(RangeSet &&) = default;

[PATCH] D85635: [clangd] Compute the inactive code range for semantic highlighting.

2020-08-26 Thread Haojian Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0aaa2acc4ca0: [clangd] Compute the inactive code range for 
semantic highlighting. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85635

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -503,11 +503,11 @@
 
   #define $Macro[[test]]
   #undef $Macro[[test]]
-$InactiveCode[[]]  #ifdef $Macro[[test]]
-$InactiveCode[[]]  #endif
+$InactiveCode[[#ifdef test]]
+$InactiveCode[[#endif]]
 
-$InactiveCode[[]]  #if defined($Macro[[test]])
-$InactiveCode[[]]  #endif
+$InactiveCode[[#if defined(test)]]
+$InactiveCode[[#endif]]
 )cpp",
   R"cpp(
   struct $Class[[S]] {
@@ -614,8 +614,8 @@
   R"cpp(
   // Code in the preamble.
   // Inactive lines get an empty InactiveCode token at the beginning.
-$InactiveCode[[]]  #ifdef $Macro[[test]]
-$InactiveCode[[]]  #endif
+$InactiveCode[[#ifdef test]]
+$InactiveCode[[#endif]]
 
   // A declaration to cause the preamble to end.
   int $Variable[[EndPreamble]];
@@ -623,17 +623,17 @@
   // Code after the preamble.
   // Code inside inactive blocks does not get regular highlightings
   // because it's not part of the AST.
-$InactiveCode[[]]  #ifdef $Macro[[test]]
-$InactiveCode[[]]  int Inactive2;
-$InactiveCode[[]]  #endif
+$InactiveCode[[#ifdef test]]
+$InactiveCode[[int Inactive2;]]
+$InactiveCode[[#endif]]
 
   #ifndef $Macro[[test]]
   int $Variable[[Active1]];
   #endif
 
-$InactiveCode[[]]  #ifdef $Macro[[test]]
-$InactiveCode[[]]  int Inactive3;
-$InactiveCode[[]]  #else
+$InactiveCode[[#ifdef test]]
+$InactiveCode[[int Inactive3;]]
+$InactiveCode[[#else]]
   int $Variable[[Active2]];
   #endif
 )cpp",
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -221,23 +221,51 @@
   // the end of the Tokens).
   TokRef = TokRef.drop_front(Conflicting.size());
 }
-// Add tokens indicating lines skipped by the preprocessor.
-for (const Range  : AST.getMacros().SkippedRanges) {
+const auto  = AST.getSourceManager();
+StringRef MainCode = SM.getBuffer(SM.getMainFileID())->getBuffer();
+
+// Merge token stream with "inactive line" markers.
+std::vector WithInactiveLines;
+auto SortedSkippedRanges = AST.getMacros().SkippedRanges;
+llvm::sort(SortedSkippedRanges);
+auto It = NonConflicting.begin();
+for (const Range  : SortedSkippedRanges) {
   // Create one token for each line in the skipped range, so it works
   // with line-based diffing.
   assert(R.start.line <= R.end.line);
   for (int Line = R.start.line; Line <= R.end.line; ++Line) {
-// Don't bother computing the offset for the end of the line, just use
-// zero. The client will treat this highlighting kind specially, and
-// highlight the entire line visually (i.e. not just to where the text
-// on the line ends, but to the end of the screen).
-NonConflicting.push_back({HighlightingKind::InactiveCode,
-  {Position{Line, 0}, Position{Line, 0}}});
+// Copy tokens before the inactive line
+for (; It != NonConflicting.end() && It->R.start.line < Line; ++It)
+  WithInactiveLines.push_back(std::move(*It));
+// Add a token for the inactive line itself.
+auto StartOfLine = positionToOffset(MainCode, Position{Line, 0});
+if (StartOfLine) {
+  StringRef LineText =
+  MainCode.drop_front(*StartOfLine).take_until([](char C) {
+return C == '\n';
+  });
+  WithInactiveLines.push_back(
+  {HighlightingKind::InactiveCode,
+   {Position{Line, 0},
+Position{Line, static_cast(lspLength(LineText))}}});
+} else {
+  elog("Failed to convert position to offset: {0}",
+   StartOfLine.takeError());
+}
+
+// Skip any other tokens on the inactive line. e.g.
+// `#ifndef Foo` is considered as part of an inactive region when Foo is
+// defined, and there is a Foo macro token.
+// FIXME: we should reduce the scope of the inactive region to not
+// include the directive itself.
+while (It != NonConflicting.end() && It->R.start.line == Line)
+   

[PATCH] D86600: [SyntaxTree] Migrate `ParamatersAndQualifiers` to use the new List API

2020-08-26 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
eduucaldas requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86600

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Nodes.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
@@ -85,15 +85,16 @@
   | |-'foo'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'a'
-  |   |-','
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'b'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | |-SimpleDeclaration List_element
+  |   | | |-'int'
+  |   | | `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | |   `-'a'
+  |   | |-',' List_delimiter
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'int'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | `-'b'
   |   `-')' CloseParen
   `-CompoundStatement
 |-'{' OpenParen
@@ -3162,8 +3163,9 @@
   | |-'_c'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | `-'char'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | `-SimpleDeclaration List_element
+  |   |   `-'char'
   |   `-')' CloseParen
   `-';'
 )txt"));
@@ -3219,11 +3221,12 @@
 | |-'='
 | `-ParametersAndQualifiers
 |   |-'(' OpenParen
-|   |-SimpleDeclaration ParametersAndQualifiers_parameter
-|   | |-'const'
-|   | |-'X'
-|   | `-SimpleDeclarator SimpleDeclaration_declarator
-|   |   `-'&'
+|   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+|   | `-SimpleDeclaration List_element
+|   |   |-'const'
+|   |   |-'X'
+|   |   `-SimpleDeclarator SimpleDeclaration_declarator
+|   | `-'&'
 |   `-')' CloseParen
 `-';'
 )txt"}));
@@ -3249,14 +3252,15 @@
   | |-'+'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | `-'X'
-  |   |-','
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'const'
-  |   | |-'X'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'&'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | |-SimpleDeclaration List_element
+  |   | | `-'X'
+  |   | |-',' List_delimiter
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'const'
+  |   |   |-'X'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | `-'&'
   |   `-')' CloseParen
   `-';'
 )txt"}));
@@ -3885,16 +3889,17 @@
   | |-'f'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   |-'xs'
-  |   |   `-ArraySubscript
-  |   | |-'[' OpenParen
-  |   | |-'static'
-  |   | |-IntegerLiteralExpression ArraySubscript_sizeExpression
-  |   | | `-'10' LiteralToken
-  |   | `-']' CloseParen
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'int'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | |-'xs'
+  |   | `-ArraySubscript
+  |   |   |-'[' OpenParen
+  |   |   |-'static'
+  |   |   |-IntegerLiteralExpression ArraySubscript_sizeExpression
+  |   |   | `-'10' LiteralToken
+  |   |   `-']' CloseParen
   |   `-')' CloseParen
   `-';'
 )txt"));
@@ -3933,10 +3938,11 @@
 | | |-'func1'
 | | `-ParametersAndQualifiers
 | |   |-'(' OpenParen
-| |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-| |   | |-'int'
-| |   | `-SimpleDeclarator SimpleDeclaration_declarator
-| |   |   `-'a'
+| |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+| |   | `-SimpleDeclaration List_element
+| |   |   |-'int'
+| |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+| |   | `-'a'
 | |   `-')' CloseParen
 | `-';'
 |-SimpleDeclaration
@@ -3945,11 +3951,12 @@
 | | |-'func2'
 | | `-ParametersAndQualifiers
 | |   |-'(' OpenParen
-| |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-| |   | |-'int'
-| |   | `-SimpleDeclarator SimpleDeclaration_declarator
-| |   |   |-'*'
-| |   |   `-'ap'
+| |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+| |   | `-SimpleDeclaration List_element
+| |   |   |-'int'
+| |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+| |   | |-'*'
+| |   | `-'ap'
 | |   `-')' CloseParen
 | `-';'

[clang-tools-extra] 0aaa2ac - [clangd] Compute the inactive code range for semantic highlighting.

2020-08-26 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2020-08-26T10:50:31+02:00
New Revision: 0aaa2acc4ca0389a79a46bca3dc5b9365c641d77

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

LOG: [clangd] Compute the inactive code range for semantic highlighting.

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

Added: 


Modified: 
clang-tools-extra/clangd/SemanticHighlighting.cpp
clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/SemanticHighlighting.cpp 
b/clang-tools-extra/clangd/SemanticHighlighting.cpp
index fb1ef1e326b41..4e66a9bb4e857 100644
--- a/clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ b/clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -221,23 +221,51 @@ class HighlightingsBuilder {
   // the end of the Tokens).
   TokRef = TokRef.drop_front(Conflicting.size());
 }
-// Add tokens indicating lines skipped by the preprocessor.
-for (const Range  : AST.getMacros().SkippedRanges) {
+const auto  = AST.getSourceManager();
+StringRef MainCode = SM.getBuffer(SM.getMainFileID())->getBuffer();
+
+// Merge token stream with "inactive line" markers.
+std::vector WithInactiveLines;
+auto SortedSkippedRanges = AST.getMacros().SkippedRanges;
+llvm::sort(SortedSkippedRanges);
+auto It = NonConflicting.begin();
+for (const Range  : SortedSkippedRanges) {
   // Create one token for each line in the skipped range, so it works
   // with line-based 
diff ing.
   assert(R.start.line <= R.end.line);
   for (int Line = R.start.line; Line <= R.end.line; ++Line) {
-// Don't bother computing the offset for the end of the line, just use
-// zero. The client will treat this highlighting kind specially, and
-// highlight the entire line visually (i.e. not just to where the text
-// on the line ends, but to the end of the screen).
-NonConflicting.push_back({HighlightingKind::InactiveCode,
-  {Position{Line, 0}, Position{Line, 0}}});
+// Copy tokens before the inactive line
+for (; It != NonConflicting.end() && It->R.start.line < Line; ++It)
+  WithInactiveLines.push_back(std::move(*It));
+// Add a token for the inactive line itself.
+auto StartOfLine = positionToOffset(MainCode, Position{Line, 0});
+if (StartOfLine) {
+  StringRef LineText =
+  MainCode.drop_front(*StartOfLine).take_until([](char C) {
+return C == '\n';
+  });
+  WithInactiveLines.push_back(
+  {HighlightingKind::InactiveCode,
+   {Position{Line, 0},
+Position{Line, static_cast(lspLength(LineText))}}});
+} else {
+  elog("Failed to convert position to offset: {0}",
+   StartOfLine.takeError());
+}
+
+// Skip any other tokens on the inactive line. e.g.
+// `#ifndef Foo` is considered as part of an inactive region when Foo 
is
+// defined, and there is a Foo macro token.
+// FIXME: we should reduce the scope of the inactive region to not
+// include the directive itself.
+while (It != NonConflicting.end() && It->R.start.line == Line)
+  ++It;
   }
 }
-// Re-sort the tokens because that's what the 
diff ing expects.
-llvm::sort(NonConflicting);
-return NonConflicting;
+// Copy tokens after the last inactive line
+for (; It != NonConflicting.end(); ++It)
+  WithInactiveLines.push_back(std::move(*It));
+return WithInactiveLines;
   }
 
 private:
@@ -493,9 +521,6 @@ toSemanticTokens(llvm::ArrayRef Tokens) {
   std::vector Result;
   const HighlightingToken *Last = nullptr;
   for (const HighlightingToken  : Tokens) {
-// FIXME: support inactive code - we need to provide the actual bounds.
-if (Tok.Kind == HighlightingKind::InactiveCode)
-  continue;
 Result.emplace_back();
 SemanticToken  = Result.back();
 // deltaStart/deltaLine are relative if possible.

diff  --git a/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp 
b/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
index 06743080166b4..232be6a783803 100644
--- a/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ b/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -503,11 +503,11 @@ TEST(SemanticHighlighting, GetsCorrectTokens) {
 
   #define $Macro[[test]]
   #undef $Macro[[test]]
-$InactiveCode[[]]  #ifdef $Macro[[test]]
-$InactiveCode[[]]  #endif
+$InactiveCode[[#ifdef test]]
+$InactiveCode[[#endif]]
 
-$InactiveCode[[]]  #if defined($Macro[[test]])
-$InactiveCode[[]]  #endif
+$InactiveCode[[#if 

[clang] f22d276 - [NFC] Fix some spelling errors in clang Driver Options.td

2020-08-26 Thread Puyan Lotfi via cfe-commits

Author: Yang Zhihui
Date: 2020-08-26T04:58:38-04:00
New Revision: f22d27624b6532a5542b283de9ce586c72c6b846

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

LOG: [NFC] Fix some spelling errors in clang Driver Options.td

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 5da072ee4cc2..b5a158cd3336 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -698,7 +698,7 @@ def emit_ast : Flag<["-"], "emit-ast">,
 def emit_llvm : Flag<["-"], "emit-llvm">, Flags<[CC1Option]>, 
Group,
   HelpText<"Use the LLVM representation for assembler and object files">;
 def emit_interface_stubs : Flag<["-"], "emit-interface-stubs">, 
Flags<[CC1Option]>, Group,
-  HelpText<"Generate Inteface Stub Files.">;
+  HelpText<"Generate Interface Stub Files.">;
 def emit_merged_ifs : Flag<["-"], "emit-merged-ifs">,
   Flags<[CC1Option]>, Group,
   HelpText<"Generate Interface Stub Files, emit merged text not binary.">;
@@ -1809,7 +1809,7 @@ def fstack_protector : Flag<["-"], "fstack-protector">, 
Group,
"This uses a loose heuristic which considers functions vulnerable 
if they "
"contain a char (or 8bit integer) array or constant sized calls to 
alloca "
", which are of greater size than ssp-buffer-size (default: 8 
bytes). All "
-   "variable sized calls to alloca are considered vulnerable. A 
function with"
+   "variable sized calls to alloca are considered vulnerable. A 
function with "
"a stack protector has a guard value added to the stack frame that 
is "
"checked on function exit. The guard value must be positioned in 
the "
"stack frame such that a buffer overflow from a vulnerable variable 
will "



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


[PATCH] D86427: Fix some spelling errors

2020-08-26 Thread Puyan Lotfi via Phabricator via cfe-commits
plotfi added a comment.

@YangZhihui landed at 
https://github.com/llvm/llvm-project/commit/f22d27624b6532a5542b283de9ce586c72c6b846

Thanks! :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86427

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


[PATCH] D86602: [clangd] Enable recovery-ast-type by default.

2020-08-26 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added a reviewer: sammccall.
Herald added subscribers: usaxena95, kadircet, arphaman, jkorous.
Herald added a project: clang.
hokein requested review of this revision.
Herald added subscribers: MaskRay, ilya-biryukov.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86602

Files:
  clang-tools-extra/clangd/ClangdServer.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
@@ -291,9 +291,8 @@
 opt RecoveryASTType{
 "recovery-ast-type",
 cat(Features),
-desc("Preserve the type for recovery AST. Note that "
- "this feature is experimental and may lead to crashes"),
-init(false),
+desc("Preserve the type for recovery AST."),
+init(ClangdServer::Options().PreserveRecoveryASTType),
 Hidden,
 };
 
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -131,7 +131,7 @@
 bool BuildRecoveryAST = true;
 
 /// If true, turn on the `-frecovery-ast-type` clang flag.
-bool PreserveRecoveryASTType = false;
+bool PreserveRecoveryASTType = true;
 
 /// Clangd's workspace root. Relevant for "workspace" operations not bound
 /// to a particular file.


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -291,9 +291,8 @@
 opt RecoveryASTType{
 "recovery-ast-type",
 cat(Features),
-desc("Preserve the type for recovery AST. Note that "
- "this feature is experimental and may lead to crashes"),
-init(false),
+desc("Preserve the type for recovery AST."),
+init(ClangdServer::Options().PreserveRecoveryASTType),
 Hidden,
 };
 
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -131,7 +131,7 @@
 bool BuildRecoveryAST = true;
 
 /// If true, turn on the `-frecovery-ast-type` clang flag.
-bool PreserveRecoveryASTType = false;
+bool PreserveRecoveryASTType = true;
 
 /// Clangd's workspace root. Relevant for "workspace" operations not bound
 /// to a particular file.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D86427: Fix some spelling errors

2020-08-26 Thread Puyan Lotfi via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf22d27624b65: [NFC] Fix some spelling errors in clang Driver 
Options.td (authored by YangZhihui, committed by plotfi).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86427

Files:
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -698,7 +698,7 @@
 def emit_llvm : Flag<["-"], "emit-llvm">, Flags<[CC1Option]>, 
Group,
   HelpText<"Use the LLVM representation for assembler and object files">;
 def emit_interface_stubs : Flag<["-"], "emit-interface-stubs">, 
Flags<[CC1Option]>, Group,
-  HelpText<"Generate Inteface Stub Files.">;
+  HelpText<"Generate Interface Stub Files.">;
 def emit_merged_ifs : Flag<["-"], "emit-merged-ifs">,
   Flags<[CC1Option]>, Group,
   HelpText<"Generate Interface Stub Files, emit merged text not binary.">;
@@ -1809,7 +1809,7 @@
"This uses a loose heuristic which considers functions vulnerable 
if they "
"contain a char (or 8bit integer) array or constant sized calls to 
alloca "
", which are of greater size than ssp-buffer-size (default: 8 
bytes). All "
-   "variable sized calls to alloca are considered vulnerable. A 
function with"
+   "variable sized calls to alloca are considered vulnerable. A 
function with "
"a stack protector has a guard value added to the stack frame that 
is "
"checked on function exit. The guard value must be positioned in 
the "
"stack frame such that a buffer overflow from a vulnerable variable 
will "


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -698,7 +698,7 @@
 def emit_llvm : Flag<["-"], "emit-llvm">, Flags<[CC1Option]>, Group,
   HelpText<"Use the LLVM representation for assembler and object files">;
 def emit_interface_stubs : Flag<["-"], "emit-interface-stubs">, Flags<[CC1Option]>, Group,
-  HelpText<"Generate Inteface Stub Files.">;
+  HelpText<"Generate Interface Stub Files.">;
 def emit_merged_ifs : Flag<["-"], "emit-merged-ifs">,
   Flags<[CC1Option]>, Group,
   HelpText<"Generate Interface Stub Files, emit merged text not binary.">;
@@ -1809,7 +1809,7 @@
"This uses a loose heuristic which considers functions vulnerable if they "
"contain a char (or 8bit integer) array or constant sized calls to alloca "
", which are of greater size than ssp-buffer-size (default: 8 bytes). All "
-   "variable sized calls to alloca are considered vulnerable. A function with"
+   "variable sized calls to alloca are considered vulnerable. A function with "
"a stack protector has a guard value added to the stack frame that is "
"checked on function exit. The guard value must be positioned in the "
"stack frame such that a buffer overflow from a vulnerable variable will "
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2020-08-26 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added a comment.

In D86533#2236009 , @Szelethus wrote:

> @vsavchenko I just realized a significant portion of your work for this 
> release is the following list:
>
>   git log llvmorg-11-init..llvmorg-11.0.0-rc2 --oneline -- 
> clang/utils/analyzer/
>
> Is it a correct guess that while your primary audience are the analyzer 
> developers, it wouldn't hurt to mention it in the release notes?

Sure, I think that we can mention that there is a beta-version of the 
dockerized testing system.

On the other note, a huge portion of my work is related to the solver, like 
b13d9878b8dc 
 and 
e63b488f2755 
. I think 
it can be mentioned in the notes.
Also, 239c53b72b18 
 might be 
pretty important for our Obj-C users.


Repository:
  rG LLVM Github Monorepo

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] D82582: [SVE] Remove calls to VectorType::getNumElements from clang

2020-08-26 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon accepted this revision.
RKSimon added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82582

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


[PATCH] D86547: [compiler-rt][builtins] Use c[tl]zsi macro instead of __builtin_c[tl]z

2020-08-26 Thread Mikael Holmén via Phabricator via cfe-commits
uabelho added a comment.

We've run with changes like this for a long time to make the routines work for 
our out of tree target where int is also 16 bits so thumbs up from me even if 
I'm not sure I can formally LGTM it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86547

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


[PATCH] D86604: [clangd] Use string[] for allCommitCharacters

2020-08-26 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev created this revision.
kbobyrev added a reviewer: sammccall.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman, jkorous.
Herald added a project: clang.
kbobyrev requested review of this revision.
Herald added subscribers: MaskRay, ilya-biryukov.

As per LSP specification, allCommitCharacters should be string[] instead of
string:

https://microsoft.github.io/language-server-protocol/specification#textDocument_completion


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86604

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/test/initialize-params.test


Index: clang-tools-extra/clangd/test/initialize-params.test
===
--- clang-tools-extra/clangd/test/initialize-params.test
+++ clang-tools-extra/clangd/test/initialize-params.test
@@ -7,7 +7,35 @@
 # CHECK-NEXT:"capabilities": {
 # CHECK-NEXT:  "codeActionProvider": true,
 # CHECK-NEXT:  "completionProvider": {
-# CHECK-NEXT:"allCommitCharacters": " 

[PATCH] D86604: [clangd] Use string[] for allCommitCharacters

2020-08-26 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Oops, nice catch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86604

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


[libunwind] e524daa - [libunwind] Convert x86, x86_64, arm64 register restore functions to C calling convention and name mangling

2020-08-26 Thread Martin Storsjö via cfe-commits

Author: Martin Storsjö
Date: 2020-08-26T14:32:32+03:00
New Revision: e524daa7e8719f4b43e6ebcf25fd4e7d74c5d1c4

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

LOG: [libunwind] Convert x86, x86_64, arm64 register restore functions to C 
calling convention and name mangling

Currently, the assembly functions for restoring register state have
been direct implementations of the Registers_*::jumpto() method
(contrary to the functions for saving register state, which are
implementations of the extern C function __unw_getcontext). This has
included having the assembly function name match the C++ mangling of
that method name (and having the function match the C++ member
function calling convention). To simplify the interface of the assembly
implementations, make the functions have C calling conventions and
name mangling.

This fixes building the library in with a MSVC C++ ABI with clang-cl,
which uses a significantly different method name mangling scheme.
(The library might not be of much use as C++ exception unwinder in such
an environment, but the libunwind.h interface for stepwise unwinding
still is usable, as is the _Unwind_Backtrace function.)

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

Added: 


Modified: 
libunwind/src/Registers.hpp
libunwind/src/UnwindRegistersRestore.S

Removed: 




diff  --git a/libunwind/src/Registers.hpp b/libunwind/src/Registers.hpp
index c76b05bf314e..4d963b4156d1 100644
--- a/libunwind/src/Registers.hpp
+++ b/libunwind/src/Registers.hpp
@@ -39,6 +39,8 @@ enum {
 };
 
 #if defined(_LIBUNWIND_TARGET_I386)
+class _LIBUNWIND_HIDDEN Registers_x86;
+extern "C" void __libunwind_Registers_x86_jumpto(Registers_x86 *);
 /// Registers_x86 holds the register state of a thread in a 32-bit intel
 /// process.
 class _LIBUNWIND_HIDDEN Registers_x86 {
@@ -56,7 +58,7 @@ class _LIBUNWIND_HIDDEN Registers_x86 {
   v128getVectorRegister(int num) const;
   voidsetVectorRegister(int num, v128 value);
   static const char *getRegisterName(int num);
-  voidjumpto();
+  voidjumpto() { __libunwind_Registers_x86_jumpto(this); }
   static int  lastDwarfRegNum() { return 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_X86; }
   static int  getArch() { return REGISTERS_X86; }
 
@@ -248,6 +250,8 @@ inline void Registers_x86::setVectorRegister(int, v128) {
 #if defined(_LIBUNWIND_TARGET_X86_64)
 /// Registers_x86_64  holds the register state of a thread in a 64-bit intel
 /// process.
+class _LIBUNWIND_HIDDEN Registers_x86_64;
+extern "C" void __libunwind_Registers_x86_64_jumpto(Registers_x86_64 *);
 class _LIBUNWIND_HIDDEN Registers_x86_64 {
 public:
   Registers_x86_64();
@@ -263,7 +267,7 @@ class _LIBUNWIND_HIDDEN Registers_x86_64 {
   v128getVectorRegister(int num) const;
   voidsetVectorRegister(int num, v128 value);
   static const char *getRegisterName(int num);
-  voidjumpto();
+  voidjumpto() { __libunwind_Registers_x86_64_jumpto(this); }
   static int  lastDwarfRegNum() { return 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_X86_64; }
   static int  getArch() { return REGISTERS_X86_64; }
 
@@ -1771,6 +1775,8 @@ inline const char *Registers_ppc64::getRegisterName(int 
regNum) {
 #if defined(_LIBUNWIND_TARGET_AARCH64)
 /// Registers_arm64  holds the register state of a thread in a 64-bit arm
 /// process.
+class _LIBUNWIND_HIDDEN Registers_arm64;
+extern "C" void __libunwind_Registers_arm64_jumpto(Registers_arm64 *);
 class _LIBUNWIND_HIDDEN Registers_arm64 {
 public:
   Registers_arm64();
@@ -1786,7 +1792,7 @@ class _LIBUNWIND_HIDDEN Registers_arm64 {
   v128getVectorRegister(int num) const;
   voidsetVectorRegister(int num, v128 value);
   static const char *getRegisterName(int num);
-  voidjumpto();
+  voidjumpto() { __libunwind_Registers_arm64_jumpto(this); }
   static int  lastDwarfRegNum() { return 
_LIBUNWIND_HIGHEST_DWARF_REGISTER_ARM64; }
   static int  getArch() { return REGISTERS_ARM64; }
 

diff  --git a/libunwind/src/UnwindRegistersRestore.S 
b/libunwind/src/UnwindRegistersRestore.S
index 5d5443215286..d817e6dae948 100644
--- a/libunwind/src/UnwindRegistersRestore.S
+++ b/libunwind/src/UnwindRegistersRestore.S
@@ -13,14 +13,10 @@
 #if !defined(__USING_SJLJ_EXCEPTIONS__)
 
 #if defined(__i386__)
-DEFINE_LIBUNWIND_FUNCTION(_ZN9libunwind13Registers_x866jumptoEv)
+DEFINE_LIBUNWIND_FUNCTION(__libunwind_Registers_x86_jumpto)
 #
-# void libunwind::Registers_x86::jumpto()
+# extern "C" void __libunwind_Registers_x86_jumpto(Registers_x86 *);
 #
-#if defined(_WIN32)
-# On windows, the 'this' pointer is passed in ecx instead of on the stack
-  movl   %ecx, %eax
-#else
 # On entry:
 #  +   +
 #  +---+
@@ -30,7 +26,6 @@ 

[PATCH] D86465: [analyzer][solver] Redesign constraint ranges data structure

2020-08-26 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

In D86465#2238379 , @vsavchenko wrote:

> Here are some benchmarking results. 
> In docker:
> F12777445: tiny.png 
> F12777444: small.png 
> Natively on my Mac (no memory measurements due to this issue 
>  during `psutil` 
> installation):
> F12777471: tiny-native.png 
> F12777472: small-native.png 

These are really promising figures, nice work! (And the measurement stuff 
itself is also a great addition, thanks for that!)
Not that it would matter much, but I was just wondering why there is a slightly 
bigger memory usage in some of the `docker/small` projects? The most 
conspicuous is `oatpp`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86465

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


[PATCH] D86562: [OPENMP][NFC]Release notes for OpenMP in clang (11.x).

2020-08-26 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev updated this revision to Diff 287906.
ABataev added a comment.

Added default(firstprivate)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86562

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -156,7 +156,52 @@
 OpenMP Support in Clang
 ---
 
-- ...
+New features for OpenMP 5.0 were implemented.
+
+- OpenMP 5.0 is the default version supported by the compiler. User can switch
+  to OpenMP 4.5 using ``-fopenmp-version=45`` option.
+
+- Added support for declare variant directive.
+
+- Improved support of math functions and complex types for NVPTX target.
+
+- Added support for parallel execution of target regions for NVPTX target.
+
+- Added support for ``scan`` directives and ``inscan`` modifier in 
``reduction``
+  clauses.
+
+- Added support for ``iterator`` construct.
+
+- Added support for ``depobj`` construct.
+
+- Added support for ``detach`` clauses in task-based directives.
+
+- Added support for array shaping operations.
+
+- Added support for cancellation constructs in ``taskloop`` directives.
+
+- Nonmonotonic modifier is allowed with all schedule kinds.
+
+- Added support for ``task`` and ``default`` modifiers in ``reduction`` 
clauses.
+
+- Added support for strides in array sections.
+
+- Added support for ``use_device_addr`` clause.
+
+- Added support for ``uses_allocators`` clause.
+
+- Added support for ``defaultmap`` clause.
+
+- Added basic support for ``hint`` clause in ``atomic`` directives.
+
+- Added basic support for ``affinity`` clause.
+
+- Added basic support for ``ancestor`` modifier in ``device`` clause.
+
+- Added support for ``default(firstprivate)`` clause. This clause is the part 
of
+  upcoming OpenMP 5.1 and can be enabled using ``-fopenmp-version=51`` option.
+
+- Bug fixes and optimizations.
 
 CUDA Support in Clang
 -


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -156,7 +156,52 @@
 OpenMP Support in Clang
 ---
 
-- ...
+New features for OpenMP 5.0 were implemented.
+
+- OpenMP 5.0 is the default version supported by the compiler. User can switch
+  to OpenMP 4.5 using ``-fopenmp-version=45`` option.
+
+- Added support for declare variant directive.
+
+- Improved support of math functions and complex types for NVPTX target.
+
+- Added support for parallel execution of target regions for NVPTX target.
+
+- Added support for ``scan`` directives and ``inscan`` modifier in ``reduction``
+  clauses.
+
+- Added support for ``iterator`` construct.
+
+- Added support for ``depobj`` construct.
+
+- Added support for ``detach`` clauses in task-based directives.
+
+- Added support for array shaping operations.
+
+- Added support for cancellation constructs in ``taskloop`` directives.
+
+- Nonmonotonic modifier is allowed with all schedule kinds.
+
+- Added support for ``task`` and ``default`` modifiers in ``reduction`` clauses.
+
+- Added support for strides in array sections.
+
+- Added support for ``use_device_addr`` clause.
+
+- Added support for ``uses_allocators`` clause.
+
+- Added support for ``defaultmap`` clause.
+
+- Added basic support for ``hint`` clause in ``atomic`` directives.
+
+- Added basic support for ``affinity`` clause.
+
+- Added basic support for ``ancestor`` modifier in ``device`` clause.
+
+- Added support for ``default(firstprivate)`` clause. This clause is the part of
+  upcoming OpenMP 5.1 and can be enabled using ``-fopenmp-version=51`` option.
+
+- Bug fixes and optimizations.
 
 CUDA Support in Clang
 -
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D72705: [analyzer] Added new checker 'alpha.unix.ErrorReturn'.

2020-08-26 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus requested changes to this revision.
Szelethus added a subscriber: bruntib.
Szelethus added a comment.
This revision now requires changes to proceed.

I debated this 

 report with @bruntib, depending from where you look at it, its either a false 
positive or not -- in short, this is what happens:

  char *p = /* some assumed to be valid c string */
  end = strchr(p, '\n');
  if (end - p > 4) { // <-- warning here on end's invalid use
  }

the guarded code wouldn't be executed, should `end` be zero. Now, if we 
interpret the rule in a very literal sense, that

> The successful completion or failure of each of the standard library 
> functions listed in the following table shall be determined either by 
> comparing the function’s return value with the value listed in the column 
> labeled “Error Return” or by calling one of the library functions mentioned 
> in the footnotes.

then indeed, it doesn't compare the return value with the item in the table, 
but it does compare it with superset of it. Now, we can either say that

1. A superset isn't good enough, because its a sign of code smell, or
2. Judge that the user probably did handle the error case, albeit in an 
unconventional way, and report like these don't provide any value.

I don't think we can realistically pursue point (2.). We would need to widen 
the context (by going further up the AST with `Stmt::getParent()`) we're 
considering for a potential check. However, forming a non-checking expression 
that we don't immediately report can quickly get out of control:

  char *p = /* some assumed to be valid c string */;
  end = strchr(p, '\n');
  int result = end - p;
  if (result > 4) {
  }

You would be right to believe, without context from the code that is yet to be 
executed, that the computation of `result` is invalid, because `end` is 
unchecked. However, the code complies with the rule interpreted by (2.). This 
seems to be a problem that can have infinite complexity without very severe 
restriction on the analysis. Indeed, if we wonder too far from the original 
function call (by creating values that descend from the return value to be 
checked), being sure that no checks happened (by point 2.) quickly becomes 
unmanageable.

So, for all practical purposes, we're locked to option (1.). However, the 
warning message this way is imprecise -- we're **not** enforcing whether the 
error value was checked for error, we're enforcing whether the return value was 
checked against its respective failure value, and the message should reflect 
that. In fact, the checker description, and some comments should be clarified 
in this regard as well.

I would imagine the pool of functions that deserve such incredibly strict 
enforcement is rather small. Time management, maybe, but certainly not string 
modeling functions, because problems related to them are solved by a completely 
different checker infrastructure (`CStringChecker`), just as stream modeling 
functions and memory management. Maybe we should only look for statement-local 
bugs (basically a discarded return value) for functions that don't demand this 
rigidness, but I suspect there is a clang-tidy check already out there doing 
it. Seems like I got what @NoQ meant here.

In D72705#2088319 , @NoQ wrote:

> I still don't understand how do we enable this checker, i.e. for whom and how 
> often. Is there anything we'll be able to turn on by default, like maybe warn 
> on all functions that wear `__attribute__((warn_unused_result))`?



---

I'm very happy we got another round of evaluations, we've gotten some 
invaluable information out of it. For future patches, it would be great to have 
your input on at least some of the reports as you're publishing them. For the 
latest project, I think there is clear intent from the developer to avoid null 
pointer misuses -- you should justify why a report is still appropriate there.

You mentioned in D72705#2187556  that 
on `duckdb` you stumbled across 1-2 false positives, but also that you found 23 
reports, and that you ran the checker on `vim`. This may be okay for an alpha 
checker, or maybe not, if it points to a fundamental problem in your approach. 
Please publish them before updating the patch. If all goes well and those cases 
could be patched up later, here are the next important steps:

- Have a warning message that precisely states what, and how the rule was 
violated, even if its done with placeholders, even if you only wanna place a 
FIXME and address this later. Either is fine. By the time we ship this checker, 
a message that delivers the following information, even if phrased differently, 
would be great: "According to the CERT rule ERR33-C, 

[PATCH] D86600: [SyntaxTree] Migrate `ParamatersAndQualifiers` to use the new List API

2020-08-26 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added a comment.

Could you add some tests with variadic parameter lists & variadic function 
templates? If we don't handle them correctly, please leave a FIXME in the test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86600

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


[PATCH] D86531: [analyzer][StdLibraryFunctionsChecker][NFC] Use Optionals throughout the summary API

2020-08-26 Thread Gabor Marton via Phabricator via cfe-commits
martong marked 3 inline comments as done.
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:851
+  } getPointerTy(ACtx);
+  class {
+  public:

balazske wrote:
> Why has this class different layout than `GetPointerTy` and `GetRestrictTy` 
> (beneath that here is no `ASTContext`)? It would be better if all these 
> classes look the same way: First is the operator with `QualType`, then 
> operator with `Optional` that calls the other version of the operator. And 
> all of these can be "unnamed" classes?
I'd had the same thoughts before, and was thinking about that maybe a class 
template would suffice for all these, but then I realized the following:

To make a type const, we don't need the ASTContext, that is the reason of the 
difference.
However, to make a type restricted or a pointer, we need the ASTContext. This 
is a legacy non-symmetry from the AST.
> And all of these can be "unnamed" classes?
GetPointerTy and GetRestrictTy need the ASTContext in their constructor. And 
you cannot define a constructor to an unnamed class because you cannot write 
down the nonexistent name.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:890
 
-  const QualType VoidPtrTy = ACtx.VoidPtrTy; // void *
-  const QualType IntPtrTy = ACtx.getPointerType(IntTy); // int *
+  const QualType VoidPtrTy = getPointerTy(VoidTy); // void *
+  const QualType IntPtrTy = getPointerTy(IntTy);   // int *

balazske wrote:
> Is it better to use `ACtx.VoidPtrTy`? 
I'd like to use the `ACtx` as less as possible: just to get the basic types. 
And from that on we can use our convenience API (GetConstTy, GetPointerTy, etc) 
to define all of the derived types... and we can do that in a declarative form 
(like ASTMatchters).
Also, the declarative definition of these types now look the same regardless 
the type is "derived" from a looked-up type or from a built-in type.



Comment at: 
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:1321
 
-Optional Mode_tTy = lookupType("mode_t", ACtx);
+Optional Mode_tTy = lookupTy("mode_t");
 

balazske wrote:
> It is better to get every type at the start before adding functions, or group 
> the functions and get some types at the start of these groups but mark the 
> groups at least with comments.
Well, with looked-up types I followed the usual convention to define a variable 
right before using it. This means that we lookup a type just before we try to 
add the function which first uses that type.

However, builtin types are defined at the beginning, because they are used very 
often.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86531

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


[PATCH] D86101: [AArch64][SVE] Add missing debug info for ACLE types.

2020-08-26 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen updated this revision to Diff 287911.
sdesmalen added a comment.

- Choose unsigned char element type for svbool_t bitpattern.
- Added LLVM test to ensure debug info for the vector type is correctly 
codegenerated when DISubrange has upper bound instead of count.


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

https://reviews.llvm.org/D86101

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/aarch64-debug-sve-vector-types.c
  clang/test/CodeGen/aarch64-debug-sve-vectorx2-types.c
  clang/test/CodeGen/aarch64-debug-sve-vectorx3-types.c
  clang/test/CodeGen/aarch64-debug-sve-vectorx4-types.c
  clang/test/CodeGen/aarch64-sve.c
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/test/DebugInfo/AArch64/dbg-sve-types.ll

Index: llvm/test/DebugInfo/AArch64/dbg-sve-types.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/AArch64/dbg-sve-types.ll
@@ -0,0 +1,44 @@
+; Test that the debug info for the vector type is correctly codegenerated
+; when the DISubrange has no count, but only an upperbound.
+; RUN: llc -mtriple aarch64 -mattr=+sve -filetype=obj -o %t %s
+; RUN: llvm-dwarfdump %t | FileCheck %s
+; RUN: rm %t
+
+; CHECK:  {{.*}}: DW_TAG_subrange_type
+; CHECK-NEXT:   DW_AT_type({{.*}} "__ARRAY_SIZE_TYPE__")
+; CHECK-NEXT:   DW_AT_upper_bound (DW_OP_lit8, DW_OP_bregx VG+0, DW_OP_mul, DW_OP_lit1, DW_OP_minus)
+
+define  @test_svint8_t( returned %op1) !dbg !7 {
+entry:
+  call void @llvm.dbg.value(metadata  %op1, metadata !19, metadata !DIExpression()), !dbg !20
+  ret  %op1, !dbg !21
+}
+
+declare void @llvm.dbg.value(metadata, metadata, metadata)
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+!llvm.ident = !{!6}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 12.0.0", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None)
+!1 = !DIFile(filename: "dbg-sve-types.ll", directory: "")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{!"clang version 12.0.0"}
+!7 = distinct !DISubprogram(name: "test_svint8_t", scope: !8, file: !8, line: 5, type: !9, scopeLine: 5, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !0, retainedNodes: !18)
+!8 = !DIFile(filename: "dbg-sve-types.ll", directory: "")
+!9 = !DISubroutineType(types: !10)
+!10 = !{!11, !11}
+!11 = !DIDerivedType(tag: DW_TAG_typedef, name: "svint8_t", file: !12, line: 32, baseType: !13)
+!12 = !DIFile(filename: "lib/clang/12.0.0/include/arm_sve.h", directory: "")
+!13 = !DIDerivedType(tag: DW_TAG_typedef, name: "__SVInt8_t", file: !1, baseType: !14)
+!14 = !DICompositeType(tag: DW_TAG_array_type, baseType: !15, flags: DIFlagVector, elements: !16)
+!15 = !DIBasicType(name: "signed char", size: 8, encoding: DW_ATE_signed_char)
+!16 = !{!17}
+!17 = !DISubrange(lowerBound: 0, upperBound: !DIExpression(DW_OP_constu, 8, DW_OP_bregx, 46, 0, DW_OP_mul, DW_OP_constu, 1, DW_OP_minus))
+!18 = !{!19}
+!19 = !DILocalVariable(name: "op1", arg: 1, scope: !7, file: !8, line: 5, type: !11)
+!20 = !DILocation(line: 0, scope: !7)
+!21 = !DILocation(line: 5, column: 39, scope: !7)
Index: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
+++ llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
@@ -1398,8 +1398,10 @@
  Elements[0]->getTag() == dwarf::DW_TAG_subrange_type &&
  "Invalid vector element array, expected one element of type subrange");
   const auto Subrange = cast(Elements[0]);
-  const auto CI = Subrange->getCount().get();
-  const int32_t NumVecElements = CI->getSExtValue();
+  const auto NumVecElements =
+  Subrange->getCount()
+  ? Subrange->getCount().get()->getSExtValue()
+  : 0;
 
   // Ensure we found the element count and that the actual size is wide
   // enough to contain the requested size.
Index: clang/test/CodeGen/aarch64-sve.c
===
--- clang/test/CodeGen/aarch64-sve.c
+++ clang/test/CodeGen/aarch64-sve.c
@@ -1,22 +1,6 @@
-// RUN: not %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve \
-// RUN:  -emit-llvm -o - %s -debug-info-kind=limited 2>&1 | FileCheck %s -check-prefix=CHECK-DEBUG
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve \
 // RUN:  -emit-llvm -o - %s 2>&1 | FileCheck %s -check-prefix=CHECK
 
-// CHECK-DEBUG: cannot yet generate debug info for SVE type '__SVInt8_t'
-// CHECK-DEBUG: cannot yet generate debug info for SVE type '__SVInt16_t'
-// CHECK-DEBUG: cannot yet generate debug info for SVE type '__SVInt32_t'
-// CHECK-DEBUG: cannot yet generate debug info for SVE type '__SVInt64_t'
-// CHECK-DEBUG: cannot yet generate debug info for SVE type '__SVUint8_t'
-// CHECK-DEBUG: cannot yet generate 

[PATCH] D86101: [AArch64][SVE] Add missing debug info for ACLE types.

2020-08-26 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added inline comments.



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:734
+  if (Info.ElementType == CGM.getContext().BoolTy)
+NumElemsPerVG /= 8;
+

efriedma wrote:
> I guess NumElemsPerVG of a bool vector is always divisible by 8 because we 
> don't expose `` etc.?
Yes, that's right. Only `svbool_t`, i.e. `` is exposed.



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:748
+  llvm::DINodeArray SubscriptArray = DBuilder.getOrCreateArray(Subscript);
+  llvm::DIType *ElemTy =
+  getOrCreateType(Info.ElementType, TheCU->getFile());

rsandifo-arm wrote:
> I might be misreading the code, but if we're representing svbool_t as a 
> bitmask (which is a good approach IMO), would it be better to pass 
> UnsignedCharTy rather than BoolTy here?  It seems odd to represent the type 
> as  “bools”.
You're right, good shout!



Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:1404
+  ? Subrange->getCount().get()->getSExtValue()
+  : 0;
 

efriedma wrote:
> Do we need a test for this change?
Yes it does, thanks for pointing out!


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

https://reviews.llvm.org/D86101

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


[PATCH] D86600: [SyntaxTree] Migrate `ParamatersAndQualifiers` to use the new List API

2020-08-26 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added a comment.

I think we also need to update `List::getTerminationKind()` and other similar 
List methods to handle this list kind.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86600

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


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

2020-08-26 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus updated this revision to Diff 287930.
Szelethus marked 14 inline comments as done.
Szelethus added a comment.

Fixes according to reviewer comments!


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

https://reviews.llvm.org/D86533

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -437,10 +437,76 @@
 
 - ...
 
+.. _release-notes-clang-static-analyzer:
+
 Static Analyzer
 ---
 
-- ...
+- Improved the analyzer's understanding of inherited C++ constructors.
+
+- Improved the analyzer's understanding of dynamic class method dispatching in
+  Objective-C.
+
+- Greatly improved the analyzer's constraint solver by better understanding
+  when constraints are imposed on multiple symbolic values that are known to be
+  equal or known to be non-equal.
+
+- Added :ref:`on-demand parsing ` capability to Cross 
Translation
+  Unit (CTU) analysis.
+
+- Numerous fixes and improvements for the HTML output.
+
+- New checker: :ref:`alpha.core.C11Lock ` and
+  :ref:`alpha.fuchsia.Lock ` checks for their respective
+  locking APIs.
+
+- New checker: :ref:`alpha.security.cert.pos.34c `
+  finds calls to ``putenv`` where a pointer to an autmoatic variable is passed
+  as an argument.
+
+- New checker: :ref:`webkit.NoUncountedMemberChecker
+  ` to enforce the existence of virtual
+  destructors for all uncounted types used as base classes.
+
+- New checker: :ref:`webkit.RefCntblBaseVirtualDtor
+  ` checks that only ref-counted types
+  are used as class members, not raw pointers and references to uncounted
+  types.
+
+- New checker: :ref:`alpha.cplusplus.SmartPtr ` check
+  for dereference of null smart pointers.
+
+- Moved ``PlacementNewChecker`` out of alpha, making it enabled by default.
+
+- Added support for multi-dimensional variadic arrays in ``core.VLASize``.
+
+- Added a check for insufficient storage in array placement new calls, as well
+  as support for alignment variants to ``cplusplus.PlacementNew``.
+
+- While still in alpha, ``alpha.unix.PthreadLock``, the iterator and container
+  modeling infrastructure, ``alpha.unix.Stream``, and taint analysis were
+  improved greatly. An ongoing, currently off-by-default improvement was made 
on
+  the pre-condition modeling of several functions defined in the POSIX 
standard.
+
+- Improved the warning messages of several checkers.
+
+- Fixed a few remaining cases of checkers emitting reports under incorrect
+  checker names, and employed a few restrictions to more easily identify and
+  avoid such errors.
+
+- Moved several non-reporting checkers (those that model, among other things,
+  standard functions, but emit no diagnostics) to be listed under
+  ``-analyzer-checker-help-developer`` instead of ``-analyzer-checker-help``.
+  Manually enabling or disabling checkers found on this list is not supported
+  in production.
+
+- Numerous fixes for crashes, false positives and false negatives in
+  ``unix.Malloc``, ``osx.cocoa.NSError``, and several other checkers.
+
+- Implemented a dockerized testing system to more easily determine the
+  correctness and performance impact of a change to the static analyzer itself.
+  The currently beta-version tool is found in
+  (llvm-project repository)/clang/utils/analyzer/SATest.py.
 
 .. _release-notes-ubsan:
 


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -437,10 +437,76 @@
 
 - ...
 
+.. _release-notes-clang-static-analyzer:
+
 Static Analyzer
 ---
 
-- ...
+- Improved the analyzer's understanding of inherited C++ constructors.
+
+- Improved the analyzer's understanding of dynamic class method dispatching in
+  Objective-C.
+
+- Greatly improved the analyzer's constraint solver by better understanding
+  when constraints are imposed on multiple symbolic values that are known to be
+  equal or known to be non-equal.
+
+- Added :ref:`on-demand parsing ` capability to Cross Translation
+  Unit (CTU) analysis.
+
+- Numerous fixes and improvements for the HTML output.
+
+- New checker: :ref:`alpha.core.C11Lock ` and
+  :ref:`alpha.fuchsia.Lock ` checks for their respective
+  locking APIs.
+
+- New checker: :ref:`alpha.security.cert.pos.34c `
+  finds calls to ``putenv`` where a pointer to an autmoatic variable is passed
+  as an argument.
+
+- New checker: :ref:`webkit.NoUncountedMemberChecker
+  ` to enforce the existence of virtual
+  destructors for all uncounted types used as base classes.
+
+- New checker: :ref:`webkit.RefCntblBaseVirtualDtor
+  ` checks that only ref-counted types
+  are used as class members, not raw pointers and references to uncounted
+  types.
+
+- New checker: :ref:`alpha.cplusplus.SmartPtr ` check
+  for dereference of null smart pointers.
+
+- Moved ``PlacementNewChecker`` 

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

2020-08-26 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:471
+
+- Improve the pre- and post condition modeling of several hundred more standard
+  C functions.

whisperity wrote:
> martong wrote:
> > Umm, this is still an alpha command line option, plus we improved only the 
> > pre-condition checks.
> > So, I'd rather say something like:
> > ```
> > Improve the pre-condition modeling of several functions defined in the 
> > POSIX standard. This is in alpha currently. To enable, one must explicitly 
> > set the ``ModelPOSIX`` argument of the ``apiModeling.StdCLibraryFunctions`` 
> > checker.
> > ```
> Maybe it's worth mentioning the checker here too, akin to the other list 
> elements?
I don't believe in advertising development only options much, especially that 
we don't expect, nor want non-developers to interact with `apiModeling` stuff 
often. :/ I ended up removing the entry as such, if you don't mind.



Comment at: clang/docs/ReleaseNotes.rst:471-472
+
+- Improve the pre- and post condition modeling of several hundred more standard
+  C functions.
+

Szelethus wrote:
> whisperity wrote:
> > martong wrote:
> > > Umm, this is still an alpha command line option, plus we improved only 
> > > the pre-condition checks.
> > > So, I'd rather say something like:
> > > ```
> > > Improve the pre-condition modeling of several functions defined in the 
> > > POSIX standard. This is in alpha currently. To enable, one must 
> > > explicitly set the ``ModelPOSIX`` argument of the 
> > > ``apiModeling.StdCLibraryFunctions`` checker.
> > > ```
> > Maybe it's worth mentioning the checker here too, akin to the other list 
> > elements?
> I don't believe in advertising development only options much, especially that 
> we don't expect, nor want non-developers to interact with `apiModeling` stuff 
> often. :/ I ended up removing the entry as such, if you don't mind.
We don't want users to tinker with developer-only checkers.



Comment at: clang/docs/ReleaseNotes.rst:498
 
 .. _release-notes-ubsan:
 

whisperity wrote:
> @Szelethus Speaking of labels in the dependency patch D86532, there is no 
> label for the CSA changeset...
It is only important if you want to use that label -- in fact, this is the only 
one in the entire file :^)


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] D86533: (Urgent!) [release][docs][analyzer] Add 11.0.0. release notes

2020-08-26 Thread Gabor Marton via Phabricator via cfe-commits
martong accepted this revision.
martong added a comment.
This revision is now accepted and ready to land.

LGTM! (At least those changes that involved me, perhaps it is better to wait 
for more LGs.)




Comment at: clang/docs/ReleaseNotes.rst:471
+
+- Improve the pre- and post condition modeling of several hundred more standard
+  C functions.

Szelethus wrote:
> Szelethus wrote:
> > whisperity wrote:
> > > martong wrote:
> > > > Umm, this is still an alpha command line option, plus we improved only 
> > > > the pre-condition checks.
> > > > So, I'd rather say something like:
> > > > ```
> > > > Improve the pre-condition modeling of several functions defined in the 
> > > > POSIX standard. This is in alpha currently. To enable, one must 
> > > > explicitly set the ``ModelPOSIX`` argument of the 
> > > > ``apiModeling.StdCLibraryFunctions`` checker.
> > > > ```
> > > Maybe it's worth mentioning the checker here too, akin to the other list 
> > > elements?
> > I don't believe in advertising development only options much, especially 
> > that we don't expect, nor want non-developers to interact with 
> > `apiModeling` stuff often. :/ I ended up removing the entry as such, if you 
> > don't mind.
> We don't want users to tinker with developer-only checkers.
OK, fair enough.


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] D86533: (Urgent!) [release][docs][analyzer] Add 11.0.0. release notes

2020-08-26 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:487
+- While still in alpha, ``alpha.unix.PthreadLock``, the iterator and container
+  modeling infrastructure, ``alpha.unix.Stream``, and taint analysis were
+  improved greatly. An ongoing, currently off-by-default improvement was made 
on

Unfortunately, my taint related patched not upstreamed yet. So you should not 
mention that IMO.


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] D86600: [SyntaxTree] Migrate `ParamatersAndQualifiers` to use the new List API

2020-08-26 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas updated this revision to Diff 287947.
eduucaldas added a comment.

answer code-review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86600

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Nodes.cpp
  clang/lib/Tooling/Syntax/Tree.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
@@ -85,15 +85,16 @@
   | |-'foo'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'a'
-  |   |-','
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'b'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | |-SimpleDeclaration List_element
+  |   | | |-'int'
+  |   | | `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | |   `-'a'
+  |   | |-',' List_delimiter
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'int'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | `-'b'
   |   `-')' CloseParen
   `-CompoundStatement
 |-'{' OpenParen
@@ -3162,8 +3163,9 @@
   | |-'_c'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | `-'char'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | `-SimpleDeclaration List_element
+  |   |   `-'char'
   |   `-')' CloseParen
   `-';'
 )txt"));
@@ -3219,11 +3221,12 @@
 | |-'='
 | `-ParametersAndQualifiers
 |   |-'(' OpenParen
-|   |-SimpleDeclaration ParametersAndQualifiers_parameter
-|   | |-'const'
-|   | |-'X'
-|   | `-SimpleDeclarator SimpleDeclaration_declarator
-|   |   `-'&'
+|   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+|   | `-SimpleDeclaration List_element
+|   |   |-'const'
+|   |   |-'X'
+|   |   `-SimpleDeclarator SimpleDeclaration_declarator
+|   | `-'&'
 |   `-')' CloseParen
 `-';'
 )txt"}));
@@ -3249,14 +3252,15 @@
   | |-'+'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | `-'X'
-  |   |-','
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'const'
-  |   | |-'X'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'&'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | |-SimpleDeclaration List_element
+  |   | | `-'X'
+  |   | |-',' List_delimiter
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'const'
+  |   |   |-'X'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | `-'&'
   |   `-')' CloseParen
   `-';'
 )txt"}));
@@ -3885,16 +3889,17 @@
   | |-'f'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   |-'xs'
-  |   |   `-ArraySubscript
-  |   | |-'[' OpenParen
-  |   | |-'static'
-  |   | |-IntegerLiteralExpression ArraySubscript_sizeExpression
-  |   | | `-'10' LiteralToken
-  |   | `-']' CloseParen
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'int'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | |-'xs'
+  |   | `-ArraySubscript
+  |   |   |-'[' OpenParen
+  |   |   |-'static'
+  |   |   |-IntegerLiteralExpression ArraySubscript_sizeExpression
+  |   |   | `-'10' LiteralToken
+  |   |   `-']' CloseParen
   |   `-')' CloseParen
   `-';'
 )txt"));
@@ -3933,10 +3938,11 @@
 | | |-'func1'
 | | `-ParametersAndQualifiers
 | |   |-'(' OpenParen
-| |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-| |   | |-'int'
-| |   | `-SimpleDeclarator SimpleDeclaration_declarator
-| |   |   `-'a'
+| |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+| |   | `-SimpleDeclaration List_element
+| |   |   |-'int'
+| |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+| |   | `-'a'
 | |   `-')' CloseParen
 | `-';'
 |-SimpleDeclaration
@@ -3945,11 +3951,12 @@
 | | |-'func2'
 | | `-ParametersAndQualifiers
 | |   |-'(' OpenParen
-| |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-| |   | |-'int'
-| |   | `-SimpleDeclarator SimpleDeclaration_declarator
-| |   |   |-'*'
-| |   |   `-'ap'
+| |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+| |   | `-SimpleDeclaration List_element
+| |   |   |-'int'
+| |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+| |   | 

[PATCH] D85998: Add clang-cl "vctoolsdir" option to specify the location of the msvc toolchain

2020-08-26 Thread Hans Wennborg via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG087047144210: Add clang-cl vctoolsdir option to 
specify the location of the msvc toolchain (authored by zahen, committed by 
hans).

Changed prior to commit:
  https://reviews.llvm.org/D85998?vs=287671=287949#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85998

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/test/Driver/cl-options.c

Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -682,4 +682,13 @@
 // CLANG-NOT: "--dependent-lib=libcmt"
 // CLANG-NOT: "-vectorize-slp"
 
+// Validate that the default triple is used when run an empty tools dir is specified
+// RUN: %clang_cl -vctoolsdir "" -### -- %s 2>&1 | FileCheck %s --check-prefix VCTOOLSDIR
+// VCTOOLSDIR: "-cc1" "-triple" "x86_64-pc-windows-msvc19.11.0"
+
+// Validate that built-in include paths are based on the supplied path
+// RUN: %clang_cl -vctoolsdir "/fake" -### -- %s 2>&1 | FileCheck %s --check-prefix FAKEDIR
+// FAKEDIR: "-internal-isystem" "/fake{{.}}include"
+// FAKEDIR: "-internal-isystem" "/fake{{.}}atlmfc{{.}}include"
+
 void f() { }
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -66,6 +66,20 @@
 static bool getSystemRegistryString(const char *keyPath, const char *valueName,
 std::string , std::string *phValue);
 
+// Check command line arguments to try and find a toolchain.
+static bool
+findVCToolChainViaCommandLine(const ArgList , std::string ,
+  MSVCToolChain::ToolsetLayout ) {
+  // Don't validate the input; trust the value supplied by the user.
+  // The primary motivation is to prevent unnecessary file and registry access.
+  if (Arg *A = Args.getLastArg(options::OPT__SLASH_vctoolsdir)) {
+Path = A->getValue();
+VSLayout = MSVCToolChain::ToolsetLayout::VS2017OrNewer;
+return true;
+  }
+  return false;
+}
+
 // Check various environment variables to try and find a toolchain.
 static bool findVCToolChainViaEnvironment(std::string ,
   MSVCToolChain::ToolsetLayout ) {
@@ -747,11 +761,12 @@
   if (getDriver().getInstalledDir() != getDriver().Dir)
 getProgramPaths().push_back(getDriver().Dir);
 
-  // Check the environment first, since that's probably the user telling us
-  // what they want to use.
-  // Failing that, just try to find the newest Visual Studio version we can
-  // and use its default VC toolchain.
-  findVCToolChainViaEnvironment(VCToolChainPath, VSLayout) ||
+  // Check the command line first, that's the user explicitly telling us what to
+  // use. Check the environment next, in case we're being invoked from a VS
+  // command prompt. Failing that, just try to find the newest Visual Studio
+  // version we can and use its default VC toolchain.
+  findVCToolChainViaCommandLine(Args, VCToolChainPath, VSLayout) ||
+  findVCToolChainViaEnvironment(VCToolChainPath, VSLayout) ||
   findVCToolChainViaSetupConfig(VCToolChainPath, VSLayout) ||
   findVCToolChainViaRegistry(VCToolChainPath, VSLayout);
 }
@@ -1263,15 +1278,18 @@
 return;
 
   // Honor %INCLUDE%. It should know essential search paths with vcvarsall.bat.
-  if (llvm::Optional cl_include_dir =
-  llvm::sys::Process::GetEnv("INCLUDE")) {
-SmallVector Dirs;
-StringRef(*cl_include_dir)
-.split(Dirs, ";", /*MaxSplit=*/-1, /*KeepEmpty=*/false);
-for (StringRef Dir : Dirs)
-  addSystemInclude(DriverArgs, CC1Args, Dir);
-if (!Dirs.empty())
-  return;
+  // Skip if the user expressly set a vctoolsdir
+  if (!DriverArgs.getLastArg(options::OPT__SLASH_vctoolsdir)) {
+if (llvm::Optional cl_include_dir =
+llvm::sys::Process::GetEnv("INCLUDE")) {
+  SmallVector Dirs;
+  StringRef(*cl_include_dir)
+  .split(Dirs, ";", /*MaxSplit=*/-1, /*KeepEmpty=*/false);
+  for (StringRef Dir : Dirs)
+addSystemInclude(DriverArgs, CC1Args, Dir);
+  if (!Dirs.empty())
+return;
+}
   }
 
   // When built with access to the proper Windows APIs, try to actually find
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4746,6 +4746,8 @@
 def _SLASH_Tp : CLCompileJoinedOrSeparate<"Tp">,
   HelpText<"Treat  as C++ source file">, MetaVarName<"">;
 def _SLASH_TP : CLCompileFlag<"TP">, HelpText<"Treat all source files as C++">;
+def _SLASH_vctoolsdir : CLJoinedOrSeparate<"vctoolsdir">,
+  HelpText<"Path to the 

[clang] 0870471 - Add clang-cl "vctoolsdir" option to specify the location of the msvc toolchain

2020-08-26 Thread Hans Wennborg via cfe-commits

Author: Zachary Henkel
Date: 2020-08-26T15:09:18+02:00
New Revision: 08704714421086e775a297339fc60963cc07eec9

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

LOG: Add clang-cl "vctoolsdir" option to specify the location of the msvc 
toolchain

Add an option to directly specify where the msvc toolchain lives for
clang-cl and avoid unwanted file and registry probes.

Differential revision: https://reviews.llvm.org/D85998

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/MSVC.cpp
clang/test/Driver/cl-options.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index b5a158cd3336..0bb5df726712 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4746,6 +4746,8 @@ def _SLASH_TC : CLCompileFlag<"TC">, HelpText<"Treat all 
source files as C">;
 def _SLASH_Tp : CLCompileJoinedOrSeparate<"Tp">,
   HelpText<"Treat  as C++ source file">, MetaVarName<"">;
 def _SLASH_TP : CLCompileFlag<"TP">, HelpText<"Treat all source files as C++">;
+def _SLASH_vctoolsdir : CLJoinedOrSeparate<"vctoolsdir">,
+  HelpText<"Path to the VCToolChain">, MetaVarName<"">;
 def _SLASH_volatile_iso : Option<["/", "-"], "volatile:iso", KIND_FLAG>,
   Group<_SLASH_volatile_Group>, Flags<[CLOption, DriverOption]>,
   HelpText<"Volatile loads and stores have standard semantics">;

diff  --git a/clang/lib/Driver/ToolChains/MSVC.cpp 
b/clang/lib/Driver/ToolChains/MSVC.cpp
index 6b3c00e2ab6d..7faccdff6bee 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -66,6 +66,20 @@ using namespace llvm::opt;
 static bool getSystemRegistryString(const char *keyPath, const char *valueName,
 std::string , std::string *phValue);
 
+// Check command line arguments to try and find a toolchain.
+static bool
+findVCToolChainViaCommandLine(const ArgList , std::string ,
+  MSVCToolChain::ToolsetLayout ) {
+  // Don't validate the input; trust the value supplied by the user.
+  // The primary motivation is to prevent unnecessary file and registry access.
+  if (Arg *A = Args.getLastArg(options::OPT__SLASH_vctoolsdir)) {
+Path = A->getValue();
+VSLayout = MSVCToolChain::ToolsetLayout::VS2017OrNewer;
+return true;
+  }
+  return false;
+}
+
 // Check various environment variables to try and find a toolchain.
 static bool findVCToolChainViaEnvironment(std::string ,
   MSVCToolChain::ToolsetLayout 
) {
@@ -747,11 +761,12 @@ MSVCToolChain::MSVCToolChain(const Driver , const 
llvm::Triple ,
   if (getDriver().getInstalledDir() != getDriver().Dir)
 getProgramPaths().push_back(getDriver().Dir);
 
-  // Check the environment first, since that's probably the user telling us
-  // what they want to use.
-  // Failing that, just try to find the newest Visual Studio version we can
-  // and use its default VC toolchain.
-  findVCToolChainViaEnvironment(VCToolChainPath, VSLayout) ||
+  // Check the command line first, that's the user explicitly telling us what 
to
+  // use. Check the environment next, in case we're being invoked from a VS
+  // command prompt. Failing that, just try to find the newest Visual Studio
+  // version we can and use its default VC toolchain.
+  findVCToolChainViaCommandLine(Args, VCToolChainPath, VSLayout) ||
+  findVCToolChainViaEnvironment(VCToolChainPath, VSLayout) ||
   findVCToolChainViaSetupConfig(VCToolChainPath, VSLayout) ||
   findVCToolChainViaRegistry(VCToolChainPath, VSLayout);
 }
@@ -1263,15 +1278,18 @@ void MSVCToolChain::AddClangSystemIncludeArgs(const 
ArgList ,
 return;
 
   // Honor %INCLUDE%. It should know essential search paths with vcvarsall.bat.
-  if (llvm::Optional cl_include_dir =
-  llvm::sys::Process::GetEnv("INCLUDE")) {
-SmallVector Dirs;
-StringRef(*cl_include_dir)
-.split(Dirs, ";", /*MaxSplit=*/-1, /*KeepEmpty=*/false);
-for (StringRef Dir : Dirs)
-  addSystemInclude(DriverArgs, CC1Args, Dir);
-if (!Dirs.empty())
-  return;
+  // Skip if the user expressly set a vctoolsdir
+  if (!DriverArgs.getLastArg(options::OPT__SLASH_vctoolsdir)) {
+if (llvm::Optional cl_include_dir =
+llvm::sys::Process::GetEnv("INCLUDE")) {
+  SmallVector Dirs;
+  StringRef(*cl_include_dir)
+  .split(Dirs, ";", /*MaxSplit=*/-1, /*KeepEmpty=*/false);
+  for (StringRef Dir : Dirs)
+addSystemInclude(DriverArgs, CC1Args, Dir);
+  if (!Dirs.empty())
+return;
+}
   }
 
   // When built with access to the proper Windows APIs, try to actually find

diff  --git a/clang/test/Driver/cl-options.c 

[PATCH] D70378: [LLD][COFF] Cover usage of LLD as a library

2020-08-26 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added inline comments.



Comment at: clang/tools/driver/driver.cpp:537
+  // When running in integrated-cc1 mode, the CrashRecoveryContext returns
+  // the same code as if the program crashed. On Unix, that is codes >128.
+  IsCrash |= CommandRes > 128;

MaskRay wrote:
> (From a non-native speaker)
> 
> "that is codes >128" Should the singular form be used?
Rephrased.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70378

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


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

2020-08-26 Thread Whisperity via Phabricator via cfe-commits
whisperity added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:509
+  The currently beta-version tool is found in
+  (llvm-project repository)/clang/utils/analyzer/SATest.py.
 

Let's put this into monospace font too. Otherwise LGTM from a readability 
standpoint.


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] D86465: [analyzer][solver] Redesign constraint ranges data structure

2020-08-26 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:118-123
+/// Create a new set with all ranges from both LHS and RHS.
+/// Possible intersections are not checked here.
+///
+/// Complexity: O(N + M)
+/// where N = size(LHS), M = size(RHS)
+RangeSet add(RangeSet LHS, RangeSet RHS);

vsavchenko wrote:
> steakhal wrote:
> > What about `merge` or `combine`? I know that `union` is a keyword thus we 
> > can not use.
> Maybe, but the real `union` function is not present.  And I think that in the 
> original code it is `add` to hint that it's not really a union and nothing 
> complex is done here.  Maybe something like `mergeUnchecked` would work.
Now I get it. Let's keep it as-is.
Might worth highlighting the `**with all ranges from both**` part though.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:170-174
+/// Delete the given point from the range set.
+///
+/// Complexity: O(N)
+/// where N = size(From)
+RangeSet deletePoint(const llvm::APSInt , RangeSet From);

vsavchenko wrote:
> steakhal wrote:
> > Why does this operation take `O(N)` time? Shouldn't be `O(logN)` instead?
> We still create a copy of an old vector to maintain persistence, that's why 
> it's `O(N)`.
Thanks. BTW I just forgot about this comment :D



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:272-273
+private:
+  RangeSet(ContainerType *RawContainer) : Impl(RawContainer) {}
+  RangeSet(UnderlyingType Ptr) : Impl(Ptr) {}
 

vsavchenko wrote:
> steakhal wrote:
> > Missing `explicit`.
> More like missing `/* implicit */` because it is intentional
It doesn't have a too long identifier.
The users can always refer to it `auto R = RangeSet(...)`, so we still don't 
repeat ourselves.
Do you have any particular counterexample?
Probably the tests will become slightly more bloated but eh. whatever.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:177-178
+
+  --It;
+  return It->Includes(Point);
+}

vsavchenko wrote:
> steakhal wrote:
> > 
> I don't really see the benefits of one way over another and as I said in 
> another comment, I don't really like to pay for an extra copy with iterators 
> as just a rule of thumb.
Iterators supposed to be cheap to copy. That is why we take them by value all 
over the place.
IMO it should boil down to the very same codegen in both cases. 
https://godbolt.org/z/8x1zMh

To prove it, I disassembled the following functions in release clang build:
```lang=C++
// _Z21raw_rangeset_iteratorN5clang4ento8RangeSetE
const llvm::APSInt _rangeset_iterator(RangeSet What) {
  RangeSet::iterator It = What.begin();
  --It;
  return It->To();
}
// _Z26std_prev_rangeset_iteratorN5clang4ento8RangeSetE
const llvm::APSInt _prev_rangeset_iterator(RangeSet What) {
  RangeSet::iterator It = What.begin();
  return std::prev(It)->To();
}
```

```lang=asm
(gdb) disassemble _Z21raw_rangeset_iteratorN5clang4ento8RangeSetE
Dump of assembler code for function 
raw_rangeset_iterator(clang::ento::RangeSet):
   0x06102b10 <+0>: mov(%rdi),%rax
   0x06102b13 <+3>: mov-0x8(%rax),%rax
   0x06102b17 <+7>: retq   
End of assembler dump.
```

```lang=asm
(gdb) disassemble _Z26std_prev_rangeset_iteratorN5clang4ento8RangeSetE
Dump of assembler code for function 
_Z26std_prev_rangeset_iteratorN5clang4ento8RangeSetE:
   0x061040d0 <+0>: mov(%rdi),%rax
   0x061040d3 <+3>: mov-0x8(%rax),%rax
   0x061040d7 <+7>: retq   
End of assembler dump.
```



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:322-325
+  auto swap = [, , , ]() {
+std::swap(First, Second);
+std::swap(FirstEnd, SecondEnd);
+  };

vsavchenko wrote:
> steakhal wrote:
> > It could definitely bear a longer name.
> I think that there is nothing wrong in spelling out `std::swap` twice.
> And do we have a naming convention for lambdas, is it a variable or a 
> function from a naming perspective?
That's a good question :)
I would say that its a variable, since you can mark it `const`, otherwise you 
could overwrite it. xD But that's a different story I think.
About the `swap` thingie, its a good practice to respect ADL for functions 
which know to be used via ADL.
Even if we don't depend on ADL in this particular case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86465

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


[PATCH] D81083: [Clang] Allow "vector_size" applied to Booleans

2020-08-26 Thread Simon Moll via Phabricator via cfe-commits
simoll added a comment.

In D81083#2237284 , @rsmith wrote:

> 

Thanks for dropping by!

> Have you considered using the `ext_vector_type` attribute instead of 
> `vector_size` for this? That would have a couple of advantages:
>
> - It's not a GCC attribute, so there's no risk that GCC would give different 
> meaning to the same syntax (such as using one byte per vector element, which 
> would be the natural meaning for a vector of `bool` as an extension of 
> existing functionality).
> - `ext_vector_type` takes as an argument a number of elements, not a size in 
> bytes, so you could support vectors of non-multiple-of-8 `bool`s.

Whichever solution is going to land in Clang, we will end up in the situation 
that Clang supports bool vectors and GCC does not. Any code that uses this 
feature and is supposed to compile with GCC will need some `#ifdef` guard. This 
is why i am not too worried about (ab-)using the vector_size attribute for this.

> However, using either an `ext_vector_type` of `bool` or a `vector_size` of 
> `bool` would still seem problematic in a couple of other ways:
>
> - Those types always produce a vector whose element type is the specified 
> type; you can form an lvalue denoting the element, the element is always 
> represented the same as the underlying type, and you can pun between a vector 
> of N `T` and an array of N `T`. GCC even permits forming a pointer or 
> reference to a vector element, and you should assume that Clang will 
> eventually support that too. That would not be possible for `bool` if packed 
> as a bit-vector.
> - You can already perform logical operations between our existing vector 
> types -- for example, comparing two vectors of 4 `int`s. If vectors of `bool` 
> are valid, it would be logical and natural to expect a vector of 4 `bool`s to 
> have some connection to the result of such a comparison, but it won't: the 
> type of a comparison of two vectors of 4 `int`s is a vector of 4 `int`s each 
> of which is either 0 or -1, and we can't convert that to a vector of 4 
> `bool`s represented as our existing vector types, because such conversions 
> would be interpreted as bitcasts, and we'd reject because the bitwidth of the 
> vectors is different.
> - Vectors of integer types (such as `bool`) generally support arithmetic 
> operators, which you presumably do not want to support here.
> - Our existing vector types carry a lot of baggage (for example, lax vector 
> conversions, and the egregious attribute-on-typedef-changes-the-type hack) 
> that we would not want a new type to include.

I agree that the vector_size syntax for bool vectors raises some expectations 
on the behavior of the bool vector. However, i see this more as an issue of 
proper documentation. The moment somebody uses vector_size attributes they know 
they are deep in compiler-extension land and far from standard C/C++ semantics.
Now about the vector representation issues in Clang and how we could make this 
work for bool vectors: earlier, i suggested that we could introduce a 
Clang-internal `Bit` datatype that can only be used as a vector element type. 
By doing so, we wouldn't violate the invariant that `bits(vector) == 
size_of_vector * bits(element_type)`.

> So I think you should seriously consider using a new syntax to form a 
> bit-vector type. It seems to me that an N-bit bit-vector is quite similar to 
> an `_ExtInt(N)`, but without the arithmetic support and with a different 
> expected IR type. Maybe following that syntactic path and adding 
> `_BitVector(N)` syntax would work out better?

I am open to a different syntax, if piggy backing on the vector_size syntax is 
the main point of contention. Up to now, the plan was to have vector_size bool 
now and work on a proper bool vector type to replace it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81083

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


[PATCH] D70378: [LLD][COFF] Cover usage of LLD as a library

2020-08-26 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea updated this revision to Diff 287952.
aganea marked 2 inline comments as done.
aganea added a comment.

Address comments.
Added a CrashRecoveryTest.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70378

Files:
  clang/tools/driver/driver.cpp
  lld/COFF/Driver.cpp
  lld/COFF/Writer.cpp
  lld/COFF/Writer.h
  lld/Common/ErrorHandler.cpp
  lld/ELF/Driver.cpp
  lld/MachO/Driver.cpp
  lld/include/lld/Common/Driver.h
  lld/include/lld/Common/ErrorHandler.h
  lld/lib/Driver/DarwinLdDriver.cpp
  lld/test/COFF/dll.test
  lld/test/COFF/guardcf-lto.ll
  lld/test/COFF/lit.local.cfg
  lld/tools/lld/lld.cpp
  lld/wasm/Driver.cpp
  llvm/include/llvm/Support/CrashRecoveryContext.h
  llvm/include/llvm/Support/Signals.h
  llvm/lib/Support/CrashRecoveryContext.cpp
  llvm/lib/Support/Unix/Signals.inc
  llvm/lib/Support/Windows/Signals.inc
  llvm/unittests/Support/CrashRecoveryTest.cpp

Index: llvm/unittests/Support/CrashRecoveryTest.cpp
===
--- llvm/unittests/Support/CrashRecoveryTest.cpp
+++ llvm/unittests/Support/CrashRecoveryTest.cpp
@@ -109,4 +109,11 @@
   EXPECT_TRUE(CrashRecoveryContext().RunSafely(outputString));
 }
 
+TEST(CrashRecoveryTest, Abort) {
+  llvm::CrashRecoveryContext::Enable();
+  auto A = []() { abort(); };
+  EXPECT_FALSE(CrashRecoveryContext().RunSafely(A));
+  // Test a second time to ensure we reinstall the abort signal handler.
+  EXPECT_FALSE(CrashRecoveryContext().RunSafely(A));
+}
 #endif
Index: llvm/lib/Support/Windows/Signals.inc
===
--- llvm/lib/Support/Windows/Signals.inc
+++ llvm/lib/Support/Windows/Signals.inc
@@ -868,3 +868,5 @@
  #pragma GCC diagnostic warning "-Wformat"
  #pragma GCC diagnostic warning "-Wformat-extra-args"
 #endif
+
+void sys::unregisterHandlers() {}
Index: llvm/lib/Support/Unix/Signals.inc
===
--- llvm/lib/Support/Unix/Signals.inc
+++ llvm/lib/Support/Unix/Signals.inc
@@ -331,7 +331,7 @@
 registerHandler(S, SignalKind::IsInfo);
 }
 
-static void UnregisterHandlers() {
+void sys::unregisterHandlers() {
   // Restore all of the signal handlers to how they were before we showed up.
   for (unsigned i = 0, e = NumRegisteredSignals.load(); i != e; ++i) {
 sigaction(RegisteredSignalInfo[i].SigNo,
@@ -367,7 +367,7 @@
   // crashes when we return and the signal reissues.  This also ensures that if
   // we crash in our signal handler that the program will terminate immediately
   // instead of recursing in the signal handler.
-  UnregisterHandlers();
+  sys::unregisterHandlers();
 
   // Unmask all potentially blocked kill signals.
   sigset_t SigMask;
Index: llvm/lib/Support/CrashRecoveryContext.cpp
===
--- llvm/lib/Support/CrashRecoveryContext.cpp
+++ llvm/lib/Support/CrashRecoveryContext.cpp
@@ -97,6 +97,13 @@
 
 CrashRecoveryContextCleanup::~CrashRecoveryContextCleanup() {}
 
+CrashRecoveryContext::CrashRecoveryContext() {
+  // On Windows, if abort() was previously triggered (and caught by a previous
+  // CrashRecoveryContext) the Windows CRT removes our installed signal handler,
+  // so we need to install it again.
+  sys::DisableSystemDialogsOnCrash();
+}
+
 CrashRecoveryContext::~CrashRecoveryContext() {
   // Reclaim registered resources.
   CrashRecoveryContextCleanup *i = head;
@@ -370,9 +377,10 @@
   sigaddset(, Signal);
   sigprocmask(SIG_UNBLOCK, , nullptr);
 
-  // As per convention, -2 indicates a crash or timeout as opposed to failure to
-  // execute (see llvm/include/llvm/Support/Program.h)
-  int RetCode = -2;
+  // Return the same error code as if the program crashed, as mentioned in the
+  // section "Exit Status for Commands":
+  // https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html
+  int RetCode = 128 + Signal;
 
   // Don't consider a broken pipe as a crash (see clang/lib/Driver/Driver.cpp)
   if (Signal == SIGPIPE)
Index: llvm/include/llvm/Support/Signals.h
===
--- llvm/include/llvm/Support/Signals.h
+++ llvm/include/llvm/Support/Signals.h
@@ -115,6 +115,8 @@
   /// Context is a system-specific failure context: it is the signal type on
   /// Unix; the ExceptionContext on Windows.
   void CleanupOnSignal(uintptr_t Context);
+
+  void unregisterHandlers();
 } // End sys namespace
 } // End llvm namespace
 
Index: llvm/include/llvm/Support/CrashRecoveryContext.h
===
--- llvm/include/llvm/Support/CrashRecoveryContext.h
+++ llvm/include/llvm/Support/CrashRecoveryContext.h
@@ -44,11 +44,11 @@
 /// executed in any case, whether crash occurs or not. These actions may be used
 /// to reclaim resources in the case of crash.
 class CrashRecoveryContext {
-  

[PATCH] D86629: [AVR][clang] Pass the address of the data section to the linker for ATmega328

2020-08-26 Thread Dylan McKay via Phabricator via cfe-commits
dylanmckay created this revision.
dylanmckay added a reviewer: aykevl.
Herald added a subscriber: Jim.
Herald added a project: clang.
dylanmckay requested review of this revision.

This patch modifies the Clang AVR toolchain so that it always passes
the '-Tdata=0x800100' to the linker for ATmega328 devices. This matches
AVR-GCC behaviour, and also corresponds to the address of the start of
the data section in data space according to the ATmega328 datasheet.

Without this, clang does not produce a valid ATmega328 binary.

When targeting all non-ATmega328 chips, a warning will be emitted due to
the fact that proper handling for the chips data section address is
not yet implemented.

I've held off adding other microcontrollers for now, mostly because the
AVR toolchain logic is smeared across LLVM core TableGen files, and two Clang
libraries. The 'family detection' logic is also only implemented for
ATmega328 at the moment, for similar reasons.

In the future, I aim to write an RFC to llvm-dev to find a better way
for LLVM to expose target-specific details such as these to compiler
frontends.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86629

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/ToolChains/AVR.cpp


Index: clang/lib/Driver/ToolChains/AVR.cpp
===
--- clang/lib/Driver/ToolChains/AVR.cpp
+++ clang/lib/Driver/ToolChains/AVR.cpp
@@ -13,6 +13,7 @@
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/Options.h"
 #include "llvm/ADT/Optional.h"
+#include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/MC/MCSubtargetInfo.h"
 #include "llvm/MC/SubtargetFeature.h"
@@ -36,6 +37,13 @@
   .Default(Optional());
 }
 
+llvm::Optional GetMcuSectionAddressData(StringRef MCU) {
+  return llvm::StringSwitch>(MCU)
+  .Case("atmega328", Optional(0x800100))
+  .Case("atmega328p", Optional(0x800100))
+  .Default(Optional());
+}
+
 const StringRef PossibleAVRLibcLocations[] = {
 "/usr/avr",
 "/usr/lib/avr",
@@ -103,6 +111,7 @@
   // Compute information about the target AVR.
   std::string CPU = getCPUName(Args, getToolChain().getTriple());
   llvm::Optional FamilyName = GetMcuFamilyName(CPU);
+  llvm::Optional SectionAddressData = GetMcuSectionAddressData(CPU);
 
   std::string Linker = getToolChain().GetProgramPath(getShortName());
   ArgStringList CmdArgs;
@@ -118,6 +127,17 @@
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   getToolChain().AddFilePathLibArgs(Args, CmdArgs);
 
+  if (SectionAddressData.hasValue()) {
+std::string DataSectionArg = std::string("-Tdata=0x") +
+ 
llvm::utohexstr(SectionAddressData.getValue());
+CmdArgs.push_back(Args.MakeArgString(DataSectionArg));
+  } else {
+// We do not have an entry for this CPU in the address mapping table yet.
+getToolChain().getDriver().Diag(
+diag::warn_drv_avr_linker_section_addresses_not_implemented)
+<< CPU;
+  }
+
   // If the family name is known, we can link with the device-specific libgcc.
   // Without it, libgcc will simply not be linked. This matches avr-gcc
   // behavior.
Index: clang/include/clang/Basic/DiagnosticDriverKinds.td
===
--- clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -44,6 +44,10 @@
 def warn_drv_avr_family_linking_stdlibs_not_implemented: Warning<
   "support for linking stdlibs for microcontroller '%0' is not implemented">,
   InGroup;
+def warn_drv_avr_linker_section_addresses_not_implemented: Warning<
+  "support for passing the data section address to the linker for "
+  "microcontroller '%0' is not implemented">,
+  InGroup;
 def warn_drv_avr_stdlib_not_linked: Warning<
   "standard library not linked and so no interrupt vector table or "
   "compiler runtime routines will be linked">,


Index: clang/lib/Driver/ToolChains/AVR.cpp
===
--- clang/lib/Driver/ToolChains/AVR.cpp
+++ clang/lib/Driver/ToolChains/AVR.cpp
@@ -13,6 +13,7 @@
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/Options.h"
 #include "llvm/ADT/Optional.h"
+#include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/MC/MCSubtargetInfo.h"
 #include "llvm/MC/SubtargetFeature.h"
@@ -36,6 +37,13 @@
   .Default(Optional());
 }
 
+llvm::Optional GetMcuSectionAddressData(StringRef MCU) {
+  return llvm::StringSwitch>(MCU)
+  .Case("atmega328", Optional(0x800100))
+  .Case("atmega328p", Optional(0x800100))
+  .Default(Optional());
+}
+
 const StringRef PossibleAVRLibcLocations[] = {
 "/usr/avr",
 "/usr/lib/avr",
@@ -103,6 +111,7 @@
   // Compute information about the target AVR.
   std::string CPU = getCPUName(Args, getToolChain().getTriple());
   llvm::Optional FamilyName = 

[PATCH] D85984: [analyzer] Add a new checker alpha.cplusplus.CPlusPlus11Lock

2020-08-26 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov updated this revision to Diff 287997.
ASDenysPetrov edited the summary of this revision.
ASDenysPetrov added a comment.

Added support of:

- std::timed_mutex
- std::recursive_timed_mutex
- std::shared_mutex
- std::shared_timed_mutex


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

https://reviews.llvm.org/D85984

Files:
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/PthreadLockChecker.cpp
  clang/test/Analysis/Checkers/CPlusPlus11LockChecker.cpp

Index: clang/test/Analysis/Checkers/CPlusPlus11LockChecker.cpp
===
--- /dev/null
+++ clang/test/Analysis/Checkers/CPlusPlus11LockChecker.cpp
@@ -0,0 +1,621 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=alpha.cplusplus.CPlusPlus11Lock -verify %s
+
+namespace std {
+
+struct mutex {
+  void lock();
+  bool try_lock();
+  void unlock();
+};
+
+struct timed_mutex {
+  void lock();
+  bool try_lock();
+  void unlock();
+};
+
+struct recursive_mutex {
+  void lock();
+  bool try_lock();
+  void unlock();
+};
+
+struct recursive_timed_mutex {
+  void lock();
+  bool try_lock();
+  void unlock();
+};
+
+struct shared_mutex {
+  void lock();
+  bool try_lock();
+  void unlock();
+};
+
+struct shared_timed_mutex {
+  void lock();
+  bool try_lock();
+  void unlock();
+};
+
+template 
+struct lock_guard {
+  T 
+  lock_guard(T ) : t(m) {
+t.lock();
+  }
+  ~lock_guard() {
+t.unlock();
+  }
+};
+} // namespace std
+
+std::mutex m1;
+std::mutex m2;
+
+// mutex ok
+
+void m_ok1() {
+  m1.lock(); // no-warning
+}
+
+void m_ok2() {
+  m1.unlock(); // no-warning
+}
+
+void m_ok3() {
+  m1.lock();   // no-warning
+  m1.unlock(); // no-warning
+}
+
+void m_ok4() {
+  m1.lock();   // no-warning
+  m1.unlock(); // no-warning
+  m1.lock();   // no-warning
+  m1.unlock(); // no-warning
+}
+
+void m_ok5() {
+  m1.lock();   // no-warning
+  m1.unlock(); // no-warning
+  m2.lock();   // no-warning
+  m2.unlock(); // no-warning
+}
+
+void m_ok6(void) {
+  m1.lock();   // no-warning
+  m2.lock();   // no-warning
+  m2.unlock(); // no-warning
+  m1.unlock(); // no-warning
+}
+
+void m_ok7(void) {
+  if (m1.try_lock()) // no-warning
+m1.unlock(); // no-warning
+}
+
+void m_ok8(void) {
+  m1.unlock();   // no-warning
+  if (m1.try_lock()) // no-warning
+m1.unlock(); // no-warning
+}
+
+void m_ok9(void) {
+  if (!m1.try_lock()) // no-warning
+m1.lock();// no-warning
+  m1.unlock();// no-warning
+}
+
+void m_ok10() {
+  std::lock_guard gl1(m1); // no-warning
+}
+
+// mutex bad
+
+void m_bad1() {
+  m1.lock(); // no-warning
+  m1.lock(); // expected-warning{{This lock has already been acquired}}
+}
+
+void m_bad2() {
+  m1.lock();   // no-warning
+  m1.unlock(); // no-warning
+  m1.unlock(); // expected-warning {{This lock has already been unlocked}}
+}
+
+void m_bad3() {
+  m1.lock();   // no-warning
+  m2.lock();   // no-warning
+  m1.unlock(); // expected-warning {{This was not the most recently acquired lock. Possible lock order reversal}}
+  m2.unlock(); // no-warning
+}
+
+void m_bad5() {
+  while (true)
+m1.unlock(); // expected-warning {{This lock has already been unlocked}}
+}
+
+void m_bad6() {
+  while (true)
+m1.lock(); // expected-warning{{This lock has already been acquired}}
+}
+
+void m_bad7() {
+  if (m1.try_lock()) // no-warning
+m1.lock();   // expected-warning{{This lock has already been acquired}}
+}
+
+std::timed_mutex tm1;
+std::timed_mutex tm2;
+
+// timed_mutex ok
+
+void tm_ok1() {
+  tm1.lock(); // no-warning
+}
+
+void tm_ok2() {
+  tm1.unlock(); // no-warning
+}
+
+void tm_ok3() {
+  tm1.lock();   // no-warning
+  tm1.unlock(); // no-warning
+}
+
+void tm_ok4() {
+  tm1.lock();   // no-warning
+  tm1.unlock(); // no-warning
+  tm1.lock();   // no-warning
+  tm1.unlock(); // no-warning
+}
+
+void tm_ok5() {
+  tm1.lock();   // no-warning
+  tm1.unlock(); // no-warning
+  tm2.lock();   // no-warning
+  tm2.unlock(); // no-warning
+}
+
+void tm_ok6(void) {
+  tm1.lock();   // no-warning
+  tm2.lock();   // no-warning
+  tm2.unlock(); // no-warning
+  tm1.unlock(); // no-warning
+}
+
+void tm_ok7(void) {
+  if (tm1.try_lock()) // no-warning
+tm1.unlock(); // no-warning
+}
+
+void tm_ok8(void) {
+  tm1.unlock();   // no-warning
+  if (tm1.try_lock()) // no-warning
+tm1.unlock(); // no-warning
+}
+
+void tm_ok9(void) {
+  if (!tm1.try_lock()) // no-warning
+tm1.lock();// no-warning
+  tm1.unlock();// no-warning
+}
+
+void tm_ok10() {
+  std::lock_guard gl(tm1); // no-warning
+}
+
+// timed_mutex bad
+
+void tm_bad1() {
+  tm1.lock(); // no-warning
+  tm1.lock(); // expected-warning{{This lock has already been acquired}}
+}
+
+void tm_bad2() {
+  tm1.lock();   // no-warning
+  tm1.unlock(); // no-warning
+  tm1.unlock(); // expected-warning {{This lock has already been unlocked}}
+}
+
+void tm_bad3() {
+  tm1.lock();   // 

[PATCH] D86600: [SyntaxTree] Migrate `ParamatersAndQualifiers` to use the new List API

2020-08-26 Thread Eduardo Caldas via Phabricator via cfe-commits
eduucaldas updated this revision to Diff 288010.
eduucaldas added a comment.

Add test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86600

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Nodes.cpp
  clang/lib/Tooling/Syntax/Tree.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
@@ -85,15 +85,16 @@
   | |-'foo'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'a'
-  |   |-','
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'b'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | |-SimpleDeclaration List_element
+  |   | | |-'int'
+  |   | | `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | |   `-'a'
+  |   | |-',' List_delimiter
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'int'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | `-'b'
   |   `-')' CloseParen
   `-CompoundStatement
 |-'{' OpenParen
@@ -3162,8 +3163,9 @@
   | |-'_c'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | `-'char'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | `-SimpleDeclaration List_element
+  |   |   `-'char'
   |   `-')' CloseParen
   `-';'
 )txt"));
@@ -3219,11 +3221,12 @@
 | |-'='
 | `-ParametersAndQualifiers
 |   |-'(' OpenParen
-|   |-SimpleDeclaration ParametersAndQualifiers_parameter
-|   | |-'const'
-|   | |-'X'
-|   | `-SimpleDeclarator SimpleDeclaration_declarator
-|   |   `-'&'
+|   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+|   | `-SimpleDeclaration List_element
+|   |   |-'const'
+|   |   |-'X'
+|   |   `-SimpleDeclarator SimpleDeclaration_declarator
+|   | `-'&'
 |   `-')' CloseParen
 `-';'
 )txt"}));
@@ -3249,14 +3252,15 @@
   | |-'+'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | `-'X'
-  |   |-','
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'const'
-  |   | |-'X'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   `-'&'
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | |-SimpleDeclaration List_element
+  |   | | `-'X'
+  |   | |-',' List_delimiter
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'const'
+  |   |   |-'X'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | `-'&'
   |   `-')' CloseParen
   `-';'
 )txt"}));
@@ -3885,16 +3889,17 @@
   | |-'f'
   | `-ParametersAndQualifiers
   |   |-'(' OpenParen
-  |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-  |   | |-'int'
-  |   | `-SimpleDeclarator SimpleDeclaration_declarator
-  |   |   |-'xs'
-  |   |   `-ArraySubscript
-  |   | |-'[' OpenParen
-  |   | |-'static'
-  |   | |-IntegerLiteralExpression ArraySubscript_sizeExpression
-  |   | | `-'10' LiteralToken
-  |   | `-']' CloseParen
+  |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+  |   | `-SimpleDeclaration List_element
+  |   |   |-'int'
+  |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+  |   | |-'xs'
+  |   | `-ArraySubscript
+  |   |   |-'[' OpenParen
+  |   |   |-'static'
+  |   |   |-IntegerLiteralExpression ArraySubscript_sizeExpression
+  |   |   | `-'10' LiteralToken
+  |   |   `-']' CloseParen
   |   `-')' CloseParen
   `-';'
 )txt"));
@@ -3933,10 +3938,11 @@
 | | |-'func1'
 | | `-ParametersAndQualifiers
 | |   |-'(' OpenParen
-| |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-| |   | |-'int'
-| |   | `-SimpleDeclarator SimpleDeclaration_declarator
-| |   |   `-'a'
+| |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+| |   | `-SimpleDeclaration List_element
+| |   |   |-'int'
+| |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+| |   | `-'a'
 | |   `-')' CloseParen
 | `-';'
 |-SimpleDeclaration
@@ -3945,11 +3951,12 @@
 | | |-'func2'
 | | `-ParametersAndQualifiers
 | |   |-'(' OpenParen
-| |   |-SimpleDeclaration ParametersAndQualifiers_parameter
-| |   | |-'int'
-| |   | `-SimpleDeclarator SimpleDeclaration_declarator
-| |   |   |-'*'
-| |   |   `-'ap'
+| |   |-ParameterDeclarationList ParametersAndQualifiers_parameters
+| |   | `-SimpleDeclaration List_element
+| |   |   |-'int'
+| |   |   `-SimpleDeclarator SimpleDeclaration_declarator
+| |   | |-'*'
+| |   | 

[PATCH] D85431: [analyzer] Implement a new checker ThreadPrimitivesChecker

2020-08-26 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov abandoned this revision.
ASDenysPetrov added a comment.

Guys!
I've moved my work to PthreadLockChecker https://reviews.llvm.org/D85984. You 
are welcome to look at it.


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

https://reviews.llvm.org/D85431

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


[PATCH] D83472: [SystemZ/ZOS] Add header file to encapsulate use of

2020-08-26 Thread Kai Nacke via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGed07e1fe0ffd: [SystemZ/ZOS] Add header file to encapsulate 
use of sysexits.h (authored by Kai).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D83472?vs=278146=288015#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83472

Files:
  clang/lib/Driver/Driver.cpp
  llvm/cmake/config-ix.cmake
  llvm/include/llvm/Config/config.h.cmake
  llvm/include/llvm/Support/ExitCodes.h
  llvm/lib/Support/CrashRecoveryContext.cpp
  llvm/lib/Support/Unix/Signals.inc

Index: llvm/lib/Support/Unix/Signals.inc
===
--- llvm/lib/Support/Unix/Signals.inc
+++ llvm/lib/Support/Unix/Signals.inc
@@ -36,6 +36,7 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/Config/config.h"
 #include "llvm/Demangle/Demangle.h"
+#include "llvm/Support/ExitCodes.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FileUtilities.h"
 #include "llvm/Support/Format.h"
@@ -46,7 +47,6 @@
 #include "llvm/Support/raw_ostream.h"
 #include 
 #include 
-#include 
 #ifdef HAVE_BACKTRACE
 # include BACKTRACE_HEADER // For backtrace().
 #endif
Index: llvm/lib/Support/CrashRecoveryContext.cpp
===
--- llvm/lib/Support/CrashRecoveryContext.cpp
+++ llvm/lib/Support/CrashRecoveryContext.cpp
@@ -9,14 +9,12 @@
 #include "llvm/Support/CrashRecoveryContext.h"
 #include "llvm/Config/llvm-config.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/ExitCodes.h"
 #include "llvm/Support/ManagedStatic.h"
 #include "llvm/Support/Signals.h"
 #include "llvm/Support/ThreadLocal.h"
 #include 
 #include 
-#if LLVM_ON_UNIX
-#include  // EX_IOERR
-#endif
 
 using namespace llvm;
 
Index: llvm/include/llvm/Support/ExitCodes.h
===
--- /dev/null
+++ llvm/include/llvm/Support/ExitCodes.h
@@ -0,0 +1,33 @@
+//===-- llvm/Support/ExitCodes.h - Exit codes for exit()  ---*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+/// This file contains definitions of exit codes for exit() function. They are
+/// either defined by sysexits.h if it is supported, or defined here if
+/// sysexits.h is not supported.
+///
+//===--===//
+
+#ifndef LLVM_SUPPORT_EXITCODES_H
+#define LLVM_SUPPORT_EXITCODES_H
+
+#include "llvm/Config/config.h"
+
+#if HAVE_SYSEXITS_H
+#include 
+#elif __MVS__
+//  does not exist on z/OS. The only value used in LLVM is
+// EX_IOERR, which is used to signal a special error condition (broken pipe).
+// Define the macro with its usual value from BSD systems, which is chosen to
+// not clash with more standard exit codes like 1.
+#define EX_IOERR 74
+#elif LLVM_ON_UNIX
+#error Exit code EX_IOERR not available
+#endif
+
+#endif
Index: llvm/include/llvm/Config/config.h.cmake
===
--- llvm/include/llvm/Config/config.h.cmake
+++ llvm/include/llvm/Config/config.h.cmake
@@ -208,6 +208,9 @@
 /* Define to 1 if you have the  header file. */
 #cmakedefine HAVE_SYS_TYPES_H ${HAVE_SYS_TYPES_H}
 
+/* Define to 1 if you have the  header file. */
+#cmakedefine HAVE_SYSEXITS_H ${HAVE_SYSEXITS_H}
+
 /* Define if the setupterm() function is supported this platform. */
 #cmakedefine LLVM_ENABLE_TERMINFO ${LLVM_ENABLE_TERMINFO}
 
Index: llvm/cmake/config-ix.cmake
===
--- llvm/cmake/config-ix.cmake
+++ llvm/cmake/config-ix.cmake
@@ -54,6 +54,7 @@
 check_include_file(sys/stat.h HAVE_SYS_STAT_H)
 check_include_file(sys/time.h HAVE_SYS_TIME_H)
 check_include_file(sys/types.h HAVE_SYS_TYPES_H)
+check_include_file(sysexits.h HAVE_SYSEXITS_H)
 check_include_file(termios.h HAVE_TERMIOS_H)
 check_include_file(unistd.h HAVE_UNISTD_H)
 check_include_file(valgrind/valgrind.h HAVE_VALGRIND_VALGRIND_H)
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -71,6 +71,7 @@
 #include "llvm/Option/Option.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/ExitCodes.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Host.h"
@@ -87,7 +88,6 @@
 #include 
 #if LLVM_ON_UNIX
 #include  // getpid
-#include  // EX_IOERR
 #endif
 
 using namespace clang::driver;

[clang] ed07e1f - [SystemZ/ZOS] Add header file to encapsulate use of

2020-08-26 Thread Kai Nacke via cfe-commits

Author: Kai Nacke
Date: 2020-08-26T12:44:30-04:00
New Revision: ed07e1fe0ffdb2c1dbff26ff4cf7558e0c419737

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

LOG: [SystemZ/ZOS] Add header file to encapsulate use of 

The non-standard header file `` provides some return values.
`EX_IOERR` is used to as a special value to signal a broken pipe to the clang 
driver.
On z/OS Unix System Services, this header file does not exists. This patch

- adds a check for ``, removing the dependency on `LLVM_ON_UNIX`
- adds a new header file `llvm/Support/ExitCodes`, which either includes
  `` or defines `EX_IOERR`
- updates the users of `EX_IOERR` to include the new header file

Reviewed By: hubert.reinterpretcast

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

Added: 
llvm/include/llvm/Support/ExitCodes.h

Modified: 
clang/lib/Driver/Driver.cpp
llvm/cmake/config-ix.cmake
llvm/include/llvm/Config/config.h.cmake
llvm/lib/Support/CrashRecoveryContext.cpp
llvm/lib/Support/Unix/Signals.inc

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 45b5907126b9..93b6d8464900 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -71,6 +71,7 @@
 #include "llvm/Option/Option.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/ExitCodes.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Host.h"
@@ -87,7 +88,6 @@
 #include 
 #if LLVM_ON_UNIX
 #include  // getpid
-#include  // EX_IOERR
 #endif
 
 using namespace clang::driver;

diff  --git a/llvm/cmake/config-ix.cmake b/llvm/cmake/config-ix.cmake
index 11abb32c9072..6b92180b739e 100644
--- a/llvm/cmake/config-ix.cmake
+++ b/llvm/cmake/config-ix.cmake
@@ -54,6 +54,7 @@ check_include_file(sys/resource.h HAVE_SYS_RESOURCE_H)
 check_include_file(sys/stat.h HAVE_SYS_STAT_H)
 check_include_file(sys/time.h HAVE_SYS_TIME_H)
 check_include_file(sys/types.h HAVE_SYS_TYPES_H)
+check_include_file(sysexits.h HAVE_SYSEXITS_H)
 check_include_file(termios.h HAVE_TERMIOS_H)
 check_include_file(unistd.h HAVE_UNISTD_H)
 check_include_file(valgrind/valgrind.h HAVE_VALGRIND_VALGRIND_H)

diff  --git a/llvm/include/llvm/Config/config.h.cmake 
b/llvm/include/llvm/Config/config.h.cmake
index a65947bf24c4..aec8d08f30e7 100644
--- a/llvm/include/llvm/Config/config.h.cmake
+++ b/llvm/include/llvm/Config/config.h.cmake
@@ -208,6 +208,9 @@
 /* Define to 1 if you have the  header file. */
 #cmakedefine HAVE_SYS_TYPES_H ${HAVE_SYS_TYPES_H}
 
+/* Define to 1 if you have the  header file. */
+#cmakedefine HAVE_SYSEXITS_H ${HAVE_SYSEXITS_H}
+
 /* Define if the setupterm() function is supported this platform. */
 #cmakedefine LLVM_ENABLE_TERMINFO ${LLVM_ENABLE_TERMINFO}
 

diff  --git a/llvm/include/llvm/Support/ExitCodes.h 
b/llvm/include/llvm/Support/ExitCodes.h
new file mode 100644
index ..2715c5ca4128
--- /dev/null
+++ b/llvm/include/llvm/Support/ExitCodes.h
@@ -0,0 +1,33 @@
+//===-- llvm/Support/ExitCodes.h - Exit codes for exit()  ---*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+/// This file contains definitions of exit codes for exit() function. They are
+/// either defined by sysexits.h if it is supported, or defined here if
+/// sysexits.h is not supported.
+///
+//===--===//
+
+#ifndef LLVM_SUPPORT_EXITCODES_H
+#define LLVM_SUPPORT_EXITCODES_H
+
+#include "llvm/Config/config.h"
+
+#if HAVE_SYSEXITS_H
+#include 
+#elif __MVS__
+//  does not exist on z/OS. The only value used in LLVM is
+// EX_IOERR, which is used to signal a special error condition (broken pipe).
+// Define the macro with its usual value from BSD systems, which is chosen to
+// not clash with more standard exit codes like 1.
+#define EX_IOERR 74
+#elif LLVM_ON_UNIX
+#error Exit code EX_IOERR not available
+#endif
+
+#endif

diff  --git a/llvm/lib/Support/CrashRecoveryContext.cpp 
b/llvm/lib/Support/CrashRecoveryContext.cpp
index ec7d7d641dce..d4fd8216123f 100644
--- a/llvm/lib/Support/CrashRecoveryContext.cpp
+++ b/llvm/lib/Support/CrashRecoveryContext.cpp
@@ -9,14 +9,12 @@
 #include "llvm/Support/CrashRecoveryContext.h"
 #include "llvm/Config/llvm-config.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/ExitCodes.h"
 #include "llvm/Support/ManagedStatic.h"
 #include "llvm/Support/Signals.h"
 #include "llvm/Support/ThreadLocal.h"
 #include 
 

[PATCH] D86488: [X86] Default to -mtune=generic unless -march is passed to the driver. Add TuneCPU to the AST serialization

2020-08-26 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/lib/Serialization/ASTReader.cpp:395
 CHECK_TARGET_OPT(CPU, "target CPU");
+CHECK_TARGET_OPT(TuneCPU, "tune CPU");
+  }

erichkeane wrote:
> What does this string do?  Does there have to be a test for it?
It seems to be used by a diagnostic. But I couldn't find any tests for the 
diagnostic for "target CPU" that I could copy from.


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

https://reviews.llvm.org/D86488

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


[PATCH] D86626: [OpenCL][Docs] 10.x release notes

2020-08-26 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:267
 
-...
+- Added `cl_khr_extended_subgroup` to clang and the internal header.
+

cl_khr_extended_subgroups (ends with -s)?

But isn't it supposed to be `cl_khr_subgroup_extensions`? I am really confused 
now.



Comment at: clang/docs/ReleaseNotes.rst:275
+
+- Improved in command line options for fast relaxed math.
+

Drop "in".



Comment at: clang/docs/ReleaseNotes.rst:277
+
+- Improved `atomic_fetch_min/max` function in the internal header
+  (`opencl-c.h`).

functions


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

https://reviews.llvm.org/D86626

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


[PATCH] D86622: Fix failing tests after VCTOOLSDIR change

2020-08-26 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added a comment.

I've pushed one more fix: rG33ce275fc156c8b015acfad918937028b2cc235c 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86622

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


[PATCH] D86376: [HIP] Improve kernel launching latency

2020-08-26 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D86376#2236704 , @tra wrote:

> 



> It's still suspiciously high. AFAICT, config/push/pull is just an std::vector 
> push/pop. It should not take *that* long.  Few function calls should not lead 
> to microseconds of overhead, once linker has resolved the symbol, if they 
> come from a shared library.
> https://github.com/ROCm-Developer-Tools/HIP/blob/master/vdi/hip_platform.cpp#L590
>
> I wonder if it's the logging facilities that add all this overhead.

You are right. The 19 us are mostly due to overhead from rocprofiler. If I do 
not use rocprofiler and use a simple loop to measure execution time of 
`__hipPushCallConfigure/__hipPopCallConfigure`, I got 180 ns.

>> The kernel launching latency are measured by a simple loop in which a simple 
>> kernel is launched then hipStreamSynchronize is called. trace is collected 
>> by rocprofiler and the latency is measured from the end of 
>> hipStreamSynchronize to the real start of kernel execution. Without this 
>> patch, the latency is about 77 us. With this patch, the latency is about 46 
>> us. The improvement is about 40%. The decrement of 31 us is more than 19 us 
>> since it also eliminates the overhead of kernel stub.
>
> This is rather surprising. A function call by itself does *not* have such 
> high overhead. There must be something else. I strongly suspect logging. If 
> you remove logging statements from push/pop without changing anything else, 
> how does that affect performance?

The 19 us overhead was due to rocprofiler. Without rocprofiler, I can only 
measure the average duration of a kernel launching together with 
hipStreamSynchronize. When the kernel is empty, it serves as an estimation of 
kernel launching latency. With such measurement, the latency is about 14.0 us. 
The improvement due to this patch is not significant.

>> In a C/C++ program, a kernel is launched by call of hipLaunchKernel with the 
>> kernel symbol.
>
> Do you mean the host-side symbol, registered with the runtime that you've 
> described above? Or do you mean that the device-side symbol is somehow 
> visible from the host side. I think that's where HIP is different from CUDA.

I mean the host-side symbol. A host program can only use host-side symbol to 
launch a kernel.

> I do not follow your reasoning why the stub name is a problem. It's awkward, 
> yes, but losing the stub as a specific kernel entry point seems to be a real 
> loss in debugability, which is worse, IMO.
> Could you give me an example where the stub name causes problems?

For example, in HIP program, there is a kernel `void foo(int*)`. If a C++ 
program wants to launch it, the desirable way is

  void foo(int*);
  hipLaunchKernel(foo, grids, blocks, args, shmem, stream);

Due to the prefixed kernel stub name, currently the users have to use

  void __device_stub_foo(int*);
  hipLaunchKernel(__device_stub_foo, grids, blocks, args, shmem, stream);


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

https://reviews.llvm.org/D86376

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


[PATCH] D86581: [clang-format] Handle shifts within conditions

2020-08-26 Thread Miguel Saldivar via Phabricator via cfe-commits
Saldivarcher updated this revision to Diff 288013.
Saldivarcher added a comment.

Added some more tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86581

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7549,6 +7549,21 @@
   verifyFormat("static_assert(is_convertible::value, \"AAA\");");
   verifyFormat("Constructor(A... a) : a_(X{std::forward(a)}...) {}");
   verifyFormat("< < < < < < < < < < < < < < < < < < < < < < < < < < < < < <");
+  verifyFormat("some_templated_type");
+}
+
+TEST_F(FormatTest, UnderstandsShiftOperators) {
+  verifyFormat("if (i < x >> 1)");
+  verifyFormat("while (i < x >> 1)");
+  verifyFormat("for (unsigned i = 0; i < i; ++i, v = v >> 1)");
+  verifyFormat("for (unsigned i = 0; i < x >> 1; ++i, v = v >> 1)");
+  verifyFormat(
+  "for (std::vector::iterator i = 0; i < x >> 1; ++i, v = v >> 1)");
+  verifyFormat("Foo.call>()");
+  verifyFormat("if (Foo.call>() == 0)");
+  verifyFormat("for (std::vector>::iterator i = 0; i < x >> 1; "
+   "++i, v = v >> 1)");
+  verifyFormat("if (w>, 1>::t)");
 }
 
 TEST_F(FormatTest, BitshiftOperatorWidth) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -56,6 +56,13 @@
  Left->Previous->MatchingParen->is(TT_LambdaLSquare);
 }
 
+/// Returns \c true if the token is followed by a boolean condition, \c false
+/// otherwise.
+static bool isKeywordWithCondition(const FormatToken ) {
+  return Tok.isOneOf(tok::kw_if, tok::kw_for, tok::kw_while, tok::kw_switch,
+ tok::kw_constexpr, tok::kw_catch);
+}
+
 /// A parser that gathers additional information about tokens.
 ///
 /// The \c TokenAnnotator tries to match parenthesis and square brakets and
@@ -108,6 +115,12 @@
 
 while (CurrentToken) {
   if (CurrentToken->is(tok::greater)) {
+// Try to do a better job at looking for ">>" within the condition of
+// a statement.
+if (CurrentToken->Next && CurrentToken->Next->is(tok::greater) &&
+Left->ParentBracket != tok::less &&
+isKeywordWithCondition(*Line.First))
+  return false;
 Left->MatchingParen = CurrentToken;
 CurrentToken->MatchingParen = Left;
 // In TT_Proto, we must distignuish between:
@@ -2733,13 +2746,6 @@
   Right.ParameterCount > 0);
 }
 
-/// Returns \c true if the token is followed by a boolean condition, \c false
-/// otherwise.
-static bool isKeywordWithCondition(const FormatToken ) {
-  return Tok.isOneOf(tok::kw_if, tok::kw_for, tok::kw_while, tok::kw_switch,
- tok::kw_constexpr, tok::kw_catch);
-}
-
 bool TokenAnnotator::spaceRequiredBetween(const AnnotatedLine ,
   const FormatToken ,
   const FormatToken ) {


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7549,6 +7549,21 @@
   verifyFormat("static_assert(is_convertible::value, \"AAA\");");
   verifyFormat("Constructor(A... a) : a_(X{std::forward(a)}...) {}");
   verifyFormat("< < < < < < < < < < < < < < < < < < < < < < < < < < < < < <");
+  verifyFormat("some_templated_type");
+}
+
+TEST_F(FormatTest, UnderstandsShiftOperators) {
+  verifyFormat("if (i < x >> 1)");
+  verifyFormat("while (i < x >> 1)");
+  verifyFormat("for (unsigned i = 0; i < i; ++i, v = v >> 1)");
+  verifyFormat("for (unsigned i = 0; i < x >> 1; ++i, v = v >> 1)");
+  verifyFormat(
+  "for (std::vector::iterator i = 0; i < x >> 1; ++i, v = v >> 1)");
+  verifyFormat("Foo.call>()");
+  verifyFormat("if (Foo.call>() == 0)");
+  verifyFormat("for (std::vector>::iterator i = 0; i < x >> 1; "
+   "++i, v = v >> 1)");
+  verifyFormat("if (w>, 1>::t)");
 }
 
 TEST_F(FormatTest, BitshiftOperatorWidth) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -56,6 +56,13 @@
  Left->Previous->MatchingParen->is(TT_LambdaLSquare);
 }
 
+/// Returns \c true if the token is followed by a boolean condition, \c false
+/// otherwise.
+static bool isKeywordWithCondition(const FormatToken ) {
+  return Tok.isOneOf(tok::kw_if, tok::kw_for, tok::kw_while, tok::kw_switch,
+ tok::kw_constexpr, tok::kw_catch);
+}
+
 /// A parser that gathers additional information about tokens.
 ///
 /// The \c 

[PATCH] D86089: [flang][driver]Add experimental flang driver and frontend with help screen

2020-08-26 Thread Andrzej Warzynski via Phabricator via cfe-commits
andwar updated this revision to Diff 288018.
andwar added a comment.

- Canonicalised FLANG_BUILD_NEW_DRIVER in flang/test/CMakeLists.txt and updated 
the LIT config scripts accordingly
- Implemented proper handling of `-emit-obj` (via diagnostics) in 
CompilerInvocation.cpp
- Removed members from InputKind which are not needed (and the related methods)
- Removed/updated comments, added new comments to clarify the design and to 
highlight the future steps
- Simplified the original change in OptTable::PrintHelp (made it more generic)
- Removed unused #includes
- Fine-tuned the tests (I wanted to make sure that they clearly communicate 
what is currently supported and what is not)
- Addressed all the outstanding comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86089

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Flang.cpp
  clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
  clang/lib/Tooling/Tooling.cpp
  clang/test/Driver/flang/flang.f90
  clang/test/Driver/flang/flang_ucase.F90
  clang/test/Driver/flang/multiple-inputs-mixed.f90
  clang/test/Driver/flang/multiple-inputs.f90
  clang/unittests/Driver/SanitizerArgsTest.cpp
  clang/unittests/Driver/ToolChainTest.cpp
  flang/CMakeLists.txt
  flang/include/flang/Frontend/CompilerInstance.h
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/include/flang/FrontendTool/Utils.h
  flang/lib/CMakeLists.txt
  flang/lib/Frontend/CMakeLists.txt
  flang/lib/Frontend/CompilerInstance.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendOptions.cpp
  flang/lib/FrontendTool/CMakeLists.txt
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/test/CMakeLists.txt
  flang/test/Flang-Driver/driver-error-cc1.c
  flang/test/Flang-Driver/driver-error-cc1.cpp
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Flang-Driver/driver-version.f90
  flang/test/Flang-Driver/emit-obj.f90
  flang/test/lit.cfg.py
  flang/test/lit.site.cfg.py.in
  flang/tools/CMakeLists.txt
  flang/tools/flang-driver/CMakeLists.txt
  flang/tools/flang-driver/driver.cpp
  flang/tools/flang-driver/fc1_main.cpp
  flang/unittests/CMakeLists.txt
  flang/unittests/Frontend/CMakeLists.txt
  flang/unittests/Frontend/CompilerInstanceTest.cpp
  llvm/include/llvm/Option/OptTable.h
  llvm/lib/Option/OptTable.cpp

Index: llvm/lib/Option/OptTable.cpp
===
--- llvm/lib/Option/OptTable.cpp
+++ llvm/lib/Option/OptTable.cpp
@@ -610,9 +610,12 @@
   continue;
 
 unsigned Flags = getInfo(Id).Flags;
-if (FlagsToInclude && !(Flags & FlagsToInclude))
+
+unsigned ExplicitelyIncluded = Flags & FlagsToInclude;
+if (FlagsToInclude && !(ExplicitelyIncluded))
   continue;
-if (Flags & FlagsToExclude)
+
+if (!(ExplicitelyIncluded) && (Flags & FlagsToExclude))
   continue;
 
 // If an alias doesn't have a help text, show a help text for the aliased
Index: llvm/include/llvm/Option/OptTable.h
===
--- llvm/include/llvm/Option/OptTable.h
+++ llvm/include/llvm/Option/OptTable.h
@@ -225,7 +225,8 @@
   /// \param Usage - USAGE: Usage
   /// \param Title - OVERVIEW: Title
   /// \param FlagsToInclude - If non-zero, only include options with any
-  /// of these flags set.
+  /// of these flags set. Takes precedence over
+  /// FlagsToExclude.
   /// \param FlagsToExclude - Exclude options with any of these flags set.
   /// \param ShowAllAliases - If true, display all options including aliases
   /// that don't have help texts. By default, we display
Index: flang/unittests/Frontend/CompilerInstanceTest.cpp
===
--- /dev/null
+++ flang/unittests/Frontend/CompilerInstanceTest.cpp
@@ -0,0 +1,52 @@
+//===- unittests/Frontend/CompilerInstanceTest.cpp - CI tests -===//
+//
+// 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
+//
+//===--===//
+
+#include "flang/Frontend/CompilerInstance.h"
+#include "gtest/gtest.h"
+#include "flang/Frontend/CompilerInvocation.h"
+#include "clang/Basic/DiagnosticOptions.h"
+#include "clang/Driver/Options.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+using namespace llvm;
+using namespace Fortran::frontend;
+
+namespace {
+
+TEST(CompilerInstance, 

[clang-tools-extra] 667867e - [clangd] Enable recovery-ast-type by default.

2020-08-26 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2020-08-26T16:47:04+02:00
New Revision: 667867e0df26e45ed2c86e192fee69dd484167c7

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

LOG: [clangd] Enable recovery-ast-type by default.

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

Added: 


Modified: 
clang-tools-extra/clangd/ClangdServer.h
clang-tools-extra/clangd/tool/ClangdMain.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/ClangdServer.h 
b/clang-tools-extra/clangd/ClangdServer.h
index 7068cd5eb4217..ae10dba32b58c 100644
--- a/clang-tools-extra/clangd/ClangdServer.h
+++ b/clang-tools-extra/clangd/ClangdServer.h
@@ -131,7 +131,7 @@ class ClangdServer {
 bool BuildRecoveryAST = true;
 
 /// If true, turn on the `-frecovery-ast-type` clang flag.
-bool PreserveRecoveryASTType = false;
+bool PreserveRecoveryASTType = true;
 
 /// Clangd's workspace root. Relevant for "workspace" operations not bound
 /// to a particular file.

diff  --git a/clang-tools-extra/clangd/tool/ClangdMain.cpp 
b/clang-tools-extra/clangd/tool/ClangdMain.cpp
index 57dac600014d5..dcbaa35238226 100644
--- a/clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ b/clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -291,9 +291,8 @@ opt RecoveryAST{
 opt RecoveryASTType{
 "recovery-ast-type",
 cat(Features),
-desc("Preserve the type for recovery AST. Note that "
- "this feature is experimental and may lead to crashes"),
-init(false),
+desc("Preserve the type for recovery AST."),
+init(ClangdServer::Options().PreserveRecoveryASTType),
 Hidden,
 };
 



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


[PATCH] D86624: [clang] Exclude invalid destructors from lookups.

2020-08-26 Thread Adam Czachorowski via Phabricator via cfe-commits
adamcz created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
adamcz requested review of this revision.

This fixes a crash when declaring a destructor with a wrong name, then
writing result to pch file and loading it again. The PCH storage uses
DeclarationNameKey as key and it is the same key for both the invalid
destructor and the implicit one that was created because the other one
was invalid. When querying for the Foo::~Foo we end up getting
Foo::~Bar, which is then rejected and we end up with nullptr in
CXXRecordDecl::GetDestructor().

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86624

Files:
  clang/lib/AST/DeclBase.cpp
  clang/test/PCH/cxx-invalid-destructor.cpp
  clang/test/PCH/cxx-invalid-destructor.h


Index: clang/test/PCH/cxx-invalid-destructor.h
===
--- /dev/null
+++ clang/test/PCH/cxx-invalid-destructor.h
@@ -0,0 +1,14 @@
+class Base {
+public:
+  ~Base();
+};
+
+class Bar {
+public:
+  ~Bar();
+};
+
+class Foo : public Base {
+public:
+  ~Bar();
+};
Index: clang/test/PCH/cxx-invalid-destructor.cpp
===
--- /dev/null
+++ clang/test/PCH/cxx-invalid-destructor.cpp
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 -emit-pch -o %t 
%S/cxx-invalid-destructor.h -fallow-pch-with-compiler-errors
+// RUN: %clang_cc1 -x c++ -std=c++11 -include-pch %t 
%S/cxx-invalid-destructor.cpp -fsyntax-only -fno-validate-pch
+
+Foo f;
Index: clang/lib/AST/DeclBase.cpp
===
--- clang/lib/AST/DeclBase.cpp
+++ clang/lib/AST/DeclBase.cpp
@@ -1486,6 +1486,8 @@
   if (auto *FD = dyn_cast(D))
 if (FD->isFunctionTemplateSpecialization())
   return true;
+  if (isa(D) && D->isInvalidDecl())
+return true;
 
   return false;
 }


Index: clang/test/PCH/cxx-invalid-destructor.h
===
--- /dev/null
+++ clang/test/PCH/cxx-invalid-destructor.h
@@ -0,0 +1,14 @@
+class Base {
+public:
+  ~Base();
+};
+
+class Bar {
+public:
+  ~Bar();
+};
+
+class Foo : public Base {
+public:
+  ~Bar();
+};
Index: clang/test/PCH/cxx-invalid-destructor.cpp
===
--- /dev/null
+++ clang/test/PCH/cxx-invalid-destructor.cpp
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 -emit-pch -o %t %S/cxx-invalid-destructor.h -fallow-pch-with-compiler-errors
+// RUN: %clang_cc1 -x c++ -std=c++11 -include-pch %t %S/cxx-invalid-destructor.cpp -fsyntax-only -fno-validate-pch
+
+Foo f;
Index: clang/lib/AST/DeclBase.cpp
===
--- clang/lib/AST/DeclBase.cpp
+++ clang/lib/AST/DeclBase.cpp
@@ -1486,6 +1486,8 @@
   if (auto *FD = dyn_cast(D))
 if (FD->isFunctionTemplateSpecialization())
   return true;
+  if (isa(D) && D->isInvalidDecl())
+return true;
 
   return false;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D86602: [clangd] Enable recovery-ast-type by default.

2020-08-26 Thread Haojian Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG667867e0df26: [clangd] Enable recovery-ast-type by default. 
(authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86602

Files:
  clang-tools-extra/clangd/ClangdServer.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
@@ -291,9 +291,8 @@
 opt RecoveryASTType{
 "recovery-ast-type",
 cat(Features),
-desc("Preserve the type for recovery AST. Note that "
- "this feature is experimental and may lead to crashes"),
-init(false),
+desc("Preserve the type for recovery AST."),
+init(ClangdServer::Options().PreserveRecoveryASTType),
 Hidden,
 };
 
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -131,7 +131,7 @@
 bool BuildRecoveryAST = true;
 
 /// If true, turn on the `-frecovery-ast-type` clang flag.
-bool PreserveRecoveryASTType = false;
+bool PreserveRecoveryASTType = true;
 
 /// Clangd's workspace root. Relevant for "workspace" operations not bound
 /// to a particular file.


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -291,9 +291,8 @@
 opt RecoveryASTType{
 "recovery-ast-type",
 cat(Features),
-desc("Preserve the type for recovery AST. Note that "
- "this feature is experimental and may lead to crashes"),
-init(false),
+desc("Preserve the type for recovery AST."),
+init(ClangdServer::Options().PreserveRecoveryASTType),
 Hidden,
 };
 
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -131,7 +131,7 @@
 bool BuildRecoveryAST = true;
 
 /// If true, turn on the `-frecovery-ast-type` clang flag.
-bool PreserveRecoveryASTType = false;
+bool PreserveRecoveryASTType = true;
 
 /// Clangd's workspace root. Relevant for "workspace" operations not bound
 /// to a particular file.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D85150: [OpenMP] Ensure testing for versions 4.5 and default - Part 2

2020-08-26 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85150

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


[PATCH] D86631: [Fixed Point] Add fixed-point to floating point cast types and consteval.

2020-08-26 Thread Bevin Hansson via Phabricator via cfe-commits
ebevhan created this revision.
ebevhan added reviewers: leonardchan, rjmccall.
Herald added subscribers: bjope, martong.
Herald added a project: clang.
ebevhan requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86631

Files:
  clang/include/clang/AST/OperationKinds.def
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Edit/RewriteObjCFoundationAPI.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/test/Frontend/fixed_point_conversions_const.c
  clang/test/Frontend/fixed_point_errors.c
  clang/test/Frontend/fixed_point_unknown_conversions.c

Index: clang/test/Frontend/fixed_point_unknown_conversions.c
===
--- clang/test/Frontend/fixed_point_unknown_conversions.c
+++ clang/test/Frontend/fixed_point_unknown_conversions.c
@@ -22,16 +22,12 @@
   _Fract fract = accum; // ok
   _Accum *accum_ptr;
 
-  accum = f;   // expected-error{{conversion between fixed point and 'float' is not yet supported}}
-  accum = d;   // expected-error{{conversion between fixed point and 'double' is not yet supported}}
   accum = dc;  // expected-error{{conversion between fixed point and '_Complex double' is not yet supported}}
   accum = ic;  // expected-error{{conversion between fixed point and '_Complex int' is not yet supported}}
   accum = s;   // expected-error{{assigning to '_Accum' from incompatible type 'struct S'}}
   accum = ptr; // expected-error{{assigning to '_Accum' from incompatible type 'int *'}}
   accum_ptr = ptr; // expected-warning{{incompatible pointer types assigning to '_Accum *' from 'int *'}}
 
-  f = accum;   // expected-error{{conversion between fixed point and 'float' is not yet supported}}
-  d = accum;   // expected-error{{conversion between fixed point and 'double' is not yet supported}}
   dc = accum;  // expected-error{{conversion between fixed point and '_Complex double' is not yet supported}}
   ic = accum;  // expected-error{{conversion between fixed point and '_Complex int' is not yet supported}}
   s = accum;   // expected-error{{assigning to 'struct S' from incompatible type '_Accum'}}
Index: clang/test/Frontend/fixed_point_errors.c
===
--- clang/test/Frontend/fixed_point_errors.c
+++ clang/test/Frontend/fixed_point_errors.c
@@ -286,8 +286,3 @@
 
 // Division by zero
 short _Accum div_zero = 4.5k / 0.0lr;  // expected-error {{initializer element is not a compile-time constant}}
-
-void foo(void) {
-  _Accum x = 0.5k;
-  if (x == 0.5) {} // expected-error{{invalid operands to binary expression ('_Accum' and 'double')}}
-}
Index: clang/test/Frontend/fixed_point_conversions_const.c
===
--- clang/test/Frontend/fixed_point_conversions_const.c
+++ clang/test/Frontend/fixed_point_conversions_const.c
@@ -43,6 +43,37 @@
 short _Accum sa_const7 = -256;
 // CHECK-DAG: @sa_const7 = {{.*}}global i16 -32768, align 2
 
+// Fixed point to floating point
+float fl_const = 1.0hk;
+// CHECK-DAG: @fl_const = {{.*}}global float 1.00e+00, align 4
+float fl_const2 = -128.0k;
+// CHECK-DAG: @fl_const2 = {{.*}}global float -1.28e+02, align 4
+float fl_const3 = 0.0872802734375k;
+// CHECK-DAG: @fl_const3 = {{.*}}global float 0x3FB65800, align 4
+float fl_const4 = 192.5k;
+// CHECK-DAG: @fl_const4 = {{.*}}global float 1.925000e+02, align 4
+float fl_const5 = -192.5k;
+// CHECK-DAG: @fl_const5 = {{.*}}global float -1.925000e+02, align 4
+
+// Floating point to fixed point
+_Accum a_fl_const = 1.0f;
+// CHECK-DAG: @a_fl_const = {{.*}}global i32 32768, align 4
+_Accum a_fl_const2 = -128.0f;
+// CHECK-DAG: @a_fl_const2 = {{.*}}global i32 -4194304, align 4
+_Accum a_fl_const3 = 0.0872802734375f;
+// CHECK-DAG: @a_fl_const3 = {{.*}}global i32 2860, align 4
+_Accum a_fl_const4 = 0.0872802734375;
+// CHECK-DAG: @a_fl_const4 = {{.*}}global i32 2860, align 4
+_Accum a_fl_const5 = -0.0872802734375f;
+// CHECK-DAG: @a_fl_const5 = {{.*}}global i32 -2860, align 4
+_Fract f_fl_const = 0.5f;
+// CHECK-DAG: @f_fl_const = {{.*}}global i16 16384, align 2
+_Fract f_fl_const2 = -0.75;
+// CHECK-DAG: @f_fl_const2 = {{.*}}global i16 -24576, align 2
+unsigned short _Accum usa_fl_const = 48.75f;
+// SIGNED-DAG: @usa_fl_const = {{.*}}global i16 12480, align 2
+// UNSIGNED-DAG: @usa_fl_const = {{.*}}global i16 6240, align 2
+
 // Signedness
 unsigned short _Accum usa_const2 = 2.5hk;
 // SIGNED-DAG: @usa_const2  = {{.*}}global i16 640, align 2
Index: clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
+++ 

[PATCH] D86559: [Sema, CodeGen] Allow [[likely]] and [[unlikely]] on labels

2020-08-26 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D86559#2237037 , @Mordante wrote:

> In D86559#2236931 , @Quuxplusone 
> wrote:
>
>> It seems like this patch would basically "copy" the `[[likely]]` attribute 
>> from line C up to lines A and B, where it would reinforce the likelihood of 
>> path A and (maybe?) "cancel out" the unlikelihood of path B, without 
>> actually saying anything specifically about the likelihood of label C (which 
>> is surely what the programmer intended by applying the attribute, right?).
>
> Yes A is double `[[likely]]` and B is both `[[likely]]` and `[[unlikely]]`.  
> Based on http://eel.is/c++draft/dcl.attr.likelihood#:attribute,likely
> "The use of the likely attribute is intended to allow implementations to 
> optimize for the case where paths of execution including it are arbitrarily 
> more likely than any alternative path of execution that does not include such 
> an attribute on a statement or label." 
> So it seem it's intended to see a goto as a part of a path of execution, 
> since it's an unconditional jump.
>
> But I think the standard should be improved:
>
>   if(foo) {
> [[likely]][[unlikely]] bar(1); // error: The attribute-token likely shall 
> not appear in an
> bar(2);  //  attribute-specifier-seq 
> that contains the attribute-token unlikely.
>   }
>   if(foo) {
> [[likely]] bar(1); 
> [[unlikely]] bar(2);// This contradiction in the 
> `ThenStmt` is allowed
>   }
>   if(foo) {
> [[likely]] bar(1);
>   } else {
> [[likely]] bar(2);   // This contradiction between the 
> `ThenStmt` and `ElseStmt` is allowed
>   }
>
> So I'll work on a paper to discuss these issues. I already have some notes, 
> but I would prefer to get more implementation experience before starting to 
> write.
> IMO we should ignore conflicting likelihoods and issue a diagnostic. (For a 
> switch multiple `[[likely]]` cases would be allowed, but still no mixing.)

I'd like to understand your reasoning for ignore + diagnose as opposed to count 
attrs (+ optionally diagnose) or other strategies. I can see pros and cons to 
basically anything we do here.

If we decide to ignore conflicting likelihoods, then I agree we should issue a 
diagnostic. However, I suspect that's going to come up frequently in practice 
because people are going to write macros that include these attributes. For 
instance, it's very sensible for a developer to put [[unlikely]] in front of an 
`assert` under the assumption this is telling the compiler "this assertion 
isn't likely to happen" when in fact it's saying "this branch containing the 
assertion is unlikely to be taken". This is one of the reasons why the GCC 
behavior of allowing these attributes on arbitrary statements feels like an 
awful trap for users to get into. If the attribute only applied to compound 
statements following a flow control construct, I think the average programmer 
will have a far better chance of not using this wrong. (I know that I said in 
the other thread we should match the GCC behavior, but I'm still uncomfortable 
with it because that behavior seems to be fraught with dangers for users, and 
this patch introduces new sharp edges, as @Quuxplusone pointed out.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86559

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


[PATCH] D86626: [OpenCL][Docs] 10.x release notes

2020-08-26 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 287984.
Anastasia added a comment.

- Addressed comments from Sven.


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

https://reviews.llvm.org/D86626

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -261,10 +261,36 @@
 Objective-C Language Changes in Clang
 -
 
-OpenCL C Language Changes in Clang
---
+OpenCL Kernel Language Changes in Clang
+---
 
-...
+- Added extensions from  `cl_khr_subgroup_extensions` to clang and the internal
+  header.
+
+- Added rocm device libs linking for AMDGPU.
+
+- Added diagnostic for OpenCL 2.0 blocks used in function arguments.
+
+- Fixed MS mangling for OpenCL 2.0 pipe type specifier.
+
+- Improved command line options for fast relaxed math.
+
+- Improved `atomic_fetch_min/max` functions in the internal header
+  (`opencl-c.h`).
+
+- Improved size of builtin function table for `TableGen`-based internal header
+  (enabled by `-fdeclare-opencl-builtins`) and added new functionality for
+  OpenCL 2.0 atomics, pipes, enqueue kernel, `cl_khr_subgroups`,
+  `cl_arm_integer_dot_product`.
+
+Changes related to C++ for OpenCL
+^
+
+- Added `addrspace_cast` operator.
+
+- Improved address space deduction in templates.
+
+- Improved diagnostics of address spaces in nested pointer conversions.
 
 ABI Changes in Clang
 


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -261,10 +261,36 @@
 Objective-C Language Changes in Clang
 -
 
-OpenCL C Language Changes in Clang
---
+OpenCL Kernel Language Changes in Clang
+---
 
-...
+- Added extensions from  `cl_khr_subgroup_extensions` to clang and the internal
+  header.
+
+- Added rocm device libs linking for AMDGPU.
+
+- Added diagnostic for OpenCL 2.0 blocks used in function arguments.
+
+- Fixed MS mangling for OpenCL 2.0 pipe type specifier.
+
+- Improved command line options for fast relaxed math.
+
+- Improved `atomic_fetch_min/max` functions in the internal header
+  (`opencl-c.h`).
+
+- Improved size of builtin function table for `TableGen`-based internal header
+  (enabled by `-fdeclare-opencl-builtins`) and added new functionality for
+  OpenCL 2.0 atomics, pipes, enqueue kernel, `cl_khr_subgroups`,
+  `cl_arm_integer_dot_product`.
+
+Changes related to C++ for OpenCL
+^
+
+- Added `addrspace_cast` operator.
+
+- Improved address space deduction in templates.
+
+- Improved diagnostics of address spaces in nested pointer conversions.
 
 ABI Changes in Clang
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D86369: [Sema][MSVC] warn at dynamic_cast when /GR- is given

2020-08-26 Thread Hans Wennborg via Phabricator via cfe-commits
hans added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:7436
   "use of dynamic_cast requires -frtti">;
+def warn_no_dynamic_cast_with_RTTI_disabled: Warning<
+  "dynamic_cast will not work since RTTI data is disabled by " 

The other warning names spell rtti in lower-case, so I'd suggest that here too 
for consistency.



Comment at: clang/lib/Sema/SemaCast.cpp:895
+  if (!Self.getLangOpts().RTTIData &&
+  !Self.getDiagnostics().isIgnored(diag::warn_no_typeid_with_RTTI_disabled,
+   OpRange.getBegin())) {

Is the isIgnored() check necessary here? I think in general we call Diag() 
anyway, and if the warning is ignored, it will be ignored.

The reason we sometimes check isIgnored() explicitly is to avoid expensive 
computation when possible, but that's not the case here.



Comment at: clang/lib/Sema/SemaCast.cpp:900
+diag::warn_no_dynamic_cast_with_RTTI_disabled)
+  << Self.getLangOpts().MSVCCompat;
+  }

getLangOpts().MSVCCompat can be true both with clang-cl and regular clang, it 
just depends on teh -fms-compatibility flag.

Driver::IsCLMode() is the sure way to check for clang-cl, but I don't think 
that information is forwarded to the compiler frontend.

One slightly hacky way to check, and in this case maybe it makes sense, is to 
look at the TextDiagnosticFormat. If that's MSVC, it's very likely the driver 
was clang-cl.



Comment at: clang/test/SemaCXX/ms_no_dynamic_cast.cpp:1
+// RUN: %clang_cl %s /GR- -fsyntax-only 2>&1 | FileCheck %s
+

When using %clang_cl, the source file should always come after a "--", 
otherwise if for example the source file is "/Users/foo/src/test.cc" the 
filename can get interpreted as a command-line option.

But tests outside of Driver/ generally invoke cc1 directly, with %clang_cc1 and 
passing the appropriate flags. I'd suggest doing that here too. (And in the 
other test.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86369

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


[clang] 33ce275 - [Clang] Fix tests following rG087047144210

2020-08-26 Thread Alexandre Ganea via cfe-commits

Author: Alexandre Ganea
Date: 2020-08-26T11:32:46-04:00
New Revision: 33ce275fc156c8b015acfad918937028b2cc235c

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

LOG: [Clang] Fix tests following rG087047144210

Added: 


Modified: 
clang/test/Driver/cl-options.c

Removed: 




diff  --git a/clang/test/Driver/cl-options.c b/clang/test/Driver/cl-options.c
index f4d2d66129b0..89dbdebbaf69 100644
--- a/clang/test/Driver/cl-options.c
+++ b/clang/test/Driver/cl-options.c
@@ -688,7 +688,7 @@
 
 // Validate that built-in include paths are based on the supplied path
 // RUN: %clang_cl -vctoolsdir "/fake" -### -- %s 2>&1 | FileCheck %s 
--check-prefix FAKEDIR
-// FAKEDIR: "-internal-isystem" "/fake{{.}}include"
-// FAKEDIR: "-internal-isystem" "/fake{{.}}atlmfc{{.}}include"
+// FAKEDIR: "-internal-isystem" "/fake{{/|}}include"
+// FAKEDIR: "-internal-isystem" "/fake{{/|}}atlmfc{{/|}}include"
 
 void f() { }



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


[PATCH] D84603: Thread safety analysis: More consistent warning message

2020-08-26 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Analysis/ThreadSafety.cpp:1644
 if (!LDat) {
-  Analyzer->Handler.handleMutexNotHeld("", D, POK, Cp.toString(),
-   LK_Shared, Loc);
+  Analyzer->Handler.handleMutexNotHeld("negative capability", D, POK,
+   Cp.toString(), LK_Shared, Loc);

aaronpuchert wrote:
> aaron.ballman wrote:
> > It's a bit odd that we aren't using `DiagKind` as below, I assume that's 
> > because this is a negative test and the others are positive tests, but 
> > doesn't this introduce a terminology difference where a positive failure 
> > may call it a mutex and a negative failure may call it a negative 
> > capability? Should this be hooked in to `ClassifyDiagnostic()` (perhaps we 
> > need a `ClassifyNegativeDiagnostic()`?
> My thinking was that whatever the positive capability is called, we should 
> only talk about a "negative capability" instead of a "negative mutex" or a 
> "negative role". Also because not holding a capability is in some way its own 
> kind of capability.
I may still be confused or thinking of this differently, but I would assume 
that a negative mutex would be a mutex that's explicitly not held, which you 
may want to ensure on a function boundary to avoid deadlock. From that, I'd 
have guessed we would want the diagnostic to read `cannot call function 'bar' 
while mutex 'mu' is held` or `calling function 'bar' requires mutex 'mu' to not 
be held` because that's more clear than talking about negative capabilities 
(when the user is thinking in terms of mutexes which are or aren't held).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84603

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


[PATCH] D86089: [flang][driver]Add experimental flang driver and frontend with help screen

2020-08-26 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added a comment.

@CarolineConcatto - thank you for working on this! @all, thank you for your 
reviews, this is much appreciated!

While Carol is away, I'll try my best to address all the outstanding comments. 
I will also update the patch accordingly. I've identified a few small issues 
myself - that will also be updated in the next patch.




Comment at: clang/lib/Driver/Driver.cpp:1573
+ExcludedFlagsBitmask |= options::CC1Option;
+IncludedFlagsBitmask |= options::FlangOption;
+  } else

sameeranjoshi wrote:
> In `enum ClangFlags` 
> inside File `clang/include/clang/Driver/Options.h`
> there are various other options do they need to be considered?
> If not, how are they handled?
> 
> do they need to be considered?

Not at this stage. This is sufficient to make sure that `flang-new -help` only 
prints options relevant to Flang.

We may want to fine-tune this in the future, but currently it would be a bit 
tricky with only 2 options being  supported ;-)



Comment at: flang/include/flang/Frontend/CompilerInstance.h:11
+
+#include "flang/Frontend/CompilerInvocation.h"
+

CarolineConcatto wrote:
> tskeith wrote:
> > Why is this called "Frontend" rather than "Driver"?
> The way we think is that the driver is split in:
> **the driver** libDriver -> that implements the driver. ATM it is inside 
> clang/lib/Driver. And it can be clang( called inside 
> clang/tools/driver/driver.cpp) or flang-new(called inside 
> flang/tools/driver/driver.cpp) according to the mode the driver is called.
> **the frontend driver**  -> it can be:
>  clang frontend driver: clang -cc1  that calls libclangfrontend 
>  flang frontend driver: flang-new -fc1 that calls libflangfrontend. 
> the -xc1 has its functions/methods implemented inside the driver Frontend 
> 
> So this folder is called Frontend because it belongs to the part that 
> implements the driver frontend of the compiler and we would like to leave 
> this way so it has the same design as clang.
>  
Just to further clarify, I think that it's important to distinguish between:

* the compiler driver, `flang`, implemented in terms of `libclandDriver` (it 
creates and executes jobs/commands, e.g. linker or  frontend jobs)
* the frontend driver, `flang -fc1`, implemented in terms of `libflangFrontend` 
(it creates frontend actions, e.g. preprocessor actions)

"Frontend" in this case means "Frontend Driver".  "Driver" is reserved for the 
compiler driver, i.e. "libclangDriver".  

As Carol mentioned, our terminology is inspired by Clang. Keeping the names 
consistent felt like a good idea. @tskeith, would you prefer "FrontendDriver" 
instead of "Frontend"?

(`libclangDriver` is the Clang compiler driver library that we want to re-use, 
`libflangFrontend` is the Flang frontend driver library, inspired by 
`libclangFrontend`)



Comment at: flang/include/flang/Frontend/FrontendOptions.h:31-32
+  Language lang_;
+  unsigned fmt_ : 3;
+  unsigned preprocessed_ : 1;
+

> Why isn't the type bool?

@tskeith Bitfields are used here for optimization. An instance of `InputKind` 
is created per input file, so this could be a substantial saving (if the 
bitfields happen to be laid out nicely).

Btw,  we won't need `fmt_` or `preprocessed_` (and the corresponding member 
methods) just now. I will delete them.



Comment at: flang/include/flang/Frontend/FrontendOptions.h:65
+  /// Show the -version text.
+  unsigned ShowVersion : 1;
+

CarolineConcatto wrote:
> tskeith wrote:
> > Why aren't the types `bool`?
> Most of these things are going to be set by option::driver. That is the 
> reason it is as it is.
> Why aren't the types bool?

@tskeith See above.



Comment at: flang/lib/Frontend/CompilerInvocation.cpp:46
+  InputKind DashX(Language::Unknown);
+  return DashX;
+}

CarolineConcatto wrote:
> tskeith wrote:
> > Why not `return InputKind{Language::Unknown};`?
> Just because the next lines also return DashX.
I agree with @tskeith , `return InputKind{Language::Unknown};` would be 
cleaner. I will update this.



Comment at: flang/lib/Frontend/CompilerInvocation.cpp:91
+  InputKind DashX = ParseFrontendArgs(Res.getFrontendOpts(), Args, Diags);
+  (void)DashX;
+

tskeith wrote:
> What is the purpose of `DashX` here?
Not needed for now, I will delete it. Thanks!



Comment at: flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:20
+
+using namespace flang;
+namespace flang {

CarolineConcatto wrote:
> tskeith wrote:
> > What is this for?
> Because of CompilerInstance *Flang.
It's not needed, good catch, cheers!



Comment at: flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:39
+
+  return true;
+}

sameeranjoshi wrote:
> The comment in header for `ExecuteCompilerInvocation` mentions,
> ```
>   

[PATCH] D86488: [X86] Default to -mtune=generic unless -march is passed to the driver. Add TuneCPU to the AST serialization

2020-08-26 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/lib/Serialization/ASTReader.cpp:395
 CHECK_TARGET_OPT(CPU, "target CPU");
+CHECK_TARGET_OPT(TuneCPU, "tune CPU");
+  }

What does this string do?  Does there have to be a test for it?


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

https://reviews.llvm.org/D86488

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


[PATCH] D86169: Initial support for letting plugins perform custom parsing of attribute arguments.

2020-08-26 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D86169#2236457 , 
@jonathan.protzenko wrote:

> Thanks for the review!
>
> Regarding Declarator: I briefly mentioned something related in the details 
> section... actually maybe you can tell me what's the best approach here. I 
> was thinking of just passing in a void* and expecting plugins to do
>
>   if (const Declarator *D = isa_and_nonnull(Context))
>
> This would allow a future-proof API where we can, in the future, pass in more 
> classes for the "Context" argument (not just a Declarator), relying on 
> clients doing dynamic casts. If I understood 
> https://llvm.org/docs/ProgrammersManual.html#isa this `void*` cast would work?

I don't think `isa<>` would work well with a `void *` because the LLVM casting 
infrastructure works by eventually trying to call a static function on a class, 
and that static function is given a pointer value which it often calls a member 
function on. If the types are all correct, then things should work out okay, 
but I'd not want to design a plugin feature around that unsafe of an interface. 
In fact, I think it would require the user to use C-style casts because you 
cannot form a reference to a `void *`.

> My only hesitation is I'm not sure about the right technical device to use 
> for this polymorphism pattern, as I've seen a couple related things in the 
> clang code base:
>
> - I've seen a pattern where there's a wrapper class that has a Kind() method 
> and then allows downcasting based on the results of the Kind (seems overkill 
> here)
> - I've also seen references to `opaque_ptr` somewhere with a `get` 
> method... (maybe these are helpers to do what I'm doing better?)
>
> If you can confirm the void* is the right way to go (or point me to a 
> suitable pattern I can take inspiration from), I'll submit a revised patch, 
> along with the extra spelling argument (good point, thanks!).

I don't think `void *` is the right way to go and I'm hoping we can devise a 
way to not require the entity being attributed to be passed when parsing the 
attribute. For instance, some attributes are parsed before you know what you're 
attaching them to: `[[foobar]] ;` could be a statement attribute 
or a declaration attribute, depending on what `` is. Another 
example is: `int f [[foobar]] ;` where the attribute could be 
appertaining to a function (if `` was `()`) or a variable (if 
`` was ` = 12`). My intuition is that we're going to need to 
wait until we know what AST node we're dealing with before asking a plugin to 
decide whether an attribute appertains to it or not. WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86169

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


[PATCH] D86369: [Sema][MSVC] warn at dynamic_cast when /GR- is given

2020-08-26 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu updated this revision to Diff 288062.
zequanwu marked 3 inline comments as done.
zequanwu added a comment.

Address cmments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86369

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/SemaCXX/ms_no_dynamic_cast.cpp
  clang/test/SemaCXX/no_dynamic_cast.cpp

Index: clang/test/SemaCXX/no_dynamic_cast.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/no_dynamic_cast.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 %s -fno-rtti-data -fsyntax-only -verify
+
+namespace std {
+struct type_info {};
+} // namespace std
+class B {
+public:
+  virtual ~B() = default;
+};
+
+class D1 : public B {
+public:
+  ~D1() = default;
+};
+
+void f() {
+  B *b = new D1();
+  auto d = dynamic_cast(b); // expected-warning{{dynamic_cast will not work since RTTI data is disabled by -fno-rtti-data}}
+  (void)typeid(int);  // expected-warning{{typeid will not work since RTTI data is disabled by -fno-rtti-data}}
+}
Index: clang/test/SemaCXX/ms_no_dynamic_cast.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/ms_no_dynamic_cast.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cl /GR- -fsyntax-only -- %s 2>&1 | FileCheck %s
+
+namespace std {
+struct type_info {};
+} // namespace std
+class B {
+public:
+  virtual ~B() = default;
+};
+
+class D1 : public B {
+public:
+  ~D1() = default;
+};
+
+void f() {
+  B *b = new D1();
+  auto d = dynamic_cast(b); // CHECK: warning: dynamic_cast will not work since RTTI data is disabled by /GR-
+  (void)typeid(int);  // CHECK: warning: typeid will not work since RTTI data is disabled by /GR-
+}
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -646,6 +646,12 @@
 return ExprError(Diag(OpLoc, diag::err_no_typeid_with_fno_rtti));
   }
 
+  // Warns when typeid is used with RTTI disabled.
+  if (!getLangOpts().RTTIData)
+Diag(OpLoc, diag::warn_no_typeid_with_rtti_disabled)
+<< (getDiagnostics().getDiagnosticOptions().getFormat() ==
+DiagnosticOptions::MSVC);
+
   QualType TypeInfoType = Context.getTypeDeclType(CXXTypeInfoDecl);
 
   if (isType) {
Index: clang/lib/Sema/SemaCast.cpp
===
--- clang/lib/Sema/SemaCast.cpp
+++ clang/lib/Sema/SemaCast.cpp
@@ -890,6 +890,16 @@
 return;
   }
 
+  // Warns when dynamic_cast is used with RTTI disabled.
+  if (!Self.getLangOpts().RTTIData) {
+bool isMSVC = Self.getDiagnostics().getDiagnosticOptions().getFormat() ==
+  DiagnosticOptions::MSVC;
+if (isMSVC || !DestPointee->isVoidType())
+  Self.Diag(OpRange.getBegin(),
+diag::warn_no_dynamic_cast_with_rtti_disabled)
+  << isMSVC;
+  }
+
   // Done. Everything else is run-time checks.
   Kind = CK_Dynamic;
 }
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -7433,6 +7433,12 @@
   "use of typeid requires -frtti">;
 def err_no_dynamic_cast_with_fno_rtti : Error<
   "use of dynamic_cast requires -frtti">;
+def warn_no_dynamic_cast_with_rtti_disabled: Warning<
+  "dynamic_cast will not work since RTTI data is disabled by " 
+  "%select{-fno-rtti-data|/GR-}0">, InGroup;
+def warn_no_typeid_with_rtti_disabled: Warning<
+  "typeid will not work since RTTI data is disabled by "
+  "%select{-fno-rtti-data|/GR-}0">, InGroup;
 
 def err_cannot_form_pointer_to_member_of_reference_type : Error<
   "cannot form a pointer-to-member to member %0 of reference type %1">;
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -1229,3 +1229,5 @@
 }
 
 def WebAssemblyExceptionSpec : DiagGroup<"wasm-exception-spec">;
+
+def RTTI : DiagGroup<"rtti">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D86369: [Sema][MSVC] warn at dynamic_cast when /GR- is given

2020-08-26 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu added inline comments.



Comment at: clang/test/SemaCXX/ms_no_dynamic_cast.cpp:1
+// RUN: %clang_cl %s /GR- -fsyntax-only 2>&1 | FileCheck %s
+

hans wrote:
> When using %clang_cl, the source file should always come after a "--", 
> otherwise if for example the source file is "/Users/foo/src/test.cc" the 
> filename can get interpreted as a command-line option.
> 
> But tests outside of Driver/ generally invoke cc1 directly, with %clang_cc1 
> and passing the appropriate flags. I'd suggest doing that here too. (And in 
> the other test.)
This test is for testing in clang-cl. Another test is for clang. If I use 
%clang_cc1, /GR- can not be passed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86369

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


[clang] 677e3db - [clang][NFC] Properly fix a GCC warning in ASTImporterTest.cpp

2020-08-26 Thread Raphael Isemann via cfe-commits

Author: Raphael Isemann
Date: 2020-08-26T17:10:13+02:00
New Revision: 677e3db5806af9c6bbe9e76c135f801e8b06a8ed

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

LOG: [clang][NFC] Properly fix a GCC warning in ASTImporterTest.cpp

Follow up to c9b45ce1fd97531c228e092bedee719b971f82a3 which just defined
the function instead of just 'using' the function from the base class (thanks
David).

Added: 


Modified: 
clang/unittests/AST/ASTImporterTest.cpp

Removed: 




diff  --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index ecddd4d43752..51391d221626 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -5803,7 +5803,7 @@ struct SourceWithCompletedTagList : 
clang::ExternalASTSource {
 Record->completeDefinition();
 CompletedTags.push_back(Tag);
   }
-  void CompleteType(ObjCInterfaceDecl *) override {}
+  using clang::ExternalASTSource::CompleteType;
 };
 
 TEST_P(ImportWithExternalSource, CompleteRecordBeforeImporting) {



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


[PATCH] D86626: [OpenCL][Docs] 10.x release notes

2020-08-26 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 287985.
Anastasia added a comment.

Fixed extra space


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

https://reviews.llvm.org/D86626

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -261,10 +261,36 @@
 Objective-C Language Changes in Clang
 -
 
-OpenCL C Language Changes in Clang
---
+OpenCL Kernel Language Changes in Clang
+---
 
-...
+- Added extensions from `cl_khr_subgroup_extensions` to clang and the internal
+  header.
+
+- Added rocm device libs linking for AMDGPU.
+
+- Added diagnostic for OpenCL 2.0 blocks used in function arguments.
+
+- Fixed MS mangling for OpenCL 2.0 pipe type specifier.
+
+- Improved command line options for fast relaxed math.
+
+- Improved `atomic_fetch_min/max` functions in the internal header
+  (`opencl-c.h`).
+
+- Improved size of builtin function table for `TableGen`-based internal header
+  (enabled by `-fdeclare-opencl-builtins`) and added new functionality for
+  OpenCL 2.0 atomics, pipes, enqueue kernel, `cl_khr_subgroups`,
+  `cl_arm_integer_dot_product`.
+
+Changes related to C++ for OpenCL
+^
+
+- Added `addrspace_cast` operator.
+
+- Improved address space deduction in templates.
+
+- Improved diagnostics of address spaces in nested pointer conversions.
 
 ABI Changes in Clang
 


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -261,10 +261,36 @@
 Objective-C Language Changes in Clang
 -
 
-OpenCL C Language Changes in Clang
---
+OpenCL Kernel Language Changes in Clang
+---
 
-...
+- Added extensions from `cl_khr_subgroup_extensions` to clang and the internal
+  header.
+
+- Added rocm device libs linking for AMDGPU.
+
+- Added diagnostic for OpenCL 2.0 blocks used in function arguments.
+
+- Fixed MS mangling for OpenCL 2.0 pipe type specifier.
+
+- Improved command line options for fast relaxed math.
+
+- Improved `atomic_fetch_min/max` functions in the internal header
+  (`opencl-c.h`).
+
+- Improved size of builtin function table for `TableGen`-based internal header
+  (enabled by `-fdeclare-opencl-builtins`) and added new functionality for
+  OpenCL 2.0 atomics, pipes, enqueue kernel, `cl_khr_subgroups`,
+  `cl_arm_integer_dot_product`.
+
+Changes related to C++ for OpenCL
+^
+
+- Added `addrspace_cast` operator.
+
+- Improved address space deduction in templates.
+
+- Improved diagnostics of address spaces in nested pointer conversions.
 
 ABI Changes in Clang
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D86562: [OPENMP][NFC]Release notes for OpenMP in clang (11.x).

2020-08-26 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

>> but we can merge this right away (IMHO)
>
> It is up to Hans if he has some time. But I think I covered almost all new 
> features (+ complex for NVPTX), so after the update it can be merged with 
> 11.x release.

It's fine by me if you want to wait a day or two for more comments, or go ahead 
and merge directly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86562

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


[PATCH] D85736: [Sema][AArch64] Support arm_sve_vector_bits attribute

2020-08-26 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM aside from some minor nits.




Comment at: clang/include/clang/AST/Type.h:3228
+SveFixedLengthDataVector,
+/// is AArch64 SVE fixed-length predicate vector
+SveFixedLengthPredicateVector

Add a bit of vertical whitespace for consistency with surrounding enumerators?



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2928
+def err_typecheck_vector_not_convertable_sizeless : Error<
+  "cannot convert between fixed-length and sizeless vector (%0 and %1)">;
 def err_typecheck_vector_not_convertable_implict_truncation : Error<

vector -> vectors
(alternatively, `a fixed-length and a sizeless vector`)



Comment at: clang/lib/AST/ASTContext.cpp:1945
+// Adjust the alignment for fixed-length SVE predicates.
+if (VT->getVectorKind() == VectorType::SveFixedLengthPredicateVector)
+  Align = 16;

`else if`?



Comment at: clang/lib/AST/ASTContext.cpp:8396
+
+  auto IsValidCast = [&](QualType FirstType, QualType SecondType) {
+if (const auto *BT = FirstType->getAs()) {

This only needs to capture `this` and not reference capture everything, right? 
I'd prefer that (esp given that the lambda parameters shadow the names of the 
function parameters).



Comment at: clang/lib/Sema/SemaExpr.cpp:9913
+  // Returns true if the operands are SVE VLA and VLS types.
+  auto IsSveConversion = [](QualType , QualType ) {
+const VectorType *VecType = SecondType->getAs();

No need for the parameters to be non-const references (you can use value types 
here, they're cheap).



Comment at: clang/lib/Sema/SemaOverload.cpp:1656
+  if (ToType->isSizelessBuiltinType() || FromType->isSizelessBuiltinType()) {
+if (S.Context.areCompatibleSveTypes(FromType, ToType)) {
+  ICK = ICK_SVE_Vector_Conversion;

This can be hoisted into the preceding `if` statement.



Comment at: clang/lib/Sema/SemaType.cpp:7817
+  if (BT->getKind() == BuiltinType::SveBool) {
+// Predicates are represented as i8
+VecSize /= S.Context.getCharWidth() * S.Context.getCharWidth();

Full stop at the end of the comment.


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

https://reviews.llvm.org/D85736

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


[PATCH] D86581: [clang-format] Handle shifts within conditions

2020-08-26 Thread Miguel Saldivar via Phabricator via cfe-commits
Saldivarcher added a comment.

MyDeveloperDay, I added your tests. Sorry to step on your toes, I didn't know 
there was a patch open for this already :(. Yeah, JakeMerdichAMD, it's kinda 
tough to handle those types of cases without some sort of parsing. I'm glad 
you're working on that, and my code doesn't get in the way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86581

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


[PATCH] D86089: [flang][driver]Add experimental flang driver and frontend with help screen

2020-08-26 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added a comment.

@andwar is my Phabricator alter-ego. Apologies for the confusion - I had my 
Arcanist misconfigured.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86089

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


[PATCH] D86027: [analyzer] Add bool operator modeling for unque_ptr

2020-08-26 Thread Nithin VR via Phabricator via cfe-commits
vrnithinkumar updated this revision to Diff 288048.
vrnithinkumar marked an inline comment as done.
vrnithinkumar added a comment.

- Removing unnecessary notetags.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86027

Files:
  clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
  clang/test/Analysis/smart-ptr-text-output.cpp
  clang/test/Analysis/smart-ptr.cpp

Index: clang/test/Analysis/smart-ptr.cpp
===
--- clang/test/Analysis/smart-ptr.cpp
+++ clang/test/Analysis/smart-ptr.cpp
@@ -8,12 +8,13 @@
 void clang_analyzer_warnIfReached();
 void clang_analyzer_numTimesReached();
 void clang_analyzer_eval(bool);
+void clang_analyzer_warnOnDeadSymbol(int *);
 
 void derefAfterMove(std::unique_ptr P) {
   std::unique_ptr Q = std::move(P);
   if (Q)
 clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
-  *Q.get() = 1; // no-warning
+  *Q.get() = 1; // expected-warning {{Dereference of null pointer [core.NullDereference]}}
   if (P)
 clang_analyzer_warnIfReached(); // no-warning
   // TODO: Report a null dereference (instead).
@@ -333,3 +334,69 @@
   P = returnRValRefOfUniquePtr();
   P->foo(); // No warning. 
 }
+
+void derefConditionOnNullPtr() {
+  std::unique_ptr P;
+  if (P)
+P->foo(); // No warning.
+  else
+P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
+}
+
+void derefConditionOnNotNullPtr() {
+  std::unique_ptr P;
+  if (!P)
+P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
+}
+
+void derefConditionOnValidPtr() {
+  std::unique_ptr P(new A());
+  std::unique_ptr PNull;
+  if (P)
+PNull->foo(); // expected-warning {{Dereference of null smart pointer 'PNull' [alpha.cplusplus.SmartPtr]}}
+}
+
+void derefConditionOnNotValidPtr() {
+  std::unique_ptr P(new A());
+  std::unique_ptr PNull;
+  if (!P)
+PNull->foo(); // No warning.
+}
+
+void derefConditionOnUnKnownPtr(std::unique_ptr P) {
+  if (P)
+P->foo(); // No warning.
+  else
+P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
+}
+
+void derefOnValidPtrAfterReset(std::unique_ptr P) {
+  P.reset(new A());
+  if (!P)
+P->foo(); // No warning.
+  else
+P->foo(); // No warning.
+}
+
+void innerPointerSymbolLiveness() {
+  std::unique_ptr P(new int());
+  clang_analyzer_warnOnDeadSymbol(P.get());
+  int *RP = P.release();
+} // expected-warning{{SYMBOL DEAD}}
+
+void boolOpCreatedConjuredSymbolLiveness(std::unique_ptr P) {
+  if (P) {
+int *X = P.get();
+clang_analyzer_warnOnDeadSymbol(X);
+  }
+} // expected-warning{{SYMBOL DEAD}}
+
+void getCreatedConjuredSymbolLiveness(std::unique_ptr P) {
+  int *X = P.get();
+  clang_analyzer_warnOnDeadSymbol(X);
+  int Y;
+  if (!P) {
+Y = *P.get(); // expected-warning {{Dereference of null pointer [core.NullDereference]}}
+// expected-warning@-1 {{SYMBOL DEAD}}
+  }
+}
Index: clang/test/Analysis/smart-ptr-text-output.cpp
===
--- clang/test/Analysis/smart-ptr-text-output.cpp
+++ clang/test/Analysis/smart-ptr-text-output.cpp
@@ -170,3 +170,108 @@
   P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
   // expected-note@-1 {{Dereference of null smart pointer 'P'}}
 }
+
+void derefConditionOnNullPtrFalseBranch() {
+  std::unique_ptr P; // expected-note {{Default constructed smart pointer 'P' is null}}
+  if (P) { // expected-note {{Taking false branch}}
+P->foo(); // No warning.
+  } else {
+P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
+// expected-note@-1{{Dereference of null smart pointer 'P'}}
+  }
+}
+
+void derefConditionOnNullPtrTrueBranch() {
+  std::unique_ptr P; // expected-note {{Default constructed smart pointer 'P' is null}}
+  if (!P) { // expected-note {{Taking true branch}}
+P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
+// expected-note@-1{{Dereference of null smart pointer 'P'}}
+  }
+}
+
+void derefConditionOnValidPtrTrueBranch() {
+  std::unique_ptr P(new A());
+  std::unique_ptr PNull; // expected-note {{Default constructed smart pointer 'PNull' is null}}
+  if (P) { // expected-note {{Taking true branch}}
+PNull->foo(); // expected-warning {{Dereference of null smart pointer 'PNull' [alpha.cplusplus.SmartPtr]}}
+// expected-note@-1{{Dereference of null smart pointer 'PNull'}}
+  } else {
+PNull->foo(); // No warning
+  }
+}
+
+void derefConditionOnValidPtrFalseBranch() {
+  std::unique_ptr P(new A());
+  std::unique_ptr PNull; // expected-note {{Default constructed smart pointer 'PNull' is null}}
+  if (!P) { // expected-note {{Taking false branch}}
+PNull->foo(); // No warning
+  } 

[PATCH] D86622: Fix failing tests after VCTOOLSDIR change

2020-08-26 Thread Zachary Henkel via Phabricator via cfe-commits
zahen added a comment.

Sorry again about the break!  As with the initial patch, I'll need you to land 
this change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86622

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


[PATCH] D86581: [clang-format] Handle shifts within conditions

2020-08-26 Thread Jake Merdich via Phabricator via cfe-commits
JakeMerdichAMD added a comment.

Agreed that this is a very nice solution for this case. LGTM too assuming it 
passes @MyDeveloperDay's tests.

Minor heads up: there are still some cases I can dream up where we'd currently 
spit out invalid code from splitting a right shift even after this fix. Long 
story short, C++14 made some cases completely ambiguous and impossible to 
detect without semantic analysis (https://godbolt.org/z/rxEqTG). I'll be having 
a fix out for that soon, but it's rather complementary to this one-- yours 
improves template detection, mine acts more conservative in case we guessed 
wrong about it being a template.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86581

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


[PATCH] D85214: [OpenMP] Ensure testing for versions 4.5 and default - Part 3

2020-08-26 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85214

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


[PATCH] D86626: [OpenCL][Docs] 10.x release notes

2020-08-26 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh accepted this revision.
svenvh added a comment.
This revision is now accepted and ready to land.

LGTM!


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

https://reviews.llvm.org/D86626

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


[PATCH] D86624: [clang] Exclude invalid destructors from lookups.

2020-08-26 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/AST/DeclBase.cpp:1489
   return true;
+  if (isa(D) && D->isInvalidDecl())
+return true;

split into separate block, add a comment why



Comment at: clang/test/PCH/cxx-invalid-destructor.cpp:2
+// RUN: %clang_cc1 -x c++ -std=c++11 -emit-pch -o %t 
%S/cxx-invalid-destructor.h -fallow-pch-with-compiler-errors
+// RUN: %clang_cc1 -x c++ -std=c++11 -include-pch %t 
%S/cxx-invalid-destructor.cpp -fsyntax-only -fno-validate-pch
+

nit: -fno-validate-pch shouldn't be needed IIUC



Comment at: clang/test/PCH/cxx-invalid-destructor.h:6
+
+class Bar {
+public:

nit: we can eliminate Bar I think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86624

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


[PATCH] D86562: [OPENMP][NFC]Release notes for OpenMP in clang (11.x).

2020-08-26 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D86562#2239136 , @hans wrote:

>>> but we can merge this right away (IMHO)
>>
>> It is up to Hans if he has some time. But I think I covered almost all new 
>> features (+ complex for NVPTX), so after the update it can be merged with 
>> 11.x release.
>
> It's fine by me if you want to wait a day or two for more comments, or go 
> ahead and merge directly.

Let's wait a day more then. Tomorrow it would be definitely ok to merge it with 
11.x


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86562

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


[PATCH] D86632: [Fixed Point] Add codegen for conversion between fixed-point and floating point.

2020-08-26 Thread Bevin Hansson via Phabricator via cfe-commits
ebevhan created this revision.
ebevhan added reviewers: leonardchan, rjmccall.
Herald added subscribers: llvm-commits, cfe-commits, bjope.
Herald added projects: clang, LLVM.
ebevhan requested review of this revision.

The patch adds the required methods to FixedPointBuilder
for converting between fixed-point and floating point,
and uses them from Clang.

This depends on D54749 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86632

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/Frontend/fixed_point_compound.c
  clang/test/Frontend/fixed_point_conversions.c
  llvm/include/llvm/IR/FixedPointBuilder.h

Index: llvm/include/llvm/IR/FixedPointBuilder.h
===
--- llvm/include/llvm/IR/FixedPointBuilder.h
+++ llvm/include/llvm/IR/FixedPointBuilder.h
@@ -159,6 +159,48 @@
DstSema, false);
   }
 
+  Value *CreateFixedToFloating(Value *Src, const FixedPointSemantics ,
+   Type *DstTy) {
+Value *Result;
+// Convert the raw fixed-point value directly to floating point. If the
+// value is too large to fit, it will be rounded, not truncated.
+Result = SrcSema.isSigned() ? B.CreateSIToFP(Src, DstTy)
+: B.CreateUIToFP(Src, DstTy);
+// Rescale the integral-in-floating point by the scaling factor. This is
+// lossless, except for overflow to infinity which is unlikely.
+return B.CreateFMul(Result,
+ConstantFP::get(DstTy, std::pow(2, -(int)SrcSema.getScale(;
+  }
+
+  Value *CreateFloatingToFixed(Value *Src, const FixedPointSemantics ) {
+bool UseSigned = DstSema.isSigned() || DstSema.hasUnsignedPadding();
+Value *Result;
+// Rescale the floating point value so that its significant bits (for the
+// purposes of the conversion) are in the integral range.
+Result = B.CreateFMul(Src,
+ConstantFP::get(Src->getType(), std::pow(2, DstSema.getScale(;
+
+Type *ResultTy = B.getIntNTy(DstSema.getWidth());
+if (DstSema.isSaturated()) {
+  Intrinsic::ID IID =
+  UseSigned ? Intrinsic::fptosi_sat : Intrinsic::fptoui_sat;
+  Result = B.CreateIntrinsic(IID, {ResultTy, Src->getType()}, {Result});
+} else {
+  Result = UseSigned ? B.CreateFPToSI(Result, ResultTy)
+ : B.CreateFPToUI(Result, ResultTy);
+}
+
+// When saturating unsigned-with-padding using signed operations, we may
+// get negative values. Emit an extra clamp to zero.
+if (DstSema.isSaturated() && DstSema.hasUnsignedPadding()) {
+  Constant *Zero = Constant::getNullValue(Result->getType());
+  Result =
+  B.CreateSelect(B.CreateICmpSLT(Result, Zero), Zero, Result, "satmin");
+}
+
+return Result;
+  }
+
   /// Add two fixed-point values and return the result in their common semantic.
   /// \p LHS - The left hand side
   /// \p LHSSema - The semantic of the left hand side
Index: clang/test/Frontend/fixed_point_conversions.c
===
--- clang/test/Frontend/fixed_point_conversions.c
+++ clang/test/Frontend/fixed_point_conversions.c
@@ -26,11 +26,15 @@
 _Sat short _Fract sat_sf;
 _Sat _Fract sat_f;
 _Sat long _Fract sat_lf;
+_Sat unsigned _Fract sat_uf;
 
 short s;
 int i;
 unsigned int ui;
 
+float fl;
+double d;
+
 // CHECK-LABEL: @fix_same1(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* @a, align 4
@@ -695,3 +699,298 @@
 void int_sat4() {
   sat_usa = ui;
 }
+
+
+// CHECK-LABEL: @float_fix1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = load float, float* @fl, align 4
+// CHECK-NEXT:[[TMP1:%.*]] = fmul float [[TMP0]], 1.28e+02
+// CHECK-NEXT:[[TMP2:%.*]] = fptosi float [[TMP1]] to i16
+// CHECK-NEXT:store i16 [[TMP2]], i16* @sa, align 2
+// CHECK-NEXT:ret void
+//
+void float_fix1() {
+  sa = fl;
+}
+
+// CHECK-LABEL: @float_fix2(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = load float, float* @fl, align 4
+// CHECK-NEXT:[[TMP1:%.*]] = fmul float [[TMP0]], 3.276800e+04
+// CHECK-NEXT:[[TMP2:%.*]] = fptosi float [[TMP1]] to i32
+// CHECK-NEXT:store i32 [[TMP2]], i32* @a, align 4
+// CHECK-NEXT:ret void
+//
+void float_fix2() {
+  a = fl;
+}
+
+// CHECK-LABEL: @float_fix3(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = load float, float* @fl, align 4
+// CHECK-NEXT:[[TMP1:%.*]] = fmul float [[TMP0]], 0x41E0
+// CHECK-NEXT:[[TMP2:%.*]] = fptosi float [[TMP1]] to i64
+// CHECK-NEXT:store i64 [[TMP2]], i64* @la, align 8
+// CHECK-NEXT:ret void
+//
+void float_fix3() {
+  la = fl;
+}
+
+// CHECK-LABEL: @float_fix4(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = load float, float* @fl, align 4
+// CHECK-NEXT:[[TMP1:%.*]] = fmul float [[TMP0]], 1.28e+02
+// CHECK-NEXT:[[TMP2:%.*]] = fptosi float [[TMP1]] to i8

[PATCH] D77219: UBSan ␇ runtime

2020-08-26 Thread JF Bastien via Phabricator via cfe-commits
jfb abandoned this revision.
jfb added a comment.
Herald added a subscriber: dang.

I don't think the world is ready for this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77219

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


[PATCH] D85485: Fix quiet mode in git-clang-format

2020-08-26 Thread serge 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 rG294e1900f281: Fix quiet mode in git-clang-format (authored 
by Gvald, committed by serge-sans-paille).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85485

Files:
  clang/tools/clang-format/git-clang-format


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -148,7 +148,8 @@
   for filename in changed_lines:
 print('%s' % filename)
   if not changed_lines:
-print('no modified files to format')
+if opts.verbose >= 0:
+  print('no modified files to format')
 return
   # The computed diff outputs absolute paths, so we must cd before accessing
   # those files.


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -148,7 +148,8 @@
   for filename in changed_lines:
 print('%s' % filename)
   if not changed_lines:
-print('no modified files to format')
+if opts.verbose >= 0:
+  print('no modified files to format')
 return
   # The computed diff outputs absolute paths, so we must cd before accessing
   # those files.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 294e190 - Fix quiet mode in git-clang-format

2020-08-26 Thread via cfe-commits

Author: Gi Vald
Date: 2020-08-26T18:15:52+02:00
New Revision: 294e1900f281f35aff0362232225e85c2e551e55

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

LOG: Fix quiet mode in git-clang-format

Quiet mode is very useful for scripting, when only the diff format output is
required, or no output if not formatting is needed.
In case of no modified files, git-clang-format will output to screen even though
the quiet mode enabled.

This patch changes this behavior, so if quiet flag passes in - no output will be
available, even if no modified files exists.

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

Added: 


Modified: 
clang/tools/clang-format/git-clang-format

Removed: 




diff  --git a/clang/tools/clang-format/git-clang-format 
b/clang/tools/clang-format/git-clang-format
index f3cd585e7f4a..e4dc4cbc1dc9 100755
--- a/clang/tools/clang-format/git-clang-format
+++ b/clang/tools/clang-format/git-clang-format
@@ -148,7 +148,8 @@ def main():
   for filename in changed_lines:
 print('%s' % filename)
   if not changed_lines:
-print('no modified files to format')
+if opts.verbose >= 0:
+  print('no modified files to format')
 return
   # The computed 
diff  outputs absolute paths, so we must cd before accessing
   # those files.



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


[PATCH] D86636: [SyntaxTree] Refactor `NodeRole`s

2020-08-26 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 accepted this revision.
gribozavr2 added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/include/clang/Tooling/Syntax/Nodes.h:156
   // Roles specific to particular node kinds.
-  OperatorExpression_operatorToken,
-  UnaryOperatorExpression_operand,
-  BinaryOperatorExpression_leftHandSide,
-  BinaryOperatorExpression_rightHandSide,
-  CaseStatement_value,
-  IfStatement_thenStatement,
-  IfStatement_elseKeyword,
-  IfStatement_elseStatement,
-  ReturnStatement_value,
-  ExpressionStatement_expression,
-  CompoundStatement_statement,
-  StaticAssertDeclaration_condition,
-  StaticAssertDeclaration_message,
-  SimpleDeclaration_declarator,
-  TemplateDeclaration_declaration,
-  ExplicitTemplateInstantiation_declaration,
-  ArraySubscript_sizeExpression,
-  TrailingReturnType_declarator,
-  ParametersAndQualifiers_parameters,
-  ParametersAndQualifiers_trailingReturn,
-  IdExpression_id,
-  IdExpression_qualifier,
-  ParenExpression_subExpression,
-  MemberExpression_object,
-  MemberExpression_accessToken,
-  MemberExpression_member,
-  CallExpression_callee,
-  CallExpression_arguments,
+  // OperatorExpression
+  OperatorToken,

I'd suggest to remove the cross-references in the comments. In my experience, 
one is much better off using "find references" in the IDE. The comments can 
(and do) rapidly become stale.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86636

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


[PATCH] D85091: [Sema, CodeGen] Implement [[likely]] and [[unlikely]] in IfStmt

2020-08-26 Thread Mark de Wever via Phabricator via cfe-commits
Mordante marked 4 inline comments as done.
Mordante added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:1726
+  }
+  }];
+}

aaron.ballman wrote:
> Something else we should document is what our behavior is when the attribute 
> is not immediately inside of an `if` or `else` statement. e.g.,
> ```
> void func() { // Does not behave as though specified with [[gnu::hot]]
>   [[likely]];
> }
> 
> void func() {
>   if (x) {
> {
>   [[likely]]; // Does this make the if branch likely?
>   SomeRAIIObj Obj;
> }
>   } else {
>   }
> }
> 
> void func() {
>   if (x) {
> int y = ({[[likely]]; /* Does this make the if branch likely? */ 1;});
>   } else {
>   }
> }
> ```
> Something else we should document is what our behavior is when the attribute 
> is not immediately inside of an `if` or `else` statement. e.g.,
> ```
> void func() { // Does not behave as though specified with [[gnu::hot]]
>   [[likely]];
> }

No a few days ago I wondered whether it makes sense, but the [[gnu::hot]] 
should be at the declaration of the function and not in the body. 
So I think this doesn't make sense and the `[[likely]]` here will be ignored.

> void func() {
>   if (x) {
> {
>   [[likely]]; // Does this make the if branch likely?
>   SomeRAIIObj Obj;
> }
>   } else {
>   }
> }

Yes this should work, the attribute will recursively visit compound statements.

> void func() {
>   if (x) {
> int y = ({[[likely]]; /* Does this make the if branch likely? */ 1;});
>   } else {
>   }
> }
> ```

Not in this patch. I'm working on more improvements to make switch statements 
working. I tested it with my current WIP and there it does work.
So in the future this will work.



Comment at: clang/lib/CodeGen/CGStmt.cpp:691
+  Visit(S);
+  if (Result != None)
+return;

aaron.ballman wrote:
> Is early return the correct logic? Won't that give surprising results in the 
> case the programmer has both attributes in the same compound statement? I 
> think we need to look over all the statements in the current block, increment 
> a counter when we hit `[[likely]]`, decrement the counter when we hit 
> `[[unlikely]]` and return whether the counter is 0, negative (unlikely), or 
> positive (likely).
Yes here it accepts the first likelihood it finds and accepts that as the 
wanted likelihood. I also start to doubt whether that's wanted. In my current 
switch WIP I  issue an diagnostic if there's a conflict between the likelihood 
diagnostics and ignore them. I feel that's a better approach. This diagnostic 
is added to the `-Wignored-attributes` group, which is shown by default.

I don't like the idea of using a counter. If the attribute is "hidden" in a 
validation macro, adding it to a branch might suddenly change the likelihood of 
that branch.




Comment at: clang/lib/CodeGen/CGStmt.cpp:723
+  // The user can use conflicting likelihood attributes within one of the
+  // statements or between the statements. These conflicts are ignored and the
+  // first match is used.

aaron.ballman wrote:
> I do not think conflicts should result in the first match being used (unless 
> we're diagnosing the situation, at which point some of this code should be 
> lifted into Sema and set a bit on an AST node that can be read during codegen 
> time), so this comment may need to be updated.
Agreed. In my current switch WIP I already started experimenting with moving 
the likelihood selection to Sema and store the likelihood in the AST bits.



Comment at: clang/lib/CodeGen/CGStmt.cpp:791
+  llvm::MDNode *Weights = nullptr;
+  uint64_t Count = getProfileCount(S.getThen());
+  if (!Count && CGM.getCodeGenOpts().OptimizationLevel) {

aaron.ballman wrote:
> Perhaps not for this patch, but I wonder if we'd be doing users a good deed 
> by alerting them when PGO weights do not match the attribute specified. e.g., 
> if an attribute says "this branch is likely" and PGO shows it's unlikely, 
> that seems like something the programmer may wish to know. WDYT?
I already investigated before and there's a diagnostic 
`warn_profile_data_misexpect` when using `__builtin_expect` so I expect I can 
reuse existing code. So I want to have a look at it, but I first want to get 
the more important parts of the likelihood attributes working properly.


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

https://reviews.llvm.org/D85091

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


  1   2   >