[PATCH] D56411: [CUDA][HIP][Sema] Fix template kernel with function as template parameter

2019-01-07 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Sema won't necessarily have resolved a template decl when parsing a template 
argument list, so trying to propagate that decl down to indicate that we're 
resolving a template argument is not a good approach.

I was going to suggest recording that we're within a template argument in the 
current `ExpressionEvaluationContextRecord`, but in fact there's an even 
simpler and more general solution: there's no reason to enforce this 
restriction in *any* unevaluated context.  If someone wants to refer to a 
device function within a `decltype` or `sizeof` operand, that should be fine.  
So you should just conditionalize the diagnostic on whether this is within an 
unevaluated context.


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

https://reviews.llvm.org/D56411



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


[PATCH] D56424: [clang-tidy] Add check for underscores in googletest names.

2019-01-07 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D56424#1349218 , @karepker wrote:

> Clean up comments in test file.


For reference, what documentation sources did you read when creating the review 
itseft?
I thought it was documented that an appropriate category (`[clang-tidy]`) 
should be present in the subject.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56424



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


[PATCH] D56395: [ASTMatchers] Improve assert message for broken parent map.

2019-01-07 Thread Sam McCall via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL350612: [ASTMatchers] Improve assert message for broken 
parent map. (authored by sammccall, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56395

Files:
  cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp


Index: cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp
+++ cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -676,13 +676,17 @@
   //  c) there is a bug in the AST, and the node is not reachable
   // Usually the traversal scope is the whole AST, which precludes b.
   // Bugs are common enough that it's worthwhile asserting when we can.
-  assert((Node.get() ||
-  /* Traversal scope is limited if none of the bounds are the TU */
-  llvm::none_of(ActiveASTContext->getTraversalScope(),
-[](Decl *D) {
-  return D->getKind() == Decl::TranslationUnit;
-})) &&
- "Found node that is not in the complete parent map!");
+#ifndef NDEBUG
+  if (!Node.get() &&
+  /* Traversal scope is full AST if any of the bounds are the TU */
+  llvm::any_of(ActiveASTContext->getTraversalScope(), [](Decl *D) {
+return D->getKind() == Decl::TranslationUnit;
+  })) {
+llvm::errs() << "Tried to match orphan node:\n";
+Node.dump(llvm::errs(), ActiveASTContext->getSourceManager());
+llvm_unreachable("Parent map should be complete!");
+  }
+#endif
   return false;
 }
 if (Parents.size() == 1) {


Index: cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp
+++ cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -676,13 +676,17 @@
   //  c) there is a bug in the AST, and the node is not reachable
   // Usually the traversal scope is the whole AST, which precludes b.
   // Bugs are common enough that it's worthwhile asserting when we can.
-  assert((Node.get() ||
-  /* Traversal scope is limited if none of the bounds are the TU */
-  llvm::none_of(ActiveASTContext->getTraversalScope(),
-[](Decl *D) {
-  return D->getKind() == Decl::TranslationUnit;
-})) &&
- "Found node that is not in the complete parent map!");
+#ifndef NDEBUG
+  if (!Node.get() &&
+  /* Traversal scope is full AST if any of the bounds are the TU */
+  llvm::any_of(ActiveASTContext->getTraversalScope(), [](Decl *D) {
+return D->getKind() == Decl::TranslationUnit;
+  })) {
+llvm::errs() << "Tried to match orphan node:\n";
+Node.dump(llvm::errs(), ActiveASTContext->getSourceManager());
+llvm_unreachable("Parent map should be complete!");
+  }
+#endif
   return false;
 }
 if (Parents.size() == 1) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r350612 - [ASTMatchers] Improve assert message for broken parent map.

2019-01-07 Thread Sam McCall via cfe-commits
Author: sammccall
Date: Mon Jan  7 23:29:46 2019
New Revision: 350612

URL: http://llvm.org/viewvc/llvm-project?rev=350612&view=rev
Log:
[ASTMatchers] Improve assert message for broken parent map.

Summary:
This assert catches places where the AST (as seen by RecursiveASTVisitor)
becomes disconnected due to incomplete traversal.
Making it print the actual parent-less node is a lot more helpful - it's
possible to work out which part of the tree wasn't traversed.

Reviewers: ilya-biryukov

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp

Modified: cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp?rev=350612&r1=350611&r2=350612&view=diff
==
--- cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp (original)
+++ cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp Mon Jan  7 23:29:46 2019
@@ -676,13 +676,17 @@ private:
   //  c) there is a bug in the AST, and the node is not reachable
   // Usually the traversal scope is the whole AST, which precludes b.
   // Bugs are common enough that it's worthwhile asserting when we can.
-  assert((Node.get() ||
-  /* Traversal scope is limited if none of the bounds are the TU */
-  llvm::none_of(ActiveASTContext->getTraversalScope(),
-[](Decl *D) {
-  return D->getKind() == Decl::TranslationUnit;
-})) &&
- "Found node that is not in the complete parent map!");
+#ifndef NDEBUG
+  if (!Node.get() &&
+  /* Traversal scope is full AST if any of the bounds are the TU */
+  llvm::any_of(ActiveASTContext->getTraversalScope(), [](Decl *D) {
+return D->getKind() == Decl::TranslationUnit;
+  })) {
+llvm::errs() << "Tried to match orphan node:\n";
+Node.dump(llvm::errs(), ActiveASTContext->getSourceManager());
+llvm_unreachable("Parent map should be complete!");
+  }
+#endif
   return false;
 }
 if (Parents.size() == 1) {


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


[PATCH] D55662: [Sema][ObjC] Do not warn about repeated uses of weak variables when the variables are accessed in an unevaluated context.

2019-01-07 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Oh, and please update the commit message to primarily talk about the changes to 
placeholder checking.  You can discuss the impact on the repeated-use-of-weak 
warning in a follow-up paragraph.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55662



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


[PATCH] D55662: [Sema][ObjC] Do not warn about repeated uses of weak variables when the variables are accessed in an unevaluated context.

2019-01-07 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: lib/Sema/SemaLambda.cpp:793
+  else
+Args = Init;
+

Please maintain the original order here, even though I suspect it doesn't 
matter: if this is direct-initialization, use the arguments, otherwise use 
either `DeducedAutoInit` or `Init`.  Although really, consider just reassigning 
`Init` immediately after the `deduceVarType...` call.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55662



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


[PATCH] D56367: [AST] Pack CXXDependentScopeMemberExpr

2019-01-07 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Yeah, LGTM.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56367



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


[PATCH] D17741: adds __FILE_BASENAME__ builtin macro

2019-01-07 Thread Kristina Brooks via Phabricator via cfe-commits
kristina added a comment.

Ping for author? This is one of the changes I'd like to see through, though the 
complexity here can be massively reduced as stated above. I wouldn't mind 
opening a new diff if the author is away with just a change in PPMacroExpansion 
and a testcase (which should probably be included here) but I would appreciate 
some form of consensus since this exact idea with a special macro for filename 
was previously rejected.


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

https://reviews.llvm.org/D17741



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


[PATCH] D56424: Add check for underscores in googletest names.

2019-01-07 Thread Kar Epker via Phabricator via cfe-commits
karepker updated this revision to Diff 180603.
karepker added a comment.

Clean up comments in test file.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56424

Files:
  clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
  clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.h
  clang-tidy/google/CMakeLists.txt
  clang-tidy/google/GoogleTidyModule.cpp
  
docs/clang-tidy/checks/google-readability-avoid-underscore-in-googletest-name.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/readability-avoid-underscore-in-googletest-name.cpp

Index: test/clang-tidy/readability-avoid-underscore-in-googletest-name.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-avoid-underscore-in-googletest-name.cpp
@@ -0,0 +1,103 @@
+// RUN: %check_clang_tidy %s google-readability-avoid-underscore-in-googletest-name %t
+
+#define TEST(test_case_name, test_name) void test_case_name##test_name()
+#define TEST_F(test_case_name, test_name) void test_case_name##test_name()
+#define TEST_P(test_case_name, test_name) void test_case_name##test_name()
+#define TYPED_TEST(test_case_name, test_name) void test_case_name##test_name()
+#define TYPED_TEST_P(test_case_name, test_name) void test_case_name##test_name()
+
+TEST(TestCaseName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST(TestCaseName, DISABLED_Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(TestCaseName, Illegal_Test_Name) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: avoid using "_" in test name "Illegal_Test_Name" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(Illegal_TestCaseName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_TestCaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(Illegal_Test_CaseName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_Test_CaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(Illegal_TestCaseName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_TestCaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+// CHECK-MESSAGES: :[[@LINE-2]]:28: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_F(TestCaseFixtureName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_F(TestCaseFixtureName, DISABLED_Illegal_Test_Name) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: avoid using "_" in test name "Illegal_Test_Name" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_F(TestCaseFixtureName, Illegal_Test_Name) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: avoid using "_" in test name "Illegal_Test_Name" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_F(Illegal_TestCaseFixtureName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test case name "Illegal_TestCaseFixtureName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_F(Illegal_TestCaseFixtureName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test case name "Illegal_TestCaseFixtureName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+// CHECK-MESSAGES: :[[@LINE-2]]:37: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_F(Illegal_Test_CaseFixtureName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test case name "Illegal_Test_CaseFixtureName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_P(ParameterizedTestCaseFixtureName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:42: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_P(ParameterizedTestCaseFixtureName, DISABLED_Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:42: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avo

[PATCH] D56424: Add check for underscores in googletest names.

2019-01-07 Thread Kar Epker via Phabricator via cfe-commits
karepker created this revision.
karepker added a reviewer: hokein.
Herald added a subscriber: mgorny.

Adds a clang-tidy warning for underscores in googletest names.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D56424

Files:
  clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
  clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.h
  clang-tidy/google/CMakeLists.txt
  clang-tidy/google/GoogleTidyModule.cpp
  
docs/clang-tidy/checks/google-readability-avoid-underscore-in-googletest-name.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/readability-avoid-underscore-in-googletest-name.cpp

Index: test/clang-tidy/readability-avoid-underscore-in-googletest-name.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-avoid-underscore-in-googletest-name.cpp
@@ -0,0 +1,107 @@
+// RUN: %check_clang_tidy %s google-readability-avoid-underscore-in-googletest-name %t
+
+#define TEST(test_case_name, test_name) void test_case_name##test_name()
+#define TEST_F(test_case_name, test_name) void test_case_name##test_name()
+#define TEST_P(test_case_name, test_name) void test_case_name##test_name()
+#define TYPED_TEST(test_case_name, test_name) void test_case_name##test_name()
+#define TYPED_TEST_P(test_case_name, test_name) void test_case_name##test_name()
+
+TEST(TestCaseName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST(TestCaseName, DISABLED_Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(TestCaseName, Illegal_Test_Name) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: avoid using "_" in test name "Illegal_Test_Name" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(Illegal_TestCaseName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_TestCaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(Illegal_Test_CaseName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_Test_CaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST(Illegal_TestCaseName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_TestCaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+// CHECK-MESSAGES: :[[@LINE-2]]:28: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_F(TestCaseFixtureName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_F(TestCaseFixtureName, DISABLED_Illegal_Test_Name) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: avoid using "_" in test name "Illegal_Test_Name" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_F(TestCaseFixtureName, Illegal_Test_Name) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: avoid using "_" in test name "Illegal_Test_Name" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_F(Illegal_TestCaseFixtureName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test case name "Illegal_TestCaseFixtureName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_F(Illegal_TestCaseFixtureName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test case name "Illegal_TestCaseFixtureName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+// CHECK-MESSAGES: :[[@LINE-2]]:37: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_F(Illegal_Test_CaseFixtureName, TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test case name "Illegal_Test_CaseFixtureName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+
+TEST_P(ParameterizedTestCaseFixtureName, Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:42: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+TEST_P(ParameterizedTestCaseFixtureName, DISABLED_Illegal_TestName) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:42: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-und

[PATCH] D56415: NFC: Port QueryParser to StringRef

2019-01-07 Thread Kristina Brooks via Phabricator via cfe-commits
kristina added a reviewer: kristina.
kristina added a comment.

LGTM aside from one comment.




Comment at: clang-query/QueryParser.cpp:36
+  if (Line.front() == '#') {
+Line = {};
 return StringRef();

I don't think this is the best way of handling it, in fact I'm pretty certain 
you're leaking memory here.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56415



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


[PATCH] D56160: [clang-tidy] modernize-use-trailing-return check

2019-01-07 Thread Bernhard Manfred Gruber via Phabricator via cfe-commits
bernhardmgruber added a comment.

@JonasToth Do you really think I should drop the extra information on why I 
could not provide a FixIt? If truly yes, than I would like to keep them as 
comments.


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

https://reviews.llvm.org/D56160



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


[PATCH] D37035: Implement __builtin_LINE() et. al. to support source location capture.

2019-01-07 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF marked 18 inline comments as done.
EricWF added a comment.

Mark more review comments as done.




Comment at: lib/AST/Expr.cpp:2026-2027
+  // human readable name.
+  if (IdentifierInfo *II = FD->getDeclName().getAsIdentifierInfo())
+return MkStr(II->getNameStart());
+  return MkStr(PredefinedExpr::ComputeName(PredefinedExpr::Function, FD));

rsmith wrote:
> Is the benefit of avoiding a `std::string` allocation here really worth the 
> cost of duplicating this portion of the `__FUNCTION__` logic?
> 
> If we care about the extra string allocation, it'd seem more worthwhile to 
> extend `ComputeName` so that a stack-allocated `SmallString` buffer can be 
> passed in (eg, `StringRef ComputeName(..., SmallVectorImpl 
> &NameStorage)`, where `NameStorage` may, but need not, be used to store the 
> resulting string).
Probably. not. I think this optimization attempt is a remnant from an older 
caching approach.



Comment at: lib/AST/ExprConstant.cpp:2653-2655
+APValue::LValueBase const &Base,
 uint64_t Index) {
+  const Expr *Lit = Base.get();

rsmith wrote:
> Hm, why the move of the `get` from caller to callee? This widens the set of 
> possible arguments to `extractStringLiteralCharacter`, but all the new 
> possibilities result in crashes -- shouldn't the caller, rather than the 
> callee, still be the place where we house the assertion that the base is 
> indeed an expression?
Remant of an older version of the patch. I'll revert.

Sorry, I'll try being better about reviewing patches for unnecessary changes.



Comment at: lib/AST/ExprConstant.cpp:3370-3371
+
+  assert((!Base || !isa(Base)) &&
+ "Base should have already been transformed into a StringLiteral");
+

rsmith wrote:
> There are lots of forms of expression that cannot be the base of an `LValue` 
> (see the list above `LValueExprEvaluator` for the expression forms that *can* 
> be the base of an `LValue`); is it important to give this one special 
> treatment?
Because a `SourceLocExpr` *can* be the base of an `LValue`. But the way that's 
supported is by transforming the `SourceLocExpr` into a `StringLiteral`. 



Comment at: lib/CodeGen/CGExprConstant.cpp:1762
+ConstantLValue
+ConstantLValueEmitter::VisitSourceLocExpr(const SourceLocExpr *E) {
+  const APValue::LValueBase& Base = Value.getLValueBase();

rsmith wrote:
> Hmm, is this reachable? I thought `SourceLocExpr` was always a prvalue.
You're right. Not sure what I was thinking.



Comment at: lib/Sema/TreeTransform.h:9990
+  bool NeedRebuildFunc = E->getIdentType() == SourceLocExpr::Function &&
+ isa(getSema().CurContext) &&
+ getSema().CurContext != E->getParentContext();

rsmith wrote:
> If we generalize `__builtin_FUNCTION()` to behave like `__FUNCTION__` (and 
> handle function-like contexts that aren't `FunctionDecl`s), this `isa` check 
> will be wrong.
I'll remove it. 


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

https://reviews.llvm.org/D37035



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


[PATCH] D37035: Implement __builtin_LINE() et. al. to support source location capture.

2019-01-07 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF updated this revision to Diff 180597.
EricWF marked 4 inline comments as done.
EricWF added a comment.

Address review comments.


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

https://reviews.llvm.org/D37035

Files:
  docs/LanguageExtensions.rst
  include/clang/AST/ASTContext.h
  include/clang/AST/CurrentSourceLocExprScope.h
  include/clang/AST/Expr.h
  include/clang/AST/ExprCXX.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/AST/Stmt.h
  include/clang/Basic/StmtNodes.td
  include/clang/Basic/TokenKinds.def
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/Expr.cpp
  lib/AST/ExprCXX.cpp
  lib/AST/ExprClassification.cpp
  lib/AST/ExprConstant.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CGExprAgg.cpp
  lib/CodeGen/CGExprComplex.cpp
  lib/CodeGen/CGExprConstant.cpp
  lib/CodeGen/CGExprScalar.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/Parse/ParseExpr.cpp
  lib/Sema/SemaDeclCXX.cpp
  lib/Sema/SemaExceptionSpec.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaExprObjC.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  test/CodeGenCXX/builtin-source-location.cpp
  test/CodeGenCXX/builtin_FUNCTION.cpp
  test/CodeGenCXX/builtin_LINE.cpp
  test/CodeGenCXX/debug-info-line.cpp
  test/Parser/builtin_source_location.c
  test/Sema/source_location.c
  test/SemaCXX/Inputs/source-location-file.h
  test/SemaCXX/source_location.cpp
  tools/libclang/CXCursor.cpp

Index: tools/libclang/CXCursor.cpp
===
--- tools/libclang/CXCursor.cpp
+++ tools/libclang/CXCursor.cpp
@@ -279,6 +279,7 @@
   case Stmt::ParenListExprClass:
   case Stmt::PredefinedExprClass:
   case Stmt::ShuffleVectorExprClass:
+  case Stmt::SourceLocExprClass:
   case Stmt::ConvertVectorExprClass:
   case Stmt::VAArgExprClass:
   case Stmt::ObjCArrayLiteralClass:
Index: test/SemaCXX/source_location.cpp
===
--- /dev/null
+++ test/SemaCXX/source_location.cpp
@@ -0,0 +1,590 @@
+// RUN: %clang_cc1 -std=c++1z -fcxx-exceptions -fexceptions -verify %s
+// expected-no-diagnostics
+
+#define assert(...) ((__VA_ARGS__) ? ((void)0) : throw 42)
+#define CURRENT_FROM_MACRO() SL::current()
+#define FORWARD(...) __VA_ARGS__
+
+template 
+struct Printer;
+
+namespace std {
+namespace experimental {
+struct source_location {
+private:
+  unsigned int __m_line = 0;
+  unsigned int __m_col = 0;
+  const char *__m_file = nullptr;
+  const char *__m_func = nullptr;
+public:
+  static constexpr source_location current(
+  const char *__file = __builtin_FILE(),
+  const char *__func = __builtin_FUNCTION(),
+  unsigned int __line = __builtin_LINE(),
+  unsigned int __col = __builtin_COLUMN()) noexcept {
+source_location __loc;
+__loc.__m_line = __line;
+__loc.__m_col = __col;
+__loc.__m_file = __file;
+__loc.__m_func = __func;
+return __loc;
+  }
+  constexpr source_location() = default;
+  constexpr source_location(source_location const &) = default;
+  constexpr unsigned int line() const noexcept { return __m_line; }
+  constexpr unsigned int column() const noexcept { return __m_col; }
+  constexpr const char *file() const noexcept { return __m_file; }
+  constexpr const char *function() const noexcept { return __m_func; }
+};
+} // namespace experimental
+} // namespace std
+
+using SL = std::experimental::source_location;
+
+#include "Inputs/source-location-file.h"
+namespace SLF = source_location_file;
+
+constexpr bool is_equal(const char *LHS, const char *RHS) {
+  while (*LHS != 0 && *RHS != 0) {
+if (*LHS != *RHS)
+  return false;
+++LHS;
+++RHS;
+  }
+  return *LHS == 0 && *RHS == 0;
+}
+
+template 
+constexpr T identity(T t) {
+  return t;
+}
+
+template 
+struct Pair {
+  T first;
+  U second;
+};
+
+template 
+constexpr bool is_same = false;
+template 
+constexpr bool is_same = true;
+
+// test types
+static_assert(is_same);
+static_assert(is_same);
+static_assert(is_same);
+static_assert(is_same);
+
+// test noexcept
+static_assert(noexcept(__builtin_LINE()));
+static_assert(noexcept(__builtin_COLUMN()));
+static_assert(noexcept(__builtin_FILE()));
+static_assert(noexcept(__builtin_FUNCTION()));
+
+//===--===//
+//__builtin_LINE()
+//===--===//
+
+namespace test_line {
+static_assert(SL::current().line() == __LINE__);
+static_assert(SL::current().line() == CURRENT_FROM_MACRO().line());
+
+static constexpr SL GlobalS = SL::current();
+
+static_assert(GlobalS.line() == __LINE__ - 2);
+
+// clang-format off
+constexpr bool test_line_fn() {
+  const

[PATCH] D56160: [clang-tidy] modernize-use-trailing-return check

2019-01-07 Thread Bernhard Manfred Gruber via Phabricator via cfe-commits
bernhardmgruber added inline comments.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:33
+  const TypeSourceInfo *TSI = F.getTypeSourceInfo();
+  assert(TSI);
+  const FunctionTypeLoc FTL =

JonasToth wrote:
> Please add an error-msg to the assertion like `assert(TSI && "Reason why this 
> must hold");`. Humanreadable for debugging.
I replaced the asserts by an error with a message. Honestly, I do not know when 
these might be nullptr. It just never occured during my tests.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:38
+
+  // if the function argument list ends inside of a macro, it is dangerous to
+  // start lexing from here, bail out

JonasToth wrote:
> Please make that comment (and all comments in general) full grammatical 
> sentence with correct punctuation.
I am not a native English speaker, but the only thing that might be odd about 
this sentence is that `, bail out`. Maybe a em-dash is what we need here, but 
this not Latex. Oh yes, and inside of a macro is also weird.

I will make it: if the function argument list ends inside a macro, it is 
dangerous to start lexing from here - bail out.

I will also add dots at the end of sentences, other checks seem to follow this 
convention (Personally, I do not like the punctuation at the end, as it does 
not add significant information)



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:42
+  if (ClosingParen.isMacroID()) {
+diag(
+F.getLocation(),

JonasToth wrote:
> weird formatting, did clang-format do that?
I use the latest version of Visual Studio and it picks up .clang-format files 
and formats automatically when I save. I can try to run clang-format by hand.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:45
+std::string(Message) +
+" (no FixIt provided, function argument list end is inside 
macro)");
+return {};

JonasToth wrote:
> I think you can ellide that extra message. Not emitting the fixit is clear 
> already.
I actually like having a reason why my check could not provide a FixIt. 
Especially because there are multiple reasons why this might happen.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:46
+" (no FixIt provided, function argument list end is inside 
macro)");
+return {};
+  }

JonasToth wrote:
> Indiciator to use `llvm::Optional` as return type instead. What do you think?
I absolutely agree that optional is a great type. But SourceLocation has a 
sentinel/empty value, which can be queried using `Valid()/Invalid()`. 
SourceLocation has the optionality built in so to speak. I have also seen other 
checks using a default constructed source location to indicate no result. Using 
optional would make the function interface more clear, but then we could have 
the weird case of an initialized optional containing an invalid source 
location. I would like to leave it as it is.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:53
+  // skip subsequent CV and ref qualifiers
+  const std::pair Loc = SM.getDecomposedLoc(Result);
+  const StringRef File = SM.getBufferData(Loc.first);

JonasToth wrote:
> Values are usually not `const`'ed. Please change that for consistency.
I do not agree to have something mutable, that should not change. Especially, 
now that everything else around is const, I would be suspicious why the writer 
had not put a const here and where the variable is modified after its 
initialization. But if you require it for consistency, I can remove it.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:67
+
+if (T.is(tok::amp) || T.is(tok::ampamp) || T.is(tok::kw_const) ||
+T.is(tok::kw_volatile)) {

JonasToth wrote:
> why are pointers not relevant here?
> There should be `Token.oneOf()` or `Token.isOneOf()` or similar for this 
> usecase
I am lexing CV and ref qualifiers after the closing parenthesis of a function's 
argument list (i.e. a member function then). I do not know what you mean with 
pointers here. An asterisk cannot appear as a qualifier on a method AFAIK.

Thanks for the tip!



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:173
+
+  if (F->getDeclaredReturnType()->isFunctionPointerType()) {
+diag(F->getLocation(), std::string(Message) +

JonasToth wrote:
> What about data-pointer-member types? 
> (https://en.cppreference.com/w/cpp/language/pointer point 2))
> Its an uncommon construct, but better catch it here instead of bug-reports.
Those are fine, because they do not span space before and behind the function 
name and argument list when declaring them. But member function pointer types 
also needed to be excluded. Thank you for leading me to this test case!

Edit: I just found out

[PATCH] D56160: [clang-tidy] modernize-use-trailing-return check

2019-01-07 Thread Bernhard Manfred Gruber via Phabricator via cfe-commits
bernhardmgruber updated this revision to Diff 180596.
bernhardmgruber marked 31 inline comments as done.
bernhardmgruber added a comment.

Fixed most of the issues pointed out by @JonasToth and added a few more tests. 
The tests with data member pointers currently fail and I will investiage this.


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

https://reviews.llvm.org/D56160

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/UseTrailingReturnCheck.cpp
  clang-tidy/modernize/UseTrailingReturnCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-use-trailing-return.rst
  test/clang-tidy/modernize-use-trailing-return.cpp

Index: test/clang-tidy/modernize-use-trailing-return.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-trailing-return.cpp
@@ -0,0 +1,271 @@
+// RUN: %check_clang_tidy %s modernize-use-trailing-return %t -- -- --std=c++14
+
+namespace std {
+template 
+class vector;
+
+class string;
+}
+
+//
+// Functions
+//
+
+int f();
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto f() -> int;{{$}}
+int f(int);
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto f(int) -> int;{{$}}
+int f(int arg);
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto f(int arg) -> int;{{$}}
+int f(int arg1, int arg2, int arg3);
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto f(int arg1, int arg2, int arg3) -> int;{{$}}
+int f(int arg1, int arg2, int arg3, ...);
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto f(int arg1, int arg2, int arg3, ...) -> int;{{$}}
+template  int f(T t);
+// CHECK-MESSAGES: :[[@LINE-1]]:27: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}template  auto f(T t) -> int;{{$}}
+
+//
+// Functions with formatting
+//
+
+int a1() { return 42; }
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto a1() -> int { return 42; }{{$}}
+int a2() {
+return 42;
+}
+// CHECK-MESSAGES: :[[@LINE-3]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto a2() -> int {{{$}}
+int a3()
+{
+return 42;
+}
+// CHECK-MESSAGES: :[[@LINE-4]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto a3() -> int{{$}}
+int a4(int   arg   )   ;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto a4(int   arg   ) -> int   ;{{$}}
+int a5
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto a5{{$}}
+(int arg);
+// CHECK-FIXES: {{^}}(int arg) -> int;{{$}}
+
+//
+// Functions with qualifiers and specifiers
+//
+
+inline int d1(int arg);
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}inline auto d1(int arg) -> int;{{$}}
+extern "C" int d2(int arg);
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}extern "C" auto d2(int arg) -> int;{{$}}
+inline int d3(int arg) noexcept(true);
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}inline auto d3(int arg) -> int noexcept(true);{{$}}
+inline int d4(int arg) try { } catch(...) { }
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}inline auto d4(int arg) -> int try { } catch(...) { }{{$}}
+
+//
+// Functions in namespaces
+//
+
+namespace N {
+int e1();
+}
+// CHECK-MESSAGES: :[[@LINE-2]]:10: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto e1() -> int;{{$}}
+int N::e1() {}
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: use a trailing return type for this function [modernize-use-trailing-return]
+// CHECK-FIXES: {{^}}auto N::e1() -> int {}{{$}}
+
+//
+// Functions with complex return types
+//
+
+inline volatile const std::vector e2();
+// CHECK-MESSAGES: :[[@LINE-1]]:48: warning: use a 

[PATCH] D56405: Split -Wdelete-non-virtual-dtor into two groups

2019-01-07 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: include/clang/Basic/DiagnosticGroups.td:108-109
 def DeleteNonVirtualDtor : DiagGroup<"delete-non-virtual-dtor">;
+def DeleteAbstractNonVirtualDtor : 
DiagGroup<"delete-abstract-non-virtual-dtor",
+ [DeleteNonVirtualDtor]>;
 def AbstractFinalClass : DiagGroup<"abstract-final-class">;

aaron.ballman wrote:
> rsmith wrote:
> > This is backwards: this says that `-Wdelete-abstract-non-virtual-dtor` also 
> > controls `-Wdelete-non-virtual-dtor`. You presumably want the opposite 
> > relationship, so that `-Wdelete-non-virtual-dtor` controls both warnings 
> > and `-Wdelete-abstract-non-virtual-dtor` only controls the "abstract" 
> > warning.
> I took this to be the correct order because disabling the abstract case is 
> more dangerous than disabling the non-abstract case (if you disable the 
> abstract one, you're saying "I don't care how bad it gets, don't tell me 
> about it.").
That seems reasonable as a strategy, but the end result doesn't seem to make 
much sense: `-Wdelete-abstract-non-virtual-dtor` enables, and  
`-Wno-delete-abstract-non-virtual-dtor` disables, warnings that have nothing to 
do with deleting an abstract class with a non-virtual destructor, and 
`-Wno-delete-non-virtual-dtor` fails to silence warnings about deleting an 
object of a class type with a non-virtual destructor. It's also 
backwards-incompatible, because the meaning of the existing `-W` flag has been 
changed.

One way to fix this would be to rename the groups:

* `delete-abstract-non-virtual-dtor` -> `delete-non-virtual-dtor`
* `delete-non-virtual-dtor` -> `delete-nonabstract-non-virtual-dtor` (yuck)

(Or we could keep the existing `delete-abstract-non-virtual-dtor`, add 
`delete-nonabstract-non-virtual-dtor`, and make `delete-non-virtual-dtor` be a 
group that contains those other two groups and has no diagnostics of its own.)

Instead / as well, we could address the false positives more directly: we could 
only warn if the class in question *introduces* a virtual function (suggesting 
that it's intended to be used as a base class), rather than warning if the 
class merely *has* virtual functions (if it overrides virtual functions and 
doesn't introduce any, there's a good chance it's a leaf class). 
`-Wdelete-non-virtual-dtor` was supposed to be the "few/no false positives" 
version of `-Wnon-virtual-dtor` (which is really really just a stylistic 
warning), and if we can improve it so that people don't want to turn it off, 
that'd seem better.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56405



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


[PATCH] D55662: [Sema][ObjC] Do not warn about repeated uses of weak variables when the variables are accessed in an unevaluated context.

2019-01-07 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak updated this revision to Diff 180593.
ahatanak added a comment.

Make `deduceVarTypeFromInitializer` and `DeduceVariableDeclarationType` return 
the new initialization expression and use it in `Sema::AddInitializerToDecl`. 
Add a test case that tests lambda capture with an initializer.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55662

Files:
  include/clang/Sema/Sema.h
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Sema/SemaExprObjC.cpp
  lib/Sema/SemaLambda.cpp
  lib/Sema/SemaTemplateDeduction.cpp
  lib/Sema/SemaType.cpp
  test/SemaObjC/arc-repeated-weak.mm

Index: test/SemaObjC/arc-repeated-weak.mm
===
--- test/SemaObjC/arc-repeated-weak.mm
+++ test/SemaObjC/arc-repeated-weak.mm
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime-has-weak -fobjc-arc -fblocks -Wno-objc-root-class -std=c++11 -Warc-repeated-use-of-weak -verify %s
-// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime-has-weak -fobjc-weak -fblocks -Wno-objc-root-class -std=c++11 -Warc-repeated-use-of-weak -verify %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime-has-weak -fobjc-arc -fblocks -Wno-objc-root-class -std=c++11 -Warc-repeated-use-of-weak -std=c++14 -verify %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime-has-weak -fobjc-weak -fblocks -Wno-objc-root-class -std=c++11 -Warc-repeated-use-of-weak -std=c++14 -verify %s
 
 @interface Test {
 @public
@@ -462,6 +462,17 @@
   NSString * t2 = NSBundle.foo2.prop;
   use(NSBundle.foo2.weakProp); // expected-warning{{weak property 'weakProp' may be accessed multiple times}}
   use(NSBundle2.foo2.weakProp); // expected-note{{also accessed here}}
+  decltype([NSBundle2.foo2 weakProp]) t3;
+  decltype(NSBundle2.foo2.weakProp) t4;
+  __typeof__(NSBundle2.foo2.weakProp) t5;
+}
+
+void testAuto() {
+  auto __weak wp = NSBundle2.foo2.weakProp;
+}
+
+void testLambdaCaptureInit() {
+  [capture(NSBundle2.foo2.weakProp)] {} ();
 }
 
 // This used to crash in the constructor of WeakObjectProfileTy when a
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -8056,9 +8056,7 @@
 }
 
 QualType Sema::BuildTypeofExprType(Expr *E, SourceLocation Loc) {
-  ExprResult ER = CheckPlaceholderExpr(E);
-  if (ER.isInvalid()) return QualType();
-  E = ER.get();
+  assert(!E->hasPlaceholderType() && "unexpected placeholder");
 
   if (!getLangOpts().CPlusPlus && E->refersToBitField())
 Diag(E->getExprLoc(), diag::err_sizeof_alignof_typeof_bitfield) << 2;
@@ -8143,9 +8141,7 @@
 
 QualType Sema::BuildDecltypeType(Expr *E, SourceLocation Loc,
  bool AsUnevaluated) {
-  ExprResult ER = CheckPlaceholderExpr(E);
-  if (ER.isInvalid()) return QualType();
-  E = ER.get();
+  assert(!E->hasPlaceholderType() && "unexpected placeholder");
 
   if (AsUnevaluated && CodeSynthesisContexts.empty() &&
   E->HasSideEffects(Context, false)) {
Index: lib/Sema/SemaTemplateDeduction.cpp
===
--- lib/Sema/SemaTemplateDeduction.cpp
+++ lib/Sema/SemaTemplateDeduction.cpp
@@ -4429,6 +4429,10 @@
 return DAR_FailedAlreadyDiagnosed;
   }
 
+  ExprResult ER = CheckPlaceholderExpr(Init);
+  if (ER.isInvalid())
+return DAR_FailedAlreadyDiagnosed;
+  Init = ER.get();
   QualType Deduced = BuildDecltypeType(Init, Init->getBeginLoc(), false);
   if (Deduced.isNull())
 return DAR_FailedAlreadyDiagnosed;
Index: lib/Sema/SemaLambda.cpp
===
--- lib/Sema/SemaLambda.cpp
+++ lib/Sema/SemaLambda.cpp
@@ -759,9 +759,10 @@
   TypeSourceInfo *TSI = TLB.getTypeSourceInfo(Context, DeductType);
 
   // Deduce the type of the init capture.
+  Expr *DeducedAutoInit = nullptr;
   QualType DeducedType = deduceVarTypeFromInitializer(
   /*VarDecl*/nullptr, DeclarationName(Id), DeductType, TSI,
-  SourceRange(Loc, Loc), IsDirectInit, Init);
+  SourceRange(Loc, Loc), IsDirectInit, Init, &DeducedAutoInit);
   if (DeducedType.isNull())
 return QualType();
 
@@ -779,10 +780,18 @@
: InitializationKind::CreateDirectList(Loc))
   : InitializationKind::CreateCopy(Loc, Init->getBeginLoc());
 
-  MultiExprArg Args = Init;
-  if (CXXDirectInit)
+  MultiExprArg Args;
+
+  if (DeducedAutoInit) {
+assert(!isa(DeducedAutoInit) &&
+   "paren list expr not expected");
+Args = DeducedAutoInit;
+  } else if (CXXDirectInit)
 Args =
 MultiExprArg(CXXDirectInit->getExprs(), CXXDirectInit->getNumExprs());
+  else
+Args = Init;
+
   QualType DclT;
   InitializationSequence InitSeq(*this, Entity, Kind, Args);
   ExprResult Result = InitSeq.Perform(*this, Entity, Kind, Args, &DclT);
Index: lib/Sema/SemaExprObjC.cpp
=

[PATCH] D56405: Split -Wdelete-non-virtual-dtor into two groups

2019-01-07 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: include/clang/Basic/DiagnosticGroups.td:108-109
 def DeleteNonVirtualDtor : DiagGroup<"delete-non-virtual-dtor">;
+def DeleteAbstractNonVirtualDtor : 
DiagGroup<"delete-abstract-non-virtual-dtor",
+ [DeleteNonVirtualDtor]>;
 def AbstractFinalClass : DiagGroup<"abstract-final-class">;

rsmith wrote:
> This is backwards: this says that `-Wdelete-abstract-non-virtual-dtor` also 
> controls `-Wdelete-non-virtual-dtor`. You presumably want the opposite 
> relationship, so that `-Wdelete-non-virtual-dtor` controls both warnings and 
> `-Wdelete-abstract-non-virtual-dtor` only controls the "abstract" warning.
I took this to be the correct order because disabling the abstract case is more 
dangerous than disabling the non-abstract case (if you disable the abstract 
one, you're saying "I don't care how bad it gets, don't tell me about it.").


Repository:
  rC Clang

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

https://reviews.llvm.org/D56405



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


[PATCH] D56405: Split -Wdelete-non-virtual-dtor into two groups

2019-01-07 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: include/clang/Basic/DiagnosticGroups.td:108-109
 def DeleteNonVirtualDtor : DiagGroup<"delete-non-virtual-dtor">;
+def DeleteAbstractNonVirtualDtor : 
DiagGroup<"delete-abstract-non-virtual-dtor",
+ [DeleteNonVirtualDtor]>;
 def AbstractFinalClass : DiagGroup<"abstract-final-class">;

This is backwards: this says that `-Wdelete-abstract-non-virtual-dtor` also 
controls `-Wdelete-non-virtual-dtor`. You presumably want the opposite 
relationship, so that `-Wdelete-non-virtual-dtor` controls both warnings and 
`-Wdelete-abstract-non-virtual-dtor` only controls the "abstract" warning.



Comment at: test/SemaCXX/non-virtual-dtors.cpp:3-4
+// RUN: %clang_cc1 %s -verify -DDIAG1 -DDIAG2 -Wdelete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -DDIAG1 -Wmost 
-Wno-delete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -Wmost 
-Wno-delete-abstract-non-virtual-dtor
+

The test also verifies that the `-W` flags are wrong :)


Repository:
  rC Clang

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

https://reviews.llvm.org/D56405



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


Buildbot numbers for the last week of 12/30/2018 - 01/05/2019

2019-01-07 Thread Galina Kistanova via cfe-commits
Hello everyone,

Below are some buildbot numbers for the last week of 12/30/2018 -
01/05/2019.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
   buildername| was_red
--+-
 sanitizer-ppc64le-linux  | 81:04:19
 sanitizer-x86_64-linux-android   | 79:22:06
 sanitizer-x86_64-linux-bootstrap-msan| 58:05:25
 sanitizer-x86_64-linux-bootstrap-ubsan   | 56:03:34
 sanitizer-x86_64-linux-fast  | 55:35:54
 sanitizer-x86_64-linux-bootstrap | 51:37:10
 sanitizer-x86_64-linux   | 26:11:54
 llvm-clang-x86_64-expensive-checks-win   | 13:16:38
 clang-x86_64-linux-selfhost-modules  | 13:00:17
 clang-cuda-build | 07:27:52
 clang-with-lto-ubuntu| 06:55:52
 clang-cmake-armv7-selfhost   | 06:02:05
 clang-lld-x86_64-2stage  | 05:55:42
 clang-cmake-aarch64-lld  | 04:47:32
 clang-bpf-build  | 04:24:19
 clang-cmake-armv8-selfhost-neon  | 04:03:51
 clang-cmake-aarch64-full | 04:00:27
 clang-ppc64le-linux-multistage   | 03:49:41
 lldb-x64-windows-ninja   | 03:43:30
 clang-cmake-armv8-lld| 03:41:42
 lldb-x86_64-ubuntu-14.04-buildserver | 03:21:15
 clang-s390x-linux| 03:16:42
 clang-with-thin-lto-ubuntu   | 03:14:59
 lldb-amd64-ninja-netbsd8 | 02:47:22
 clang-ppc64le-linux  | 02:30:11
 clang-cmake-armv8-global-isel| 02:11:46
 clang-s390x-linux-lnt| 02:01:20
 clang-cmake-armv7-global-isel| 02:00:17
 clang-s390x-linux-multistage | 01:48:47
 clang-cmake-x86_64-avx2-linux| 01:39:54
 clang-x64-windows-msvc   | 01:29:46
 clang-cmake-armv8-quick  | 01:27:22
 polly-arm-linux  | 01:21:31
 clang-cmake-aarch64-quick| 01:18:23
 clang-cmake-armv8-full   | 01:18:07
 clang-ppc64be-linux-lnt  | 01:13:16
 sanitizer-ppc64be-linux  | 01:12:48
 clang-cmake-aarch64-global-isel  | 01:10:39
 clang-cmake-armv7-full   | 01:09:47
 clang-ppc64be-linux  | 01:05:50
 polly-amd64-linux| 00:57:30
 clang-cmake-x86_64-avx2-linux-perf   | 00:55:36
 clang-cmake-armv7-quick  | 00:55:25
 clang-ppc64le-linux-lnt  | 00:53:15
 clang-cmake-x86_64-sde-avx512-linux  | 00:50:19
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 00:50:16
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast   | 00:50:06
 clang-atom-d525-fedora-rel   | 00:49:47
 clang-ppc64be-linux-multistage   | 00:49:24
 clang-aarch64-linux-build-cache  | 00:23:53
 lld-x86_64-darwin13  | 00:18:42
 clang-x86_64-linux-abi-test  | 00:14:25
 lld-x86_64-freebsd   | 00:13:35
 lld-x86_64-win7  | 00:13:26
 clang-armv7-linux-build-cache| 00:09:33
(55 rows)


"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green):
   buildername   | builds | changes
| status_change_ratio
-++-+
 clang-x86_64-linux-selfhost-modules | 41 |  19
|46.3
 clang-ppc64le-linux-multistage  | 42 |  10
|23.8
 clang-cuda-build|121 |  25
|20.7
 clang-with-thin-lto-ubuntu  | 69 |  14
|20.3
 lldb-amd64-ninja-netbsd8| 90 |  16
|17.8
 llvm-clang-x86_64-expensive-checks-win  |  

Buildbot numbers for the week of 12/23/2018 - 12/29/2018

2019-01-07 Thread Galina Kistanova via cfe-commits
Hello everyone,

Below are some buildbot numbers for the week of 12/23/2018 - 12/29/2018.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
   buildername| was_red
--+-
 clang-x86_64-linux-selfhost-modules  | 22:39:33
 sanitizer-x86_64-linux-bootstrap-msan| 17:30:51
 clang-cuda-build | 08:57:37
 clang-lld-x86_64-2stage  | 05:34:00
 clang-cmake-armv8-global-isel| 05:22:54
 sanitizer-x86_64-linux-fast  | 05:12:53
 clang-bpf-build  | 05:00:51
 lldb-amd64-ninja-netbsd8 | 04:59:52
 clang-cmake-aarch64-lld  | 04:37:52
 clang-ppc64be-linux-lnt  | 04:31:17
 clang-ppc64le-linux-lnt  | 04:24:29
 clang-cmake-armv8-selfhost-neon  | 03:58:04
 clang-ppc64le-linux-multistage   | 03:43:39
 clang-with-lto-ubuntu| 03:43:00
 clang-cmake-aarch64-global-isel  | 03:34:58
 sanitizer-ppc64be-linux  | 03:30:20
 clang-cmake-x86_64-avx2-linux| 03:16:15
 sanitizer-x86_64-linux   | 03:16:07
 clang-cmake-armv8-lld| 03:14:45
 clang-ppc64be-linux-multistage   | 03:14:38
 clang-ppc64be-linux  | 03:10:24
 clang-ppc64le-linux  | 03:09:42
 clang-with-thin-lto-ubuntu   | 03:09:24
 llvm-clang-x86_64-expensive-checks-win   | 02:55:41
 clang-x64-windows-msvc   | 02:55:39
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 02:55:27
 clang-s390x-linux| 02:54:42
 clang-atom-d525-fedora-rel   | 02:54:25
 clang-cmake-x86_64-sde-avx512-linux  | 02:54:17
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast   | 02:54:01
 clang-cmake-aarch64-quick| 02:43:29
 sanitizer-x86_64-linux-bootstrap-ubsan   | 02:42:47
 clang-s390x-linux-lnt| 02:31:20
 sanitizer-x86_64-linux-bootstrap | 02:27:55
 clang-s390x-linux-multistage | 01:50:35
 clang-cmake-armv8-quick  | 01:38:20
 clang-cmake-armv8-full   | 01:18:38
 sanitizer-x86_64-linux-fuzzer| 01:05:47
 lldb-x64-windows-ninja   | 00:55:34
 clang-cmake-x86_64-avx2-linux-perf   | 00:46:03
 sanitizer-windows| 00:44:33
 sanitizer-x86_64-linux-android   | 00:23:53
 lld-perf-testsuite   | 00:21:22
 lld-x86_64-darwin13  | 00:18:43
(44 rows)


"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green):
   buildername| builds | changes |
status_change_ratio
--++-+
 clang-x86_64-linux-selfhost-modules  | 34 |  14
|41.2
 lldb-amd64-ninja-netbsd8 | 61 |  17
|27.9
 clang-cuda-build | 62 |  16
|25.8
 sanitizer-x86_64-linux-fast  | 89 |  22
|24.7
 clang-cmake-aarch64-lld  | 36 |   6
|16.7
 lldb-x64-windows-ninja   | 69 |  10
|14.5
 sanitizer-x86_64-linux-bootstrap-msan| 74 |  10
|13.5
 llvm-clang-x86_64-expensive-checks-win   | 55 |   7
|12.7
 clang-with-thin-lto-ubuntu   | 51 |   6
|11.8
 clang-ppc64le-linux-lnt  | 70 |   8
|11.4
 clang-ppc64le-linux-multistage   | 39 |   4
|10.3
 clang-with-lto-ubuntu| 42 |   4
| 9.5
 clang-ppc64be-linux-multistage   | 79 |   6
| 7.6
 clang-bpf-build  | 5

[PATCH] D55500: [Builtins] Implement __builtin_is_constant_evaluated for use in C++2a

2019-01-07 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno added inline comments.



Comment at: include/clang/Basic/Builtins.def:759
+// Random C++ builtins.
+LANGBUILTIN(__builtin_is_constant_evaluated, "b", "ncu", CXX_LANG)
+

EricWF wrote:
> EricWF wrote:
> > bruno wrote:
> > > Name bikeshedding : perhaps the builtin name could be detached from the 
> > > std:: name? Suggestion: `__builtin_in_constant_evaluation_context`
> > I'm not sure detaching it from the `std::` name is desirable. Most 
> > importantly it should match w/e GCC does/decides to do.
> > 
> > But if it is, we should name in deference to the standardese it implements. 
> > Specifically weither an expression or conversion is //manifestly 
> > constant-evaluated// 
> > [[expr.const](http://eel.is/c++draft/expr.const#11)]p11.
> > 
> > Therefore I proffer  `__builtin_is_manifestly_constant_evaluated()` or 
> > `__builtin_is_being_manifestly_constant_evaluated()`.
> > 
> > 
> Actually, GCC has `__builtin_is_constant_evaluated` so we should use that 
> name too.
Agreed!


Repository:
  rC Clang

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

https://reviews.llvm.org/D55500



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


Re: r350572 - Add a __has_feature check for namespaces on #pragma clang attribute.

2019-01-07 Thread Richard Smith via cfe-commits
On Mon, 7 Jan 2019 at 16:12, Erik Pilkington via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On 1/7/19 3:51 PM, Richard Smith wrote:
>
> On Mon, 7 Jan 2019 at 13:57, Erik Pilkington via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: epilk
>> Date: Mon Jan  7 13:54:00 2019
>> New Revision: 350572
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=350572&view=rev
>> Log:
>> Add a __has_feature check for namespaces on #pragma clang attribute.
>>
>
> Should this be __has_extension rather than __has_feature, since it's not a
> standard feature?
>
>
> I suppose, but it doesn't really seem like that's the rule that we're
> following here. If you look at every other FEATURE(...) above this, they
> all have to do with clang extensions like attributes and sanitizers, which
> obviously aren't standard features. Every EXTENSION(...) has to do with
> language features that are shared between languages (cxx_fixed_enum in C,
> for instance). So it seems like the most internally consistent place to put
> this is in FEATURE(...). WDYT?
>
What you're seeing is a historical legacy of the time before the current
approach. The design and documented intent of __has_feature is that it
checks for standardized features. See the documentation here, and
particularly the note about backwards compatibility:

https://clang.llvm.org/docs/LanguageExtensions.html#has-feature-and-has-extension

... and the design discussion when __has_extension was introduced:

http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20110425/041452.html

... and the comment on HasFeature in Lex/PPMacroExpansion.cpp:

/// HasFeature - Return true if we recognize and implement the feature
/// specified by the identifier as a standard language feature.

We seem to have detached that comment from the actual list of features when
the features were moved to a .def file. Oops :(

If we want to revisit the design based on experience using __has_feature /
__has_extension, I'm all for that (the distinction between the two seems
confusing and not especially useful to me; the behavior of the current
language mode can be tested using eg __STDC_VERSION__ and __cplusplus, so
the only thing that's really interesting for us to expose is what features
the current compliation supports), but we should follow the current design
until we do.

> Support for this was added in r349845.
>>
>> Modified:
>> cfe/trunk/docs/LanguageExtensions.rst
>> cfe/trunk/include/clang/Basic/Features.def
>> cfe/trunk/test/Sema/pragma-attribute-namespace.c
>>
>> Modified: cfe/trunk/docs/LanguageExtensions.rst
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=350572&r1=350571&r2=350572&view=diff
>>
>> ==
>> --- cfe/trunk/docs/LanguageExtensions.rst (original)
>> +++ cfe/trunk/docs/LanguageExtensions.rst Mon Jan  7 13:54:00 2019
>> @@ -2725,7 +2725,9 @@ same namespace. For instance:
>>  Without the namespaces on the macros, ``other_function`` will be
>> annotated with
>>  ``[[noreturn]]`` instead of ``__attribute__((unavailable))``. This may
>> seem like
>>  a contrived example, but its very possible for this kind of situation to
>> appear
>> -in real code if the pragmas are spread out across a large file.
>> +in real code if the pragmas are spread out across a large file. You can
>> test if
>> +your version of clang supports namespaces on ``#pragma clang attribute``
>> with
>> +``__has_feature(pragma_clang_attribute_namespaces)``.
>>
>>  Subject Match Rules
>>  ---
>>
>> Modified: cfe/trunk/include/clang/Basic/Features.def
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Features.def?rev=350572&r1=350571&r2=350572&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/Features.def (original)
>> +++ cfe/trunk/include/clang/Basic/Features.def Mon Jan  7 13:54:00 2019
>> @@ -69,6 +69,7 @@ FEATURE(attribute_overloadable, true)
>>  FEATURE(attribute_unavailable_with_message, true)
>>  FEATURE(attribute_unused_on_fields, true)
>>  FEATURE(attribute_diagnose_if_objc, true)
>> +FEATURE(pragma_clang_attribute_namespaces, true)
>>  FEATURE(blocks, LangOpts.Blocks)
>>  FEATURE(c_thread_safety_attributes, true)
>>  FEATURE(cxx_exceptions, LangOpts.CXXExceptions)
>>
>> Modified: cfe/trunk/test/Sema/pragma-attribute-namespace.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/pragma-attribute-namespace.c?rev=350572&r1=350571&r2=350572&view=diff
>>
>> ==
>> --- cfe/trunk/test/Sema/pragma-attribute-namespace.c (original)
>> +++ cfe/trunk/test/Sema/pragma-attribute-namespace.c Mon Jan  7 13:54:00
>> 2019
>> @@ -1,5 +1,9 @@
>>  // RUN: %clang_cc1 -fsyntax-only -verify %s
>>
>> +#if !__has_feature(pragma_clang_attribute_namespaces)
>> +#error
>> +#endif
>> +

r350585 - Split -Wdelete-non-virtual-dtor into -Wdelete-abstract-non-virtual-dtor

2019-01-07 Thread Erik Pilkington via cfe-commits
Author: epilk
Date: Mon Jan  7 16:21:05 2019
New Revision: 350585

URL: http://llvm.org/viewvc/llvm-project?rev=350585&view=rev
Log:
Split -Wdelete-non-virtual-dtor into -Wdelete-abstract-non-virtual-dtor

-Wdelete-non-virtual-dtor previously controlled two diagnostics: 1)
calling a non-virtual dtor from an abstract class, and 2) calling a
non-virtual dtor from a polymorphic class. 1) is a lot more severe
than 2), since 1) is a guaranteed crash, but 2) is just "code smell".
Previously, projects compiled with -Wall -Wno-delete-non-virtual-dtor,
which is somewhat reasonable, silently crashed on 1).

rdar://40380564

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

Added:
cfe/trunk/test/SemaCXX/non-virtual-dtors.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=350585&r1=350584&r2=350585&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Mon Jan  7 16:21:05 2019
@@ -105,6 +105,8 @@ def MissingNoEscape : DiagGroup<"missing
 
 def DeleteIncomplete : DiagGroup<"delete-incomplete">;
 def DeleteNonVirtualDtor : DiagGroup<"delete-non-virtual-dtor">;
+def DeleteAbstractNonVirtualDtor : 
DiagGroup<"delete-abstract-non-virtual-dtor",
+ [DeleteNonVirtualDtor]>;
 def AbstractFinalClass : DiagGroup<"abstract-final-class">;
 
 def CXX11CompatDeprecatedWritableStr :

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=350585&r1=350584&r2=350585&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Jan  7 16:21:05 
2019
@@ -6460,7 +6460,7 @@ def note_delete_non_virtual : Note<
   "qualify call to silence this warning">;
 def warn_delete_abstract_non_virtual_dtor : Warning<
   "%select{delete|destructor}0 called on %1 that is abstract but has "
-  "non-virtual destructor">, InGroup, ShowInSystemHeader;
+  "non-virtual destructor">, InGroup, 
ShowInSystemHeader;
 def warn_overloaded_virtual : Warning<
   "%q0 hides overloaded virtual %select{function|functions}1">,
   InGroup, DefaultIgnore;

Added: cfe/trunk/test/SemaCXX/non-virtual-dtors.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/non-virtual-dtors.cpp?rev=350585&view=auto
==
--- cfe/trunk/test/SemaCXX/non-virtual-dtors.cpp (added)
+++ cfe/trunk/test/SemaCXX/non-virtual-dtors.cpp Mon Jan  7 16:21:05 2019
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 %s -verify -DDIAG1
+// RUN: %clang_cc1 %s -verify -DDIAG1 -DDIAG2 -Wdelete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -DDIAG1 -Wmost 
-Wno-delete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -Wmost 
-Wno-delete-abstract-non-virtual-dtor
+
+#ifndef DIAG1
+#ifndef DIAG2
+// expected-no-diagnostics
+#endif
+#endif
+
+struct S1 {
+  ~S1() {}
+  virtual void abs() = 0;
+};
+
+void f1(S1 *s1) { delete s1; }
+#ifdef DIAG1
+// expected-warning@-2 {{delete called on 'S1' that is abstract but has 
non-virtual destructor}}
+#endif
+
+struct Base {
+  virtual void abs() = 0;
+};
+struct S2 : Base {
+  ~S2() {}
+  void abs() {}
+};
+void f2(S2 *s2) { delete s2; }
+#ifdef DIAG2
+// expected-warning@-2 {{delete called on non-final 'S2' that has virtual 
functions but non-virtual destructor}}
+#endif


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


[PATCH] D56405: Split -Wdelete-non-virtual-dtor into two groups

2019-01-07 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC350585: Split -Wdelete-non-virtual-dtor into 
-Wdelete-abstract-non-virtual-dtor (authored by epilk, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D56405?vs=180532&id=180584#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D56405

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  test/SemaCXX/non-virtual-dtors.cpp


Index: include/clang/Basic/DiagnosticGroups.td
===
--- include/clang/Basic/DiagnosticGroups.td
+++ include/clang/Basic/DiagnosticGroups.td
@@ -105,6 +105,8 @@
 
 def DeleteIncomplete : DiagGroup<"delete-incomplete">;
 def DeleteNonVirtualDtor : DiagGroup<"delete-non-virtual-dtor">;
+def DeleteAbstractNonVirtualDtor : 
DiagGroup<"delete-abstract-non-virtual-dtor",
+ [DeleteNonVirtualDtor]>;
 def AbstractFinalClass : DiagGroup<"abstract-final-class">;
 
 def CXX11CompatDeprecatedWritableStr :
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -6460,7 +6460,7 @@
   "qualify call to silence this warning">;
 def warn_delete_abstract_non_virtual_dtor : Warning<
   "%select{delete|destructor}0 called on %1 that is abstract but has "
-  "non-virtual destructor">, InGroup, ShowInSystemHeader;
+  "non-virtual destructor">, InGroup, 
ShowInSystemHeader;
 def warn_overloaded_virtual : Warning<
   "%q0 hides overloaded virtual %select{function|functions}1">,
   InGroup, DefaultIgnore;
Index: test/SemaCXX/non-virtual-dtors.cpp
===
--- test/SemaCXX/non-virtual-dtors.cpp
+++ test/SemaCXX/non-virtual-dtors.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 %s -verify -DDIAG1
+// RUN: %clang_cc1 %s -verify -DDIAG1 -DDIAG2 -Wdelete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -DDIAG1 -Wmost 
-Wno-delete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -Wmost 
-Wno-delete-abstract-non-virtual-dtor
+
+#ifndef DIAG1
+#ifndef DIAG2
+// expected-no-diagnostics
+#endif
+#endif
+
+struct S1 {
+  ~S1() {}
+  virtual void abs() = 0;
+};
+
+void f1(S1 *s1) { delete s1; }
+#ifdef DIAG1
+// expected-warning@-2 {{delete called on 'S1' that is abstract but has 
non-virtual destructor}}
+#endif
+
+struct Base {
+  virtual void abs() = 0;
+};
+struct S2 : Base {
+  ~S2() {}
+  void abs() {}
+};
+void f2(S2 *s2) { delete s2; }
+#ifdef DIAG2
+// expected-warning@-2 {{delete called on non-final 'S2' that has virtual 
functions but non-virtual destructor}}
+#endif


Index: include/clang/Basic/DiagnosticGroups.td
===
--- include/clang/Basic/DiagnosticGroups.td
+++ include/clang/Basic/DiagnosticGroups.td
@@ -105,6 +105,8 @@
 
 def DeleteIncomplete : DiagGroup<"delete-incomplete">;
 def DeleteNonVirtualDtor : DiagGroup<"delete-non-virtual-dtor">;
+def DeleteAbstractNonVirtualDtor : DiagGroup<"delete-abstract-non-virtual-dtor",
+ [DeleteNonVirtualDtor]>;
 def AbstractFinalClass : DiagGroup<"abstract-final-class">;
 
 def CXX11CompatDeprecatedWritableStr :
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -6460,7 +6460,7 @@
   "qualify call to silence this warning">;
 def warn_delete_abstract_non_virtual_dtor : Warning<
   "%select{delete|destructor}0 called on %1 that is abstract but has "
-  "non-virtual destructor">, InGroup, ShowInSystemHeader;
+  "non-virtual destructor">, InGroup, ShowInSystemHeader;
 def warn_overloaded_virtual : Warning<
   "%q0 hides overloaded virtual %select{function|functions}1">,
   InGroup, DefaultIgnore;
Index: test/SemaCXX/non-virtual-dtors.cpp
===
--- test/SemaCXX/non-virtual-dtors.cpp
+++ test/SemaCXX/non-virtual-dtors.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 %s -verify -DDIAG1
+// RUN: %clang_cc1 %s -verify -DDIAG1 -DDIAG2 -Wdelete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -DDIAG1 -Wmost -Wno-delete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -Wmost -Wno-delete-abstract-non-virtual-dtor
+
+#ifndef DIAG1
+#ifndef DIAG2
+// expected-no-diagnostics
+#endif
+#endif
+
+struct S1 {
+  ~S1() {}
+  virtual void abs() = 0;
+};
+
+void f1(S1 *s1) { delete s1; }
+#ifdef DIAG1
+// expected-warning@-2 {{delete called on 'S1' that is abstract but has non-virtual destructor}}
+#endif
+
+struct Base {
+  virtual void abs() = 0;
+};
+struct S2 : Base {
+  ~S2() {}
+  void abs() {}

[PATCH] D37035: Implement __builtin_LINE() et. al. to support source location capture.

2019-01-07 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: include/clang/AST/ASTContext.h:279
 
+  /// A cache mapping a function declaration to its human-readable function or
+  /// file name.

Comment seems out of date: the key here is a string rather than a function 
declaration.



Comment at: lib/AST/Expr.cpp:2012-2020
+  case SourceLocExpr::Function:
+  case SourceLocExpr::File: {
+return [&]() {
+  auto MkStr = [&](StringRef Tmp) {
+StringLiteral *Res = Ctx.getPredefinedStringLiteralFromCache(Tmp);
+return APValue(Res, CharUnits::Zero(), APValue::NoLValuePath(), 0);
+  };

Combining these two cases doesn't really make sense since they have nothing in 
common (except that both produce strings). Instead, consider hoisting the 
`MkStr` lambda out of the switch and separating the cases.



Comment at: lib/AST/Expr.cpp:2022-2023
+  const auto *FD = dyn_cast_or_null(Context);
+  if (!FD)
+return MkStr("");
+  // If we have a simple identifier there is no need to cache the

Why not call into `PredefinedExpr` for the other cases that `__FUNCTION__` 
supports (`BlockDecl`, `CapturedDecl`, `ObjCMethodDecl`)?



Comment at: lib/AST/Expr.cpp:2026-2027
+  // human readable name.
+  if (IdentifierInfo *II = FD->getDeclName().getAsIdentifierInfo())
+return MkStr(II->getNameStart());
+  return MkStr(PredefinedExpr::ComputeName(PredefinedExpr::Function, FD));

Is the benefit of avoiding a `std::string` allocation here really worth the 
cost of duplicating this portion of the `__FUNCTION__` logic?

If we care about the extra string allocation, it'd seem more worthwhile to 
extend `ComputeName` so that a stack-allocated `SmallString` buffer can be 
passed in (eg, `StringRef ComputeName(..., SmallVectorImpl 
&NameStorage)`, where `NameStorage` may, but need not, be used to store the 
resulting string).



Comment at: lib/AST/ExprConstant.cpp:2653-2655
+APValue::LValueBase const &Base,
 uint64_t Index) {
+  const Expr *Lit = Base.get();

Hm, why the move of the `get` from caller to callee? This widens the set of 
possible arguments to `extractStringLiteralCharacter`, but all the new 
possibilities result in crashes -- shouldn't the caller, rather than the 
callee, still be the place where we house the assertion that the base is indeed 
an expression?



Comment at: lib/AST/ExprConstant.cpp:3370-3371
+
+  assert((!Base || !isa(Base)) &&
+ "Base should have already been transformed into a StringLiteral");
+

There are lots of forms of expression that cannot be the base of an `LValue` 
(see the list above `LValueExprEvaluator` for the expression forms that *can* 
be the base of an `LValue`); is it important to give this one special treatment?



Comment at: lib/CodeGen/CGExprConstant.cpp:1762
+ConstantLValue
+ConstantLValueEmitter::VisitSourceLocExpr(const SourceLocExpr *E) {
+  const APValue::LValueBase& Base = Value.getLValueBase();

Hmm, is this reachable? I thought `SourceLocExpr` was always a prvalue.



Comment at: lib/CodeGen/CGExprConstant.cpp:1766
+  "Expected string literal result");
+  const StringLiteral* Str = cast(Base.get());
+

`const auto *Str`



Comment at: lib/CodeGen/CGExprConstant.cpp:1768-1769
+
+  // assert(Base.isGlobalString() &&
+  //   "source location expression does not evaluate to global string?");
+  return CGM.GetAddrOfConstantCString(Str->getBytes());

Please remove or uncomment this.



Comment at: lib/Sema/TreeTransform.h:9990
+  bool NeedRebuildFunc = E->getIdentType() == SourceLocExpr::Function &&
+ isa(getSema().CurContext) &&
+ getSema().CurContext != E->getParentContext();

If we generalize `__builtin_FUNCTION()` to behave like `__FUNCTION__` (and 
handle function-like contexts that aren't `FunctionDecl`s), this `isa` check 
will be wrong.


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

https://reviews.llvm.org/D37035



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


[PATCH] D56367: [AST] Pack CXXDependentScopeMemberExpr

2019-01-07 Thread Bruno Ricci via Phabricator via cfe-commits
riccibruno added a comment.

> Okay. That comment seems reasonable. Glad to hear you're on top of it. :)

I guess that means I can land this as is ?


Repository:
  rC Clang

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

https://reviews.llvm.org/D56367



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


[clang-tools-extra] r350584 - ReleaseNotes: Update with my clang-query contributions this cycle

2019-01-07 Thread Stephen Kelly via cfe-commits
Author: steveire
Date: Mon Jan  7 16:09:34 2019
New Revision: 350584

URL: http://llvm.org/viewvc/llvm-project?rev=350584&view=rev
Log:
ReleaseNotes: Update with my clang-query contributions this cycle

Modified:
clang-tools-extra/trunk/docs/ReleaseNotes.rst

Modified: clang-tools-extra/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/ReleaseNotes.rst?rev=350584&r1=350583&r2=350584&view=diff
==
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst (original)
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst Mon Jan  7 16:09:34 2019
@@ -57,7 +57,47 @@ The improvements are...
 Improvements to clang-query
 ---
 
-The improvements are...
+- A new command line parameter ``--preload`` was added to
+  run commands from a file and then start the interactive interpreter.
+
+- The command ``q`` can was added as an alias for ``quit`` to exit the
+  ``clang-query`` interpreter.
+
+- It is now possible to bind to named values (the result of ``let``
+  expressions). For example:
+
+  .. code-block:: none
+
+let fn functionDecl()
+match fn.bind("foo")
+
+- It is now possible to write comments in ``clang-query`` code. This
+  is primarily useful when using script-mode. Comments are all content
+  following the ``#`` character on a line:
+
+  .. code-block:: none
+
+# This is a comment
+match fn.bind("foo") # This is a trailing comment
+
+- The new ``set print-matcher true`` command now causes ``clang-query`` to
+  print the evaluated matcher together with the resulting bindings.
+
+- A new output mode ``detailed-ast`` was added to ``clang-query``. The
+  existing ``dump`` output mode is now a deprecated alias
+  for ``detailed-ast``
+
+- Output modes can now be enabled or disabled non-exclusively.  For example,
+
+  .. code-block:: none
+
+# Enable detailed-ast without disabling other output, such as diag
+enable output detailed-ast
+m functionDecl()
+
+# Disable detailed-ast only
+disable output detailed-ast
+m functionDecl()
 
 Improvements to clang-rename
 


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


Re: r350572 - Add a __has_feature check for namespaces on #pragma clang attribute.

2019-01-07 Thread Erik Pilkington via cfe-commits


On 1/7/19 3:51 PM, Richard Smith wrote:
On Mon, 7 Jan 2019 at 13:57, Erik Pilkington via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:


Author: epilk
Date: Mon Jan  7 13:54:00 2019
New Revision: 350572

URL: http://llvm.org/viewvc/llvm-project?rev=350572&view=rev
Log:
Add a __has_feature check for namespaces on #pragma clang attribute.


Should this be __has_extension rather than __has_feature, since it's 
not a standard feature?



I suppose, but it doesn't really seem like that's the rule that we're 
following here. If you look at every other FEATURE(...) above this, they 
all have to do with clang extensions like attributes and sanitizers, 
which obviously aren't standard features. Every EXTENSION(...) has to do 
with language features that are shared between languages (cxx_fixed_enum 
in C, for instance). So it seems like the most internally consistent 
place to put this is in FEATURE(...). WDYT?




Support for this was added in r349845.

Modified:
    cfe/trunk/docs/LanguageExtensions.rst
    cfe/trunk/include/clang/Basic/Features.def
    cfe/trunk/test/Sema/pragma-attribute-namespace.c

Modified: cfe/trunk/docs/LanguageExtensions.rst
URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=350572&r1=350571&r2=350572&view=diff

==
--- cfe/trunk/docs/LanguageExtensions.rst (original)
+++ cfe/trunk/docs/LanguageExtensions.rst Mon Jan  7 13:54:00 2019
@@ -2725,7 +2725,9 @@ same namespace. For instance:
 Without the namespaces on the macros, ``other_function`` will be
annotated with
 ``[[noreturn]]`` instead of ``__attribute__((unavailable))``.
This may seem like
 a contrived example, but its very possible for this kind of
situation to appear
-in real code if the pragmas are spread out across a large file.
+in real code if the pragmas are spread out across a large file.
You can test if
+your version of clang supports namespaces on ``#pragma clang
attribute`` with
+``__has_feature(pragma_clang_attribute_namespaces)``.

 Subject Match Rules
 ---

Modified: cfe/trunk/include/clang/Basic/Features.def
URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Features.def?rev=350572&r1=350571&r2=350572&view=diff

==
--- cfe/trunk/include/clang/Basic/Features.def (original)
+++ cfe/trunk/include/clang/Basic/Features.def Mon Jan  7 13:54:00
2019
@@ -69,6 +69,7 @@ FEATURE(attribute_overloadable, true)
 FEATURE(attribute_unavailable_with_message, true)
 FEATURE(attribute_unused_on_fields, true)
 FEATURE(attribute_diagnose_if_objc, true)
+FEATURE(pragma_clang_attribute_namespaces, true)
 FEATURE(blocks, LangOpts.Blocks)
 FEATURE(c_thread_safety_attributes, true)
 FEATURE(cxx_exceptions, LangOpts.CXXExceptions)

Modified: cfe/trunk/test/Sema/pragma-attribute-namespace.c
URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/pragma-attribute-namespace.c?rev=350572&r1=350571&r2=350572&view=diff

==
--- cfe/trunk/test/Sema/pragma-attribute-namespace.c (original)
+++ cfe/trunk/test/Sema/pragma-attribute-namespace.c Mon Jan  7
13:54:00 2019
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s

+#if !__has_feature(pragma_clang_attribute_namespaces)
+#error
+#endif
+
 #pragma clang attribute MyNamespace.push
(__attribute__((annotate)), apply_to=function) // expected-error 2
{{'annotate' attribute}}

 int some_func(); // expected-note{{when applied to this declaration}}


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

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


[PATCH] D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch.

2019-01-07 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai added inline comments.



Comment at: 
libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp:161
+  {
+// Though types are different, initialization can be done with `memcpy`.
+int32_t array[1] = {-1};

Quuxplusone wrote:
> vsapsai wrote:
> > Quuxplusone wrote:
> > > I might add "can be, but currently isn't, done with memcpy."
> > > 
> > > Here's my other suggested test:
> > > 
> > > ```
> > > struct X { int x; };
> > > struct Y { int y; };
> > > struct Z : X, Y { int z; };
> > > {
> > > Z z;
> > > Z *array[1] = { &z };
> > > // Though the types Z* and Y* are very similar, initialization still 
> > > cannot be done with memcpy.
> > > std::vector v(array, array + 1);
> > > assert(v[0] == &z);
> > > }
> > > ```
> > Thanks, I'll try your `XYZ` test, looks like it should help with my 
> > `iostream*/ostream*` struggles.
> LGTM! Ship it!
> (I'm surprised the structs can be defined inside the body of `main()` like 
> that, but I have no objection to doing so.)
I've decided not to add "can be, but currently isn't, done with memcpy" because 
I don't believe that comment will be kept up to date.

Thanks for all the rounds of review, Arthur.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D48342



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


[PATCH] D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch.

2019-01-07 Thread Volodymyr Sapsai via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL350583: [libcxx] Optimize vectors construction of trivial 
types from an iterator range… (authored by vsapsai, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D48342?vs=180577&id=180583#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D48342

Files:
  libcxx/trunk/include/memory
  
libcxx/trunk/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp

Index: libcxx/trunk/include/memory
===
--- libcxx/trunk/include/memory
+++ libcxx/trunk/include/memory
@@ -1502,6 +1502,12 @@
 typedef typename _Alloc::difference_type type;
 };
 
+template 
+struct __is_default_allocator : false_type {};
+
+template 
+struct __is_default_allocator<_VSTD::allocator<_Tp> > : true_type {};
+
 template 
 struct _LIBCPP_TEMPLATE_VIS allocator_traits
 {
@@ -1615,7 +1621,7 @@
 static
 typename enable_if
 <
-(is_same >::value
+(__is_default_allocator::value
 || !__has_construct::value) &&
  is_trivially_move_constructible<_Tp>::value,
 void
@@ -1640,23 +1646,25 @@
 construct(__a, _VSTD::__to_raw_pointer(__begin2), *__begin1);
 }
 
-template 
+template ::type,
+  class _RawDestTp = typename remove_const<_DestTp>::type>
 _LIBCPP_INLINE_VISIBILITY
 static
 typename enable_if
 <
-(is_same >::value
-|| !__has_construct::value) &&
- is_trivially_move_constructible<_Tp>::value,
+is_trivially_move_constructible<_DestTp>::value &&
+is_same<_RawSourceTp, _RawDestTp>::value &&
+(__is_default_allocator::value ||
+ !__has_construct::value),
 void
 >::type
-__construct_range_forward(allocator_type&, _Tp* __begin1, _Tp* __end1, _Tp*& __begin2)
+__construct_range_forward(allocator_type&, _SourceTp* __begin1, _SourceTp* __end1, _DestTp*& __begin2)
 {
-typedef typename remove_const<_Tp>::type _Vp;
 ptrdiff_t _Np = __end1 - __begin1;
 if (_Np > 0)
 {
-_VSTD::memcpy(const_cast<_Vp*>(__begin2), __begin1, _Np * sizeof(_Tp));
+_VSTD::memcpy(const_cast<_RawDestTp*>(__begin2), __begin1, _Np * sizeof(_DestTp));
 __begin2 += _Np;
 }
 }
@@ -1679,7 +1687,7 @@
 static
 typename enable_if
 <
-(is_same >::value
+(__is_default_allocator::value
 || !__has_construct::value) &&
  is_trivially_move_constructible<_Tp>::value,
 void
Index: libcxx/trunk/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp
===
--- libcxx/trunk/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp
+++ libcxx/trunk/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp
@@ -146,9 +146,40 @@
 #endif
 }
 
+// Initialize a vector with a different value type.
+void test_ctor_with_different_value_type() {
+  {
+// Make sure initialization is performed with each element value, not with
+// a memory blob.
+float array[3] = {0.0f, 1.0f, 2.0f};
+std::vector v(array, array + 3);
+assert(v[0] == 0);
+assert(v[1] == 1);
+assert(v[2] == 2);
+  }
+  struct X { int x; };
+  struct Y { int y; };
+  struct Z : X, Y { int z; };
+  {
+Z z;
+Z *array[1] = { &z };
+// Though the types Z* and Y* are very similar, initialization still cannot
+// be done with `memcpy`.
+std::vector v(array, array + 1);
+assert(v[0] == &z);
+  }
+  {
+// Though the types are different, initialization can be done with `memcpy`.
+int32_t array[1] = { -1 };
+std::vector v(array, array + 1);
+assert(v[0] == 4294967295);
+  }
+}
+
 
 int main() {
   basic_test_cases();
   emplaceable_concept_tests(); // See PR34898
   test_ctor_under_alloc();
+  test_ctor_with_different_value_type();
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r350572 - Add a __has_feature check for namespaces on #pragma clang attribute.

2019-01-07 Thread Richard Smith via cfe-commits
On Mon, 7 Jan 2019 at 13:57, Erik Pilkington via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: epilk
> Date: Mon Jan  7 13:54:00 2019
> New Revision: 350572
>
> URL: http://llvm.org/viewvc/llvm-project?rev=350572&view=rev
> Log:
> Add a __has_feature check for namespaces on #pragma clang attribute.
>

Should this be __has_extension rather than __has_feature, since it's not a
standard feature?


> Support for this was added in r349845.
>
> Modified:
> cfe/trunk/docs/LanguageExtensions.rst
> cfe/trunk/include/clang/Basic/Features.def
> cfe/trunk/test/Sema/pragma-attribute-namespace.c
>
> Modified: cfe/trunk/docs/LanguageExtensions.rst
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=350572&r1=350571&r2=350572&view=diff
>
> ==
> --- cfe/trunk/docs/LanguageExtensions.rst (original)
> +++ cfe/trunk/docs/LanguageExtensions.rst Mon Jan  7 13:54:00 2019
> @@ -2725,7 +2725,9 @@ same namespace. For instance:
>  Without the namespaces on the macros, ``other_function`` will be
> annotated with
>  ``[[noreturn]]`` instead of ``__attribute__((unavailable))``. This may
> seem like
>  a contrived example, but its very possible for this kind of situation to
> appear
> -in real code if the pragmas are spread out across a large file.
> +in real code if the pragmas are spread out across a large file. You can
> test if
> +your version of clang supports namespaces on ``#pragma clang attribute``
> with
> +``__has_feature(pragma_clang_attribute_namespaces)``.
>
>  Subject Match Rules
>  ---
>
> Modified: cfe/trunk/include/clang/Basic/Features.def
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Features.def?rev=350572&r1=350571&r2=350572&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/Features.def (original)
> +++ cfe/trunk/include/clang/Basic/Features.def Mon Jan  7 13:54:00 2019
> @@ -69,6 +69,7 @@ FEATURE(attribute_overloadable, true)
>  FEATURE(attribute_unavailable_with_message, true)
>  FEATURE(attribute_unused_on_fields, true)
>  FEATURE(attribute_diagnose_if_objc, true)
> +FEATURE(pragma_clang_attribute_namespaces, true)
>  FEATURE(blocks, LangOpts.Blocks)
>  FEATURE(c_thread_safety_attributes, true)
>  FEATURE(cxx_exceptions, LangOpts.CXXExceptions)
>
> Modified: cfe/trunk/test/Sema/pragma-attribute-namespace.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/pragma-attribute-namespace.c?rev=350572&r1=350571&r2=350572&view=diff
>
> ==
> --- cfe/trunk/test/Sema/pragma-attribute-namespace.c (original)
> +++ cfe/trunk/test/Sema/pragma-attribute-namespace.c Mon Jan  7 13:54:00
> 2019
> @@ -1,5 +1,9 @@
>  // RUN: %clang_cc1 -fsyntax-only -verify %s
>
> +#if !__has_feature(pragma_clang_attribute_namespaces)
> +#error
> +#endif
> +
>  #pragma clang attribute MyNamespace.push (__attribute__((annotate)),
> apply_to=function) // expected-error 2 {{'annotate' attribute}}
>
>  int some_func(); // expected-note{{when applied to this declaration}}
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D56050: [Sema] Diagnose array access preceding the array bounds even when the base type is incomplete.

2019-01-07 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D56050



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


[PATCH] D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch.

2019-01-07 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added inline comments.



Comment at: 
libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp:161
+  {
+// Though types are different, initialization can be done with `memcpy`.
+int32_t array[1] = {-1};

vsapsai wrote:
> Quuxplusone wrote:
> > I might add "can be, but currently isn't, done with memcpy."
> > 
> > Here's my other suggested test:
> > 
> > ```
> > struct X { int x; };
> > struct Y { int y; };
> > struct Z : X, Y { int z; };
> > {
> > Z z;
> > Z *array[1] = { &z };
> > // Though the types Z* and Y* are very similar, initialization still 
> > cannot be done with memcpy.
> > std::vector v(array, array + 1);
> > assert(v[0] == &z);
> > }
> > ```
> Thanks, I'll try your `XYZ` test, looks like it should help with my 
> `iostream*/ostream*` struggles.
LGTM! Ship it!
(I'm surprised the structs can be defined inside the body of `main()` like 
that, but I have no objection to doing so.)


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

https://reviews.llvm.org/D48342



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


[PATCH] D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch.

2019-01-07 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai updated this revision to Diff 180577.
vsapsai added a comment.

- Test initializing vector of pointers with array of pointers of convertible 
type.


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

https://reviews.llvm.org/D48342

Files:
  libcxx/include/memory
  
libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp

Index: libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp
===
--- libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp
+++ libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp
@@ -146,9 +146,40 @@
 #endif
 }
 
+// Initialize a vector with a different value type.
+void test_ctor_with_different_value_type() {
+  {
+// Make sure initialization is performed with each element value, not with
+// a memory blob.
+float array[3] = {0.0f, 1.0f, 2.0f};
+std::vector v(array, array + 3);
+assert(v[0] == 0);
+assert(v[1] == 1);
+assert(v[2] == 2);
+  }
+  struct X { int x; };
+  struct Y { int y; };
+  struct Z : X, Y { int z; };
+  {
+Z z;
+Z *array[1] = { &z };
+// Though the types Z* and Y* are very similar, initialization still cannot
+// be done with `memcpy`.
+std::vector v(array, array + 1);
+assert(v[0] == &z);
+  }
+  {
+// Though the types are different, initialization can be done with `memcpy`.
+int32_t array[1] = { -1 };
+std::vector v(array, array + 1);
+assert(v[0] == 4294967295);
+  }
+}
+
 
 int main() {
   basic_test_cases();
   emplaceable_concept_tests(); // See PR34898
   test_ctor_under_alloc();
+  test_ctor_with_different_value_type();
 }
Index: libcxx/include/memory
===
--- libcxx/include/memory
+++ libcxx/include/memory
@@ -1502,6 +1502,12 @@
 typedef typename _Alloc::difference_type type;
 };
 
+template 
+struct __is_default_allocator : false_type {};
+
+template 
+struct __is_default_allocator<_VSTD::allocator<_Tp> > : true_type {};
+
 template 
 struct _LIBCPP_TEMPLATE_VIS allocator_traits
 {
@@ -1615,7 +1621,7 @@
 static
 typename enable_if
 <
-(is_same >::value
+(__is_default_allocator::value
 || !__has_construct::value) &&
  is_trivially_move_constructible<_Tp>::value,
 void
@@ -1640,23 +1646,25 @@
 construct(__a, _VSTD::__to_raw_pointer(__begin2), *__begin1);
 }
 
-template 
+template ::type,
+  class _RawDestTp = typename remove_const<_DestTp>::type>
 _LIBCPP_INLINE_VISIBILITY
 static
 typename enable_if
 <
-(is_same >::value
-|| !__has_construct::value) &&
- is_trivially_move_constructible<_Tp>::value,
+is_trivially_move_constructible<_DestTp>::value &&
+is_same<_RawSourceTp, _RawDestTp>::value &&
+(__is_default_allocator::value ||
+ !__has_construct::value),
 void
 >::type
-__construct_range_forward(allocator_type&, _Tp* __begin1, _Tp* __end1, _Tp*& __begin2)
+__construct_range_forward(allocator_type&, _SourceTp* __begin1, _SourceTp* __end1, _DestTp*& __begin2)
 {
-typedef typename remove_const<_Tp>::type _Vp;
 ptrdiff_t _Np = __end1 - __begin1;
 if (_Np > 0)
 {
-_VSTD::memcpy(const_cast<_Vp*>(__begin2), __begin1, _Np * sizeof(_Tp));
+_VSTD::memcpy(const_cast<_RawDestTp*>(__begin2), __begin1, _Np * sizeof(_DestTp));
 __begin2 += _Np;
 }
 }
@@ -1679,7 +1687,7 @@
 static
 typename enable_if
 <
-(is_same >::value
+(__is_default_allocator::value
 || !__has_construct::value) &&
  is_trivially_move_constructible<_Tp>::value,
 void
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D56415: NFC: Port QueryParser to StringRef

2019-01-07 Thread Stephen Kelly via Phabricator via cfe-commits
steveire created this revision.
steveire added a reviewer: aaron.ballman.
Herald added a subscriber: cfe-commits.

There is no reason for it to not be a StringRef.  Making it one
simplifies existing code, and makes follow-up features easier.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D56415

Files:
  clang-query/QueryParser.cpp
  clang-query/QueryParser.h

Index: clang-query/QueryParser.h
===
--- clang-query/QueryParser.h
+++ clang-query/QueryParser.h
@@ -37,7 +37,7 @@
 
 private:
   QueryParser(StringRef Line, const QuerySession &QS)
-  : Begin(Line.begin()), End(Line.end()), CompletionPos(nullptr), QS(QS) {}
+  : Line(Line), CompletionPos(nullptr), QS(QS) {}
 
   StringRef lexWord();
 
@@ -55,8 +55,7 @@
   /// \c InvalidQuery if a parse error occurs.
   QueryRef doParse();
 
-  const char *Begin;
-  const char *End;
+  StringRef Line;
 
   const char *CompletionPos;
   std::vector Completions;
Index: clang-query/QueryParser.cpp
===
--- clang-query/QueryParser.cpp
+++ clang-query/QueryParser.cpp
@@ -27,29 +27,19 @@
 // is found before End, return StringRef().  Begin is adjusted to exclude the
 // lexed region.
 StringRef QueryParser::lexWord() {
-  while (true) {
-if (Begin == End)
-  return StringRef(Begin, 0);
+  Line = Line.ltrim();
+ 
+  if (Line.empty())
+return StringRef(Line.begin(), 0);
 
-if (!isWhitespace(*Begin))
-  break;
-
-++Begin;
-  }
-
-  if (*Begin == '#') {
-End = Begin;
+  if (Line.front() == '#') {
+Line = {};
 return StringRef();
   }
 
-  const char *WordBegin = Begin;
-
-  while (true) {
-++Begin;
-
-if (Begin == End || isWhitespace(*Begin))
-  return StringRef(WordBegin, Begin - WordBegin);
-  }
+  StringRef Word = Line.take_while([](char c){ return !isWhitespace(c); });
+  Line = Line.drop_front(Word.size());
+  return Word;
 }
 
 // This is the StringSwitch-alike used by lexOrCompleteWord below. See that
@@ -133,10 +123,9 @@
 }
 
 QueryRef QueryParser::endQuery(QueryRef Q) {
-  const char *Extra = Begin;
+  const StringRef Extra = Line;
   if (!lexWord().empty())
-return new InvalidQuery("unexpected extra input: '" +
-StringRef(Extra, End - Extra) + "'");
+return new InvalidQuery("unexpected extra input: '" + Extra + "'");
   return Q;
 }
 
@@ -174,7 +163,7 @@
 
 QueryRef QueryParser::completeMatcherExpression() {
   std::vector Comps = Parser::completeExpression(
-  StringRef(Begin, End - Begin), CompletionPos - Begin, nullptr,
+  Line, CompletionPos - Line.begin(), nullptr,
   &QS.NamedValues);
   for (auto I = Comps.begin(), E = Comps.end(); I != E; ++I) {
 Completions.push_back(LineEditor::Completion(I->TypedText, I->MatcherDecl));
@@ -222,7 +211,7 @@
 
 Diagnostics Diag;
 ast_matchers::dynamic::VariantValue Value;
-if (!Parser::parseExpression(StringRef(Begin, End - Begin), nullptr,
+if (!Parser::parseExpression(Line, nullptr,
  &QS.NamedValues, &Value, &Diag)) {
   return makeInvalidQueryFromDiagnostics(Diag);
 }
@@ -235,7 +224,7 @@
   return completeMatcherExpression();
 
 Diagnostics Diag;
-auto MatcherSource = StringRef(Begin, End - Begin).trim();
+auto MatcherSource = Line.trim();
 Optional Matcher = Parser::parseMatcherExpression(
 MatcherSource, nullptr, &QS.NamedValues, &Diag);
 if (!Matcher) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D56354: [AST] Replace asserts with if() in SourceLocation accessors

2019-01-07 Thread Stephen Kelly via Phabricator via cfe-commits
steveire marked an inline comment as done.
steveire added inline comments.



Comment at: lib/AST/NestedNameSpecifier.cpp:465
 TypeLoc NestedNameSpecifierLoc::getTypeLoc() const {
-  assert((Qualifier->getKind() == NestedNameSpecifier::TypeSpec ||
-  Qualifier->getKind() == NestedNameSpecifier::TypeSpecWithTemplate) &&
- "Nested-name-specifier location is not a type");
+  if ((Qualifier->getKind() != NestedNameSpecifier::TypeSpec &&
+  Qualifier->getKind() != NestedNameSpecifier::TypeSpecWithTemplate))

aaron.ballman wrote:
> aaron.ballman wrote:
> > Remove spurious parens.
> Formatting is still off here for the second line of the if statement (one too 
> many spaces on the indentation).
Fixed, thanks. I ran c-f before fixing the parens.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56354



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


[PATCH] D56413: [OpenMP] Avoid remainder operations for loop index values on a collapsed loop nest.

2019-01-07 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits
gtbercea created this revision.
gtbercea added reviewers: ABataev, caomhin.
Herald added subscribers: cfe-commits, arphaman, guansong.

Change the strategy for computing loop index variables after collapsing a loop 
nest via the collapse clause by replacing the expensive remainder operation 
with multiplications and additions.


Repository:
  rC Clang

https://reviews.llvm.org/D56413

Files:
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/for_codegen.cpp
  test/OpenMP/for_simd_codegen.cpp
  test/OpenMP/parallel_for_simd_codegen.cpp
  test/OpenMP/simd_codegen.cpp

Index: test/OpenMP/simd_codegen.cpp
===
--- test/OpenMP/simd_codegen.cpp
+++ test/OpenMP/simd_codegen.cpp
@@ -278,7 +278,11 @@
 // CHECK-NEXT: [[I_2:%.+]] = trunc i64 [[I_1_ADD0]] to i32
 // CHECK-NEXT: store i32 [[I_2]], i32* {{%.+}}{{.*}}!llvm.mem.parallel_loop_access ![[T1_ID]]
 // CHECK: [[IV2:%.+]] = load i64, i64* [[T1_OMP_IV]]{{.*}}!llvm.mem.parallel_loop_access ![[T1_ID]]
-// CHECK-NEXT: [[J_1:%.+]] = srem i64 [[IV2]], 4
+// CHECK: [[IV2_1:%.+]] = load i64, i64* [[T1_OMP_IV]]{{.*}}!llvm.mem.parallel_loop_access ![[T1_ID]]
+// CHECK-NEXT: [[DIV_1:%.+]] = sdiv i64 [[IV2_1]], 4
+// CHECK-NEXT: [[I_1_MUL1:%.+]] = mul nsw i64 [[DIV_1]], 4
+// CHECK-NEXT: [[I_1_ADD0:%.+]] = add nsw i64 0, [[I_1_MUL1]]
+// CHECK-NEXT: [[J_1:%.+]] = sub nsw i64 [[IV2]], [[I_1_ADD0]]
 // CHECK-NEXT: [[J_2:%.+]] = mul nsw i64 [[J_1]], 2
 // CHECK-NEXT: [[J_2_ADD0:%.+]] = add nsw i64 0, [[J_2]]
 // CHECK-NEXT: store i64 [[J_2_ADD0]], i64* {{%.+}}{{.*}}!llvm.mem.parallel_loop_access ![[T1_ID]]
@@ -393,22 +397,77 @@
 // CHECK-NEXT: [[CALC_I_1_MUL1:%.+]] = mul i32 [[CALC_I_1]], 1
 // CHECK-NEXT: [[CALC_I_2:%.+]] = add i32 1, [[CALC_I_1_MUL1]]
 // CHECK-NEXT: store i32 [[CALC_I_2]], i32* [[LC_I:.+]]
+
 // CHECK: [[IV1_2:%.+]] = load i32, i32* [[OMP_IV]]{{.+}}!llvm.mem.parallel_loop_access ![[COLL1_LOOP_ID]]
-// CHECK-NEXT: [[CALC_J_1:%.+]] = udiv i32 [[IV1_2]], 20
-// CHECK-NEXT: [[CALC_J_2:%.+]] = urem i32 [[CALC_J_1]], 3
+// CHECK: [[IV1_2_1:%.+]] = load i32, i32* [[OMP_IV]]{{.+}}!llvm.mem.parallel_loop_access ![[COLL1_LOOP_ID]]
+// CHECK-NEXT: [[CALC_J_1:%.+]] = udiv i32 [[IV1_2_1]], 60
+// CHECK-NEXT: [[MUL_1:%.+]] = mul i32 [[CALC_J_1]], 60
+// CHECK-NEXT: [[ADD_2:%.+]] = add i32 0, [[MUL_1]]
+// CHECK-NEXT: [[SUB_3:%.+]] = sub i32 [[IV1_2]], [[ADD_2]]
+// CHECK-NEXT: [[CALC_J_2:%.+]] = udiv i32 [[SUB_3]], 20
 // CHECK-NEXT: [[CALC_J_2_MUL1:%.+]] = mul i32 [[CALC_J_2]], 1
 // CHECK-NEXT: [[CALC_J_3:%.+]] = add i32 2, [[CALC_J_2_MUL1]]
 // CHECK-NEXT: store i32 [[CALC_J_3]], i32* [[LC_J:.+]]
+
 // CHECK: [[IV1_3:%.+]] = load i32, i32* [[OMP_IV]]{{.+}}!llvm.mem.parallel_loop_access ![[COLL1_LOOP_ID]]
-// CHECK-NEXT: [[CALC_K_1:%.+]] = udiv i32 [[IV1_3]], 5
-// CHECK-NEXT: [[CALC_K_2:%.+]] = urem i32 [[CALC_K_1]], 4
-// CHECK-NEXT: [[CALC_K_2_MUL1:%.+]] = mul i32 [[CALC_K_2]], 1
-// CHECK-NEXT: [[CALC_K_3:%.+]] = add i32 3, [[CALC_K_2_MUL1]]
-// CHECK-NEXT: store i32 [[CALC_K_3]], i32* [[LC_K:.+]]
-// CHECK: [[IV1_4:%.+]] = load i32, i32* [[OMP_IV]]{{.+}}!llvm.mem.parallel_loop_access ![[COLL1_LOOP_ID]]
-// CHECK-NEXT: [[CALC_L_1:%.+]] = urem i32 [[IV1_4]], 5
-// CHECK-NEXT: [[CALC_L_1_MUL1:%.+]] = mul i32 [[CALC_L_1]], 1
-// CHECK-NEXT: [[CALC_L_2:%.+]] = add i32 4, [[CALC_L_1_MUL1]]
+// CHECK: [[IV1_3_1:%.+]] = load i32, i32* [[OMP_IV]]{{.+}}!llvm.mem.parallel_loop_access ![[COLL1_LOOP_ID]]
+// CHECK-NEXT: [[DIV_1:%.+]] = udiv i32 [[IV1_3_1]], 60
+// CHECK-NEXT: [[MUL_2:%.+]] = mul i32 [[DIV_1]], 60
+// CHECK-NEXT: [[ADD_3:%.+]] = add i32 0, [[MUL_2]]
+
+// CHECK: [[IV1_4:%.+]] = load i32, i32* [[OMP_IV]]
+// CHECK: [[IV1_4_1:%.+]] = load i32, i32* [[OMP_IV]]
+// CHECK-NEXT: [[DIV_2:%.+]] = udiv i32 [[IV1_4_1]], 60
+// CHECK-NEXT: [[MUL_3:%.+]] = mul i32 [[DIV_2]], 60
+// CHECK-NEXT: [[ADD_4:%.+]] = add i32 0, [[MUL_3]]
+// CHECK-NEXT: [[SUB_6:%.+]] = sub i32 [[IV1_4]], [[ADD_4]]
+// CHECK-NEXT: [[DIV_3:%.+]] = udiv i32 [[SUB_6]], 20
+// CHECK-NEXT: [[MUL_4:%.+]] = mul i32 [[DIV_3]], 20
+// CHECK-NEXT: [[ADD_5:%.+]] = add i32 [[ADD_3]], [[MUL_4]]
+// CHECK-NEXT: [[SUB_7:%.+]] = sub i32 [[IV1_3]], [[ADD_5]]
+// CHECK-NEXT: [[DIV_4:%.+]] = udiv i32 [[SUB_7]], 5
+// CHECK-NEXT: [[MUL_5:%.+]] = mul i32 [[DIV_4]], 1
+// CHECK-NEXT: [[ADD_6:%.+]] = add i32 3, [[MUL_5]]
+// CHECK-NEXT: store i32 [[ADD_6]], i32* [[LC_K:.+]]
+
+// CHECK: [[IV1_5:%.+]] = load i32, i32* [[OMP_IV]]{{.+}}!llvm.mem.parallel_loop_access ![[COLL1_LOOP_ID]]
+// CHECK: [[IV1_5_1:%.+]] = load i32, i32* [[OMP_IV]]{{.+}}!llvm.mem.parallel_loop_access ![[COLL1_LOOP_ID]]
+// CHECK-NEXT: [[DIV_5:%.+]] = udiv i32 [[IV1_5_1]], 60
+// CHECK-NEXT: [[MUL_6:%.+]] = mul i32 [[DIV_5]], 60
+// CHECK-NEXT: [[ADD_7:%.+]] = add i32 0, [[MUL_6]]
+
+// CHECK: [[IV1_6:%.+]] = load i32, i32* [[OMP_IV]]
+// CHECK: [[IV1_6_1:%.+]] = load i32, i32* [[OMP_IV]]
+// CHECK-NEXT: [[DIV_6:%.+]] = udiv i32 [[IV1_6_1]], 60
+// CHECK-NEXT: [[MUL_7:%.+]] = mul i32 [[DIV_6]], 60
+/

[PATCH] D56411: [CUDA][HIP][Sema] Fix template kernel with function as template parameter

2019-01-07 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl created this revision.
yaxunl added reviewers: tra, rjmccall.

If a kernel template has a function as its template parameter, a device 
function should be
allowed as template argument since a kernel can call a device function. However,
currently if the kernel template is instantiated in a host function, clang will 
emit an error
message saying the device function is an invalid candidate for the template 
parameter.

This happens because clang checks the reference to the device function during 
parsing
the template arguments. At this point, the template is not instantiated yet. 
Clang incorrectly
assumes the device function is called by the host function and emits the error 
message.

This patch fixes the issue by disabling checking of device function during 
parsing template
arguments and deferring the check to the instantion of the template. At that 
point, the
template decl is already available, therefore the check can be done against the 
instantiated
function template decl.


https://reviews.llvm.org/D56411

Files:
  include/clang/Sema/Sema.h
  lib/Parse/ParseTemplate.cpp
  lib/Sema/SemaCUDA.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaTemplate.cpp
  test/SemaCUDA/kernel-template-with-device-func-arg.cu

Index: test/SemaCUDA/kernel-template-with-device-func-arg.cu
===
--- /dev/null
+++ test/SemaCUDA/kernel-template-with-device-func-arg.cu
@@ -0,0 +1,49 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+#include "Inputs/cuda.h"
+
+struct C {
+  __device__ void devfun() {}
+  void hostfun() {}
+  template __device__ void devtempfun() {}
+};
+
+__device__ void devfun() {}
+__host__ void hostfun() {}
+template __device__ void devtempfun() {}
+
+template  __global__ void kernel() { devF();}
+template  __global__ void kernel2(T *p) { (p->*devF)(); }
+
+template<> __global__ void kernel();
+template<> __global__ void kernel(); // expected-error {{no function template matches function template specialization 'kernel'}}
+  // expected-note@-5 {{candidate template ignored: invalid explicitly-specified argument for template parameter 'devF'}}
+template<> __global__ void kernel >();
+
+template<> __global__ void kernel<&devfun>();
+template<> __global__ void kernel<&hostfun>(); // expected-error {{no function template matches function template specialization 'kernel'}}
+   // expected-note@-10 {{candidate template ignored: invalid explicitly-specified argument for template parameter 'devF'}}
+template<> __global__ void kernel<&devtempfun >();
+
+template<> __global__ void kernel2(C *p);
+template<> __global__ void kernel2(C *p); // expected-error {{no function template matches function template specialization 'kernel2'}}
+  // expected-note@-14 {{candidate template ignored: invalid explicitly-specified argument for template parameter 'devF'}}
+template<> __global__ void kernel2 >(C *p);
+
+void fun() {
+  kernel<&devfun><<<1,1>>>();
+  kernel<&hostfun><<<1,1>>>(); // expected-error {{no matching function for call to 'kernel'}}
+   // expected-note@-21 {{candidate template ignored: invalid explicitly-specified argument for template parameter 'devF'}}
+  kernel<&devtempfun ><<<1,1>>>();
+
+  kernel<<<1,1>>>();
+  kernel<<<1,1>>>(); // expected-error {{no matching function for call to 'kernel'}}
+  // expected-note@-26 {{candidate template ignored: invalid explicitly-specified argument for template parameter 'devF'}}
+  kernel ><<<1,1>>>();
+
+  C a;
+  kernel2<<<1,1>>>(&a);
+  kernel2<<<1,1>>>(&a); // expected-error {{no matching function for call to 'kernel2'}}
+// expected-note@-31 {{candidate template ignored: invalid explicitly-specified argument for template parameter 'devF'}}
+  kernel2 ><<<1,1>>>(&a);
+}
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -4753,8 +4753,8 @@
   TemplateArgument Result;
   unsigned CurSFINAEErrors = NumSFINAEErrors;
   ExprResult Res =
-CheckTemplateArgument(NTTP, NTTPType, Arg.getArgument().getAsExpr(),
-  Result, CTAK);
+  CheckTemplateArgument(NTTP, NTTPType, Arg.getArgument().getAsExpr(),
+Result, CTAK, dyn_cast(Template));
   if (Res.isInvalid())
 return true;
   // If the current template argument causes an error, give up now.
@@ -6123,6 +6123,27 @@
   return true;
 }
 
+namespace {
+bool CheckCUDATemplateArgument(Sema &S, Expr *Arg, TemplateDecl *Template) {
+  if (Template) {
+Expr *E = Arg;
+if (UnaryOperator *UO = dyn_cast(E)) {
+  E = UO ? UO->getSubExpr() : nullptr;
+}
+if (DeclRefExpr *DRE = dyn_cast_or_null(E)) {
+  ValueDecl

[PATCH] D56354: [AST] Replace asserts with if() in SourceLocation accessors

2019-01-07 Thread Stephen Kelly via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL350573: NFC: Replace asserts with if() in SourceLocation 
accessors (authored by steveire, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D56354?vs=180548&id=180557#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56354

Files:
  cfe/trunk/include/clang/AST/DeclarationName.h
  cfe/trunk/include/clang/AST/TemplateBase.h
  cfe/trunk/lib/AST/NestedNameSpecifier.cpp


Index: cfe/trunk/lib/AST/NestedNameSpecifier.cpp
===
--- cfe/trunk/lib/AST/NestedNameSpecifier.cpp
+++ cfe/trunk/lib/AST/NestedNameSpecifier.cpp
@@ -462,9 +462,9 @@
 }
 
 TypeLoc NestedNameSpecifierLoc::getTypeLoc() const {
-  assert((Qualifier->getKind() == NestedNameSpecifier::TypeSpec ||
-  Qualifier->getKind() == NestedNameSpecifier::TypeSpecWithTemplate) &&
- "Nested-name-specifier location is not a type");
+  if (Qualifier->getKind() != NestedNameSpecifier::TypeSpec &&
+  Qualifier->getKind() != NestedNameSpecifier::TypeSpecWithTemplate)
+return TypeLoc();
 
   // The "void*" that points at the TypeLoc data.
   unsigned Offset = getDataLength(Qualifier->getPrefix());
Index: cfe/trunk/include/clang/AST/DeclarationName.h
===
--- cfe/trunk/include/clang/AST/DeclarationName.h
+++ cfe/trunk/include/clang/AST/DeclarationName.h
@@ -729,9 +729,10 @@
   /// getNamedTypeInfo - Returns the source type info associated to
   /// the name. Assumes it is a constructor, destructor or conversion.
   TypeSourceInfo *getNamedTypeInfo() const {
-assert(Name.getNameKind() == DeclarationName::CXXConstructorName ||
-   Name.getNameKind() == DeclarationName::CXXDestructorName ||
-   Name.getNameKind() == DeclarationName::CXXConversionFunctionName);
+if (Name.getNameKind() != DeclarationName::CXXConstructorName &&
+Name.getNameKind() != DeclarationName::CXXDestructorName &&
+Name.getNameKind() != DeclarationName::CXXConversionFunctionName)
+  return nullptr;
 return LocInfo.NamedType.TInfo;
   }
 
@@ -747,7 +748,8 @@
   /// getCXXOperatorNameRange - Gets the range of the operator name
   /// (without the operator keyword). Assumes it is a (non-literal) operator.
   SourceRange getCXXOperatorNameRange() const {
-assert(Name.getNameKind() == DeclarationName::CXXOperatorName);
+if (Name.getNameKind() != DeclarationName::CXXOperatorName)
+  return SourceRange();
 return SourceRange(
  
SourceLocation::getFromRawEncoding(LocInfo.CXXOperatorName.BeginOpNameLoc),
  SourceLocation::getFromRawEncoding(LocInfo.CXXOperatorName.EndOpNameLoc)
@@ -766,7 +768,8 @@
   /// operator name (not the operator keyword).
   /// Assumes it is a literal operator.
   SourceLocation getCXXLiteralOperatorNameLoc() const {
-assert(Name.getNameKind() == DeclarationName::CXXLiteralOperatorName);
+if (Name.getNameKind() != DeclarationName::CXXLiteralOperatorName)
+  return SourceLocation();
 return SourceLocation::
   getFromRawEncoding(LocInfo.CXXLiteralOperatorName.OpNameLoc);
   }
Index: cfe/trunk/include/clang/AST/TemplateBase.h
===
--- cfe/trunk/include/clang/AST/TemplateBase.h
+++ cfe/trunk/include/clang/AST/TemplateBase.h
@@ -530,19 +530,22 @@
   }
 
   NestedNameSpecifierLoc getTemplateQualifierLoc() const {
-assert(Argument.getKind() == TemplateArgument::Template ||
-   Argument.getKind() == TemplateArgument::TemplateExpansion);
+if (Argument.getKind() != TemplateArgument::Template &&
+Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return NestedNameSpecifierLoc();
 return LocInfo.getTemplateQualifierLoc();
   }
 
   SourceLocation getTemplateNameLoc() const {
-assert(Argument.getKind() == TemplateArgument::Template ||
-   Argument.getKind() == TemplateArgument::TemplateExpansion);
+if (Argument.getKind() != TemplateArgument::Template &&
+Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return SourceLocation();
 return LocInfo.getTemplateNameLoc();
   }
 
   SourceLocation getTemplateEllipsisLoc() const {
-assert(Argument.getKind() == TemplateArgument::TemplateExpansion);
+if (Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return SourceLocation();
 return LocInfo.getTemplateEllipsisLoc();
   }
 };


Index: cfe/trunk/lib/AST/NestedNameSpecifier.cpp
===
--- cfe/trunk/lib/AST/NestedNameSpecifier.cpp
+++ cfe/trunk/lib/AST/NestedNameSpecifier.cpp
@@ -462,9 +462,9 @@
 }
 
 TypeLoc NestedNameSpecifierLoc::getTypeLoc() const {
-  assert((Qualifier->getKind() == NestedNameSpecifier::TypeSpe

r350573 - NFC: Replace asserts with if() in SourceLocation accessors

2019-01-07 Thread Stephen Kelly via cfe-commits
Author: steveire
Date: Mon Jan  7 13:57:30 2019
New Revision: 350573

URL: http://llvm.org/viewvc/llvm-project?rev=350573&view=rev
Log:
NFC: Replace asserts with if() in SourceLocation accessors

Summary:
Nowhere else in the AST classes assert on these kinds of accessors.

This way, we can call the accessors and check the validity of the result
instead of externally duplicating the conditions.  This generality will
make it possible to introspect instances for source locations:

 http://ec2-18-191-7-3.us-east-2.compute.amazonaws.com:10240/z/iiaWhw

Reviewers: aaron.ballman

Subscribers: cfe-commits

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

Modified:
cfe/trunk/include/clang/AST/DeclarationName.h
cfe/trunk/include/clang/AST/TemplateBase.h
cfe/trunk/lib/AST/NestedNameSpecifier.cpp

Modified: cfe/trunk/include/clang/AST/DeclarationName.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclarationName.h?rev=350573&r1=350572&r2=350573&view=diff
==
--- cfe/trunk/include/clang/AST/DeclarationName.h (original)
+++ cfe/trunk/include/clang/AST/DeclarationName.h Mon Jan  7 13:57:30 2019
@@ -729,9 +729,10 @@ public:
   /// getNamedTypeInfo - Returns the source type info associated to
   /// the name. Assumes it is a constructor, destructor or conversion.
   TypeSourceInfo *getNamedTypeInfo() const {
-assert(Name.getNameKind() == DeclarationName::CXXConstructorName ||
-   Name.getNameKind() == DeclarationName::CXXDestructorName ||
-   Name.getNameKind() == DeclarationName::CXXConversionFunctionName);
+if (Name.getNameKind() != DeclarationName::CXXConstructorName &&
+Name.getNameKind() != DeclarationName::CXXDestructorName &&
+Name.getNameKind() != DeclarationName::CXXConversionFunctionName)
+  return nullptr;
 return LocInfo.NamedType.TInfo;
   }
 
@@ -747,7 +748,8 @@ public:
   /// getCXXOperatorNameRange - Gets the range of the operator name
   /// (without the operator keyword). Assumes it is a (non-literal) operator.
   SourceRange getCXXOperatorNameRange() const {
-assert(Name.getNameKind() == DeclarationName::CXXOperatorName);
+if (Name.getNameKind() != DeclarationName::CXXOperatorName)
+  return SourceRange();
 return SourceRange(
  
SourceLocation::getFromRawEncoding(LocInfo.CXXOperatorName.BeginOpNameLoc),
  SourceLocation::getFromRawEncoding(LocInfo.CXXOperatorName.EndOpNameLoc)
@@ -766,7 +768,8 @@ public:
   /// operator name (not the operator keyword).
   /// Assumes it is a literal operator.
   SourceLocation getCXXLiteralOperatorNameLoc() const {
-assert(Name.getNameKind() == DeclarationName::CXXLiteralOperatorName);
+if (Name.getNameKind() != DeclarationName::CXXLiteralOperatorName)
+  return SourceLocation();
 return SourceLocation::
   getFromRawEncoding(LocInfo.CXXLiteralOperatorName.OpNameLoc);
   }

Modified: cfe/trunk/include/clang/AST/TemplateBase.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/TemplateBase.h?rev=350573&r1=350572&r2=350573&view=diff
==
--- cfe/trunk/include/clang/AST/TemplateBase.h (original)
+++ cfe/trunk/include/clang/AST/TemplateBase.h Mon Jan  7 13:57:30 2019
@@ -530,19 +530,22 @@ public:
   }
 
   NestedNameSpecifierLoc getTemplateQualifierLoc() const {
-assert(Argument.getKind() == TemplateArgument::Template ||
-   Argument.getKind() == TemplateArgument::TemplateExpansion);
+if (Argument.getKind() != TemplateArgument::Template &&
+Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return NestedNameSpecifierLoc();
 return LocInfo.getTemplateQualifierLoc();
   }
 
   SourceLocation getTemplateNameLoc() const {
-assert(Argument.getKind() == TemplateArgument::Template ||
-   Argument.getKind() == TemplateArgument::TemplateExpansion);
+if (Argument.getKind() != TemplateArgument::Template &&
+Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return SourceLocation();
 return LocInfo.getTemplateNameLoc();
   }
 
   SourceLocation getTemplateEllipsisLoc() const {
-assert(Argument.getKind() == TemplateArgument::TemplateExpansion);
+if (Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return SourceLocation();
 return LocInfo.getTemplateEllipsisLoc();
   }
 };

Modified: cfe/trunk/lib/AST/NestedNameSpecifier.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/NestedNameSpecifier.cpp?rev=350573&r1=350572&r2=350573&view=diff
==
--- cfe/trunk/lib/AST/NestedNameSpecifier.cpp (original)
+++ cfe/trunk/lib/AST/NestedNameSpecifier.cpp Mon Jan  7 13:57:30 2019
@@ -462,9 +462,9 @@ SourceRange NestedNameSpecifierLoc::getL
 }
 
 TypeLoc NestedNameSpecifierLoc::getTypeLoc() const {
-  asser

[PATCH] D56405: Split -Wdelete-non-virtual-dtor into two groups

2019-01-07 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!


Repository:
  rC Clang

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

https://reviews.llvm.org/D56405



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


[PATCH] D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch.

2019-01-07 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai added inline comments.



Comment at: 
libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp:161
+  {
+// Though types are different, initialization can be done with `memcpy`.
+int32_t array[1] = {-1};

Quuxplusone wrote:
> I might add "can be, but currently isn't, done with memcpy."
> 
> Here's my other suggested test:
> 
> ```
> struct X { int x; };
> struct Y { int y; };
> struct Z : X, Y { int z; };
> {
> Z z;
> Z *array[1] = { &z };
> // Though the types Z* and Y* are very similar, initialization still 
> cannot be done with memcpy.
> std::vector v(array, array + 1);
> assert(v[0] == &z);
> }
> ```
Thanks, I'll try your `XYZ` test, looks like it should help with my 
`iostream*/ostream*` struggles.


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

https://reviews.llvm.org/D48342



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


[PATCH] D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch.

2019-01-07 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai added inline comments.



Comment at: 
libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp:196
   test_ctor_under_alloc();
+  test_ctor_with_different_value_type();
 }

Quuxplusone wrote:
> vsapsai wrote:
> > Quuxplusone wrote:
> > > I suggest that interesting test cases include "array of `int` to vector 
> > > of `unsigned int`" (trivial, but unimplemented in this patch) and "array 
> > > of `iostream*` to vector of `ostream*`" (non-trivial because each pointer 
> > > must be adjusted).
> > What is that supposed to test? My `float/int` test is to make sure we have 
> > `is_same<_RawSourceTp, _RawDestTp>::value` and don't try to `memcpy` 
> > unrelated types. I've chosen `float` and `int` because it is easier for a 
> > human to reason about them.
> > 
> > `int` and `unsigned int` are interested for testing for values that are 
> > outside of common range. But in this case you pay more attention to 
> > conversion between ints, not to the behaviour of the constructor. That's my 
> > interpretation but maybe I've missed some of your intentions.
> > My `float/int` test is to make sure we [...] don't try to `memcpy` 
> > unrelated types [when it's unsafe to do so].
> 
> Right. I suggest two additional tests. The first additional test, 
> `int/unsigned int`, is to verify whether we `memcpy` unrelated types when it 
> //is// safe to do so. The second test, `iostream*/ostream*`, is to verify 
> whether we `memcpy` unrelated types when it is unsafe to `memcpy` them even 
> though they are both of the same "kind" (both pointer types).
> 
> These will act as regression tests, to make sure that future changes to the 
> memcpy criteria don't break these cases' behavior (although the first 
> additional test //is// expected to get more efficient).
Added test for `int32_t/uint32_t`. Size is mentioned explicitly to avoid 
surprises with testing on different architectures. Tested that such 
initialization isn't using `memcpy` and still slow.

Do you know ways to verify pointer adjustment for `iostream*/ostream*` using 
their public API? Because I found a way to do that with accessing 
`vector::data()` and mucking with pointers. But I don't like this approach 
because it seems brittle and specific to vector implementation. I'd rather use 
stable public API. Currently I don't plan to invest much effort into 
`iostream*/ostream*` test because I agree it is nice to have but `is_same` part 
is already covered.


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

https://reviews.llvm.org/D48342



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


r350572 - Add a __has_feature check for namespaces on #pragma clang attribute.

2019-01-07 Thread Erik Pilkington via cfe-commits
Author: epilk
Date: Mon Jan  7 13:54:00 2019
New Revision: 350572

URL: http://llvm.org/viewvc/llvm-project?rev=350572&view=rev
Log:
Add a __has_feature check for namespaces on #pragma clang attribute.

Support for this was added in r349845.

Modified:
cfe/trunk/docs/LanguageExtensions.rst
cfe/trunk/include/clang/Basic/Features.def
cfe/trunk/test/Sema/pragma-attribute-namespace.c

Modified: cfe/trunk/docs/LanguageExtensions.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=350572&r1=350571&r2=350572&view=diff
==
--- cfe/trunk/docs/LanguageExtensions.rst (original)
+++ cfe/trunk/docs/LanguageExtensions.rst Mon Jan  7 13:54:00 2019
@@ -2725,7 +2725,9 @@ same namespace. For instance:
 Without the namespaces on the macros, ``other_function`` will be annotated with
 ``[[noreturn]]`` instead of ``__attribute__((unavailable))``. This may seem 
like
 a contrived example, but its very possible for this kind of situation to appear
-in real code if the pragmas are spread out across a large file.
+in real code if the pragmas are spread out across a large file. You can test if
+your version of clang supports namespaces on ``#pragma clang attribute`` with
+``__has_feature(pragma_clang_attribute_namespaces)``.
 
 Subject Match Rules
 ---

Modified: cfe/trunk/include/clang/Basic/Features.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Features.def?rev=350572&r1=350571&r2=350572&view=diff
==
--- cfe/trunk/include/clang/Basic/Features.def (original)
+++ cfe/trunk/include/clang/Basic/Features.def Mon Jan  7 13:54:00 2019
@@ -69,6 +69,7 @@ FEATURE(attribute_overloadable, true)
 FEATURE(attribute_unavailable_with_message, true)
 FEATURE(attribute_unused_on_fields, true)
 FEATURE(attribute_diagnose_if_objc, true)
+FEATURE(pragma_clang_attribute_namespaces, true)
 FEATURE(blocks, LangOpts.Blocks)
 FEATURE(c_thread_safety_attributes, true)
 FEATURE(cxx_exceptions, LangOpts.CXXExceptions)

Modified: cfe/trunk/test/Sema/pragma-attribute-namespace.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/pragma-attribute-namespace.c?rev=350572&r1=350571&r2=350572&view=diff
==
--- cfe/trunk/test/Sema/pragma-attribute-namespace.c (original)
+++ cfe/trunk/test/Sema/pragma-attribute-namespace.c Mon Jan  7 13:54:00 2019
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
 
+#if !__has_feature(pragma_clang_attribute_namespaces)
+#error
+#endif
+
 #pragma clang attribute MyNamespace.push (__attribute__((annotate)), 
apply_to=function) // expected-error 2 {{'annotate' attribute}}
 
 int some_func(); // expected-note{{when applied to this declaration}}


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


[PATCH] D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch.

2019-01-07 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added inline comments.



Comment at: 
libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp:161
+  {
+// Though types are different, initialization can be done with `memcpy`.
+int32_t array[1] = {-1};

I might add "can be, but currently isn't, done with memcpy."

Here's my other suggested test:

```
struct X { int x; };
struct Y { int y; };
struct Z : X, Y { int z; };
{
Z z;
Z *array[1] = { &z };
// Though the types Z* and Y* are very similar, initialization still cannot 
be done with memcpy.
std::vector v(array, array + 1);
assert(v[0] == &z);
}
```


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

https://reviews.llvm.org/D48342



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


[PATCH] D56410: Forbid combination of --status-bugs and non-HTML output

2019-01-07 Thread Rob Day via Phabricator via cfe-commits
rkday created this revision.
rkday added a reviewer: dcoughlin.
Herald added a subscriber: cfe-commits.

I recently spent some time resolving an issue where the --status-bugs parameter 
conflicted with -plist, and scan-build always returned 0 even when there were 
errors.

This change means that scan-build rejects these as incompatible arguments.

I've tested that this works with this test program:

  $ cat test.c
  int abcd(char* x, char* y)
  {
strcpy(x, y);
  }
  
  int main()
  {
return 0;
  }

and these two commands:

  ./bin/scan-build --status-bugs -enable-checker security --use-analyzer 
/usr/bin/clang clang test.c; echo $?



  ./bin/scan-build --status-bugs -plist -enable-checker security --use-analyzer 
/usr/bin/clang clang test.c; echo $?


Repository:
  rC Clang

https://reviews.llvm.org/D56410

Files:
  bin/scan-build


Index: bin/scan-build
===
--- bin/scan-build
+++ bin/scan-build
@@ -1849,6 +1849,10 @@
   DieDiag("'c++-analyzer' does not exist at '$CmdCXX'\n") if(! -e $CmdCXX);
 }
 
+if ($Options{ExitStatusFoundBugs} == 1 && !($Options{OutputFormat} =~ /html/)) 
{
+  DieDiag("--status-bugs is only supported with the HTML output format\n");
+}
+
 Diag("Using '$Clang' for static analysis\n");
 
 SetHtmlEnv(\@ARGV, $Options{OutputDir});


Index: bin/scan-build
===
--- bin/scan-build
+++ bin/scan-build
@@ -1849,6 +1849,10 @@
   DieDiag("'c++-analyzer' does not exist at '$CmdCXX'\n") if(! -e $CmdCXX);
 }
 
+if ($Options{ExitStatusFoundBugs} == 1 && !($Options{OutputFormat} =~ /html/)) {
+  DieDiag("--status-bugs is only supported with the HTML output format\n");
+}
+
 Diag("Using '$Clang' for static analysis\n");
 
 SetHtmlEnv(\@ARGV, $Options{OutputDir});
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch.

2019-01-07 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai updated this revision to Diff 180556.
vsapsai added a comment.

- Test initializing vector of `unsigned int` with array of `int`.


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

https://reviews.llvm.org/D48342

Files:
  libcxx/include/memory
  
libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp

Index: libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp
===
--- libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp
+++ libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp
@@ -146,9 +146,29 @@
 #endif
 }
 
+// Initialize a vector with a different value type.
+void test_ctor_with_different_value_type() {
+  {
+// Make sure initialization is performed with each element value, not with
+// a memory blob.
+float array[3] = {0.0f, 1.0f, 2.0f};
+std::vector v(array, array + 3);
+assert(v[0] == 0);
+assert(v[1] == 1);
+assert(v[2] == 2);
+  }
+  {
+// Though types are different, initialization can be done with `memcpy`.
+int32_t array[1] = {-1};
+std::vector v(array, array + 1);
+assert(v[0] == 4294967295);
+  }
+}
+
 
 int main() {
   basic_test_cases();
   emplaceable_concept_tests(); // See PR34898
   test_ctor_under_alloc();
+  test_ctor_with_different_value_type();
 }
Index: libcxx/include/memory
===
--- libcxx/include/memory
+++ libcxx/include/memory
@@ -1502,6 +1502,12 @@
 typedef typename _Alloc::difference_type type;
 };
 
+template 
+struct __is_default_allocator : false_type {};
+
+template 
+struct __is_default_allocator<_VSTD::allocator<_Tp> > : true_type {};
+
 template 
 struct _LIBCPP_TEMPLATE_VIS allocator_traits
 {
@@ -1615,7 +1621,7 @@
 static
 typename enable_if
 <
-(is_same >::value
+(__is_default_allocator::value
 || !__has_construct::value) &&
  is_trivially_move_constructible<_Tp>::value,
 void
@@ -1640,23 +1646,25 @@
 construct(__a, _VSTD::__to_raw_pointer(__begin2), *__begin1);
 }
 
-template 
+template ::type,
+  class _RawDestTp = typename remove_const<_DestTp>::type>
 _LIBCPP_INLINE_VISIBILITY
 static
 typename enable_if
 <
-(is_same >::value
-|| !__has_construct::value) &&
- is_trivially_move_constructible<_Tp>::value,
+is_trivially_move_constructible<_DestTp>::value &&
+is_same<_RawSourceTp, _RawDestTp>::value &&
+(__is_default_allocator::value ||
+ !__has_construct::value),
 void
 >::type
-__construct_range_forward(allocator_type&, _Tp* __begin1, _Tp* __end1, _Tp*& __begin2)
+__construct_range_forward(allocator_type&, _SourceTp* __begin1, _SourceTp* __end1, _DestTp*& __begin2)
 {
-typedef typename remove_const<_Tp>::type _Vp;
 ptrdiff_t _Np = __end1 - __begin1;
 if (_Np > 0)
 {
-_VSTD::memcpy(const_cast<_Vp*>(__begin2), __begin1, _Np * sizeof(_Tp));
+_VSTD::memcpy(const_cast<_RawDestTp*>(__begin2), __begin1, _Np * sizeof(_DestTp));
 __begin2 += _Np;
 }
 }
@@ -1679,7 +1687,7 @@
 static
 typename enable_if
 <
-(is_same >::value
+(__is_default_allocator::value
 || !__has_construct::value) &&
  is_trivially_move_constructible<_Tp>::value,
 void
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r350571 - [OPENMP]Add call to __kmpc_push_target_tripcount() function.

2019-01-07 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Mon Jan  7 13:30:43 2019
New Revision: 350571

URL: http://llvm.org/viewvc/llvm-project?rev=350571&view=rev
Log:
[OPENMP]Add call to __kmpc_push_target_tripcount() function.

Each we create the target regions with the teams distribute inner
region, we can better estimate number of the teams required to execute
the target region. Function __kmpc_push_target_tripcount() is used for
purpose, which accepts device_id and the number of the iterations,
performed by the associated loop.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_parallel_for_codegen.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_parallel_for_if_codegen.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_parallel_for_simd_codegen.cpp

cfe/trunk/test/OpenMP/target_teams_distribute_parallel_for_simd_if_codegen.cpp
cfe/trunk/test/OpenMP/teams_distribute_codegen.cpp
cfe/trunk/test/OpenMP/teams_distribute_parallel_for_codegen.cpp
cfe/trunk/test/OpenMP/teams_distribute_parallel_for_simd_codegen.cpp
cfe/trunk/test/OpenMP/teams_distribute_simd_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=350571&r1=350570&r2=350571&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Mon Jan  7 13:30:43 2019
@@ -673,6 +673,9 @@ enum OpenMPRTLFunction {
   //
   // Offloading related calls
   //
+  // Call to void __kmpc_push_target_tripcount(int64_t device_id, kmp_uint64
+  // size);
+  OMPRTL__kmpc_push_target_tripcount,
   // Call to int32_t __tgt_target(int64_t device_id, void *host_ptr, int32_t
   // arg_num, void** args_base, void **args, size_t *arg_sizes, int64_t
   // *arg_types);
@@ -2163,6 +2166,15 @@ CGOpenMPRuntime::createRuntimeFunction(u
 FnTy, /*Name=*/"__kmpc_task_reduction_get_th_data");
 break;
   }
+  case OMPRTL__kmpc_push_target_tripcount: {
+// Build void __kmpc_push_target_tripcount(int64_t device_id, kmp_uint64
+// size);
+llvm::Type *TypeParams[] = {CGM.Int64Ty, CGM.Int64Ty};
+llvm::FunctionType *FnTy =
+llvm::FunctionType::get(CGM.VoidTy, TypeParams, /*isVarArg=*/false);
+RTLFn = CGM.CreateRuntimeFunction(FnTy, "__kmpc_push_target_tripcount");
+break;
+  }
   case OMPRTL__tgt_target: {
 // Build int32_t __tgt_target(int64_t device_id, void *host_ptr, int32_t
 // arg_num, void** args_base, void **args, size_t *arg_sizes, int64_t
@@ -8053,6 +8065,183 @@ static void emitOffloadingArraysArgument
   }
 }
 
+/// Checks if the expression is constant or does not have non-trivial function
+/// calls.
+static bool isTrivial(ASTContext &Ctx, const Expr * E) {
+  // We can skip constant expressions.
+  // We can skip expressions with trivial calls or simple expressions.
+  return (E->isEvaluatable(Ctx, Expr::SE_AllowUndefinedBehavior) ||
+  !E->hasNonTrivialCall(Ctx)) &&
+ !E->HasSideEffects(Ctx, /*IncludePossibleEffects=*/true);
+}
+
+/// Checks if the \p Body is the \a CompoundStmt and returns its child 
statement
+/// iff there is only one that is not evaluatable at the compile time.
+static const Stmt *getSingleCompoundChild(ASTContext &Ctx, const Stmt *Body) {
+  if (const auto *C = dyn_cast(Body)) {
+const Stmt *Child = nullptr;
+for (const Stmt *S : C->body()) {
+  if (const auto *E = dyn_cast(S)) {
+if (isTrivial(Ctx, E))
+  continue;
+  }
+  // Some of the statements can be ignored.
+  if (isa(S) || isa(S) || isa(S) ||
+  isa(S) || isa(S))
+continue;
+  // Analyze declarations.
+  if (const auto *DS = dyn_cast(S)) {
+if (llvm::all_of(DS->decls(), [&Ctx](const Decl *D) {
+  if (isa(D) || isa(D) ||
+  isa(D) || isa(D) ||
+  isa(D) || isa(D) ||
+  isa(D) ||
+  isa(D) ||
+  isa(D))
+return true;
+  const auto *VD = dyn_cast(D);
+  if (!VD)
+return false;
+  return VD->isConstexpr() ||
+ ((VD->getType().isTrivialType(Ctx) ||
+   VD->getType()->isReferenceType()) &&
+  (!VD->hasInit() || isTrivial(Ctx, VD->getInit(;
+}))
+  continue;
+  }
+  // Found multiple children - cannot get the one child only.
+  if (Child)
+return Body;
+  Child = S;
+}
+if (Child)
+  return Child;
+  }
+  return Body;
+}
+
+/// Check for inner distribute directive.
+static const OMPExecutableDirective *
+getNestedDistributeDirective(ASTContext &Ctx, const OMPExecutableDirective &

[PATCH] D37035: Implement __builtin_LINE() et. al. to support source location capture.

2019-01-07 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF marked 13 inline comments as done.
EricWF added a comment.

Address review comments. Updated patch coming shortly.




Comment at: include/clang/AST/Expr.h:4147
+  SourceLocation getBeginLoc() const LLVM_READONLY { return BuiltinLoc; }
+  SourceLocation getEndLoc() const LLVM_READONLY { return RParenLoc; }
+

riccibruno wrote:
> I don't think that `LLVM_READONLY` is useful here since it is just a simple 
> getter.
> Same remark for `getIdentType`, `isStringType` and `isIntType`.
> And even for `getBuiltinStr` does it actually make a difference ?
It probably doesn't make any difference. Removing.



Comment at: lib/AST/ASTContext.cpp:10145
+   unsigned Length) const {
+  // A C++ string literal has a const-qualified element type (C++ 2.13.4p1).
+  EltTy = EltTy.withConst();

riccibruno wrote:
> And what about C ? It seems to me that `getStringLiteralArrayType`
> should be used systematically when the type of a string literal is needed.
> 
> (eg in `ActOnStringLiteral` but this is not the only place...)
It should be. I'll fix it to act like `ActOnStringLiteral` and then deduplicate 
the code.



Comment at: lib/AST/Expr.cpp:1961
+// A C++ string literal has a const-qualified element type (C++ 2.13.4p1).
+if (Ctx.getLangOpts().CPlusPlus || Ctx.getLangOpts().ConstStrings)
+  Ty = Ty.withConst();

riccibruno wrote:
> Is it taking into account `adjustStringLiteralBaseType` as in 
> `getStringLiteralArrayType` ?
Nope. Fixed.



Comment at: lib/AST/Expr.cpp:2025
+  // If we have a simple identifier there is no need to cache the
+  // human readable name.
+  if (IdentifierInfo *II = FD->getDeclName().getAsIdentifierInfo())

riccibruno wrote:
> This comment is strange since MkStr will call 
> `getPredefinedStringLiteralFromCache`
> when `FD->getDeclName()` is a simple identifier.
I think this should say `compute` instead of `cache`.



Comment at: lib/AST/Expr.cpp:2037
+llvm::APSInt IntVal(
+llvm::APInt(Ctx.getTargetInfo().getIntWidth(), LineOrCol));
+return APValue(IntVal);

riccibruno wrote:
> Both `getLine`, `getColumn` and `APInt` take an unsigned.
What's your objection here? That I used `int64_t` or `getIntWidth()`? I've 
reworked this bit of code. Let me know if it's still problematic.


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

https://reviews.llvm.org/D37035



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


[PATCH] D55337: NFC: Move dumpDeclRef to NodeDumper

2019-01-07 Thread Stephen Kelly via Phabricator via cfe-commits
steveire marked an inline comment as done.
steveire added inline comments.



Comment at: include/clang/AST/TextNodeDumper.h:28
const comments::FullComment *> {
+  TextTreeStructure &TreeStructure;
   raw_ostream &OS;

steveire wrote:
> steveire wrote:
> > aaron.ballman wrote:
> > > steveire wrote:
> > > > aaron.ballman wrote:
> > > > > This makes me a bit wary because you create a node dumper in the same 
> > > > > situations you make a tree structure object, but now there's a strict 
> > > > > ordering between the two object creations. If you're doing this 
> > > > > construction local to a function, you wind up with a dangling 
> > > > > reference unless you're careful (which is unfortunate, but not the 
> > > > > end of the world). If you're doing this construction as part of a 
> > > > > constructor's initializer list, you now have to properly order the 
> > > > > member declarations within the class and that is also unfortunate. 
> > > > > Given that those are the two common scenarios for how I envision 
> > > > > constructing an ast dump of some kind, I worry about the fragility. 
> > > > > e.g.,
> > > > > ```
> > > > > unique_ptr createASTDumper(...) {
> > > > >   TextTreeStructure TreeStructure;
> > > > >   TextNodeDumper NodeDumper(TreeStructure); // Oops, dangling 
> > > > > reference
> > > > >   return make_unique(TreeStructure, 
> > > > > NodeDumper, ...);
> > > > > }
> > > > > 
> > > > > // vs
> > > > > 
> > > > > struct MySuperAwesomeASTDumper : ... {
> > > > >   MySuperAwesomeASTDumper() : TreeStructure(...), 
> > > > > NodeDumper(TreeStructure, ...) {}
> > > > > private:
> > > > >   TextTreeStructure TreeStructure; // This order is now SUPER 
> > > > > important
> > > > >   TextNodeDumper NodeDumper;
> > > > > };
> > > > > ```
> > > > > There's a part of me that wonders if a better approach is to have 
> > > > > this object passed to the `dumpFoo()` calls as a reference parameter. 
> > > > > This way, the caller is still responsible for creating an object, but 
> > > > > the creation order between the tree and the node dumper isn't as 
> > > > > fragile.
> > > > In your first snippet there is a dangling reference because the author 
> > > > of `MySuperAwesomeASTDumper` decided to make the members references. If 
> > > > the members are references, code like your first snippet will cause 
> > > > dangling references and nothing can prevent that. Adding 
> > > > `TreeStructure&` to Visit methods as you suggested does not prevent it.
> > > > 
> > > > The only solution is make the `MySuperAwesomeASTDumper` not use member 
> > > > references (ie your second snippet). The order is then in fact not 
> > > > problematic because "taking a reference to an uninitialized object is 
> > > > legal".
> > > >  The order is then in fact not problematic because "taking a reference 
> > > > to an uninitialized object is legal".
> > > 
> > > This presumes that the constructors aren't using those references to the 
> > > uninitialized object, which would be illegal. That's what I mean about 
> > > this being very fragile -- if the stars line up correctly, everything 
> > > works fine, but if the stars aren't aligned just right, you get really 
> > > hard problems to track down.
> > Actually 'the stars would have to line up in a particular way' in order to 
> > reach the scenario you are concerned about. What would have to happen is:
> > 
> > * This patch gets in as-is
> > * Someone in the future reorders the members 
> > * But they don't reorder the init-list
> > * They build on a platform without -Wreorder (only MSVC?) enabled in the 
> > build.
> > * That passes review
> > * Other users update their checkout and everyone else also ignores the 
> > -Wreorder warning.
> > 
> > That is a vanishingly likely scenario. It's just unreasonable to consider 
> > that as a reason to create a broken interface.
> > 
> > And it would be a broken interface.
> > 
> > After the refactoring is complete, we have something like 
> > 
> > ```
> > class ASTDumper
> > : public ASTDumpTraverser 
> > {
> >   TextTreeStructure TreeStructure;
> >   TextNodeDumper NodeDumper;
> > public:
> >   TextTreeStructure &getTreeStructure() { return TreeStructure; }
> >   TextNodeDumper &getNodeDumper() { return NodeDumper; }
> > 
> >   ASTDumper(raw_ostream &OS, const SourceManager *SM)
> >   : TreeStructure(OS),
> > NodeDumper(TreeStructure, OS, SM) {}
> > };
> > 
> > ```
> > 
> > In the case, of the `ASTDumper`, the `TextNodeDumper` uses the 
> > `TextTreeStructure`.
> > 
> > However, in the case of any other subclass of `ASTDumpTraverser`, the 
> > `NodeDumper` type does not depend on the `TreeStructure` type. The 
> > `ASTDumpTraverser` should not pass the `TreeStructure` to the 
> > `NodeDumper`because the `ASTDumpTraverser` should not assume the 
> > `NodeDumper` needs the `ASTDumpTraverser`. 
> > 
> > That is true in one concrete case (the `TextNo

[PATCH] D56407: Implement the TreeStructure interface through the TextNodeDumper

2019-01-07 Thread Stephen Kelly via Phabricator via cfe-commits
steveire created this revision.
steveire added reviewers: aaron.ballman, erichkeane.
Herald added a subscriber: cfe-commits.

This way, when the generic ASTTraverser is extracted from ASTDumper,
there can't be any problem related to ordering of class members, a
concern that was raised in https://reviews.llvm.org/D55337.

This will also preserve the property that the generic traverser does not
enforce any coupling between the NodeDumper and the TreeStructure.

https://godbolt.org/z/PEtT1_


Repository:
  rC Clang

https://reviews.llvm.org/D56407

Files:
  include/clang/AST/ASTDumperUtils.h
  include/clang/AST/TextNodeDumper.h
  lib/AST/ASTDumper.cpp
  lib/AST/TextNodeDumper.cpp

Index: lib/AST/TextNodeDumper.cpp
===
--- lib/AST/TextNodeDumper.cpp
+++ lib/AST/TextNodeDumper.cpp
@@ -19,8 +19,8 @@
const SourceManager *SM,
const PrintingPolicy &PrintPolicy,
const comments::CommandTraits *Traits)
-: OS(OS), ShowColors(ShowColors), SM(SM), PrintPolicy(PrintPolicy),
-  Traits(Traits) {}
+: TextTreeStructure(OS, ShowColors), OS(OS), ShowColors(ShowColors), SM(SM),
+  PrintPolicy(PrintPolicy), Traits(Traits) {}
 
 void TextNodeDumper::Visit(const comments::Comment *C,
const comments::FullComment *FC) {
Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -44,7 +44,6 @@
 public ConstCommentVisitor,
 public TypeVisitor {
 
-TextTreeStructure TreeStructure;
 TextNodeDumper NodeDumper;
 
 raw_ostream &OS;
@@ -60,7 +59,7 @@
 
 /// Dump a child of the current node.
 template void dumpChild(Fn doDumpChild) {
-  TreeStructure.addChild(doDumpChild);
+  NodeDumper.addChild(doDumpChild);
 }
 
   public:
@@ -75,8 +74,7 @@
 ASTDumper(raw_ostream &OS, const CommandTraits *Traits,
   const SourceManager *SM, bool ShowColors,
   const PrintingPolicy &PrintPolicy)
-: TreeStructure(OS, ShowColors),
-  NodeDumper(OS, ShowColors, SM, PrintPolicy, Traits), OS(OS),
+: NodeDumper(OS, ShowColors, SM, PrintPolicy, Traits), OS(OS),
   PrintPolicy(PrintPolicy), ShowColors(ShowColors) {}
 
 void setDeserialize(bool D) { Deserialize = D; }
Index: include/clang/AST/TextNodeDumper.h
===
--- include/clang/AST/TextNodeDumper.h
+++ include/clang/AST/TextNodeDumper.h
@@ -22,9 +22,94 @@
 
 namespace clang {
 
+class TextTreeStructure {
+  raw_ostream &OS;
+  const bool ShowColors;
+
+  /// Pending[i] is an action to dump an entity at level i.
+  llvm::SmallVector, 32> Pending;
+
+  /// Indicates whether we're at the top level.
+  bool TopLevel = true;
+
+  /// Indicates if we're handling the first child after entering a new depth.
+  bool FirstChild = true;
+
+  /// Prefix for currently-being-dumped entity.
+  std::string Prefix;
+
+public:
+  /// Add a child of the current node.  Calls doAddChild without arguments
+  template  void addChild(Fn doAddChild) {
+// If we're at the top level, there's nothing interesting to do; just
+// run the dumper.
+if (TopLevel) {
+  TopLevel = false;
+  doAddChild();
+  while (!Pending.empty()) {
+Pending.back()(true);
+Pending.pop_back();
+  }
+  Prefix.clear();
+  OS << "\n";
+  TopLevel = true;
+  return;
+}
+
+auto dumpWithIndent = [this, doAddChild](bool isLastChild) {
+  // Print out the appropriate tree structure and work out the prefix for
+  // children of this node. For instance:
+  //
+  //   APrefix = ""
+  //   |-B  Prefix = "| "
+  //   | `-CPrefix = "|   "
+  //   `-D  Prefix = "  "
+  // |-EPrefix = "  | "
+  // `-FPrefix = ""
+  //   GPrefix = ""
+  //
+  // Note that the first level gets no prefix.
+  {
+OS << '\n';
+ColorScope Color(OS, ShowColors, IndentColor);
+OS << Prefix << (isLastChild ? '`' : '|') << '-';
+this->Prefix.push_back(isLastChild ? ' ' : '|');
+this->Prefix.push_back(' ');
+  }
+
+  FirstChild = true;
+  unsigned Depth = Pending.size();
+
+  doAddChild();
+
+  // If any children are left, they're the last at their nesting level.
+  // Dump those ones out now.
+  while (Depth < Pending.size()) {
+Pending.back()(true);
+this->Pending.pop_back();
+  }
+
+  // Restore the old prefix.
+  this->Prefix.resize(Prefix.size() - 2);
+};
+
+if (FirstChild) {
+  Pending.push_back(std::move(dumpWithIndent));
+} else {
+  Pending.back()(false);
+  Pending.back() = std::move(dumpWithIndent);
+}
+FirstChild = false;
+  }
+
+  TextTreeStr

[PATCH] D56354: [AST] Replace asserts with if() in SourceLocation accessors

2019-01-07 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 a formatting nit.




Comment at: include/clang/AST/DeclarationName.h:735
+   Name.getNameKind() != DeclarationName::CXXConversionFunctionName)
+  return nullptr;
 return LocInfo.NamedType.TInfo;

steveire wrote:
> aaron.ballman wrote:
> > Did you investigate the callers of this function to see which ones need a 
> > null pointer check inserted into them? Otherwise, this change turns an 
> > assertion into harder to track down UB. (I'm less worried about the other 
> > changes because those will fail more gracefully.)
> All callers in clang are fine. Here's the output of `git grep -h 
> TypeSourceInfo`:
> 
>   /// getNamedTypeInfo - Returns the source type info associated to
>   TypeSourceInfo *getNamedTypeInfo() const {
> if (TypeSourceInfo *TSInfo = NameInfo.getNamedTypeInfo())
> if (auto ToTInfoOrErr = import(From.getNamedTypeInfo()))
>   if (auto TypeNameInfo = Dtor->getNameInfo().getNamedTypeInfo()) {
> if (TypeSourceInfo *TSInfo = NameInfo.getNamedTypeInfo())
> if (TypeSourceInfo *OldTInfo = NameInfo.getNamedTypeInfo()) {
> if (TypeSourceInfo *TSInfo = Name.getNamedTypeInfo())
> 
> clang-tools-extra has no uses of it. Is there anywhere else to check?
> 
I double-checked the call to `import()` and it gracefully handles null pointers 
as well, so I think this change is safe (I cannot find any further instances 
that you didn't find). Thank you for looking into it!



Comment at: lib/AST/NestedNameSpecifier.cpp:465
 TypeLoc NestedNameSpecifierLoc::getTypeLoc() const {
-  assert((Qualifier->getKind() == NestedNameSpecifier::TypeSpec ||
-  Qualifier->getKind() == NestedNameSpecifier::TypeSpecWithTemplate) &&
- "Nested-name-specifier location is not a type");
+  if ((Qualifier->getKind() != NestedNameSpecifier::TypeSpec &&
+  Qualifier->getKind() != NestedNameSpecifier::TypeSpecWithTemplate))

aaron.ballman wrote:
> Remove spurious parens.
Formatting is still off here for the second line of the if statement (one too 
many spaces on the indentation).


Repository:
  rC Clang

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

https://reviews.llvm.org/D56354



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


r350568 - Recommit r350555 "[X86] Use funnel shift intrinsics for the VBMI2 vshld/vshrd builtins."

2019-01-07 Thread Craig Topper via cfe-commits
Author: ctopper
Date: Mon Jan  7 13:00:41 2019
New Revision: 350568

URL: http://llvm.org/viewvc/llvm-project?rev=350568&view=rev
Log:
Recommit r350555 "[X86] Use funnel shift intrinsics for the VBMI2 vshld/vshrd 
builtins."

The MSVC limit hit in AutoUpgrade.cpp has been worked around for now.

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Headers/avx512vbmi2intrin.h
cfe/trunk/lib/Headers/avx512vlvbmi2intrin.h
cfe/trunk/test/CodeGen/avx512vbmi2-builtins.c
cfe/trunk/test/CodeGen/avx512vlvbmi2-builtins.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=350568&r1=350567&r2=350568&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Mon Jan  7 13:00:41 2019
@@ -1256,43 +1256,25 @@ TARGET_BUILTIN(__builtin_ia32_vpshldw128
 TARGET_BUILTIN(__builtin_ia32_vpshldw256, "V16sV16sV16sIi", "ncV:256:", 
"avx512vl,avx512vbmi2")
 TARGET_BUILTIN(__builtin_ia32_vpshldw512, "V32sV32sV32sIi", "ncV:512:", 
"avx512vbmi2")
 
-TARGET_BUILTIN(__builtin_ia32_vpshldvd128_mask, "V4iV4iV4iV4iUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd256_mask, "V8iV8iV8iV8iUc", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd512_mask, "V16iV16iV16iV16iUs", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq128_mask, "V2LLiV2LLiV2LLiV2LLiUc", 
"ncV:128:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq256_mask, "V4LLiV4LLiV4LLiV4LLiUc", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq512_mask, "V8LLiV8LLiV8LLiV8LLiUc", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw128_mask, "V8sV8sV8sV8sUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw256_mask, "V16sV16sV16sV16sUs", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw512_mask, "V32sV32sV32sV32sUi", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd128_maskz, "V4iV4iV4iV4iUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd256_maskz, "V8iV8iV8iV8iUc", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd512_maskz, "V16iV16iV16iV16iUs", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq128_maskz, "V2LLiV2LLiV2LLiV2LLiUc", 
"ncV:128:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq256_maskz, "V4LLiV4LLiV4LLiV4LLiUc", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq512_maskz, "V8LLiV8LLiV8LLiV8LLiUc", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw128_maskz, "V8sV8sV8sV8sUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw256_maskz, "V16sV16sV16sV16sUs", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw512_maskz, "V32sV32sV32sV32sUi", 
"ncV:512:", "avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd128, "V4iV4iV4iV4i", "ncV:128:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd256, "V8iV8iV8iV8i", "ncV:256:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd512, "V16iV16iV16iV16i", "ncV:512:", 
"avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq128, "V2LLiV2LLiV2LLiV2LLi", "ncV:128:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq256, "V4LLiV4LLiV4LLiV4LLi", "ncV:256:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq512, "V8LLiV8LLiV8LLiV8LLi", "ncV:512:", 
"avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw128, "V8sV8sV8sV8s", "ncV:128:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw256, "V16sV16sV16sV16s", "ncV:256:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw512, "V32sV32sV32sV32s", "ncV:512:", 
"avx512vbmi2")
 
-TARGET_BUILTIN(__builtin_ia32_vpshrdvd128_mask, "V4iV4iV4iV4iUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvd256_mask, "V8iV8iV8iV8iUc", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvd512_mask, "V16iV16iV16iV16iUs", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvq128_mask, "V2LLiV2LLiV2LLiV2LLiUc", 
"ncV:128:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvq256_mask, "V4LLiV4LLiV4LLiV4LLiUc", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvq512_mask, "V8LLiV8LLiV8LLiV8LLiUc", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvw128_mask, "V8sV8sV8sV8sUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvw256_mask, "V16sV16sV16sV16sUs", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvw512_mask, "V32sV32sV32sV32sUi", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__built

[PATCH] D56354: [AST] Replace asserts with if() in SourceLocation accessors

2019-01-07 Thread Stephen Kelly via Phabricator via cfe-commits
steveire marked an inline comment as done.
steveire added inline comments.



Comment at: include/clang/AST/DeclarationName.h:735
+   Name.getNameKind() != DeclarationName::CXXConversionFunctionName)
+  return nullptr;
 return LocInfo.NamedType.TInfo;

aaron.ballman wrote:
> Did you investigate the callers of this function to see which ones need a 
> null pointer check inserted into them? Otherwise, this change turns an 
> assertion into harder to track down UB. (I'm less worried about the other 
> changes because those will fail more gracefully.)
All callers in clang are fine. Here's the output of `git grep -h 
TypeSourceInfo`:

  /// getNamedTypeInfo - Returns the source type info associated to
  TypeSourceInfo *getNamedTypeInfo() const {
if (TypeSourceInfo *TSInfo = NameInfo.getNamedTypeInfo())
if (auto ToTInfoOrErr = import(From.getNamedTypeInfo()))
  if (auto TypeNameInfo = Dtor->getNameInfo().getNamedTypeInfo()) {
if (TypeSourceInfo *TSInfo = NameInfo.getNamedTypeInfo())
if (TypeSourceInfo *OldTInfo = NameInfo.getNamedTypeInfo()) {
if (TypeSourceInfo *TSInfo = Name.getNamedTypeInfo())

clang-tools-extra has no uses of it. Is there anywhere else to check?



Repository:
  rC Clang

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

https://reviews.llvm.org/D56354



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


[PATCH] D56354: [AST] Replace asserts with if() in SourceLocation accessors

2019-01-07 Thread Stephen Kelly via Phabricator via cfe-commits
steveire updated this revision to Diff 180548.
steveire added a comment.

Fix formatting


Repository:
  rC Clang

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

https://reviews.llvm.org/D56354

Files:
  include/clang/AST/DeclarationName.h
  include/clang/AST/TemplateBase.h
  lib/AST/NestedNameSpecifier.cpp


Index: lib/AST/NestedNameSpecifier.cpp
===
--- lib/AST/NestedNameSpecifier.cpp
+++ lib/AST/NestedNameSpecifier.cpp
@@ -462,9 +462,9 @@
 }
 
 TypeLoc NestedNameSpecifierLoc::getTypeLoc() const {
-  assert((Qualifier->getKind() == NestedNameSpecifier::TypeSpec ||
-  Qualifier->getKind() == NestedNameSpecifier::TypeSpecWithTemplate) &&
- "Nested-name-specifier location is not a type");
+  if (Qualifier->getKind() != NestedNameSpecifier::TypeSpec &&
+   Qualifier->getKind() != NestedNameSpecifier::TypeSpecWithTemplate)
+return TypeLoc();
 
   // The "void*" that points at the TypeLoc data.
   unsigned Offset = getDataLength(Qualifier->getPrefix());
Index: include/clang/AST/TemplateBase.h
===
--- include/clang/AST/TemplateBase.h
+++ include/clang/AST/TemplateBase.h
@@ -530,19 +530,22 @@
   }
 
   NestedNameSpecifierLoc getTemplateQualifierLoc() const {
-assert(Argument.getKind() == TemplateArgument::Template ||
-   Argument.getKind() == TemplateArgument::TemplateExpansion);
+if (Argument.getKind() != TemplateArgument::Template &&
+Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return NestedNameSpecifierLoc();
 return LocInfo.getTemplateQualifierLoc();
   }
 
   SourceLocation getTemplateNameLoc() const {
-assert(Argument.getKind() == TemplateArgument::Template ||
-   Argument.getKind() == TemplateArgument::TemplateExpansion);
+if (Argument.getKind() != TemplateArgument::Template &&
+Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return SourceLocation();
 return LocInfo.getTemplateNameLoc();
   }
 
   SourceLocation getTemplateEllipsisLoc() const {
-assert(Argument.getKind() == TemplateArgument::TemplateExpansion);
+if (Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return SourceLocation();
 return LocInfo.getTemplateEllipsisLoc();
   }
 };
Index: include/clang/AST/DeclarationName.h
===
--- include/clang/AST/DeclarationName.h
+++ include/clang/AST/DeclarationName.h
@@ -729,9 +729,10 @@
   /// getNamedTypeInfo - Returns the source type info associated to
   /// the name. Assumes it is a constructor, destructor or conversion.
   TypeSourceInfo *getNamedTypeInfo() const {
-assert(Name.getNameKind() == DeclarationName::CXXConstructorName ||
-   Name.getNameKind() == DeclarationName::CXXDestructorName ||
-   Name.getNameKind() == DeclarationName::CXXConversionFunctionName);
+if (Name.getNameKind() != DeclarationName::CXXConstructorName &&
+Name.getNameKind() != DeclarationName::CXXDestructorName &&
+Name.getNameKind() != DeclarationName::CXXConversionFunctionName)
+  return nullptr;
 return LocInfo.NamedType.TInfo;
   }
 
@@ -747,7 +748,8 @@
   /// getCXXOperatorNameRange - Gets the range of the operator name
   /// (without the operator keyword). Assumes it is a (non-literal) operator.
   SourceRange getCXXOperatorNameRange() const {
-assert(Name.getNameKind() == DeclarationName::CXXOperatorName);
+if (Name.getNameKind() != DeclarationName::CXXOperatorName)
+  return SourceRange();
 return SourceRange(
  
SourceLocation::getFromRawEncoding(LocInfo.CXXOperatorName.BeginOpNameLoc),
  SourceLocation::getFromRawEncoding(LocInfo.CXXOperatorName.EndOpNameLoc)
@@ -766,7 +768,8 @@
   /// operator name (not the operator keyword).
   /// Assumes it is a literal operator.
   SourceLocation getCXXLiteralOperatorNameLoc() const {
-assert(Name.getNameKind() == DeclarationName::CXXLiteralOperatorName);
+if (Name.getNameKind() != DeclarationName::CXXLiteralOperatorName)
+  return SourceLocation();
 return SourceLocation::
   getFromRawEncoding(LocInfo.CXXLiteralOperatorName.OpNameLoc);
   }


Index: lib/AST/NestedNameSpecifier.cpp
===
--- lib/AST/NestedNameSpecifier.cpp
+++ lib/AST/NestedNameSpecifier.cpp
@@ -462,9 +462,9 @@
 }
 
 TypeLoc NestedNameSpecifierLoc::getTypeLoc() const {
-  assert((Qualifier->getKind() == NestedNameSpecifier::TypeSpec ||
-  Qualifier->getKind() == NestedNameSpecifier::TypeSpecWithTemplate) &&
- "Nested-name-specifier location is not a type");
+  if (Qualifier->getKind() != NestedNameSpecifier::TypeSpec &&
+   Qualifier->getKind() != NestedNameSpecifier::TypeSpecWithTemplate)
+return TypeLoc();
 
   // The "void*" that points at the TypeLoc data.
   unsigned Offset = ge

[PATCH] D56391: Limit COFF 'common' emission to <=32 alignment types.

2019-01-07 Thread David Majnemer via Phabricator via cfe-commits
majnemer added inline comments.



Comment at: lib/CodeGen/CodeGenModule.cpp:3766
+  // in common.
+  if (Context.getTargetInfo().getTriple().isOSBinFormatCOFF() &&
+  Context.getTypeAlignIfKnown(D->getType()) > 32)

I think this should be isKnownWindowsMSVCEnvironment


Repository:
  rC Clang

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

https://reviews.llvm.org/D56391



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


[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

2019-01-07 Thread Ed Maste via Phabricator via cfe-commits
emaste added a comment.

> There is a list of 140-150 unsafe (LLD_UNSAFE) packages with LLD.

Some of these are tagged with a PR or comment explaining why they are 
LLD_UNSAFE, but we haven't done it consistently. Some of these 140-150 were 
probably added in the early days of bringing lld into FreeBSD, and added 
without much thought - some could be as easy as differences in -ztext/-znotext 
default.


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

https://reviews.llvm.org/D56215



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


[PATCH] D55948: Modify DeclaratorChuck::getFunction to use DeclSpec for qualifiers

2019-01-07 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Thanks!  LGTM.


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

https://reviews.llvm.org/D55948



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


[PATCH] D56288: [ELF] Do not enable 'new dtags' on NetBSD by default

2019-01-07 Thread Kamil Rytarowski via Phabricator via cfe-commits
krytarowski added a comment.

On NetBSD the 'new' semantics was already implemented with 'old' RPATH. I don't 
know the timing whether there already existed RUNPATH, but the result is that 
we never implemented it and never needed it.  The core of NetBSD was convinced 
to add an alias as it was very difficult in some examples (probably due to 
Rust) to rollback to 'old' RPATH.

I don't have any complains against lld developers, the only ones are against 
the NetBSD community that we are forced to be out of the lld development. It 
would be addressed already long time and probably RUNPATH wouldn't be leaked 
into executables shipped to NetBSD in the first place... it's counter-effective 
attitude to be in opposition to use lld on philosophical principle.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56288



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


[libclc] r350565 - cmake: Install libraries to DATADIR from GNUInstallDirs

2019-01-07 Thread Jan Vesely via cfe-commits
Author: jvesely
Date: Mon Jan  7 12:20:37 2019
New Revision: 350565

URL: http://llvm.org/viewvc/llvm-project?rev=350565&view=rev
Log:
cmake: Install libraries to DATADIR from GNUInstallDirs

This moves default installation location to /usr/share to match libclc.pc.
Signed-off-by: Jan Vesely 
Reviewer: Tom Stellard

Modified:
libclc/trunk/CMakeLists.txt
libclc/trunk/libclc.pc.in

Modified: libclc/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/CMakeLists.txt?rev=350565&r1=350564&r2=350565&view=diff
==
--- libclc/trunk/CMakeLists.txt (original)
+++ libclc/trunk/CMakeLists.txt Mon Jan  7 12:20:37 2019
@@ -1,6 +1,7 @@
 cmake_minimum_required( VERSION 3.9.2 )
 
 project( libclc VERSION 0.2.0 LANGUAGES CXX )
+include( GNUInstallDirs )
 
 # List of all targets
 set( LIBCLC_TARGETS_ALL
@@ -145,8 +146,8 @@ endif()
 
 # pkg-config file
 configure_file( libclc.pc.in libclc.pc @ONLY )
-install( FILES ${CMAKE_CURRENT_BINARY_DIR}/libclc.pc DESTINATION 
share/pkgconfig )
-install( DIRECTORY generic/include/clc DESTINATION include )
+install( FILES ${CMAKE_CURRENT_BINARY_DIR}/libclc.pc DESTINATION 
${CMAKE_INSTALL_DATADIR}/pkgconfig )
+install( DIRECTORY generic/include/clc DESTINATION ${CMAKE_INSTALL_INCLUDEDIR} 
)
 
 if( ENABLE_RUNTIME_SUBNORMAL )
add_library( subnormal_use_default STATIC
@@ -154,7 +155,7 @@ if( ENABLE_RUNTIME_SUBNORMAL )
add_library( subnormal_disable STATIC
generic/lib/subnormal_disable.ll )
install( TARGETS subnormal_use_default subnormal_disable ARCHIVE
-   DESTINATION lib/clc )
+   DESTINATION ${CMAKE_INSTALL_DATADIR}/clc )
 endif()
 
 find_program( PYTHON python )
@@ -274,7 +275,7 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
prepare_builtins )
add_custom_target( "prepare-${obj_suffix}" ALL
   DEPENDS "${obj_suffix}" )
-   install( FILES ${CMAKE_CURRENT_BINARY_DIR}/${obj_suffix} 
DESTINATION lib/clc )
+   install( FILES ${CMAKE_CURRENT_BINARY_DIR}/${obj_suffix} 
DESTINATION ${CMAKE_INSTALL_DATADIR}/clc )
# nvptx-- targets don't include workitem builtins
if( NOT ${t} MATCHES ".*ptx.*--$" )
add_test( NAME external-calls-${obj_suffix}
@@ -292,7 +293,7 @@ foreach( t ${LIBCLC_TARGETS_TO_BUILD} )
   create_symlink ${obj_suffix}
   ${alias_suffix}
   DEPENDS "prepare-${obj_suffix}" )
-   install( FILES 
${CMAKE_CURRENT_BINARY_DIR}/${alias_suffix} DESTINATION lib/clc )
+   install( FILES 
${CMAKE_CURRENT_BINARY_DIR}/${alias_suffix} DESTINATION 
${CMAKE_INSTALL_DATADIR}/clc )
endforeach( a )
endforeach( d )
 endforeach( t )

Modified: libclc/trunk/libclc.pc.in
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/libclc.pc.in?rev=350565&r1=350564&r2=350565&view=diff
==
--- libclc/trunk/libclc.pc.in (original)
+++ libclc/trunk/libclc.pc.in Mon Jan  7 12:20:37 2019
@@ -1,5 +1,5 @@
-includedir=@CMAKE_INSTALL_PREFIX@/include
-libexecdir=@CMAKE_INSTALL_PREFIX@/lib/clc
+includedir=@CMAKE_INSTALL_PREFIX@/@CMAKE_INSTALL_INCLUDEDIR@
+libexecdir=@CMAKE_INSTALL_PREFIX@/@CMAKE_INSTALL_DATADIR@/clc
 
 Name: libclc
 Description: Library requirements of the OpenCL C programming language


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


[PATCH] D56405: Split -Wdelete-non-virtual-dtor into two groups

2019-01-07 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington created this revision.
erik.pilkington added reviewers: rsmith, aaron.ballman.
Herald added subscribers: dexonsmith, jkorous.

`-Wdelete-non-virtual-dtor` controlled two diagnostics: 1) calling a 
non-virtual dtor from an abstract class, and 2) calling a non-virtual dtor from 
a polymorphic class. 1) is a lot more severe than 2), since 1) is a guaranteed 
crash, but 2) is just "code smell". Previously, projects compiled with `-Wall 
-Wno-delete-non-virtual-dtor`, which is somewhat reasonable, silently crashed 
on 1).

rdar://40380564

Thanks for taking a look!


Repository:
  rC Clang

https://reviews.llvm.org/D56405

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/test/SemaCXX/non-virtual-dtors.cpp


Index: clang/test/SemaCXX/non-virtual-dtors.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/non-virtual-dtors.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 %s -verify -DDIAG1
+// RUN: %clang_cc1 %s -verify -DDIAG1 -DDIAG2 -Wdelete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -DDIAG1 -Wmost 
-Wno-delete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -Wmost 
-Wno-delete-abstract-non-virtual-dtor
+
+#ifndef DIAG1
+#ifndef DIAG2
+// expected-no-diagnostics
+#endif
+#endif
+
+struct S1 {
+  ~S1() {}
+  virtual void abs() = 0;
+};
+
+void f1(S1 *s1) { delete s1; }
+#ifdef DIAG1
+// expected-warning@-2 {{delete called on 'S1' that is abstract but has 
non-virtual destructor}}
+#endif
+
+struct Base {
+  virtual void abs() = 0;
+};
+struct S2 : Base {
+  ~S2() {}
+  void abs() {}
+};
+void f2(S2 *s2) { delete s2; }
+#ifdef DIAG2
+// expected-warning@-2 {{delete called on non-final 'S2' that has virtual 
functions but non-virtual destructor}}
+#endif
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6460,7 +6460,7 @@
   "qualify call to silence this warning">;
 def warn_delete_abstract_non_virtual_dtor : Warning<
   "%select{delete|destructor}0 called on %1 that is abstract but has "
-  "non-virtual destructor">, InGroup, ShowInSystemHeader;
+  "non-virtual destructor">, InGroup, 
ShowInSystemHeader;
 def warn_overloaded_virtual : Warning<
   "%q0 hides overloaded virtual %select{function|functions}1">,
   InGroup, DefaultIgnore;
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -105,6 +105,8 @@
 
 def DeleteIncomplete : DiagGroup<"delete-incomplete">;
 def DeleteNonVirtualDtor : DiagGroup<"delete-non-virtual-dtor">;
+def DeleteAbstractNonVirtualDtor : 
DiagGroup<"delete-abstract-non-virtual-dtor",
+ [DeleteNonVirtualDtor]>;
 def AbstractFinalClass : DiagGroup<"abstract-final-class">;
 
 def CXX11CompatDeprecatedWritableStr :


Index: clang/test/SemaCXX/non-virtual-dtors.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/non-virtual-dtors.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 %s -verify -DDIAG1
+// RUN: %clang_cc1 %s -verify -DDIAG1 -DDIAG2 -Wdelete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -DDIAG1 -Wmost -Wno-delete-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -Wmost -Wno-delete-abstract-non-virtual-dtor
+
+#ifndef DIAG1
+#ifndef DIAG2
+// expected-no-diagnostics
+#endif
+#endif
+
+struct S1 {
+  ~S1() {}
+  virtual void abs() = 0;
+};
+
+void f1(S1 *s1) { delete s1; }
+#ifdef DIAG1
+// expected-warning@-2 {{delete called on 'S1' that is abstract but has non-virtual destructor}}
+#endif
+
+struct Base {
+  virtual void abs() = 0;
+};
+struct S2 : Base {
+  ~S2() {}
+  void abs() {}
+};
+void f2(S2 *s2) { delete s2; }
+#ifdef DIAG2
+// expected-warning@-2 {{delete called on non-final 'S2' that has virtual functions but non-virtual destructor}}
+#endif
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6460,7 +6460,7 @@
   "qualify call to silence this warning">;
 def warn_delete_abstract_non_virtual_dtor : Warning<
   "%select{delete|destructor}0 called on %1 that is abstract but has "
-  "non-virtual destructor">, InGroup, ShowInSystemHeader;
+  "non-virtual destructor">, InGroup, ShowInSystemHeader;
 def warn_overloaded_virtual : Warning<
   "%q0 hides overloaded virtual %select{function|functions}1">,
   InGroup, DefaultIgnore;
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/Diagnostic

[PATCH] D55662: [Sema][ObjC] Do not warn about repeated uses of weak variables when the variables are accessed in an unevaluated context.

2019-01-07 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

If it's at all reasonable to just avoid doing the work multiple times, let's do 
that.  It should also avoid duplicate diagnostics if e.g. an overload is 
resolved to an unavailable function.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55662



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


[PATCH] D56066: [OpenCL] Address space for default class members

2019-01-07 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: lib/Sema/SemaInit.cpp:4539
+  if (InitCategory.isPRValue() || InitCategory.isXValue())
+T1Quals.removeAddressSpace();
+

ebevhan wrote:
> rjmccall wrote:
> > rjmccall wrote:
> > > I can understand why a pr-value wouldn't have an address space, but an 
> > > x-value's address space is surely important.
> > No, wait, I think this is more deeply wrong.  We're initializing a 
> > reference to type `cv1 T1`, and if we're initializing it with a temporary, 
> > we're dropping the address space from `cv1`?  That's definitely wrong.
> > 
> > If we're starting with a pr-value, reference-initialization normally has to 
> > start by initializing a temporary.  (The exception is it's a class type 
> > with a conversion operator to a reference type; C++ is abysmally 
> > complicated.  Let's ignore this for a moment.)  Temporaries are always in 
> > the default address space (the address space of local variables) because 
> > the language (neither OpenCL nor Embedded C) does not give us any facility 
> > for allocating temporary memory anywhere else.  So reference-initialization 
> > from a pr-value creates a temporary in the default address space and then 
> > attempts to initialize the destination reference type with that temporary.  
> > That initialization should fail if there's no conversion from the default 
> > address space to the destination address space.  For example, consider 
> > initializing a `const int __global &` from a pr-value: this should clearly 
> > not succeed, because we have no way of putting a temporary in the global 
> > address space.  That reference can only be initialized with a gl-value 
> > that's already in the `__global` address space.
> > 
> > On the other hand, we can successfully initialize a `const int &` with a 
> > gl-value of type `const int __global` not by direct reference 
> > initialization but by loading from the operand and then materializing the 
> > result into a new temporary.
> > 
> > I think what this means is:
> > 
> > - We need to be doing this checking as if pr-values were in `__private`.  
> > This includes both (1) expressions that were originally pr-values and (2) 
> > expressions that have been converted to pr-values due to a failure to 
> > perform direct reference initialization.
> > 
> > - We need to make sure that reference compatibility correctly prevents 
> > references from being bound to gl-values in incompatible address spaces.
> > On the other hand, we can successfully initialize a `const int &` with a 
> > gl-value of type `const int __global` not by direct reference 
> > initialization but by loading from the operand and then materializing the 
> > result into a new temporary.
> 
> Is this the right thing to do? It means that initializing such a reference 
> would incur a cost under the hood that might be unnoticed/unwanted by the 
> user. 
Hmm.  I was going to say that it's consistent with the normal behavior of C++, 
but looking at the actual rule, it's more complicated than that: C++ will only 
do this if the types are not reference-related or if the gl-value is a 
bit-field.  So this would only be allowed if the reference type was e.g. `const 
long &`.  It's a strange rule, but it's straightforward to stay consistent with 
it.

I think we will eventually find ourselves needing a special-case rule for 
copy-initializing and copy-assigning trivially-copyable types, but we're not 
there yet.


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

https://reviews.llvm.org/D56066



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


[PATCH] D55662: [Sema][ObjC] Do not warn about repeated uses of weak variables when the variables are accessed in an unevaluated context.

2019-01-07 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added a comment.

We can make `DeduceVariableDeclarationType` return the rewritten expression and 
replace `Init` in `Sema::AddInitializerToDecl` with it.

Alternatively, we can keep a set of `ObjCPropertyRefExpr`s passed to 
`recordUseOfWeak` (the original `ObjCPropertyRefExpr`, if it was rebuilt in 
SemaPseudoObject.cpp) and avoid recording the use of a weak variable if the 
expression is passed the second time.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55662



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


r350563 - Revert r350555 "[X86] Use funnel shift intrinsics for the VBMI2 vshld/vshrd builtins."

2019-01-07 Thread Craig Topper via cfe-commits
Author: ctopper
Date: Mon Jan  7 11:39:25 2019
New Revision: 350563

URL: http://llvm.org/viewvc/llvm-project?rev=350563&view=rev
Log:
Revert r350555 "[X86] Use funnel shift intrinsics for the VBMI2 vshld/vshrd 
builtins."

Had to revert the LLVM patch this depends on to fix a MSVC compiler limit in 
AutoUpgrade.cpp

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Headers/avx512vbmi2intrin.h
cfe/trunk/lib/Headers/avx512vlvbmi2intrin.h
cfe/trunk/test/CodeGen/avx512vbmi2-builtins.c
cfe/trunk/test/CodeGen/avx512vlvbmi2-builtins.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=350563&r1=350562&r2=350563&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Mon Jan  7 11:39:25 2019
@@ -1256,25 +1256,43 @@ TARGET_BUILTIN(__builtin_ia32_vpshldw128
 TARGET_BUILTIN(__builtin_ia32_vpshldw256, "V16sV16sV16sIi", "ncV:256:", 
"avx512vl,avx512vbmi2")
 TARGET_BUILTIN(__builtin_ia32_vpshldw512, "V32sV32sV32sIi", "ncV:512:", 
"avx512vbmi2")
 
-TARGET_BUILTIN(__builtin_ia32_vpshldvd128, "V4iV4iV4iV4i", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd256, "V8iV8iV8iV8i", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd512, "V16iV16iV16iV16i", "ncV:512:", 
"avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq128, "V2LLiV2LLiV2LLiV2LLi", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq256, "V4LLiV4LLiV4LLiV4LLi", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq512, "V8LLiV8LLiV8LLiV8LLi", "ncV:512:", 
"avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw128, "V8sV8sV8sV8s", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw256, "V16sV16sV16sV16s", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw512, "V32sV32sV32sV32s", "ncV:512:", 
"avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd128_mask, "V4iV4iV4iV4iUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd256_mask, "V8iV8iV8iV8iUc", "ncV:256:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd512_mask, "V16iV16iV16iV16iUs", 
"ncV:512:", "avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq128_mask, "V2LLiV2LLiV2LLiV2LLiUc", 
"ncV:128:", "avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq256_mask, "V4LLiV4LLiV4LLiV4LLiUc", 
"ncV:256:", "avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq512_mask, "V8LLiV8LLiV8LLiV8LLiUc", 
"ncV:512:", "avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw128_mask, "V8sV8sV8sV8sUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw256_mask, "V16sV16sV16sV16sUs", 
"ncV:256:", "avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw512_mask, "V32sV32sV32sV32sUi", 
"ncV:512:", "avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd128_maskz, "V4iV4iV4iV4iUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd256_maskz, "V8iV8iV8iV8iUc", "ncV:256:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd512_maskz, "V16iV16iV16iV16iUs", 
"ncV:512:", "avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq128_maskz, "V2LLiV2LLiV2LLiV2LLiUc", 
"ncV:128:", "avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq256_maskz, "V4LLiV4LLiV4LLiV4LLiUc", 
"ncV:256:", "avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq512_maskz, "V8LLiV8LLiV8LLiV8LLiUc", 
"ncV:512:", "avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw128_maskz, "V8sV8sV8sV8sUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw256_maskz, "V16sV16sV16sV16sUs", 
"ncV:256:", "avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw512_maskz, "V32sV32sV32sV32sUi", 
"ncV:512:", "avx512vbmi2")
 
-TARGET_BUILTIN(__builtin_ia32_vpshrdvd128, "V4iV4iV4iV4i", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvd256, "V8iV8iV8iV8i", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvd512, "V16iV16iV16iV16i", "ncV:512:", 
"avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvq128, "V2LLiV2LLiV2LLiV2LLi", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvq256, "V4LLiV4LLiV4LLiV4LLi", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvq512, "V8LLiV8LLiV8LLiV8LLi", "ncV:512:", 
"avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvw128, "V8sV8sV8sV8s", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvw256, "V16sV16sV16sV16s", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvw512, "V32sV32sV32sV32s", "ncV:512:", 
"avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshrdvd128_mask, "V4iV4iV4iV4iUc

[PATCH] D56367: [AST] Pack CXXDependentScopeMemberExpr

2019-01-07 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Okay.  That comment seems reasonable.  Glad to hear you're on top of it. :)


Repository:
  rC Clang

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

https://reviews.llvm.org/D56367



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


[PATCH] D56288: [ELF] Do not enable 'new dtags' on NetBSD by default

2019-01-07 Thread Rui Ueyama via Phabricator via cfe-commits
ruiu added a comment.

I think when we implemented the feature, there was an understanding that the 
"new dtags" might be "new" 20 years ago but they are not new at all now. This 
is not the only example of changing the default in lld; one example being that 
text segments are not writable by default (`-z text` is default as opposed to 
`-z notext`).

We could argue that making the text segment writable is a total nonsense today, 
but new/old dtags are different story. Bug even if that's the case, changing 
the default at this point has perhaps too much impact to existing lld users.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D56288



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


[PATCH] D56365: [X86] Use funnel shift intrinsics for the VBMI2 vshld/vshrd builtins.

2019-01-07 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL350555: [X86] Use funnel shift intrinsics for the VBMI2 
vshld/vshrd builtins. (authored by ctopper, committed by ).

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56365

Files:
  cfe/trunk/include/clang/Basic/BuiltinsX86.def
  cfe/trunk/lib/CodeGen/CGBuiltin.cpp
  cfe/trunk/lib/Headers/avx512vbmi2intrin.h
  cfe/trunk/lib/Headers/avx512vlvbmi2intrin.h
  cfe/trunk/test/CodeGen/avx512vbmi2-builtins.c
  cfe/trunk/test/CodeGen/avx512vlvbmi2-builtins.c

Index: cfe/trunk/lib/Headers/avx512vlvbmi2intrin.h
===
--- cfe/trunk/lib/Headers/avx512vlvbmi2intrin.h
+++ cfe/trunk/lib/Headers/avx512vlvbmi2intrin.h
@@ -421,327 +421,279 @@
   (__v8hi)_mm_setzero_si128())
 
 static __inline__ __m256i __DEFAULT_FN_ATTRS256
-_mm256_mask_shldv_epi64(__m256i __S, __mmask8 __U, __m256i __A, __m256i __B)
+_mm256_shldv_epi64(__m256i __A, __m256i __B, __m256i __C)
 {
-  return (__m256i) __builtin_ia32_vpshldvq256_mask ((__v4di) __S,
-  (__v4di) __A,
-  (__v4di) __B,
-  __U);
+  return (__m256i)__builtin_ia32_vpshldvq256((__v4di)__A, (__v4di)__B,
+ (__v4di)__C);
 }
 
 static __inline__ __m256i __DEFAULT_FN_ATTRS256
-_mm256_maskz_shldv_epi64(__mmask8 __U, __m256i __S, __m256i __A, __m256i __B)
+_mm256_mask_shldv_epi64(__m256i __A, __mmask8 __U, __m256i __B, __m256i __C)
 {
-  return (__m256i) __builtin_ia32_vpshldvq256_maskz ((__v4di) __S,
-  (__v4di) __A,
-  (__v4di) __B,
-  __U);
+  return (__m256i)__builtin_ia32_selectq_256(__U,
+  (__v4di)_mm256_shldv_epi64(__A, __B, __C),
+  (__v4di)__A);
 }
 
 static __inline__ __m256i __DEFAULT_FN_ATTRS256
-_mm256_shldv_epi64(__m256i __S, __m256i __A, __m256i __B)
+_mm256_maskz_shldv_epi64(__mmask8 __U, __m256i __A, __m256i __B, __m256i __C)
 {
-  return (__m256i) __builtin_ia32_vpshldvq256_mask ((__v4di) __S,
-  (__v4di) __A,
-  (__v4di) __B,
-  (__mmask8) -1);
+  return (__m256i)__builtin_ia32_selectq_256(__U,
+  (__v4di)_mm256_shldv_epi64(__A, __B, __C),
+  (__v4di)_mm256_setzero_si256());
 }
 
 static __inline__ __m128i __DEFAULT_FN_ATTRS128
-_mm_mask_shldv_epi64(__m128i __S, __mmask8 __U, __m128i __A, __m128i __B)
+_mm_shldv_epi64(__m128i __A, __m128i __B, __m128i __C)
 {
-  return (__m128i) __builtin_ia32_vpshldvq128_mask ((__v2di) __S,
-  (__v2di) __A,
-  (__v2di) __B,
-  __U);
+  return (__m128i)__builtin_ia32_vpshldvq128((__v2di)__A, (__v2di)__B,
+ (__v2di)__C);
 }
 
 static __inline__ __m128i __DEFAULT_FN_ATTRS128
-_mm_maskz_shldv_epi64(__mmask8 __U, __m128i __S, __m128i __A, __m128i __B)
+_mm_mask_shldv_epi64(__m128i __A, __mmask8 __U, __m128i __B, __m128i __C)
 {
-  return (__m128i) __builtin_ia32_vpshldvq128_maskz ((__v2di) __S,
-  (__v2di) __A,
-  (__v2di) __B,
-  __U);
+  return (__m128i)__builtin_ia32_selectq_128(__U,
+ (__v2di)_mm_shldv_epi64(__A, __B, __C),
+ (__v2di)__A);
 }
 
 static __inline__ __m128i __DEFAULT_FN_ATTRS128
-_mm_shldv_epi64(__m128i __S, __m128i __A, __m128i __B)
+_mm_maskz_shldv_epi64(__mmask8 __U, __m128i __A, __m128i __B, __m128i __C)
 {
-  return (__m128i) __builtin_ia32_vpshldvq128_mask ((__v2di) __S,
-  (__v2di) __A,
-  (__v2di) __B,
-  (__mmask8) -1);
+  return (__m128i)__builtin_ia32_selectq_128(__U,
+ (__v2di)_mm_shldv_epi64(__A, __B, __C),
+ (__v2di)_mm_setzero_si128());
 }
 
 static __inline__ __m256i __DEFAULT_FN_ATTRS256
-_mm256_mask_shldv_epi32(__m256i __S, __mmask8 __U, __m256i __A, __m256i __B)
+_mm256_shldv_epi32(__m256i __A, __m256i __B, __m256i __C)
 {
-  return (__m256i) __builtin_ia32_vpshldvd256_mask ((__v8si) __S,
-  (__v8si) __A,
-  (__v8si) __B,
-  __U);
+  return (__m256i)__builtin_ia32_vpshldvd256((__v8si)__A, (__v8si)__B,
+ (__v8si)__C);
 }
 
 static __inline__ __m256i __DEFAULT_FN_ATTRS256
-_mm256_maskz_shldv_epi32(__mmask8 __U, __m256i __S, __m256i __A, __m256i __B)
+_mm256_mask_shldv_epi32(__m256i __A, __mmask8 __U, __m256i __B, __m256i __C)
 {
-  return (__m256i) __builtin_ia32_vpshldvd256_maskz ((__v8si) __S,
-  (__v8si) __A,
-  (__v8si) __B,
-  __U);
+  return (__m256i)__builtin_ia32_selectd_256(__U,
+  (__v8si)_mm256_shldv_e

r350555 - [X86] Use funnel shift intrinsics for the VBMI2 vshld/vshrd builtins.

2019-01-07 Thread Craig Topper via cfe-commits
Author: ctopper
Date: Mon Jan  7 11:10:22 2019
New Revision: 350555

URL: http://llvm.org/viewvc/llvm-project?rev=350555&view=rev
Log:
[X86] Use funnel shift intrinsics for the VBMI2 vshld/vshrd builtins.

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

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Headers/avx512vbmi2intrin.h
cfe/trunk/lib/Headers/avx512vlvbmi2intrin.h
cfe/trunk/test/CodeGen/avx512vbmi2-builtins.c
cfe/trunk/test/CodeGen/avx512vlvbmi2-builtins.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=350555&r1=350554&r2=350555&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Mon Jan  7 11:10:22 2019
@@ -1256,43 +1256,25 @@ TARGET_BUILTIN(__builtin_ia32_vpshldw128
 TARGET_BUILTIN(__builtin_ia32_vpshldw256, "V16sV16sV16sIi", "ncV:256:", 
"avx512vl,avx512vbmi2")
 TARGET_BUILTIN(__builtin_ia32_vpshldw512, "V32sV32sV32sIi", "ncV:512:", 
"avx512vbmi2")
 
-TARGET_BUILTIN(__builtin_ia32_vpshldvd128_mask, "V4iV4iV4iV4iUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd256_mask, "V8iV8iV8iV8iUc", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd512_mask, "V16iV16iV16iV16iUs", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq128_mask, "V2LLiV2LLiV2LLiV2LLiUc", 
"ncV:128:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq256_mask, "V4LLiV4LLiV4LLiV4LLiUc", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq512_mask, "V8LLiV8LLiV8LLiV8LLiUc", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw128_mask, "V8sV8sV8sV8sUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw256_mask, "V16sV16sV16sV16sUs", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw512_mask, "V32sV32sV32sV32sUi", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd128_maskz, "V4iV4iV4iV4iUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd256_maskz, "V8iV8iV8iV8iUc", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvd512_maskz, "V16iV16iV16iV16iUs", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq128_maskz, "V2LLiV2LLiV2LLiV2LLiUc", 
"ncV:128:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq256_maskz, "V4LLiV4LLiV4LLiV4LLiUc", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvq512_maskz, "V8LLiV8LLiV8LLiV8LLiUc", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw128_maskz, "V8sV8sV8sV8sUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw256_maskz, "V16sV16sV16sV16sUs", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshldvw512_maskz, "V32sV32sV32sV32sUi", 
"ncV:512:", "avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd128, "V4iV4iV4iV4i", "ncV:128:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd256, "V8iV8iV8iV8i", "ncV:256:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvd512, "V16iV16iV16iV16i", "ncV:512:", 
"avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq128, "V2LLiV2LLiV2LLiV2LLi", "ncV:128:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq256, "V4LLiV4LLiV4LLiV4LLi", "ncV:256:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvq512, "V8LLiV8LLiV8LLiV8LLi", "ncV:512:", 
"avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw128, "V8sV8sV8sV8s", "ncV:128:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw256, "V16sV16sV16sV16s", "ncV:256:", 
"avx512vl,avx512vbmi2")
+TARGET_BUILTIN(__builtin_ia32_vpshldvw512, "V32sV32sV32sV32s", "ncV:512:", 
"avx512vbmi2")
 
-TARGET_BUILTIN(__builtin_ia32_vpshrdvd128_mask, "V4iV4iV4iV4iUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvd256_mask, "V8iV8iV8iV8iUc", "ncV:256:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvd512_mask, "V16iV16iV16iV16iUs", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvq128_mask, "V2LLiV2LLiV2LLiV2LLiUc", 
"ncV:128:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvq256_mask, "V4LLiV4LLiV4LLiV4LLiUc", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvq512_mask, "V8LLiV8LLiV8LLiV8LLiUc", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvw128_mask, "V8sV8sV8sV8sUc", "ncV:128:", 
"avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvw256_mask, "V16sV16sV16sV16sUs", 
"ncV:256:", "avx512vl,avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvw512_mask, "V32sV32sV32sV32sUi", 
"ncV:512:", "avx512vbmi2")
-TARGET_BUILTIN(__builtin_ia32_vpshrdvd128_maskz, "V4iV4iV

[PATCH] D56395: [ASTMatchers] Improve assert message for broken parent map.

2019-01-07 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!


Repository:
  rC Clang

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

https://reviews.llvm.org/D56395



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


[PATCH] D55433: [clang-tidy] Adding a new modernize use nodiscard checker

2019-01-07 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added a comment.

In D55433#1347553 , @MyDeveloperDay 
wrote:

> libprotobuf still builds cleanly with just the one expected warning..despite 
> adding over 500 [[nodiscards]]
>
> F7800873: image.png 
>
> I'll continue to look at other projects, but I'm happy at present that this 
> gives us a good starting point.


That looks good. If llvm (significant parts of it) are fine too, ready to go.

P.S. did you request commit rights already?


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

https://reviews.llvm.org/D55433



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


[PATCH] D56160: [clang-tidy] modernize-use-trailing-return check

2019-01-07 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added a comment.

> - if the closing parenthesis of the function is inside a macro, no FixIt will 
> be created (I cannot relyably lex for subsequent CV and ref qualifiers and 
> maybe we do not want to make changes in macros)

Usually macros are untouched because its impossible to transform them 
correctly. Someone, somewhere does evil stuff with them and is of course mad if 
the transformation interfers ;)

> - if the return type is not CV qualified, i allow macros to be part of it 
> because no lexing is required
> - if the return type is CV qualified and contains macros, I provide no FixIt
> 
>   I improved findTrailingReturnTypeSourceLocation() by discovering 
> FunctionTypeLoc::getRParenLoc(). I still require some lexing for CV and ref 
> qualifiers though.
> 
>   I tried to improve findReturnTypeAndCVSourceRange() by finding a way to get 
> the source range directly from the AST, but it seems the AST does not store 
> source locations for CV qualifiers of types. I read that in the docs for 
> QualifiedTypeLoc 
> . 
> So it seems I cannot circumvent finding the locations of const and volatile 
> by my own.

Yup.




Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:161-163
+  const auto &ctx = *Result.Context;
+  const auto &sm = *Result.SourceManager;
+  const auto &opts = getLangOpts();

bernhardmgruber wrote:
> lebedev.ri wrote:
> > 1. All the variables should be WithThisCase
> > 2. Can't tell if the `auto` is ok here? 
> > 
> 1. done
> 2. Is it important to know what types Result.Context and the others are? I am 
> just passing them on to further functions because I have to, they are not 
> relevant for the logic I am coding.
`auto` shuold only be used if its obvious what type the variable has (e.g. 
`auto foo = make_unique()`, but not for `auto Foo = GetSomeResult();`).
This makes review and reading easier and is the guideline for LLVM. It has room 
for subjective reasoning, but adding the type is usually better.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:19
+namespace modernize {
+constexpr auto Message = "use a trailing return type for this function";
+

`auto -> const char*` here, thats not nice :)

How about a `llvm::StringRef` or 
https://llvm.org/doxygen/classllvm_1_1StringLiteral.html  (in this case better)



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:33
+  const TypeSourceInfo *TSI = F.getTypeSourceInfo();
+  assert(TSI);
+  const FunctionTypeLoc FTL =

Please add an error-msg to the assertion like `assert(TSI && "Reason why this 
must hold");`. Humanreadable for debugging.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:38
+
+  // if the function argument list ends inside of a macro, it is dangerous to
+  // start lexing from here, bail out

Please make that comment (and all comments in general) full grammatical 
sentence with correct punctuation.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:42
+  if (ClosingParen.isMacroID()) {
+diag(
+F.getLocation(),

weird formatting, did clang-format do that?



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:45
+std::string(Message) +
+" (no FixIt provided, function argument list end is inside 
macro)");
+return {};

I think you can ellide that extra message. Not emitting the fixit is clear 
already.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:46
+" (no FixIt provided, function argument list end is inside 
macro)");
+return {};
+  }

Indiciator to use `llvm::Optional` as return type instead. What do you think?



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:53
+  // skip subsequent CV and ref qualifiers
+  const std::pair Loc = SM.getDecomposedLoc(Result);
+  const StringRef File = SM.getBufferData(Loc.first);

Values are usually not `const`'ed. Please change that for consistency.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:67
+
+if (T.is(tok::amp) || T.is(tok::ampamp) || T.is(tok::kw_const) ||
+T.is(tok::kw_volatile)) {

why are pointers not relevant here?
There should be `Token.oneOf()` or `Token.isOneOf()` or similar for this usecase



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:88
+diag(F.getLocation(),
+ std::string(Message) + " (failed to determine return type source "
+"range, could clang resolve all #includes?)",

Same with the other extra-bit of information. This will rather confuse the user 
of clang-tidy then give additional information. Please ellide it.


===

[PATCH] D56226: [clang-format] square parens that are followed by '=' are not Objective-C message sends

2019-01-07 Thread Ben Hamilton via Phabricator via cfe-commits
benhamilton added inline comments.



Comment at: lib/Format/TokenAnnotator.cpp:501
+CurrentToken->Next->is(tok::equal))) ||
+  (CurrentToken->Previous->Previous == Left)) &&
  Left->is(TT_ObjCMethodExpr)) {

I think you need to check if `CurrentToken->Previous` is null before 
dereferencing it.




Comment at: lib/Format/TokenAnnotator.cpp:504
+  // An ObjC method call is rarely followed by an open parenthesis or
+  // an assignment. It also usually contains more than one token.
   // FIXME: Do we incorrectly label ":" with this?

I think it's actually required to have more than one token. Can we reduce the 
change to that?


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

https://reviews.llvm.org/D56226



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


[clang-tools-extra] r350542 - [clangd] Fix Windows build after r350531

2019-01-07 Thread Ilya Biryukov via cfe-commits
Author: ibiryukov
Date: Mon Jan  7 09:03:15 2019
New Revision: 350542

URL: http://llvm.org/viewvc/llvm-project?rev=350542&view=rev
Log:
[clangd] Fix Windows build after r350531

Modified:
clang-tools-extra/trunk/clangd/FSProvider.cpp

Modified: clang-tools-extra/trunk/clangd/FSProvider.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/FSProvider.cpp?rev=350542&r1=350541&r2=350542&view=diff
==
--- clang-tools-extra/trunk/clangd/FSProvider.cpp (original)
+++ clang-tools-extra/trunk/clangd/FSProvider.cpp Mon Jan  7 09:03:15 2019
@@ -75,7 +75,7 @@ clang::clangd::RealFileSystemProvider::g
 // FIXME: Try to use a similar approach in Sema instead of relying on
 //propagation of the 'isVolatile' flag through all layers.
 #ifdef _WIN32
-  return new VolatileFileSystem(vfs::getRealFileSystem());
+  return new VolatileFileSystem(llvm::vfs::getRealFileSystem());
 #else
   return llvm::vfs::getRealFileSystem();
 #endif


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


[clang-tools-extra] r350540 - [clangd] Include instead of . NFC

2019-01-07 Thread Ilya Biryukov via cfe-commits
Author: ibiryukov
Date: Mon Jan  7 08:55:59 2019
New Revision: 350540

URL: http://llvm.org/viewvc/llvm-project?rev=350540&view=rev
Log:
[clangd] Include  instead of . NFC

This fixes the only clang-tidy check currently enabled by clangd.

Modified:
clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp
clang-tools-extra/trunk/unittests/clangd/JSONTransportTests.cpp

Modified: clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp?rev=350540&r1=350539&r2=350540&view=diff
==
--- clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp (original)
+++ clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp Mon Jan  7 08:55:59 
2019
@@ -16,8 +16,8 @@
 #include "ClangdLSPServer.h"
 #include "ClangdServer.h"
 #include "CodeComplete.h"
+#include 
 #include 
-#include 
 
 using namespace clang::clangd;
 

Modified: clang-tools-extra/trunk/unittests/clangd/JSONTransportTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/JSONTransportTests.cpp?rev=350540&r1=350539&r2=350540&view=diff
==
--- clang-tools-extra/trunk/unittests/clangd/JSONTransportTests.cpp (original)
+++ clang-tools-extra/trunk/unittests/clangd/JSONTransportTests.cpp Mon Jan  7 
08:55:59 2019
@@ -10,7 +10,7 @@
 #include "Transport.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
-#include 
+#include 
 
 namespace clang {
 namespace clangd {


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


[PATCH] D54309: [AST] Allow limiting the scope of common AST traversals (getParents, RAV).

2019-01-07 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added a comment.

@sammccall Thank you for analyzing and investigation! Keeping the assertion is 
of course good and I am not sure on how to proceed.

Given the close branch for 8.0 we might opt for an hotfix that resolves the 
issue for now.
I think the bug-report is the better place to continue working on it.


Repository:
  rC Clang

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

https://reviews.llvm.org/D54309



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


[PATCH] D56395: [ASTMatchers] Improve assert message for broken parent map.

2019-01-07 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: ilya-biryukov.
Herald added a subscriber: cfe-commits.

This assert catches places where the AST (as seen by RecursiveASTVisitor)
becomes disconnected due to incomplete traversal.
Making it print the actual parent-less node is a lot more helpful - it's
possible to work out which part of the tree wasn't traversed.


Repository:
  rC Clang

https://reviews.llvm.org/D56395

Files:
  lib/ASTMatchers/ASTMatchFinder.cpp


Index: lib/ASTMatchers/ASTMatchFinder.cpp
===
--- lib/ASTMatchers/ASTMatchFinder.cpp
+++ lib/ASTMatchers/ASTMatchFinder.cpp
@@ -676,13 +676,17 @@
   //  c) there is a bug in the AST, and the node is not reachable
   // Usually the traversal scope is the whole AST, which precludes b.
   // Bugs are common enough that it's worthwhile asserting when we can.
-  assert((Node.get() ||
-  /* Traversal scope is limited if none of the bounds are the TU */
-  llvm::none_of(ActiveASTContext->getTraversalScope(),
-[](Decl *D) {
-  return D->getKind() == Decl::TranslationUnit;
-})) &&
- "Found node that is not in the complete parent map!");
+#ifndef NDEBUG
+  if (!Node.get() &&
+  /* Traversal scope is full AST if any of the bounds are the TU */
+  llvm::any_of(ActiveASTContext->getTraversalScope(), [](Decl *D) {
+return D->getKind() == Decl::TranslationUnit;
+  })) {
+llvm::errs() << "Tried to match orphan node:\n";
+Node.dump(llvm::errs(), ActiveASTContext->getSourceManager());
+llvm_unreachable("Parent map should be complete!");
+  }
+#endif
   return false;
 }
 if (Parents.size() == 1) {


Index: lib/ASTMatchers/ASTMatchFinder.cpp
===
--- lib/ASTMatchers/ASTMatchFinder.cpp
+++ lib/ASTMatchers/ASTMatchFinder.cpp
@@ -676,13 +676,17 @@
   //  c) there is a bug in the AST, and the node is not reachable
   // Usually the traversal scope is the whole AST, which precludes b.
   // Bugs are common enough that it's worthwhile asserting when we can.
-  assert((Node.get() ||
-  /* Traversal scope is limited if none of the bounds are the TU */
-  llvm::none_of(ActiveASTContext->getTraversalScope(),
-[](Decl *D) {
-  return D->getKind() == Decl::TranslationUnit;
-})) &&
- "Found node that is not in the complete parent map!");
+#ifndef NDEBUG
+  if (!Node.get() &&
+  /* Traversal scope is full AST if any of the bounds are the TU */
+  llvm::any_of(ActiveASTContext->getTraversalScope(), [](Decl *D) {
+return D->getKind() == Decl::TranslationUnit;
+  })) {
+llvm::errs() << "Tried to match orphan node:\n";
+Node.dump(llvm::errs(), ActiveASTContext->getSourceManager());
+llvm_unreachable("Parent map should be complete!");
+  }
+#endif
   return false;
 }
 if (Parents.size() == 1) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D56303: [clang-tidy] Handle case/default statements when simplifying boolean expressions

2019-01-07 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added inline comments.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:386
 
-  bool BoolValue = Bool->getValue();
+  const bool BoolValue = Bool->getValue();
 

aaron.ballman wrote:
> LegalizeAdulthood wrote:
> > JonasToth wrote:
> > > `const` on values is uncommon in clang-tidy code. Please keep that 
> > > consistent.
> > I can change the code, but I don't understand the push back.
> > 
> > "That's the way it's done elsewhere" just doesn't seem like good reasoning.
> > 
> > I write const on values to signify that they are computed once and only 
> > once.  What is gained by removing that statement of once-and-only-once?
> > "That's the way it's done elsewhere" just doesn't seem like good reasoning.
> 
> Keeping the code consistent with the vast majority of the remainder of the 
> project is valid reasoning. I am echoing the request to drop the top-level 
> const. We don't use this pattern for non-pointer/reference types and there's 
> not a whole lot gained by using it inconsistently.
Plus we do have a clang-tidy check (in the pipeline) that could do that 
automatically if the LLVM projects decides to go that route. So we won't suffer 
in the future, if we add the const.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:745
+  // matchers, but that is currently impossible.
+  //
+  const auto *If = dyn_cast(SwitchCase->getSubStmt());

LegalizeAdulthood wrote:
> JonasToth wrote:
> > redundant empty comment line
> Meh, it's not redundant.  It's there to aid readability of a big block of 
> text by visually separating it from the associated code.
> 
> Why is this a problem?
Its subjective, I wouldn't do it so I thought you might have overlooked it, if 
we prefer this its fine from my side.


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

https://reviews.llvm.org/D56303



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


[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

2019-01-07 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added a comment.

In D56323#1347489 , @LegalizeAdulthood 
wrote:

> I managed to do some limited testing on the original source file from the bug 
> report in lldb and verified that the correct fix was applied there.  I also 
> tried a few other files and verified no false positives.


Thanks. That is no issue, I will run this check locally over multiple projects 
once committed. If I find issues I will report back!


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

https://reviews.llvm.org/D56323



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


Re: [PATCH] D56393: [DebugInfo] Don't emit DW_AT_enum_class unless it's actually an 'enum class'.

2019-01-07 Thread Zachary Turner via cfe-commits
PDB/CodeView doesn’t doesn’t distinguish between various flavors of enums
On Mon, Jan 7, 2019 at 8:14 AM Paul Robinson via Phabricator <
revi...@reviews.llvm.org> wrote:

> probinson created this revision.
> probinson added reviewers: dblaikie, rnk, zturner.
> probinson added a project: debug-info.
> Herald added subscribers: cfe-commits, JDevlieghere, aprantl.
>
> The original fix for PR36168 would emit DW_AT_enum_class for both of these
> cases:
>
> enum Fixed : short { F1  = 1 };
> enum class Class { C1 = 1 };
>
> However, it really should be applied only to the latter case.
>
> I'd just do this, except I'm not sure whether PDB cares about this
> difference.  If it does, let me know and I guess we'll have to invent a new
> flag so the DWARF and PDB generators can each DTRT.
>
> If not, I'll follow up with NFC name changes so the flag becomes
> DIFlagEnumClass.
>
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D56393
>
> Files:
>   clang/lib/CodeGen/CGDebugInfo.cpp
>   clang/test/CodeGenCXX/debug-info-enum-class.cpp
>
>
> Index: clang/test/CodeGenCXX/debug-info-enum-class.cpp
> ===
> --- clang/test/CodeGenCXX/debug-info-enum-class.cpp
> +++ clang/test/CodeGenCXX/debug-info-enum-class.cpp
> @@ -52,6 +52,7 @@
>  // FIXME: this should just be a declaration under -fno-standalone-debug
>  // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
>  // CHECK-SAME: scope: [[TEST2:![0-9]+]]
> +// CHECK-NOT:  DIFlagFixedEnum
>  // CHECK-SAME: elements: [[TEST_ENUMS:![0-9]+]]
>  // CHECK-SAME: identifier: "_ZTSN5test21EE"
>  // CHECK: [[TEST2]] = !DINamespace(name: "test2"
> @@ -67,6 +68,7 @@
>  // FIXME: this should just be a declaration under -fno-standalone-debug
>  // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
>  // CHECK-SAME: scope: [[TEST3:![0-9]+]]
> +// CHECK-NOT:  DIFlagFixedEnum
>  // CHECK-SAME: elements: [[TEST_ENUMS]]
>  // CHECK-SAME: identifier: "_ZTSN5test31EE"
>  // CHECK: [[TEST3]] = !DINamespace(name: "test3"
> @@ -78,6 +80,7 @@
>  namespace test4 {
>  // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
>  // CHECK-SAME: scope: [[TEST4:![0-9]+]]
> +// CHECK-NOT:  DIFlagFixedEnum
>  // CHECK-SAME: elements: [[TEST_ENUMS]]
>  // CHECK-SAME: identifier: "_ZTSN5test41EE"
>  // CHECK: [[TEST4]] = !DINamespace(name: "test4"
> Index: clang/lib/CodeGen/CGDebugInfo.cpp
> ===
> --- clang/lib/CodeGen/CGDebugInfo.cpp
> +++ clang/lib/CodeGen/CGDebugInfo.cpp
> @@ -2711,7 +2711,7 @@
>llvm::DIType *ClassTy = getOrCreateType(ED->getIntegerType(), DefUnit);
>return DBuilder.createEnumerationType(EnumContext, ED->getName(),
> DefUnit,
>  Line, Size, Align, EltArray,
> ClassTy,
> -Identifier, ED->isFixed());
> +Identifier, ED->isScoped());
>  }
>
>  llvm::DIMacro *CGDebugInfo::CreateMacro(llvm::DIMacroFile *Parent,
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D56012: [clang-tidy] Be more liberal about literal zeroes in abseil checks

2019-01-07 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment.

One random late comment.




Comment at: 
clang-tools-extra/trunk/test/clang-tidy/abseil-duration-factory-scale.cpp:38
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use ZeroDuration() for 
zero-length time intervals [abseil-duration-factory-scale]
+  // CHECK-FIXES: absl::ZeroDuration();
+  d = absl::Seconds(int64_t{0});

I'd add more context to the CHECK-FIXES patterns, otherwise they are not very 
reliable. There's no implicit connection to the line numbers, so any long 
enough subsequence of lines containing 'absl::ZeroDuration()' would satisfy the 
test. One way to do that is to declare variables with unique names. Another is 
to add unique comments.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56012



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


[PATCH] D56393: [DebugInfo] Don't emit DW_AT_enum_class unless it's actually an 'enum class'.

2019-01-07 Thread Paul Robinson via Phabricator via cfe-commits
probinson created this revision.
probinson added reviewers: dblaikie, rnk, zturner.
probinson added a project: debug-info.
Herald added subscribers: cfe-commits, JDevlieghere, aprantl.

The original fix for PR36168 would emit DW_AT_enum_class for both of these 
cases:

enum Fixed : short { F1  = 1 };
enum class Class { C1 = 1 };

However, it really should be applied only to the latter case.

I'd just do this, except I'm not sure whether PDB cares about this difference.  
If it does, let me know and I guess we'll have to invent a new flag so the 
DWARF and PDB generators can each DTRT.

If not, I'll follow up with NFC name changes so the flag becomes 
DIFlagEnumClass.


Repository:
  rC Clang

https://reviews.llvm.org/D56393

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-enum-class.cpp


Index: clang/test/CodeGenCXX/debug-info-enum-class.cpp
===
--- clang/test/CodeGenCXX/debug-info-enum-class.cpp
+++ clang/test/CodeGenCXX/debug-info-enum-class.cpp
@@ -52,6 +52,7 @@
 // FIXME: this should just be a declaration under -fno-standalone-debug
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
 // CHECK-SAME: scope: [[TEST2:![0-9]+]]
+// CHECK-NOT:  DIFlagFixedEnum
 // CHECK-SAME: elements: [[TEST_ENUMS:![0-9]+]]
 // CHECK-SAME: identifier: "_ZTSN5test21EE"
 // CHECK: [[TEST2]] = !DINamespace(name: "test2"
@@ -67,6 +68,7 @@
 // FIXME: this should just be a declaration under -fno-standalone-debug
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
 // CHECK-SAME: scope: [[TEST3:![0-9]+]]
+// CHECK-NOT:  DIFlagFixedEnum
 // CHECK-SAME: elements: [[TEST_ENUMS]]
 // CHECK-SAME: identifier: "_ZTSN5test31EE"
 // CHECK: [[TEST3]] = !DINamespace(name: "test3"
@@ -78,6 +80,7 @@
 namespace test4 {
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
 // CHECK-SAME: scope: [[TEST4:![0-9]+]]
+// CHECK-NOT:  DIFlagFixedEnum
 // CHECK-SAME: elements: [[TEST_ENUMS]]
 // CHECK-SAME: identifier: "_ZTSN5test41EE"
 // CHECK: [[TEST4]] = !DINamespace(name: "test4"
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2711,7 +2711,7 @@
   llvm::DIType *ClassTy = getOrCreateType(ED->getIntegerType(), DefUnit);
   return DBuilder.createEnumerationType(EnumContext, ED->getName(), DefUnit,
 Line, Size, Align, EltArray, ClassTy,
-Identifier, ED->isFixed());
+Identifier, ED->isScoped());
 }
 
 llvm::DIMacro *CGDebugInfo::CreateMacro(llvm::DIMacroFile *Parent,


Index: clang/test/CodeGenCXX/debug-info-enum-class.cpp
===
--- clang/test/CodeGenCXX/debug-info-enum-class.cpp
+++ clang/test/CodeGenCXX/debug-info-enum-class.cpp
@@ -52,6 +52,7 @@
 // FIXME: this should just be a declaration under -fno-standalone-debug
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
 // CHECK-SAME: scope: [[TEST2:![0-9]+]]
+// CHECK-NOT:  DIFlagFixedEnum
 // CHECK-SAME: elements: [[TEST_ENUMS:![0-9]+]]
 // CHECK-SAME: identifier: "_ZTSN5test21EE"
 // CHECK: [[TEST2]] = !DINamespace(name: "test2"
@@ -67,6 +68,7 @@
 // FIXME: this should just be a declaration under -fno-standalone-debug
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
 // CHECK-SAME: scope: [[TEST3:![0-9]+]]
+// CHECK-NOT:  DIFlagFixedEnum
 // CHECK-SAME: elements: [[TEST_ENUMS]]
 // CHECK-SAME: identifier: "_ZTSN5test31EE"
 // CHECK: [[TEST3]] = !DINamespace(name: "test3"
@@ -78,6 +80,7 @@
 namespace test4 {
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E"
 // CHECK-SAME: scope: [[TEST4:![0-9]+]]
+// CHECK-NOT:  DIFlagFixedEnum
 // CHECK-SAME: elements: [[TEST_ENUMS]]
 // CHECK-SAME: identifier: "_ZTSN5test41EE"
 // CHECK: [[TEST4]] = !DINamespace(name: "test4"
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2711,7 +2711,7 @@
   llvm::DIType *ClassTy = getOrCreateType(ED->getIntegerType(), DefUnit);
   return DBuilder.createEnumerationType(EnumContext, ED->getName(), DefUnit,
 Line, Size, Align, EltArray, ClassTy,
-Identifier, ED->isFixed());
+Identifier, ED->isScoped());
 }
 
 llvm::DIMacro *CGDebugInfo::CreateMacro(llvm:

[PATCH] D54945: This commit adds a chapter about clang-tidy integrations

2019-01-07 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment.

In D54945#1340528 , @MarinaKalashina 
wrote:

> @alexfh Just for me to be sure, should there be the following structure in 
> http://clang.llvm.org/extra/index.html: ...


Roughly like that. More specifically, I'd suggest to modify the See also 
section of clang-tidy/index.rst as follows:

  See also:
  
  .. toctree::
 :maxdepth: 1
  
 The list of clang-tidy checks 
 Clang-tidy IDE/Editor Integrations 
 Getting Involved 

The order of TOC items in http://clang.llvm.org/extra/index.html will be 
slightly weird (the three external docs will be placed before the headings of 
the main document), but that doesn't seem like a huge problem (and may be 
fixable).


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

https://reviews.llvm.org/D54945



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


[PATCH] D56314: [clangd] Don't store completion info if the symbol is not used for code completion.

2019-01-07 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added inline comments.



Comment at: clangd/index/Index.h:232
 /// See also isIndexedForCodeCompletion().
+/// Note that we don't store completion information (signature, snippet,
+/// documentation, type, inclues, etc) if the symbol is not indexed for 
code

This comment would be most useful beside the mentioned fields themselves. Maybe 
add it there too? Possibly with a shorter form, since there's no need to 
mention the field names there.



Comment at: clangd/index/SymbolCollector.cpp:543
+
+  if (!(S.Flags & Symbol::IndexedForCodeCompletion))
+return Insert(S);

Most of the fields updated at the bottom aren't useful. However, I feel the 
documentation is actually important, since Sema only has doc comments for the 
**current** file and the rest are currently expected to be provided by the 
index.

I'm not sure if we already have the code to query the doc comments via index 
for member completions. If not, it's an oversight.
In any case, I suggest we **always** store the comments in **dynamic** index. 
Not storing the comments in the static index is fine, since any data for member 
completions should be provided by the dynamic index (we see a member in 
completion ⇒ sema has processed the headers ⇒ the dynamic index should know 
about those members)


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56314



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


[PATCH] D55212: Handle alloc_size attribute on function pointers

2019-01-07 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added reviewers: erik.pilkington, dexonsmith.
aaron.ballman added a comment.

In D55212#1347994 , @arichardson wrote:

> I don't see an easy way of fixing the pragma clang attribute support for 
> this. 
>  Would it be okay to commit this change anyway?


It causes a regression in behavior, so I'm not certain we should move forward 
with it just yet (unless there's a pressing reason?).

> Since `alloc_size` is only used for very few functions I'd be very surprised 
> if there's any existing code that relies on using `#pragma clang atrribute` 
> with `alloc_size`.

This feature has already been available in a public release and there's no way 
to know how much code it will break (if any). It does seem rather unlikely, but 
I've been surprised by how people use this feature in the past.

> By the way GCC now also supports the attribute on function pointers: 
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=267158

Yeah, my concern isn't with the new functionality so much as it breaking old 
functionality.

I'm also adding Erik and Duncan to the review because they may have some more 
insights into whether `alloc_size` is being used with `#pragma clang attribute` 
in the wild. My feeling is: if we can't spot any uses of that feature being 
used to apply `alloc_size` with a reasonable amount of looking for it, then we 
can go ahead with this patch even if it removes support for `alloc_size` from 
the pragma. If we get push back from the community, we can fix or revert at 
that time. However, given that this is plausibly a breaking change, I'd rather 
not commit to trunk until after we branch to give folks more time to react. 
WDYT?




Comment at: test/Misc/pragma-attribute-supported-attributes-list.test:15
+// FIXME: After changing the subject from Function to HasFunctionProto, 
AllocSize is no longer listed (similar to Format, etc)
+// FIXME-NEXT: AllocSize (SubjectMatchRule_function)
 // CHECK-NEXT: AlwaysDestroy (SubjectMatchRule_variable)

arichardson wrote:
> aaron.ballman wrote:
> > arichardson wrote:
> > > This seems to also affect __attribute((format)) and others so I'm not 
> > > sure whether removing AllocSize from this list is a blocker for this 
> > > patch.
> > I believe you may need to add an `AttrSubjectMatcherSubRule` in Attr.td to 
> > expose the attribute for `#pragma clang attribute` support. Can you see if 
> > you can support it instead of shrinking this list? Otherwise, I worry that 
> > this change will break code that was using the pragma to apply the 
> > attribute to declarations.
> The problem here already has a fixme in attr.td:
> 
> ```
>   // FIXME: There's a matcher ambiguity with objc methods and blocks since
>   // functionType excludes them but functionProtoType includes them.
>   // AttrSubjectMatcherSubRule<"functionProtoType", [HasFunctionProto]>
> ```
> 
> It seems like this was already added as part of the initial pragma clang 
> attribute commit in https://reviews.llvm.org/D30009
> 
> I had a look at the AttrEmitter.cpp in tablegen but couldn't find a 
> straightforward solution.
> I'll add @arphaman to the review.
Ah, good to know that this was already a known issue. Hopefully @arphaman has 
some ideas on how to support this so we don't remove a supported attribute from 
the list.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55212



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


r350530 - [OPENMP][NVPTX]Reduce number of barriers in reductions.

2019-01-07 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Mon Jan  7 07:45:09 2019
New Revision: 350530

URL: http://llvm.org/viewvc/llvm-project?rev=350530&view=rev
Log:
[OPENMP][NVPTX]Reduce number of barriers in reductions.

After the fix for the syncthreads we don't need to generate extra
barriers for the parallel reductions.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/test/OpenMP/nvptx_target_parallel_reduction_codegen.cpp
cfe/trunk/test/OpenMP/nvptx_teams_reduction_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp?rev=350530&r1=350529&r2=350530&view=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp Mon Jan  7 07:45:09 2019
@@ -3124,7 +3124,6 @@ static void emitReductionListCopy(
 /// sync
 /// if (I am the first warp)
 ///   Copy smem[thread_id] to my local D
-/// sync
 static llvm::Value *emitInterWarpCopyFunction(CodeGenModule &CGM,
   ArrayRef Privates,
   QualType ReductionArrayTy,
@@ -3337,12 +3336,6 @@ static llvm::Value *emitInterWarpCopyFun
 
   CGF.EmitBlock(W0MergeBB);
 
-  // While warp 0 copies values from transfer medium, all other warps must
-  // wait.
-  // kmpc_barrier.
-  CGM.getOpenMPRuntime().emitBarrierCall(CGF, Loc, OMPD_unknown,
- /*EmitChecks=*/false,
- /*ForceSimpleCall=*/true);
   if (NumIters > 1) {
 Cnt = Bld.CreateNSWAdd(Cnt, llvm::ConstantInt::get(CGM.IntTy, 
/*V=*/1));
 CGF.EmitStoreOfScalar(Cnt, CntAddr, /*Volatile=*/false, C.IntTy);

Modified: cfe/trunk/test/OpenMP/nvptx_target_parallel_reduction_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/nvptx_target_parallel_reduction_codegen.cpp?rev=350530&r1=350529&r2=350530&view=diff
==
--- cfe/trunk/test/OpenMP/nvptx_target_parallel_reduction_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/nvptx_target_parallel_reduction_codegen.cpp Mon Jan  
7 07:45:09 2019
@@ -231,7 +231,6 @@ int bar(int n){
   // CHECK: br label {{%?}}[[READ_CONT]]
   //
   // CHECK: [[READ_CONT]]
-  // CHECK: call void @__kmpc_barrier(%struct.ident_t* @
   // CHECK: [[NEXT:%.+]] = add nsw i32 [[CNT]], 1
   // CHECK: store i32 [[NEXT]], i32* [[CNT_ADDR]],
   // CHECK: br label
@@ -468,7 +467,6 @@ int bar(int n){
   //
   // CHECK: [[READ_CONT]]
   // CHECK: call void @__kmpc_barrier(%struct.ident_t* @
-  // CHECK: call void @__kmpc_barrier(%struct.ident_t* @
   // CHECK: [[IS_WARP_MASTER:%.+]] = icmp eq i32 [[LANEID]], 0
   // CHECK: br i1 [[IS_WARP_MASTER]], label {{%?}}[[DO_COPY:.+]], label 
{{%?}}[[COPY_ELSE:.+]]
   //
@@ -507,7 +505,6 @@ int bar(int n){
   // CHECK: br label {{%?}}[[READ_CONT]]
   //
   // CHECK: [[READ_CONT]]
-  // CHECK: call void @__kmpc_barrier(%struct.ident_t* @
   // CHECK: ret
 
 
@@ -823,7 +820,6 @@ int bar(int n){
   // CHECK: br label {{%?}}[[READ_CONT]]
   //
   // CHECK: [[READ_CONT]]
-  // CHECK: call void @__kmpc_barrier(%struct.ident_t* @
   // CHECK: ret
 
 #endif

Modified: cfe/trunk/test/OpenMP/nvptx_teams_reduction_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/nvptx_teams_reduction_codegen.cpp?rev=350530&r1=350529&r2=350530&view=diff
==
--- cfe/trunk/test/OpenMP/nvptx_teams_reduction_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/nvptx_teams_reduction_codegen.cpp Mon Jan  7 07:45:09 
2019
@@ -473,7 +473,6 @@ int bar(int n){
   // CHECK: br label {{%?}}[[READ_CONT]]
   //
   // CHECK: [[READ_CONT]]
-  // CHECK: call void @__kmpc_barrier(%struct.ident_t* @
   // CHECK: ret
 
 #endif


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


[PATCH] D56391: Limit COFF 'common' emission to <=32 alignment types.

2019-01-07 Thread Erich Keane via Phabricator via cfe-commits
erichkeane created this revision.
erichkeane added reviewers: majnemer, rnk, pengfei.

As reported in PR33035, LLVM crashes if given a common object with an
alignment of greater than 32 bits.  This is because the COFF file format
does not support these alignments, so emitting them is broken anyway.

This patch changes any global definitions greater than 32 bit alignment
to no longer be in 'common'.

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


Repository:
  rC Clang

https://reviews.llvm.org/D56391

Files:
  lib/CodeGen/CodeGenModule.cpp
  test/CodeGen/microsoft-no-common-align.c


Index: test/CodeGen/microsoft-no-common-align.c
===
--- /dev/null
+++ test/CodeGen/microsoft-no-common-align.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm -o - %s | FileCheck 
%s
+typedef float TooLargeAlignment __attribute__((__vector_size__(64)));
+typedef float NormalAlignment __attribute__((__vector_size__(4)));
+
+TooLargeAlignment TooBig;
+// CHECK: @TooBig = dso_local global <16 x float>  zeroinitializer, align 64
+NormalAlignment JustRight;
+// CHECK: @JustRight = common dso_local global <1 x float>  zeroinitializer, 
align 4
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -3761,6 +3761,11 @@
   }
 }
   }
+  // COFF doesn't support alignments greater than 32, so these cannot be
+  // in common.
+  if (Context.getTargetInfo().getTriple().isOSBinFormatCOFF() &&
+  Context.getTypeAlignIfKnown(D->getType()) > 32)
+return true;
 
   return false;
 }


Index: test/CodeGen/microsoft-no-common-align.c
===
--- /dev/null
+++ test/CodeGen/microsoft-no-common-align.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm -o - %s | FileCheck %s
+typedef float TooLargeAlignment __attribute__((__vector_size__(64)));
+typedef float NormalAlignment __attribute__((__vector_size__(4)));
+
+TooLargeAlignment TooBig;
+// CHECK: @TooBig = dso_local global <16 x float>  zeroinitializer, align 64
+NormalAlignment JustRight;
+// CHECK: @JustRight = common dso_local global <1 x float>  zeroinitializer, align 4
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -3761,6 +3761,11 @@
   }
 }
   }
+  // COFF doesn't support alignments greater than 32, so these cannot be
+  // in common.
+  if (Context.getTargetInfo().getTriple().isOSBinFormatCOFF() &&
+  Context.getTypeAlignIfKnown(D->getType()) > 32)
+return true;
 
   return false;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch.

2019-01-07 Thread Louis Dionne via Phabricator via cfe-commits
ldionne accepted this revision.
ldionne added a comment.

LGTM, but I suggest you address @Quuxplusone 's concerns regarding the tests.


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

https://reviews.llvm.org/D48342



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


r350529 - [Sema] Fix unused variable warning in Release builds

2019-01-07 Thread Benjamin Kramer via cfe-commits
Author: d0k
Date: Mon Jan  7 07:22:08 2019
New Revision: 350529

URL: http://llvm.org/viewvc/llvm-project?rev=350529&view=rev
Log:
[Sema] Fix unused variable warning in Release builds

Modified:
cfe/trunk/lib/Sema/SemaDeclCXX.cpp

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=350529&r1=350528&r2=350529&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Jan  7 07:22:08 2019
@@ -14294,8 +14294,7 @@ NamedDecl *Sema::ActOnFriendFunctionDecl
 
   CXXScopeSpec &SS = D.getCXXScopeSpec();
   DeclarationNameInfo NameInfo = GetNameForDeclarator(D);
-  DeclarationName Name = NameInfo.getName();
-  assert(Name);
+  assert(NameInfo.getName());
 
   // Check for unexpanded parameter packs.
   if (DiagnoseUnexpandedParameterPack(Loc, TInfo, UPPC_FriendDeclaration) ||


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


[PATCH] D56390: Generate Checkers.inc under clang/Driver and use from CC1Options.td

2019-01-07 Thread Yuka Takahashi via Phabricator via cfe-commits
yamaguchi created this revision.
yamaguchi added a reviewer: thakis.
Herald added a subscriber: mgorny.

Generate Checkers.inc also under include/clang/Driver so that we can
include this file from Driver/CC1Options.td without making Driver's
tablegen output depending on StaticAnalyzer/Checker's tablegen output.


https://reviews.llvm.org/D56390

Files:
  clang/include/clang/Driver/CC1Options.td
  clang/include/clang/Driver/CMakeLists.txt


Index: clang/include/clang/Driver/CMakeLists.txt
===
--- clang/include/clang/Driver/CMakeLists.txt
+++ clang/include/clang/Driver/CMakeLists.txt
@@ -1,3 +1,7 @@
 set(LLVM_TARGET_DEFINITIONS Options.td)
 tablegen(LLVM Options.inc -gen-opt-parser-defs)
+clang_tablegen(Checkers.inc -gen-clang-sa-checkers
+   -I ${CMAKE_CURRENT_SOURCE_DIR}/../StaticAnalyzer/Checkers
+   SOURCE ${CMAKE_CURRENT_SOURCE_DIR}/../StaticAnalyzer/Checkers/Checkers.td
+   TARGET SACheckerForClangDriver)
 add_public_tablegen_target(ClangDriverOptions)
Index: clang/include/clang/Driver/CC1Options.td
===
--- clang/include/clang/Driver/CC1Options.td
+++ clang/include/clang/Driver/CC1Options.td
@@ -109,11 +109,11 @@
 const char *Values =
 #define GET_CHECKERS
 #define CHECKER(FULLNAME, CLASS, HT, DOC_URI)  FULLNAME ","
-#include "clang/StaticAnalyzer/Checkers/Checkers.inc"
+#include "clang/Driver/Checkers.inc"
 #undef GET_CHECKERS
 #define GET_PACKAGES
 #define PACKAGE(FULLNAME)  FULLNAME ","
-#include "clang/StaticAnalyzer/Checkers/Checkers.inc"
+#include "clang/Driver/Checkers.inc"
 #undef GET_PACKAGES
 ;
   }]>;


Index: clang/include/clang/Driver/CMakeLists.txt
===
--- clang/include/clang/Driver/CMakeLists.txt
+++ clang/include/clang/Driver/CMakeLists.txt
@@ -1,3 +1,7 @@
 set(LLVM_TARGET_DEFINITIONS Options.td)
 tablegen(LLVM Options.inc -gen-opt-parser-defs)
+clang_tablegen(Checkers.inc -gen-clang-sa-checkers
+   -I ${CMAKE_CURRENT_SOURCE_DIR}/../StaticAnalyzer/Checkers
+   SOURCE ${CMAKE_CURRENT_SOURCE_DIR}/../StaticAnalyzer/Checkers/Checkers.td
+   TARGET SACheckerForClangDriver)
 add_public_tablegen_target(ClangDriverOptions)
Index: clang/include/clang/Driver/CC1Options.td
===
--- clang/include/clang/Driver/CC1Options.td
+++ clang/include/clang/Driver/CC1Options.td
@@ -109,11 +109,11 @@
 const char *Values =
 #define GET_CHECKERS
 #define CHECKER(FULLNAME, CLASS, HT, DOC_URI)  FULLNAME ","
-#include "clang/StaticAnalyzer/Checkers/Checkers.inc"
+#include "clang/Driver/Checkers.inc"
 #undef GET_CHECKERS
 #define GET_PACKAGES
 #define PACKAGE(FULLNAME)  FULLNAME ","
-#include "clang/StaticAnalyzer/Checkers/Checkers.inc"
+#include "clang/Driver/Checkers.inc"
 #undef GET_PACKAGES
 ;
   }]>;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D55775: [Driver] Don't override '-march' when using '-arch x86_64h'

2019-01-07 Thread Francis Visoiu Mistrih via Phabricator via cfe-commits
thegameg added a comment.

In D55775#1338512 , @qcolombet wrote:

> Should we emit an error if we request x86_64h with an arch older than haswell?


Makes sense. I'll put up a patch soon.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D55775



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


[PATCH] D55701: [analyzer] Pass the correct loc Expr from VisitIncDecOp to evalStore

2019-01-07 Thread Rafael Stahl via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC350528: [analyzer] Pass the correct loc Expr from 
VisitIncDecOp to evalStore (authored by r.stahl, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D55701?vs=180487&id=180489#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D55701

Files:
  lib/StaticAnalyzer/Core/ExprEngineC.cpp
  unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp

Index: lib/StaticAnalyzer/Core/ExprEngineC.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngineC.cpp
+++ lib/StaticAnalyzer/Core/ExprEngineC.cpp
@@ -1052,7 +1052,7 @@
   // Perform the store, so that the uninitialized value detection happens.
   Bldr.takeNodes(*I);
   ExplodedNodeSet Dst3;
-  evalStore(Dst3, U, U, *I, state, loc, V2_untested);
+  evalStore(Dst3, U, Ex, *I, state, loc, V2_untested);
   Bldr.addNodes(Dst3);
 
   continue;
@@ -1120,7 +1120,7 @@
 // Perform the store.
 Bldr.takeNodes(*I);
 ExplodedNodeSet Dst3;
-evalStore(Dst3, U, U, *I, state, loc, Result);
+evalStore(Dst3, U, Ex, *I, state, loc, Result);
 Bldr.addNodes(Dst3);
   }
   Dst.insert(Dst2);
Index: unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp
===
--- unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp
+++ unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp
@@ -21,16 +21,7 @@
 namespace ento {
 namespace {
 
-class CustomChecker : public Checker {
-public:
-  void checkASTCodeBody(const Decl *D, AnalysisManager &Mgr,
-BugReporter &BR) const {
-BR.EmitBasicReport(D, this, "Custom diagnostic", categories::LogicError,
-   "Custom diagnostic description",
-   PathDiagnosticLocation(D, Mgr.getSourceManager()), {});
-  }
-};
-
+template 
 class TestAction : public ASTFrontendAction {
   class DiagConsumer : public PathDiagnosticConsumer {
 llvm::raw_ostream &Output;
@@ -59,23 +50,55 @@
 Compiler.getAnalyzerOpts()->CheckersControlList = {
 {"custom.CustomChecker", true}};
 AnalysisConsumer->AddCheckerRegistrationFn([](CheckerRegistry &Registry) {
-  Registry.addChecker("custom.CustomChecker", "Description",
- "");
+  Registry.addChecker("custom.CustomChecker", "Description", "");
 });
 return std::move(AnalysisConsumer);
   }
 };
 
+template 
+bool runCheckerOnCode(const std::string &Code, std::string &Diags) {
+  llvm::raw_string_ostream OS(Diags);
+  return tooling::runToolOnCode(new TestAction(OS), Code);
+}
+template 
+bool runCheckerOnCode(const std::string &Code) {
+  std::string Diags;
+  return runCheckerOnCode(Code, Diags);
+}
+
+
+class CustomChecker : public Checker {
+public:
+  void checkASTCodeBody(const Decl *D, AnalysisManager &Mgr,
+BugReporter &BR) const {
+BR.EmitBasicReport(D, this, "Custom diagnostic", categories::LogicError,
+   "Custom diagnostic description",
+   PathDiagnosticLocation(D, Mgr.getSourceManager()), {});
+  }
+};
 
 TEST(RegisterCustomCheckers, RegisterChecker) {
   std::string Diags;
-  {
-llvm::raw_string_ostream OS(Diags);
-EXPECT_TRUE(tooling::runToolOnCode(new TestAction(OS), "void f() {;}"));
-  }
+  EXPECT_TRUE(runCheckerOnCode("void f() {;}", Diags));
   EXPECT_EQ(Diags, "custom.CustomChecker:Custom diagnostic description");
 }
 
+class LocIncDecChecker : public Checker {
+public:
+  void checkLocation(SVal Loc, bool IsLoad, const Stmt *S,
+ CheckerContext &C) const {
+auto UnaryOp = dyn_cast(S);
+if (UnaryOp && !IsLoad)
+  EXPECT_FALSE(UnaryOp->isIncrementOp());
+  }
+};
+
+TEST(RegisterCustomCheckers, CheckLocationIncDec) {
+  EXPECT_TRUE(
+  runCheckerOnCode("void f() { int *p; (*p)++; }"));
+}
+
 }
 }
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D55701: [analyzer] Pass the correct loc Expr from VisitIncDecOp to evalStore

2019-01-07 Thread Rafael Stahl via Phabricator via cfe-commits
r.stahl added a comment.

I tried adding isGLValue to evalStore and the test suite didn't complain. For 
evalLoad (on BoundEx) it failed in pretty much every test. Should the evalStore 
assert also go into trunk?

Since the analyzer behavior itself remains unchanged, I don't believe any other 
checker should be affected.

For myself it was pretty obvious that there is something weird going on when I 
didn't get the expected Stmt in my checker callback. So I added the following 
workaround. With this patch, the workaround is safely skipped.

The only change that this patch might cause "in the wild" is when someone used 
the Stmt as location, but didn't test with IncDecOps. However, as far as I can 
tell this should only have positive outcome.

Do I have any other means to check if other checkers were affected than to run 
the test suite?

  // Workaround for an inconsistency with IncDecOps: The statement is not the 
location expr.
  if (auto unaryE = dyn_cast(S))
  {
if (unaryE->isIncrementDecrementOp())
{
  S = unaryE->getSubExpr();
}
  }


Repository:
  rC Clang

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

https://reviews.llvm.org/D55701



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


r350528 - [analyzer] Pass the correct loc Expr from VisitIncDecOp to evalStore

2019-01-07 Thread Rafael Stahl via cfe-commits
Author: r.stahl
Date: Mon Jan  7 07:07:01 2019
New Revision: 350528

URL: http://llvm.org/viewvc/llvm-project?rev=350528&view=rev
Log:
[analyzer] Pass the correct loc Expr from VisitIncDecOp to evalStore

Summary: The LocationE parameter of evalStore is documented as "The location 
expression that is stored to". When storing from an increment / decrement 
operator this was not satisfied. In user code this causes an inconsistency 
between the SVal and Stmt parameters of checkLocation.

Reviewers: NoQ, dcoughlin, george.karpenkov

Reviewed By: NoQ

Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, 
Szelethus, donat.nagy, dkrupp, cfe-commits

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

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineC.cpp
cfe/trunk/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineC.cpp?rev=350528&r1=350527&r2=350528&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineC.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineC.cpp Mon Jan  7 07:07:01 2019
@@ -1052,7 +1052,7 @@ void ExprEngine::VisitIncrementDecrement
   // Perform the store, so that the uninitialized value detection happens.
   Bldr.takeNodes(*I);
   ExplodedNodeSet Dst3;
-  evalStore(Dst3, U, U, *I, state, loc, V2_untested);
+  evalStore(Dst3, U, Ex, *I, state, loc, V2_untested);
   Bldr.addNodes(Dst3);
 
   continue;
@@ -1120,7 +1120,7 @@ void ExprEngine::VisitIncrementDecrement
 // Perform the store.
 Bldr.takeNodes(*I);
 ExplodedNodeSet Dst3;
-evalStore(Dst3, U, U, *I, state, loc, Result);
+evalStore(Dst3, U, Ex, *I, state, loc, Result);
 Bldr.addNodes(Dst3);
   }
   Dst.insert(Dst2);

Modified: cfe/trunk/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp?rev=350528&r1=350527&r2=350528&view=diff
==
--- cfe/trunk/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp (original)
+++ cfe/trunk/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp Mon Jan  
7 07:07:01 2019
@@ -21,16 +21,7 @@ namespace clang {
 namespace ento {
 namespace {
 
-class CustomChecker : public Checker {
-public:
-  void checkASTCodeBody(const Decl *D, AnalysisManager &Mgr,
-BugReporter &BR) const {
-BR.EmitBasicReport(D, this, "Custom diagnostic", categories::LogicError,
-   "Custom diagnostic description",
-   PathDiagnosticLocation(D, Mgr.getSourceManager()), {});
-  }
-};
-
+template 
 class TestAction : public ASTFrontendAction {
   class DiagConsumer : public PathDiagnosticConsumer {
 llvm::raw_ostream &Output;
@@ -59,23 +50,55 @@ public:
 Compiler.getAnalyzerOpts()->CheckersControlList = {
 {"custom.CustomChecker", true}};
 AnalysisConsumer->AddCheckerRegistrationFn([](CheckerRegistry &Registry) {
-  Registry.addChecker("custom.CustomChecker", "Description",
- "");
+  Registry.addChecker("custom.CustomChecker", "Description", "");
 });
 return std::move(AnalysisConsumer);
   }
 };
 
+template 
+bool runCheckerOnCode(const std::string &Code, std::string &Diags) {
+  llvm::raw_string_ostream OS(Diags);
+  return tooling::runToolOnCode(new TestAction(OS), Code);
+}
+template 
+bool runCheckerOnCode(const std::string &Code) {
+  std::string Diags;
+  return runCheckerOnCode(Code, Diags);
+}
+
+
+class CustomChecker : public Checker {
+public:
+  void checkASTCodeBody(const Decl *D, AnalysisManager &Mgr,
+BugReporter &BR) const {
+BR.EmitBasicReport(D, this, "Custom diagnostic", categories::LogicError,
+   "Custom diagnostic description",
+   PathDiagnosticLocation(D, Mgr.getSourceManager()), {});
+  }
+};
 
 TEST(RegisterCustomCheckers, RegisterChecker) {
   std::string Diags;
-  {
-llvm::raw_string_ostream OS(Diags);
-EXPECT_TRUE(tooling::runToolOnCode(new TestAction(OS), "void f() {;}"));
-  }
+  EXPECT_TRUE(runCheckerOnCode("void f() {;}", Diags));
   EXPECT_EQ(Diags, "custom.CustomChecker:Custom diagnostic description");
 }
 
+class LocIncDecChecker : public Checker {
+public:
+  void checkLocation(SVal Loc, bool IsLoad, const Stmt *S,
+ CheckerContext &C) const {
+auto UnaryOp = dyn_cast(S);
+if (UnaryOp && !IsLoad)
+  EXPECT_FALSE(UnaryOp->isIncrementOp());
+  }
+};
+
+TEST(RegisterCustomCheckers, CheckLocationIncDec) {
+  EXPECT_TRUE(
+  runCheckerOnCode("void f() { int *p; (*p)++; }"));
+}
+
 }
 }
 }


___
cfe

[PATCH] D56134: [AST] Store some data of CXXNewExpr as trailing objects

2019-01-07 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL350527: [AST] Store some data of CXXNewExpr as trailing 
objects (authored by brunoricci, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D56134?vs=179639&id=180488#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56134

Files:
  cfe/trunk/include/clang/AST/ExprCXX.h
  cfe/trunk/include/clang/AST/Stmt.h
  cfe/trunk/lib/AST/ASTImporter.cpp
  cfe/trunk/lib/AST/ExprCXX.cpp
  cfe/trunk/lib/CodeGen/CGExprCXX.cpp
  cfe/trunk/lib/Sema/SemaExprCXX.cpp
  cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
  cfe/trunk/lib/Serialization/ASTWriterStmt.cpp

Index: cfe/trunk/include/clang/AST/ExprCXX.h
===
--- cfe/trunk/include/clang/AST/ExprCXX.h
+++ cfe/trunk/include/clang/AST/ExprCXX.h
@@ -1933,54 +1933,56 @@
 
 /// Represents a new-expression for memory allocation and constructor
 /// calls, e.g: "new CXXNewExpr(foo)".
-class CXXNewExpr : public Expr {
+class CXXNewExpr final
+: public Expr,
+  private llvm::TrailingObjects {
   friend class ASTStmtReader;
   friend class ASTStmtWriter;
-
-  /// Contains an optional array size expression, an optional initialization
-  /// expression, and any number of optional placement arguments, in that order.
-  Stmt **SubExprs = nullptr;
+  friend TrailingObjects;
 
   /// Points to the allocation function used.
   FunctionDecl *OperatorNew;
 
-  /// Points to the deallocation function used in case of error. May be
-  /// null.
+  /// Points to the deallocation function used in case of error. May be null.
   FunctionDecl *OperatorDelete;
 
   /// The allocated type-source information, as written in the source.
   TypeSourceInfo *AllocatedTypeInfo;
 
-  /// If the allocated type was expressed as a parenthesized type-id,
-  /// the source range covering the parenthesized type-id.
-  SourceRange TypeIdParens;
-
   /// Range of the entire new expression.
   SourceRange Range;
 
   /// Source-range of a paren-delimited initializer.
   SourceRange DirectInitRange;
 
-  /// Was the usage ::new, i.e. is the global new to be used?
-  unsigned GlobalNew : 1;
-
-  /// Do we allocate an array? If so, the first SubExpr is the size expression.
-  unsigned Array : 1;
+  // CXXNewExpr is followed by several optional trailing objects.
+  // They are in order:
+  //
+  // * An optional "Stmt *" for the array size expression.
+  //Present if and ony if isArray().
+  //
+  // * An optional "Stmt *" for the init expression.
+  //Present if and only if hasInitializer().
+  //
+  // * An array of getNumPlacementArgs() "Stmt *" for the placement new
+  //   arguments, if any.
+  //
+  // * An optional SourceRange for the range covering the parenthesized type-id
+  //if the allocated type was expressed as a parenthesized type-id.
+  //Present if and only if isParenTypeId().
+  unsigned arraySizeOffset() const { return 0; }
+  unsigned initExprOffset() const { return arraySizeOffset() + isArray(); }
+  unsigned placementNewArgsOffset() const {
+return initExprOffset() + hasInitializer();
+  }
 
-  /// Should the alignment be passed to the allocation function?
-  unsigned PassAlignment : 1;
+  unsigned numTrailingObjects(OverloadToken) const {
+return isArray() + hasInitializer() + getNumPlacementArgs();
+  }
 
-  /// If this is an array allocation, does the usual deallocation
-  /// function for the allocated type want to know the allocated size?
-  unsigned UsualArrayDeleteWantsSize : 1;
-
-  /// The number of placement new arguments.
-  unsigned NumPlacementArgs : 26;
-
-  /// What kind of initializer do we have? Could be none, parens, or braces.
-  /// In storage, we distinguish between "none, and no initializer expr", and
-  /// "none, but an implicit initializer expr".
-  unsigned StoredInitializationStyle : 2;
+  unsigned numTrailingObjects(OverloadToken) const {
+return isParenTypeId();
+  }
 
 public:
   enum InitializationStyle {
@@ -1994,18 +1996,35 @@
 ListInit
   };
 
-  CXXNewExpr(const ASTContext &C, bool globalNew, FunctionDecl *operatorNew,
- FunctionDecl *operatorDelete, bool PassAlignment,
- bool usualArrayDeleteWantsSize, ArrayRef placementArgs,
- SourceRange typeIdParens, Expr *arraySize,
- InitializationStyle initializationStyle, Expr *initializer,
- QualType ty, TypeSourceInfo *AllocatedTypeInfo,
- SourceRange Range, SourceRange directInitRange);
-  explicit CXXNewExpr(EmptyShell Shell)
-  : Expr(CXXNewExprClass, Shell) {}
-
-  void AllocateArgsArray(const ASTContext &C, bool isArray,
- unsigned numPlaceArgs, bool hasInitializer);
+private:
+  /// Build a c++ new expression.
+  CXXNewExpr(bool IsGlobalNew, FunctionDecl *OperatorNew,
+ FunctionDecl *Operat

[PATCH] D55701: [analyzer] Pass the correct loc Expr from VisitIncDecOp to evalStore

2019-01-07 Thread Rafael Stahl via Phabricator via cfe-commits
r.stahl updated this revision to Diff 180487.
r.stahl added a comment.

rebased


Repository:
  rC Clang

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

https://reviews.llvm.org/D55701

Files:
  lib/StaticAnalyzer/Core/ExprEngineC.cpp
  unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp

Index: unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp
===
--- unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp
+++ unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp
@@ -21,16 +21,7 @@
 namespace ento {
 namespace {
 
-class CustomChecker : public Checker {
-public:
-  void checkASTCodeBody(const Decl *D, AnalysisManager &Mgr,
-BugReporter &BR) const {
-BR.EmitBasicReport(D, this, "Custom diagnostic", categories::LogicError,
-   "Custom diagnostic description",
-   PathDiagnosticLocation(D, Mgr.getSourceManager()), {});
-  }
-};
-
+template 
 class TestAction : public ASTFrontendAction {
   class DiagConsumer : public PathDiagnosticConsumer {
 llvm::raw_ostream &Output;
@@ -59,23 +50,55 @@
 Compiler.getAnalyzerOpts()->CheckersControlList = {
 {"custom.CustomChecker", true}};
 AnalysisConsumer->AddCheckerRegistrationFn([](CheckerRegistry &Registry) {
-  Registry.addChecker("custom.CustomChecker", "Description",
- "");
+  Registry.addChecker("custom.CustomChecker", "Description", "");
 });
 return std::move(AnalysisConsumer);
   }
 };
 
+template 
+bool runCheckerOnCode(const std::string &Code, std::string &Diags) {
+  llvm::raw_string_ostream OS(Diags);
+  return tooling::runToolOnCode(new TestAction(OS), Code);
+}
+template 
+bool runCheckerOnCode(const std::string &Code) {
+  std::string Diags;
+  return runCheckerOnCode(Code, Diags);
+}
+
+
+class CustomChecker : public Checker {
+public:
+  void checkASTCodeBody(const Decl *D, AnalysisManager &Mgr,
+BugReporter &BR) const {
+BR.EmitBasicReport(D, this, "Custom diagnostic", categories::LogicError,
+   "Custom diagnostic description",
+   PathDiagnosticLocation(D, Mgr.getSourceManager()), {});
+  }
+};
 
 TEST(RegisterCustomCheckers, RegisterChecker) {
   std::string Diags;
-  {
-llvm::raw_string_ostream OS(Diags);
-EXPECT_TRUE(tooling::runToolOnCode(new TestAction(OS), "void f() {;}"));
-  }
+  EXPECT_TRUE(runCheckerOnCode("void f() {;}", Diags));
   EXPECT_EQ(Diags, "custom.CustomChecker:Custom diagnostic description");
 }
 
+class LocIncDecChecker : public Checker {
+public:
+  void checkLocation(SVal Loc, bool IsLoad, const Stmt *S,
+ CheckerContext &C) const {
+auto UnaryOp = dyn_cast(S);
+if (UnaryOp && !IsLoad)
+  EXPECT_FALSE(UnaryOp->isIncrementOp());
+  }
+};
+
+TEST(RegisterCustomCheckers, CheckLocationIncDec) {
+  EXPECT_TRUE(
+  runCheckerOnCode("void f() { int *p; (*p)++; }"));
+}
+
 }
 }
 }
Index: lib/StaticAnalyzer/Core/ExprEngineC.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngineC.cpp
+++ lib/StaticAnalyzer/Core/ExprEngineC.cpp
@@ -1052,7 +1052,7 @@
   // Perform the store, so that the uninitialized value detection happens.
   Bldr.takeNodes(*I);
   ExplodedNodeSet Dst3;
-  evalStore(Dst3, U, U, *I, state, loc, V2_untested);
+  evalStore(Dst3, U, Ex, *I, state, loc, V2_untested);
   Bldr.addNodes(Dst3);
 
   continue;
@@ -1120,7 +1120,7 @@
 // Perform the store.
 Bldr.takeNodes(*I);
 ExplodedNodeSet Dst3;
-evalStore(Dst3, U, U, *I, state, loc, Result);
+evalStore(Dst3, U, Ex, *I, state, loc, Result);
 Bldr.addNodes(Dst3);
   }
   Dst.insert(Dst2);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r350527 - [AST] Store some data of CXXNewExpr as trailing objects

2019-01-07 Thread Bruno Ricci via cfe-commits
Author: brunoricci
Date: Mon Jan  7 07:04:45 2019
New Revision: 350527

URL: http://llvm.org/viewvc/llvm-project?rev=350527&view=rev
Log:
[AST] Store some data of CXXNewExpr as trailing objects

Store the optional array size expression, optional initialization expression
and optional placement new arguments in a trailing array. Additionally store
the range for the parenthesized type-id in a trailing object if needed since
in the vast majority of cases the type is not parenthesized (not a single new
expression in the translation unit of SemaDecl.cpp has a parenthesized type-id).

This saves 2 pointers per CXXNewExpr in all cases, and 2 pointers + 8 bytes
per CXXNewExpr in the common case where the type is not parenthesized.

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

Reviewed By: rjmccall


Modified:
cfe/trunk/include/clang/AST/ExprCXX.h
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/lib/AST/ASTImporter.cpp
cfe/trunk/lib/AST/ExprCXX.cpp
cfe/trunk/lib/CodeGen/CGExprCXX.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
cfe/trunk/lib/Serialization/ASTWriterStmt.cpp

Modified: cfe/trunk/include/clang/AST/ExprCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprCXX.h?rev=350527&r1=350526&r2=350527&view=diff
==
--- cfe/trunk/include/clang/AST/ExprCXX.h (original)
+++ cfe/trunk/include/clang/AST/ExprCXX.h Mon Jan  7 07:04:45 2019
@@ -1933,54 +1933,56 @@ public:
 
 /// Represents a new-expression for memory allocation and constructor
 /// calls, e.g: "new CXXNewExpr(foo)".
-class CXXNewExpr : public Expr {
+class CXXNewExpr final
+: public Expr,
+  private llvm::TrailingObjects {
   friend class ASTStmtReader;
   friend class ASTStmtWriter;
-
-  /// Contains an optional array size expression, an optional initialization
-  /// expression, and any number of optional placement arguments, in that 
order.
-  Stmt **SubExprs = nullptr;
+  friend TrailingObjects;
 
   /// Points to the allocation function used.
   FunctionDecl *OperatorNew;
 
-  /// Points to the deallocation function used in case of error. May be
-  /// null.
+  /// Points to the deallocation function used in case of error. May be null.
   FunctionDecl *OperatorDelete;
 
   /// The allocated type-source information, as written in the source.
   TypeSourceInfo *AllocatedTypeInfo;
 
-  /// If the allocated type was expressed as a parenthesized type-id,
-  /// the source range covering the parenthesized type-id.
-  SourceRange TypeIdParens;
-
   /// Range of the entire new expression.
   SourceRange Range;
 
   /// Source-range of a paren-delimited initializer.
   SourceRange DirectInitRange;
 
-  /// Was the usage ::new, i.e. is the global new to be used?
-  unsigned GlobalNew : 1;
-
-  /// Do we allocate an array? If so, the first SubExpr is the size expression.
-  unsigned Array : 1;
+  // CXXNewExpr is followed by several optional trailing objects.
+  // They are in order:
+  //
+  // * An optional "Stmt *" for the array size expression.
+  //Present if and ony if isArray().
+  //
+  // * An optional "Stmt *" for the init expression.
+  //Present if and only if hasInitializer().
+  //
+  // * An array of getNumPlacementArgs() "Stmt *" for the placement new
+  //   arguments, if any.
+  //
+  // * An optional SourceRange for the range covering the parenthesized type-id
+  //if the allocated type was expressed as a parenthesized type-id.
+  //Present if and only if isParenTypeId().
+  unsigned arraySizeOffset() const { return 0; }
+  unsigned initExprOffset() const { return arraySizeOffset() + isArray(); }
+  unsigned placementNewArgsOffset() const {
+return initExprOffset() + hasInitializer();
+  }
 
-  /// Should the alignment be passed to the allocation function?
-  unsigned PassAlignment : 1;
+  unsigned numTrailingObjects(OverloadToken) const {
+return isArray() + hasInitializer() + getNumPlacementArgs();
+  }
 
-  /// If this is an array allocation, does the usual deallocation
-  /// function for the allocated type want to know the allocated size?
-  unsigned UsualArrayDeleteWantsSize : 1;
-
-  /// The number of placement new arguments.
-  unsigned NumPlacementArgs : 26;
-
-  /// What kind of initializer do we have? Could be none, parens, or braces.
-  /// In storage, we distinguish between "none, and no initializer expr", and
-  /// "none, but an implicit initializer expr".
-  unsigned StoredInitializationStyle : 2;
+  unsigned numTrailingObjects(OverloadToken) const {
+return isParenTypeId();
+  }
 
 public:
   enum InitializationStyle {
@@ -1994,18 +1996,35 @@ public:
 ListInit
   };
 
-  CXXNewExpr(const ASTContext &C, bool globalNew, FunctionDecl *operatorNew,
- FunctionDecl *operatorDelete, bool PassAlignment,
- bool usualArrayDeleteWantsSize, ArrayRef placementArgs,
- SourceRange typeIdPare

[clang-tools-extra] r350526 - [clang-tidy] Use the public hasInit matcher, rather than defining our own, NFC

2019-01-07 Thread Hyrum Wright via cfe-commits
Author: hwright
Date: Mon Jan  7 06:36:47 2019
New Revision: 350526

URL: http://llvm.org/viewvc/llvm-project?rev=350526&view=rev
Log:
[clang-tidy] Use the public hasInit matcher, rather than defining our own, NFC

Modified:
clang-tools-extra/trunk/clang-tidy/abseil/DurationRewriter.cpp

Modified: clang-tools-extra/trunk/clang-tidy/abseil/DurationRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/abseil/DurationRewriter.cpp?rev=350526&r1=350525&r2=350526&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/abseil/DurationRewriter.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/abseil/DurationRewriter.cpp Mon Jan  7 
06:36:47 2019
@@ -104,20 +104,6 @@ llvm::StringRef getFactoryForScale(Durat
   llvm_unreachable("unknown scaling factor");
 }
 
-/// Matches the n'th item of an initializer list expression.
-///
-/// Example matches y.
-/// (matcher = initListExpr(hasInit(0, expr(
-/// \code
-///   int x{y}.
-/// \endcode
-AST_MATCHER_P2(InitListExpr, hasInit, unsigned, N,
-   ast_matchers::internal::Matcher, InnerMatcher) {
-  return N < Node.getNumInits() &&
-  InnerMatcher.matches(*Node.getInit(N)->IgnoreParenImpCasts(), Finder,
-   Builder);
-}
-
 /// Returns `true` if `Node` is a value which evaluates to a literal `0`.
 bool IsLiteralZero(const MatchFinder::MatchResult &Result, const Expr &Node) {
   auto ZeroMatcher =
@@ -132,13 +118,13 @@ bool IsLiteralZero(const MatchFinder::Ma
   // Now check to see if we're using a functional cast with a scalar
   // initializer expression, e.g. `int{0}`.
   if (selectFirst(
-  "val",
-  match(cxxFunctionalCastExpr(
-hasDestinationType(
-anyOf(isInteger(), realFloatingPointType())),
-hasSourceExpression(initListExpr(hasInit(0, ZeroMatcher
-.bind("val"),
-Node, *Result.Context)) != nullptr)
+  "val", match(cxxFunctionalCastExpr(
+   hasDestinationType(
+   anyOf(isInteger(), realFloatingPointType())),
+   hasSourceExpression(initListExpr(
+   hasInit(0, 
ignoringParenImpCasts(ZeroMatcher)
+   .bind("val"),
+   Node, *Result.Context)) != nullptr)
 return true;
 
   return false;


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


  1   2   >