[PATCH] D56429: fix python3 compability issue

2019-01-08 Thread rox via Phabricator via cfe-commits
roxma created this revision.
roxma added reviewers: ilya-biryukov, mgorny.
Herald added subscribers: cfe-commits, arphaman.
Herald added a reviewer: serge-sans-paille.

The file contents could be of str type. Should use byte length instead
of str length, otherwise utf-8 encoded files may not get properly parsed
for completion.

  

Source issue: https://github.com/ncm2/ncm2-pyclang#2


Repository:
  rC Clang

https://reviews.llvm.org/D56429

Files:
  bindings/python/clang/cindex.py


Index: bindings/python/clang/cindex.py
===
--- bindings/python/clang/cindex.py
+++ bindings/python/clang/cindex.py
@@ -2815,9 +2815,9 @@
 for i, (name, contents) in enumerate(unsaved_files):
 if hasattr(contents, "read"):
 contents = contents.read()
-
+contents = b(contents)
 unsaved_array[i].name = b(fspath(name))
-unsaved_array[i].contents = b(contents)
+unsaved_array[i].contents = contents
 unsaved_array[i].length = len(contents)
 
 ptr = conf.lib.clang_parseTranslationUnit(index,
@@ -2994,17 +2994,13 @@
 unsaved_files_array = 0
 if len(unsaved_files):
 unsaved_files_array = (_CXUnsavedFile * len(unsaved_files))()
-for i,(name,value) in enumerate(unsaved_files):
-if not isinstance(value, str):
-# FIXME: It would be great to support an efficient version
-# of this, one day.
-value = value.read()
-print(value)
-if not isinstance(value, str):
-raise TypeError('Unexpected unsaved file contents.')
-unsaved_files_array[i].name = fspath(name)
-unsaved_files_array[i].contents = value
-unsaved_files_array[i].length = len(value)
+for i,(name,contents) in enumerate(unsaved_files):
+if hasattr(contents, "read"):
+contents = contents.read()
+contents = b(contents)
+unsaved_files_array[i].name = b(fspath(name))
+unsaved_files_array[i].contents = contents
+unsaved_files_array[i].length = len(contents)
 ptr = conf.lib.clang_reparseTranslationUnit(self, len(unsaved_files),
 unsaved_files_array, options)
 
@@ -3058,17 +3054,13 @@
 unsaved_files_array = 0
 if len(unsaved_files):
 unsaved_files_array = (_CXUnsavedFile * len(unsaved_files))()
-for i,(name,value) in enumerate(unsaved_files):
-if not isinstance(value, str):
-# FIXME: It would be great to support an efficient version
-# of this, one day.
-value = value.read()
-print(value)
-if not isinstance(value, str):
-raise TypeError('Unexpected unsaved file contents.')
+for i,(name,contents) in enumerate(unsaved_files):
+if hasattr(contents, "read"):
+contents = contents.read()
+contents = b(contents)
 unsaved_files_array[i].name = b(fspath(name))
-unsaved_files_array[i].contents = b(value)
-unsaved_files_array[i].length = len(value)
+unsaved_files_array[i].contents = contents
+unsaved_files_array[i].length = len(contents)
 ptr = conf.lib.clang_codeCompleteAt(self, fspath(path), line, column,
 unsaved_files_array, len(unsaved_files), options)
 if ptr:


Index: bindings/python/clang/cindex.py
===
--- bindings/python/clang/cindex.py
+++ bindings/python/clang/cindex.py
@@ -2815,9 +2815,9 @@
 for i, (name, contents) in enumerate(unsaved_files):
 if hasattr(contents, "read"):
 contents = contents.read()
-
+contents = b(contents)
 unsaved_array[i].name = b(fspath(name))
-unsaved_array[i].contents = b(contents)
+unsaved_array[i].contents = contents
 unsaved_array[i].length = len(contents)
 
 ptr = conf.lib.clang_parseTranslationUnit(index,
@@ -2994,17 +2994,13 @@
 unsaved_files_array = 0
 if len(unsaved_files):
 unsaved_files_array = (_CXUnsavedFile * len(unsaved_files))()
-for i,(name,value) in enumerate(unsaved_files):
-if not isinstance(value, str):
-# FIXME: It would be great to support an efficient version
-# of this, one day.
-value = value.read()
-print(value)
-if not isinstance(value, str):
-raise TypeError('Unexpected unsaved file cont

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

2019-01-08 Thread Justin Lebar via Phabricator via cfe-commits
jlebar added a comment.

Without reading the patch in detail (sorry) but looking mainly at the testcase: 
It looks like we're not checking how overloading and `__host__ __device__` 
functions play into this.  Maybe there are some additional edge-cases to 
explore/check.

Just some examples:

Will we DTRT and parse `bar` call as calling the `device` overload of `bar` in

  __host__ void bar() {}
  __device__ int bar() { return 0; }
  __host__ __device__ void foo() { int x = bar(); }
  template  __global__ void kernel() { devF();}
  
  kernel();

?  Also will we know that we don't have to codegen `foo` for host (so `foo` is 
actually able to do things that only device functions can)?

Another one: How should the following template be instantiated?

  __host__ constexpr int n() { return 0; }
  __device__ constexpr int n() { return 1; }
  template  __global__ void kernel() {}
  
  kernel

Presumably the call to `n` should be the host one?  That seems correct to me, 
but then it's pretty odd that a function pointer template argument would point 
to a *device* function.  Maybe that's the right thing, but I bet I can come up 
with something weird, like:

  __host__ void bar() {}
  __device__ int bar() { return 0; }
  __device__ auto baz() -> decltype(foo()) {} // which n() does it call?  
Presumably host, but:
  __device__ auto baz() -> decltype(bar()) {}  // does baz return void or int?  
Presumably...the device one, int?

Now mix in templates and sizeof and...yeah.  Rife for opportunities.  :)


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] D56429: fix python3 compability issue

2019-01-08 Thread serge via Phabricator via cfe-commits
serge-sans-paille added inline comments.



Comment at: bindings/python/clang/cindex.py:2998
+for i,(name,contents) in enumerate(unsaved_files):
+if hasattr(contents, "read"):
+contents = contents.read()

Why did you remove the FIXME comment?


Repository:
  rC Clang

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

https://reviews.llvm.org/D56429



___
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-08 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

Thanks, mostly good to me. just a few nits.




Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:72
+TestName.consume_front(kDisabledTestPrefix);
+if (TestName.find('_') != std::string::npos) {
+  Check->diag(TestNameToken->getLocation(),

nit: using `Test.contains`



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.h:10
+
+#ifndef 
LLVM_TOOLS_CLANG_TOOLS_EXTRA_CLANG_TIDY_CLANG_TIDY_READABILITY_UNDERSCORE_IN_GOOGLETEST_TEST_MACRO_H_
+#define 
LLVM_TOOLS_CLANG_TOOLS_EXTRA_CLANG_TIDY_CLANG_TIDY_READABILITY_UNDERSCORE_IN_GOOGLETEST_TEST_MACRO_H_

nit: the header guard should be 
`LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_GOOGLE_AVOIDUNDERSCOREINGOOGLETESTNAMECHECK_H`



Comment at: 
docs/clang-tidy/checks/google-readability-avoid-underscore-in-googletest-name.rst:3
+
+google-readability-avoid-underscore-in-googletest-name
+==

nit: also mention the new check in `/docs/ReleaseNotes.rst`



Comment at: 
docs/clang-tidy/checks/google-readability-avoid-underscore-in-googletest-name.rst:7
+Checks whether there are underscores in googletest test and test case names in
+test macros, not including the ``FRIEND_TEST`` macro.
+

maybe list all test macros that the check detects?


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] D55433: [clang-tidy] Adding a new modernize use nodiscard checker

2019-01-08 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 180625.
MyDeveloperDay added a comment.

Sorry to add another revision but, rerunning no-discard checker on LLVM code 
base threw up other [[nodiscard]] placements which whilst they MAY be correct, 
I don't think we should handle in this first pass.

- conversion functions e.g. operator bool()
- lambdas
- add tests to validate both


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

https://reviews.llvm.org/D55433

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/UseNodiscardCheck.cpp
  clang-tidy/modernize/UseNodiscardCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-use-nodiscard.rst
  test/clang-tidy/modernize-use-nodiscard-clang-unused.cpp
  test/clang-tidy/modernize-use-nodiscard-cxx11.cpp
  test/clang-tidy/modernize-use-nodiscard-gcc-unused.cpp
  test/clang-tidy/modernize-use-nodiscard-no-macro-inscope-cxx11.cpp
  test/clang-tidy/modernize-use-nodiscard-no-macro.cpp
  test/clang-tidy/modernize-use-nodiscard.cpp
  test/clang-tidy/modernize-use-nodiscard.h

Index: test/clang-tidy/modernize-use-nodiscard.h
===
--- /dev/null
+++ test/clang-tidy/modernize-use-nodiscard.h
@@ -0,0 +1,5 @@
+
+#define MUST_USE_RESULT __attribute__((warn_unused_result))
+#define NO_DISCARD [[nodiscard]]
+#define NO_RETURN [[noreturn]]
+
Index: test/clang-tidy/modernize-use-nodiscard.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-nodiscard.cpp
@@ -0,0 +1,250 @@
+// RUN: %check_clang_tidy %s modernize-use-nodiscard %t -- \
+// RUN:   -config="{CheckOptions: [{key: modernize-use-nodiscard.ReplacementString, value: 'NO_DISCARD'}]}" \
+// RUN: -- -std=c++17 
+
+#include 
+
+namespace boost {
+template  
+class function;
+}
+
+#include "modernize-use-nodiscard.h"
+
+#define BOOLEAN_FUNC bool f23() const
+
+typedef unsigned my_unsigned;
+typedef unsigned &my_unsigned_reference;
+typedef const unsigned &my_unsigned_const_reference;
+
+class Foo {
+public:
+using size_type = unsigned;
+
+bool f1() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f1' should be marked NO_DISCARD [modernize-use-nodiscard] 
+// CHECK-FIXES: NO_DISCARD bool f1() const;
+
+bool f2(int) const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f2' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD bool f2(int) const;
+
+bool f3(const int &) const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f3' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD bool f3(const int &) const;
+
+bool f4(void) const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f4' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD bool f4(void) const;
+
+// negative tests
+
+void f5() const;
+
+bool f6();
+
+bool f7(int &);
+
+bool f8(int &) const;
+
+bool f9(int *) const;
+
+bool f10(const int &, int &) const;
+
+NO_DISCARD bool f12() const;
+
+MUST_USE_RESULT bool f13() const;
+
+[[nodiscard]] bool f11() const;
+
+[[clang::warn_unused_result]] bool f11a() const;
+
+[[gnu::warn_unused_result]] bool f11b() const;
+
+bool _f20() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function '_f20' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD bool _f20() const;
+
+NO_RETURN bool f21() const;
+
+~Foo();
+
+bool operator+=(int) const;
+
+// extra keywords (virtual,inline,const) on return type
+
+virtual bool f14() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f14' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD virtual bool f14() const;
+
+const bool f15() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f15' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD const bool f15() const;
+
+inline const bool f16() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f16' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD inline const bool f16() const;
+
+inline const std::string &f45() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f45' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD inline const std::string &f45() const;
+
+inline virtual const bool f17() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f17' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD inline virtual const bool f17() const;
+
+// inline with body
+bool f18() const {
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f18' should be marked

[PATCH] D56415: NFC: Port QueryParser to StringRef

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

Run clang-format


Repository:
  rCTE Clang Tools Extra

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

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 (!isWhitespace(*Begin))
-  break;
-
-++Begin;
-  }
+  if (Line.empty())
+return StringRef(Line.begin(), 0);
 
-  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,8 +163,7 @@
 
 QueryRef QueryParser::completeMatcherExpression() {
   std::vector Comps = Parser::completeExpression(
-  StringRef(Begin, End - Begin), CompletionPos - Begin, nullptr,
-  &QS.NamedValues);
+  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,8 +210,8 @@
 
 Diagnostics Diag;
 ast_matchers::dynamic::VariantValue Value;
-if (!Parser::parseExpression(StringRef(Begin, End - Begin), nullptr,
- &QS.NamedValues, &Value, &Diag)) {
+if (!Parser::parseExpression(Line, nullptr, &QS.NamedValues, &Value,
+ &Diag)) {
   return makeInvalidQueryFromDiagnostics(Diag);
 }
 
@@ -235,7 +223,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] D56415: NFC: Port QueryParser to StringRef

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

Thanks, I ran clang-format, and I'd rather let it be the rulemaker, rather than 
try to add newlines in the lambdas :).




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

kristina wrote:
> I don't think this is the best way of handling it, in fact I'm pretty certain 
> you're leaking memory here.
Hmm, I didn't know we could get a mem leak with StringRef. Can you explain?


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] D55646: [ASTImporter] Make ODR diagnostics warning by default

2019-01-08 Thread Endre Fülöp via Phabricator via cfe-commits
gamesh411 added a comment.

Hey Aleksei!
Thank you for the input! ODR violations being warnings would be beneficial from 
the code maintenance point of view, as we would not have to resort to duplicate 
some (if not most) of them as errors. There is also a flexibility advantage in 
the diagnostics, as warnings can be propagated to error level or suppressed, 
whereas errors cannot be "demoted" (AFAIK).  So while I am not opposed to 
providing an error AND a warning for these kinds of violations, if the SEMA or 
other modules do not need them to be explicitly defined as errors (for I don't 
know... tooling support or other reasons), then it would be cleaner to only 
have warnings for these.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55646



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


[PATCH] D55646: [ASTImporter] Make ODR diagnostics warning by default

2019-01-08 Thread Endre Fülöp via Phabricator via cfe-commits
gamesh411 added a comment.

Ping.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55646



___
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-08 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added inline comments.



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:1
+//===--- AvoidUnderscoreInGoogletestNameCheck.cpp - 
clang-tidy-===//
+//

nit: space after tidy and before ---



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.h:1
+//===--- AvoidUnderscoreInGoogletestNameCheck.h - 
clang-tidy---===//
+//

nit: I think you may have used an older version of add_new_check.py because the 
header looks like this now

A gap after the tidy and *- C++ -*

```
//===--- UseNodiscardCheck.h - clang-tidy ---*- C++ -*-===//
```

This could be why the header guard isn't the correct format


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] D56160: [clang-tidy] modernize-use-trailing-return check

2019-01-08 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added inline comments.



Comment at: test/clang-tidy/modernize-use-trailing-return.cpp:1
+// RUN: %check_clang_tidy %s modernize-use-trailing-return %t -- -- --std=c++14
+

nit: is there a reason here why you say C++14 when the code checks for C++11? 


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] D56160: [clang-tidy] modernize-use-trailing-return check

2019-01-08 Thread Bernhard Manfred Gruber via Phabricator via cfe-commits
bernhardmgruber marked 2 inline comments as done.
bernhardmgruber added inline comments.



Comment at: test/clang-tidy/modernize-use-trailing-return.cpp:1
+// RUN: %check_clang_tidy %s modernize-use-trailing-return %t -- -- --std=c++14
+

MyDeveloperDay wrote:
> nit: is there a reason here why you say C++14 when the code checks for C++11? 
Yes. The tests contain functions with deduced return types, such as `auto 
f();`. Those require C++14. The check itself is fine with C++11.


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] D56430: Incorrect implicit data-sharing for nested tasks

2019-01-08 Thread Sergi Mateo via Phabricator via cfe-commits
smateo created this revision.
smateo added a reviewer: ABataev.
smateo added a project: OpenMP.
Herald added a subscriber: cfe-commits.

There is a minor issue in how the implicit data-sharings for nested tasks are 
computed.

For the following example:

  int x;
  #pragma omp task shared(x)
  #pragma omp task
  x++;

We compute an implicit data-sharing of shared for `x` in the second task 
although I think that it should be firstprivate. Below you can find the part of 
the OpenMP spec that covers this example:

- // In a task generating construct, if no default clause is present, a 
variable for which the data-sharing attribute is not determined by the rules 
above and that in the enclosing context is determined to be shared by all 
implicit tasks bound to the current team is shared.//
- //In a task generating construct, if no default clause is present, a variable 
for which the data-sharing attribute is not determined by the rules above is 
firstprivate.//

Since each implicit-task has its own copy of `x`, we shouldn't apply the first 
rule.


Repository:
  rC Clang

https://reviews.llvm.org/D56430

Files:
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/task_messages.cpp


Index: test/OpenMP/task_messages.cpp
===
--- test/OpenMP/task_messages.cpp
+++ test/OpenMP/task_messages.cpp
@@ -8,7 +8,7 @@
 #pragma omp task // expected-error {{unexpected OpenMP directive '#pragma omp 
task'}}
 
 class S {
-  S(const S &s) { a = s.a + 12; } // expected-note 14 {{implicitly declared 
private here}}
+  S(const S &s) { a = s.a + 12; } // expected-note 16 {{implicitly declared 
private here}}
   int a;
 
 public:
@@ -51,6 +51,15 @@
   ++a; // expected-error {{calling a private constructor of class 'S'}}
 #pragma omp task default(shared)
 #pragma omp task
+  // expected-error@+1 {{calling a private constructor of class 'S'}}
+  ++a;
+#pragma omp parallel shared(a)
+#pragma omp task
+#pragma omp task
+  ++a;
+#pragma omp parallel shared(a)
+#pragma omp task default(shared)
+#pragma omp task
   ++a;
 #pragma omp task
 #pragma omp parallel
@@ -205,6 +214,15 @@
   ++sa; // expected-error {{calling a private constructor of class 'S'}}
 #pragma omp task default(shared)
 #pragma omp task
+  // expected-error@+1 {{calling a private constructor of class 'S'}}
+  ++sa;
+#pragma omp parallel shared(sa)
+#pragma omp task
+#pragma omp task
+  ++sa;
+#pragma omp parallel shared(sa)
+#pragma omp task default(shared)
+#pragma omp task
   ++sa;
 #pragma omp task
 #pragma omp parallel
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -676,9 +676,13 @@
   }
 
 };
+
+bool isParallelRegion(OpenMPDirectiveKind DKind) {
+  return isOpenMPParallelDirective(DKind) || isOpenMPTeamsDirective(DKind);
+}
+
 bool isParallelOrTaskRegion(OpenMPDirectiveKind DKind) {
-  return isOpenMPParallelDirective(DKind) || isOpenMPTaskingDirective(DKind) ||
- isOpenMPTeamsDirective(DKind) || DKind == OMPD_unknown;
+  return isParallelRegion(DKind) || isOpenMPTaskingDirective(DKind) || DKind 
== OMPD_unknown;
 }
 
 } // namespace
@@ -819,7 +823,7 @@
   DVar.CKind = OMPC_firstprivate;
   return DVar;
 }
-  } while (I != E && !isParallelOrTaskRegion(I->Directive));
+  } while (I != E && !isParallelRegion(I->Directive));
   DVar.CKind =
   (DVarTemp.CKind == OMPC_unknown) ? OMPC_firstprivate : OMPC_shared;
   return DVar;


Index: test/OpenMP/task_messages.cpp
===
--- test/OpenMP/task_messages.cpp
+++ test/OpenMP/task_messages.cpp
@@ -8,7 +8,7 @@
 #pragma omp task // expected-error {{unexpected OpenMP directive '#pragma omp task'}}
 
 class S {
-  S(const S &s) { a = s.a + 12; } // expected-note 14 {{implicitly declared private here}}
+  S(const S &s) { a = s.a + 12; } // expected-note 16 {{implicitly declared private here}}
   int a;
 
 public:
@@ -51,6 +51,15 @@
   ++a; // expected-error {{calling a private constructor of class 'S'}}
 #pragma omp task default(shared)
 #pragma omp task
+  // expected-error@+1 {{calling a private constructor of class 'S'}}
+  ++a;
+#pragma omp parallel shared(a)
+#pragma omp task
+#pragma omp task
+  ++a;
+#pragma omp parallel shared(a)
+#pragma omp task default(shared)
+#pragma omp task
   ++a;
 #pragma omp task
 #pragma omp parallel
@@ -205,6 +214,15 @@
   ++sa; // expected-error {{calling a private constructor of class 'S'}}
 #pragma omp task default(shared)
 #pragma omp task
+  // expected-error@+1 {{calling a private constructor of class 'S'}}
+  ++sa;
+#pragma omp parallel shared(sa)
+#pragma omp task
+#pragma omp task
+  ++sa;
+#pragma omp parallel shared(sa)
+#pragma omp task default(shared)
+#pragma omp task
   ++sa;
 #pragma omp task
 #pragma omp parallel
Index: lib/Sema/SemaOpenMP.cpp
=

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

2019-01-08 Thread Haojian Wu via Phabricator via cfe-commits
hokein marked an inline comment as done.
hokein added inline comments.



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

ilya-biryukov wrote:
> 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)
This is a good point.

For class member completions, we rely solely on Sema completions (no query 
being queried). I'm not sure it is practical to query the index for member 
completions.
- this means for **every** code completion, we query the index, it may slow 
down completions
- `fuzzyFind` is not supported for class members in our internal index service 
(due to the large number of them)

So it turns two possibilities:

1) always store comments (`SymbolCollector` doesn't know whether it is used in 
static index or dynamic index)
2) or drop them for now, this wouldn't break anything, and add it back when we 
actually use them for class completions

I slightly prefer 2) at the moment. WDYT?


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] D56430: Incorrect implicit data-sharing for nested tasks

2019-01-08 Thread Sergi Mateo via Phabricator via cfe-commits
smateo updated this revision to Diff 180631.
smateo added a comment.

Adding more context


Repository:
  rC Clang

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

https://reviews.llvm.org/D56430

Files:
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/task_messages.cpp


Index: test/OpenMP/task_messages.cpp
===
--- test/OpenMP/task_messages.cpp
+++ test/OpenMP/task_messages.cpp
@@ -8,7 +8,7 @@
 #pragma omp task // expected-error {{unexpected OpenMP directive '#pragma omp 
task'}}
 
 class S {
-  S(const S &s) { a = s.a + 12; } // expected-note 14 {{implicitly declared 
private here}}
+  S(const S &s) { a = s.a + 12; } // expected-note 16 {{implicitly declared 
private here}}
   int a;
 
 public:
@@ -51,6 +51,15 @@
   ++a; // expected-error {{calling a private constructor of class 'S'}}
 #pragma omp task default(shared)
 #pragma omp task
+  // expected-error@+1 {{calling a private constructor of class 'S'}}
+  ++a;
+#pragma omp parallel shared(a)
+#pragma omp task
+#pragma omp task
+  ++a;
+#pragma omp parallel shared(a)
+#pragma omp task default(shared)
+#pragma omp task
   ++a;
 #pragma omp task
 #pragma omp parallel
@@ -205,6 +214,15 @@
   ++sa; // expected-error {{calling a private constructor of class 'S'}}
 #pragma omp task default(shared)
 #pragma omp task
+  // expected-error@+1 {{calling a private constructor of class 'S'}}
+  ++sa;
+#pragma omp parallel shared(sa)
+#pragma omp task
+#pragma omp task
+  ++sa;
+#pragma omp parallel shared(sa)
+#pragma omp task default(shared)
+#pragma omp task
   ++sa;
 #pragma omp task
 #pragma omp parallel
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -676,9 +676,13 @@
   }
 
 };
+
+bool isParallelRegion(OpenMPDirectiveKind DKind) {
+  return isOpenMPParallelDirective(DKind) || isOpenMPTeamsDirective(DKind);
+}
+
 bool isParallelOrTaskRegion(OpenMPDirectiveKind DKind) {
-  return isOpenMPParallelDirective(DKind) || isOpenMPTaskingDirective(DKind) ||
- isOpenMPTeamsDirective(DKind) || DKind == OMPD_unknown;
+  return isParallelRegion(DKind) || isOpenMPTaskingDirective(DKind) || DKind 
== OMPD_unknown;
 }
 
 } // namespace
@@ -819,7 +823,7 @@
   DVar.CKind = OMPC_firstprivate;
   return DVar;
 }
-  } while (I != E && !isParallelOrTaskRegion(I->Directive));
+  } while (I != E && !isParallelRegion(I->Directive));
   DVar.CKind =
   (DVarTemp.CKind == OMPC_unknown) ? OMPC_firstprivate : OMPC_shared;
   return DVar;


Index: test/OpenMP/task_messages.cpp
===
--- test/OpenMP/task_messages.cpp
+++ test/OpenMP/task_messages.cpp
@@ -8,7 +8,7 @@
 #pragma omp task // expected-error {{unexpected OpenMP directive '#pragma omp task'}}
 
 class S {
-  S(const S &s) { a = s.a + 12; } // expected-note 14 {{implicitly declared private here}}
+  S(const S &s) { a = s.a + 12; } // expected-note 16 {{implicitly declared private here}}
   int a;
 
 public:
@@ -51,6 +51,15 @@
   ++a; // expected-error {{calling a private constructor of class 'S'}}
 #pragma omp task default(shared)
 #pragma omp task
+  // expected-error@+1 {{calling a private constructor of class 'S'}}
+  ++a;
+#pragma omp parallel shared(a)
+#pragma omp task
+#pragma omp task
+  ++a;
+#pragma omp parallel shared(a)
+#pragma omp task default(shared)
+#pragma omp task
   ++a;
 #pragma omp task
 #pragma omp parallel
@@ -205,6 +214,15 @@
   ++sa; // expected-error {{calling a private constructor of class 'S'}}
 #pragma omp task default(shared)
 #pragma omp task
+  // expected-error@+1 {{calling a private constructor of class 'S'}}
+  ++sa;
+#pragma omp parallel shared(sa)
+#pragma omp task
+#pragma omp task
+  ++sa;
+#pragma omp parallel shared(sa)
+#pragma omp task default(shared)
+#pragma omp task
   ++sa;
 #pragma omp task
 #pragma omp parallel
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -676,9 +676,13 @@
   }
 
 };
+
+bool isParallelRegion(OpenMPDirectiveKind DKind) {
+  return isOpenMPParallelDirective(DKind) || isOpenMPTeamsDirective(DKind);
+}
+
 bool isParallelOrTaskRegion(OpenMPDirectiveKind DKind) {
-  return isOpenMPParallelDirective(DKind) || isOpenMPTaskingDirective(DKind) ||
- isOpenMPTeamsDirective(DKind) || DKind == OMPD_unknown;
+  return isParallelRegion(DKind) || isOpenMPTaskingDirective(DKind) || DKind == OMPD_unknown;
 }
 
 } // namespace
@@ -819,7 +823,7 @@
   DVar.CKind = OMPC_firstprivate;
   return DVar;
 }
-  } while (I != E && !isParallelOrTaskRegion(I->Directive));
+  } while (I != E && !isParallelRegion(I->Directive));
   DVar.CKind =
   (DVarTemp.CKind == OMPC_unknown) ? OMPC_firstprivate : OMPC_shared;
   return DVar;
_

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

2019-01-08 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added inline comments.



Comment at: test/clang-tidy/modernize-use-trailing-return.cpp:1
+// RUN: %check_clang_tidy %s modernize-use-trailing-return %t -- -- --std=c++14
+

bernhardmgruber wrote:
> MyDeveloperDay wrote:
> > nit: is there a reason here why you say C++14 when the code checks for 
> > C++11? 
> Yes. The tests contain functions with deduced return types, such as `auto 
> f();`. Those require C++14. The check itself is fine with C++11.
I kind of half guessed it would be something like that after I hit submit,  I 
noticed some checks add secondary test files which test the various versions of 
C++, to be honest I found this useful for the checker I'm developing, 
especially as the checker has some slightly different behavior with C++11 to 
C++17, but maybe yours doesn't

to be honest i'm also fairly new here so don't know exactly the convention

examples where this is already done in other peoples checkers

modernize-deprecated-headers-cxx03.cpp
modernize-deprecated-headers-cxx11.cpp

```
// RUN: %check_clang_tidy %s modernize-deprecated-headers %t -- 
-extra-arg-before=-isystem%S/Inputs/modernize-deprecated-headers -- -std=c++03 
-v

// RUN: %check_clang_tidy %s modernize-deprecated-headers %t -- 
-extra-arg-before=-isystem%S/Inputs/modernize-deprecated-headers -- -std=c++11 
-v

```



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] D56160: [clang-tidy] modernize-use-trailing-return check

2019-01-08 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added inline comments.



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

bernhardmgruber wrote:
> 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.
@bernhardmgruber I had the same comment given to me on a review recently with 
regard to diag message, let me try and help you with what I though was the 
rational... I think the premise is something like:

1) "no FixIt provided" is implied by the fact it isn't fixed
2) "function type source info is missing"  doesn't tell the developer what they 
have to do to have it be fixed

sure it helps you as the checker developer but probably that isn't much use to 
a developer using the checker on their code and so might confuse them.

It also makes grepping for messages in a log file difficult because it means 
multiple messages coming from your checker have a different pattern (although 
there might be a common sub pattern)

For the most part where a fixit is not supplied where it should someone would 
create a test case which you could consume in your tests

To be honest as a general observation as a newbie myself, what I've noticed is 
that a lot of checker review comments are very similar, 



  - 80 characters in rst files
  - clang-format
  - alphabetic order
  - Comments with proper puncuation
  - code in comments in ``XXX``
  - don't overly use auto
  - don't use anonymous namespace functions use static functions
  - run it on a big C++ project
  - run it over all of LLVM
  - consistency of coding style (elide unnecessary const)
  - elide unnecessary braces/brackets/code/etc..



We really should try and write a "Writing a clang checker, and getting it 
though review" primer, because I really feel for these "gaints" that we ask to 
review all this code, they must go over the same thing and have to present the 
same reasons time and time again...

which is why If you don't mind I'd like to try to help give something back by 
filling in some of the reasoning gaps here to a fellow new starter










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] D54428: [clangd] XPC transport layer, framework, test-client

2019-01-08 Thread Jan Korous via Phabricator via cfe-commits
jkorous updated this revision to Diff 180640.
jkorous retitled this revision from "[clangd][WIP] XPC transport layer, 
framework, test-client" to "[clangd] XPC transport layer, framework, 
test-client".
jkorous edited the summary of this revision.
jkorous added a comment.

added one more assert


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D54428

Files:
  CMakeLists.txt
  clangd/CMakeLists.txt
  clangd/Features.inc.in
  clangd/Transport.h
  clangd/tool/CMakeLists.txt
  clangd/tool/ClangdMain.cpp
  clangd/xpc/CMakeLists.txt
  clangd/xpc/Conversion.cpp
  clangd/xpc/Conversion.h
  clangd/xpc/README.txt
  clangd/xpc/XPCTransport.cpp
  clangd/xpc/cmake/Info.plist.in
  clangd/xpc/cmake/XPCServiceInfo.plist.in
  clangd/xpc/cmake/modules/CreateClangdXPCFramework.cmake
  clangd/xpc/framework/CMakeLists.txt
  clangd/xpc/framework/ClangdXPC.cpp
  clangd/xpc/test-client/CMakeLists.txt
  clangd/xpc/test-client/ClangdXPCTestClient.cpp
  test/CMakeLists.txt
  test/clangd/xpc/initialize.test
  test/lit.cfg
  test/lit.site.cfg.in
  unittests/clangd/CMakeLists.txt
  unittests/clangd/xpc/CMakeLists.txt
  unittests/clangd/xpc/ConversionTests.cpp

Index: unittests/clangd/xpc/ConversionTests.cpp
===
--- /dev/null
+++ unittests/clangd/xpc/ConversionTests.cpp
@@ -0,0 +1,36 @@
+//===-- ConversionTests.cpp  --*- C++ -*---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "xpc/Conversion.h"
+#include "gtest/gtest.h"
+
+#include 
+
+namespace clang {
+namespace clangd {
+namespace {
+
+using namespace llvm;
+
+TEST(JsonXpcConversionTest, JsonToXpcToJson) {
+
+  for (auto &testcase :
+   {json::Value(false), json::Value(3.14), json::Value(42),
+json::Value(-100), json::Value("foo"), json::Value(""),
+json::Value("123"), json::Value(" "),
+json::Value{true, "foo", nullptr, 42},
+json::Value(json::Object{
+{"a", true}, {"b", "foo"}, {"c", nullptr}, {"d", 42}})}) {
+EXPECT_TRUE(testcase == xpcToJson(jsonToXpc(testcase))) << testcase;
+  }
+}
+
+} // namespace
+} // namespace clangd
+} // namespace clang
Index: unittests/clangd/xpc/CMakeLists.txt
===
--- /dev/null
+++ unittests/clangd/xpc/CMakeLists.txt
@@ -0,0 +1,21 @@
+set(LLVM_LINK_COMPONENTS
+  support
+  )
+
+get_filename_component(CLANGD_SOURCE_DIR
+  ${CMAKE_CURRENT_SOURCE_DIR}/../../clangd REALPATH)
+include_directories(
+  ${CLANGD_SOURCE_DIR}
+  )
+
+add_extra_unittest(ClangdXpcTests
+  ConversionTests.cpp
+  )
+
+target_link_libraries(ClangdXpcTests
+  PRIVATE
+  clangdXpcJsonConversions
+  clangDaemon
+  LLVMSupport
+  LLVMTestingSupport
+  )
Index: unittests/clangd/CMakeLists.txt
===
--- unittests/clangd/CMakeLists.txt
+++ unittests/clangd/CMakeLists.txt
@@ -60,3 +60,7 @@
   LLVMSupport
   LLVMTestingSupport
   )
+
+if (CLANGD_BUILD_XPC)
+  add_subdirectory(xpc)
+endif ()
Index: test/lit.site.cfg.in
===
--- test/lit.site.cfg.in
+++ test/lit.site.cfg.in
@@ -11,6 +11,7 @@
 config.python_executable = "@PYTHON_EXECUTABLE@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.clang_staticanalyzer = @CLANG_ENABLE_STATIC_ANALYZER@
+config.clangd_xpc_support = @CLANGD_BUILD_XPC_SUPPORT@
 
 # Support substitution of the tools and libs dirs with user parameters. This is
 # used when we can't determine the tool dir at configuration time.
Index: test/lit.cfg
===
--- test/lit.cfg
+++ test/lit.cfg
@@ -117,6 +117,10 @@
 if platform.system() not in ['Windows']:
 config.available_features.add('ansi-escape-sequences')
 
+# XPC support for Clangd.
+if config.clangd_xpc_support:
+config.available_features.add('clangd-xpc-support')
+
 if config.clang_staticanalyzer:
 config.available_features.add('static-analyzer')
 
Index: test/clangd/xpc/initialize.test
===
--- /dev/null
+++ test/clangd/xpc/initialize.test
@@ -0,0 +1,10 @@
+# RUN: clangd-xpc-test-client < %s | FileCheck %s
+# REQUIRES: clangd-xpc-support
+
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootUri":"test:///workspace","capabilities":{},"trace":"off"}}
+# CHECK: {"id":0,"jsonrpc":"2.0","result":{"capabilities"
+
+{"jsonrpc":"2.0","id":3,"method":"shutdown"}
+# CHECK: {"id":3,"jsonrpc":"2.0","result":null}
+
+{"jsonrpc":"2.0","method":"exit"}
Index: test/CMakeLists.txt
=

r350619 - [X86] Add shift-by-immediate tests for non-immediate/out-of-range values

2019-01-08 Thread Simon Pilgrim via cfe-commits
Author: rksimon
Date: Tue Jan  8 04:59:15 2019
New Revision: 350619

URL: http://llvm.org/viewvc/llvm-project?rev=350619&view=rev
Log:
[X86] Add shift-by-immediate tests for non-immediate/out-of-range values

As noted on PR40203, for gcc compatibility we need to support non-immediate 
values in the 'slli/srli/srai' shift by immediate vector intrinsics.

Modified:
cfe/trunk/test/CodeGen/avx2-builtins.c
cfe/trunk/test/CodeGen/avx512bw-builtins.c
cfe/trunk/test/CodeGen/avx512f-builtins.c
cfe/trunk/test/CodeGen/avx512vl-builtins.c
cfe/trunk/test/CodeGen/avx512vlbw-builtins.c
cfe/trunk/test/CodeGen/sse2-builtins.c

Modified: cfe/trunk/test/CodeGen/avx2-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx2-builtins.c?rev=350619&r1=350618&r2=350619&view=diff
==
--- cfe/trunk/test/CodeGen/avx2-builtins.c (original)
+++ cfe/trunk/test/CodeGen/avx2-builtins.c Tue Jan  8 04:59:15 2019
@@ -995,18 +995,36 @@ __m256i test_mm256_slli_epi16(__m256i a)
   return _mm256_slli_epi16(a, 3);
 }
 
+__m256i test_mm256_slli_epi16_2(__m256i a, int b) {
+  // CHECK-LABEL: test_mm256_slli_epi16_2
+  // CHECK: call <16 x i16> @llvm.x86.avx2.pslli.w(<16 x i16> %{{.*}}, i32 
%{{.*}})
+  return _mm256_slli_epi16(a, b);
+}
+
 __m256i test_mm256_slli_epi32(__m256i a) {
   // CHECK-LABEL: test_mm256_slli_epi32
   // CHECK: call <8 x i32> @llvm.x86.avx2.pslli.d(<8 x i32> %{{.*}}, i32 
%{{.*}})
   return _mm256_slli_epi32(a, 3);
 }
 
+__m256i test_mm256_slli_epi32_2(__m256i a, int b) {
+  // CHECK-LABEL: test_mm256_slli_epi32_2
+  // CHECK: call <8 x i32> @llvm.x86.avx2.pslli.d(<8 x i32> %{{.*}}, i32 
%{{.*}})
+  return _mm256_slli_epi32(a, b);
+}
+
 __m256i test_mm256_slli_epi64(__m256i a) {
   // CHECK-LABEL: test_mm256_slli_epi64
   // CHECK: call <4 x i64> @llvm.x86.avx2.pslli.q(<4 x i64> %{{.*}}, i32 
%{{.*}})
   return _mm256_slli_epi64(a, 3);
 }
 
+__m256i test_mm256_slli_epi64_2(__m256i a, int b) {
+  // CHECK-LABEL: test_mm256_slli_epi64_2
+  // CHECK: call <4 x i64> @llvm.x86.avx2.pslli.q(<4 x i64> %{{.*}}, i32 
%{{.*}})
+  return _mm256_slli_epi64(a, b);
+}
+
 __m256i test_mm256_slli_si256(__m256i a) {
   // CHECK-LABEL: test_mm256_slli_si256
   // CHECK: shufflevector <32 x i8> zeroinitializer, <32 x i8> %{{.*}}, <32 x 
i32> 
@@ -1055,12 +1073,24 @@ __m256i test_mm256_srai_epi16(__m256i a)
   return _mm256_srai_epi16(a, 3);
 }
 
+__m256i test_mm256_srai_epi16_2(__m256i a, int b) {
+  // CHECK-LABEL: test_mm256_srai_epi16_2
+  // CHECK: call <16 x i16> @llvm.x86.avx2.psrai.w(<16 x i16> %{{.*}}, i32 
%{{.*}})
+  return _mm256_srai_epi16(a, b);
+}
+
 __m256i test_mm256_srai_epi32(__m256i a) {
   // CHECK-LABEL: test_mm256_srai_epi32
   // CHECK: call <8 x i32> @llvm.x86.avx2.psrai.d(<8 x i32> %{{.*}}, i32 
%{{.*}})
   return _mm256_srai_epi32(a, 3);
 }
 
+__m256i test_mm256_srai_epi32_2(__m256i a, int b) {
+  // CHECK-LABEL: test_mm256_srai_epi32_2
+  // CHECK: call <8 x i32> @llvm.x86.avx2.psrai.d(<8 x i32> %{{.*}}, i32 
%{{.*}})
+  return _mm256_srai_epi32(a, b);
+}
+
 __m128i test_mm_srav_epi32(__m128i a, __m128i b) {
   // CHECK-LABEL: test_mm_srav_epi32
   // CHECK: call <4 x i32> @llvm.x86.avx2.psrav.d(<4 x i32> %{{.*}}, <4 x i32> 
%{{.*}})
@@ -1097,18 +1127,36 @@ __m256i test_mm256_srli_epi16(__m256i a)
   return _mm256_srli_epi16(a, 3);
 }
 
+__m256i test_mm256_srli_epi16_2(__m256i a, int b) {
+  // CHECK-LABEL: test_mm256_srli_epi16_2
+  // CHECK: call <16 x i16> @llvm.x86.avx2.psrli.w(<16 x i16> %{{.*}}, i32 
%{{.*}})
+  return _mm256_srli_epi16(a, b);
+}
+
 __m256i test_mm256_srli_epi32(__m256i a) {
   // CHECK-LABEL: test_mm256_srli_epi32
   // CHECK: call <8 x i32> @llvm.x86.avx2.psrli.d(<8 x i32> %{{.*}}, i32 
%{{.*}})
   return _mm256_srli_epi32(a, 3);
 }
 
+__m256i test_mm256_srli_epi32_2(__m256i a, int b) {
+  // CHECK-LABEL: test_mm256_srli_epi32_2
+  // CHECK: call <8 x i32> @llvm.x86.avx2.psrli.d(<8 x i32> %{{.*}}, i32 
%{{.*}})
+  return _mm256_srli_epi32(a, b);
+}
+
 __m256i test_mm256_srli_epi64(__m256i a) {
   // CHECK-LABEL: test_mm256_srli_epi64
   // CHECK: call <4 x i64> @llvm.x86.avx2.psrli.q(<4 x i64> %{{.*}}, i32 
%{{.*}})
   return _mm256_srli_epi64(a, 3);
 }
 
+__m256i test_mm256_srli_epi64_2(__m256i a, int b) {
+  // CHECK-LABEL: test_mm256_srli_epi64_2
+  // CHECK: call <4 x i64> @llvm.x86.avx2.psrli.q(<4 x i64> %{{.*}}, i32 
%{{.*}})
+  return _mm256_srli_epi64(a, b);
+}
+
 __m256i test_mm256_srli_si256(__m256i a) {
   // CHECK-LABEL: test_mm256_srli_si256
   // CHECK: shufflevector <32 x i8> %{{.*}}, <32 x i8> zeroinitializer, <32 x 
i32> 

Modified: cfe/trunk/test/CodeGen/avx512bw-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx512bw-builtins.c?rev=350619&r1=350618&r2=350619&view=diff
==
--- cfe/trunk/test/CodeGen/avx512bw-builtins.c (original)
+++ cfe/trunk/test/Cod

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

2019-01-08 Thread Bruno Ricci via Phabricator via cfe-commits
riccibruno marked an inline comment as done.
riccibruno added a comment.

I have no more remark, but since I am just a new contributor to clang I am sure
people will have more to say about this patch. Thanks !




Comment at: lib/AST/Expr.cpp:2091
+   : PLoc.getColumn();
+return APValue(IntVal);
+  }

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

It was just a very small remark saying that you were doing unsigned -> signed 
-> unsigned
for no apparent reason. Anyway the current way looks fine to me. 


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] D56050: [Sema] Diagnose array access preceding the array bounds even when the base type is incomplete.

2019-01-08 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL350622: [Sema] Diagnose array access preceding the array 
bounds even when the base type… (authored by brunoricci, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D56050?vs=179423&id=180647#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56050

Files:
  cfe/trunk/lib/Sema/SemaChecking.cpp
  cfe/trunk/test/SemaCXX/array-bounds.cpp


Index: cfe/trunk/test/SemaCXX/array-bounds.cpp
===
--- cfe/trunk/test/SemaCXX/array-bounds.cpp
+++ cfe/trunk/test/SemaCXX/array-bounds.cpp
@@ -287,9 +287,12 @@
 
 namespace PR39746 {
   struct S;
-  extern S xxx[2];
+  extern S xxx[2]; // expected-note {{array 'xxx' declared here}}
   class C {};
 
   C &f() { return reinterpret_cast(xxx)[1]; } // no-warning
+  // We have no info on whether this is out-of-bounds.
   C &g() { return reinterpret_cast(xxx)[2]; } // no-warning
+  // We can still diagnose this.
+  C &h() { return reinterpret_cast(xxx)[-1]; } // expected-warning 
{{array index -1 is before the beginning of the array}}
 }
Index: cfe/trunk/lib/Sema/SemaChecking.cpp
===
--- cfe/trunk/lib/Sema/SemaChecking.cpp
+++ cfe/trunk/lib/Sema/SemaChecking.cpp
@@ -12383,12 +12383,6 @@
 return;
 
   const Type *BaseType = ArrayTy->getElementType().getTypePtr();
-  // It is possible that the type of the base expression after IgnoreParenCasts
-  // is incomplete, even though the type of the base expression before
-  // IgnoreParenCasts is complete (see PR39746 for an example). In this case we
-  // have no information about whether the array access is out-of-bounds.
-  if (BaseType->isIncompleteType())
-return;
 
   Expr::EvalResult Result;
   if (!IndexExpr->EvaluateAsInt(Result, Context, Expr::SE_AllowSideEffects))
@@ -12405,6 +12399,15 @@
 ND = ME->getMemberDecl();
 
   if (index.isUnsigned() || !index.isNegative()) {
+// It is possible that the type of the base expression after
+// IgnoreParenCasts is incomplete, even though the type of the base
+// expression before IgnoreParenCasts is complete (see PR39746 for an
+// example). In this case we have no information about whether the array
+// access exceeds the array bounds. However we can still diagnose an array
+// access which precedes the array bounds.
+if (BaseType->isIncompleteType())
+  return;
+
 llvm::APInt size = ArrayTy->getSize();
 if (!size.isStrictlyPositive())
   return;


Index: cfe/trunk/test/SemaCXX/array-bounds.cpp
===
--- cfe/trunk/test/SemaCXX/array-bounds.cpp
+++ cfe/trunk/test/SemaCXX/array-bounds.cpp
@@ -287,9 +287,12 @@
 
 namespace PR39746 {
   struct S;
-  extern S xxx[2];
+  extern S xxx[2]; // expected-note {{array 'xxx' declared here}}
   class C {};
 
   C &f() { return reinterpret_cast(xxx)[1]; } // no-warning
+  // We have no info on whether this is out-of-bounds.
   C &g() { return reinterpret_cast(xxx)[2]; } // no-warning
+  // We can still diagnose this.
+  C &h() { return reinterpret_cast(xxx)[-1]; } // expected-warning {{array index -1 is before the beginning of the array}}
 }
Index: cfe/trunk/lib/Sema/SemaChecking.cpp
===
--- cfe/trunk/lib/Sema/SemaChecking.cpp
+++ cfe/trunk/lib/Sema/SemaChecking.cpp
@@ -12383,12 +12383,6 @@
 return;
 
   const Type *BaseType = ArrayTy->getElementType().getTypePtr();
-  // It is possible that the type of the base expression after IgnoreParenCasts
-  // is incomplete, even though the type of the base expression before
-  // IgnoreParenCasts is complete (see PR39746 for an example). In this case we
-  // have no information about whether the array access is out-of-bounds.
-  if (BaseType->isIncompleteType())
-return;
 
   Expr::EvalResult Result;
   if (!IndexExpr->EvaluateAsInt(Result, Context, Expr::SE_AllowSideEffects))
@@ -12405,6 +12399,15 @@
 ND = ME->getMemberDecl();
 
   if (index.isUnsigned() || !index.isNegative()) {
+// It is possible that the type of the base expression after
+// IgnoreParenCasts is incomplete, even though the type of the base
+// expression before IgnoreParenCasts is complete (see PR39746 for an
+// example). In this case we have no information about whether the array
+// access exceeds the array bounds. However we can still diagnose an array
+// access which precedes the array bounds.
+if (BaseType->isIncompleteType())
+  return;
+
 llvm::APInt size = ArrayTy->getSize();
 if (!size.isStrictlyPositive())
   return;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman

r350622 - [Sema] Diagnose array access preceding the array bounds even when the base type is incomplete.

2019-01-08 Thread Bruno Ricci via cfe-commits
Author: brunoricci
Date: Tue Jan  8 05:52:54 2019
New Revision: 350622

URL: http://llvm.org/viewvc/llvm-project?rev=350622&view=rev
Log:
[Sema] Diagnose array access preceding the array bounds even when the base type 
is incomplete.

When the type of the base expression after IgnoreParenCasts is incomplete,
it is still possible to diagnose an array access which precedes the array
bounds.

This is a follow-up on D55862 which added an early return when the type of
the base expression after IgnoreParenCasts was incomplete.

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

Reviewed By: efriedma


Modified:
cfe/trunk/lib/Sema/SemaChecking.cpp
cfe/trunk/test/SemaCXX/array-bounds.cpp

Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=350622&r1=350621&r2=350622&view=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Tue Jan  8 05:52:54 2019
@@ -12383,12 +12383,6 @@ void Sema::CheckArrayAccess(const Expr *
 return;
 
   const Type *BaseType = ArrayTy->getElementType().getTypePtr();
-  // It is possible that the type of the base expression after IgnoreParenCasts
-  // is incomplete, even though the type of the base expression before
-  // IgnoreParenCasts is complete (see PR39746 for an example). In this case we
-  // have no information about whether the array access is out-of-bounds.
-  if (BaseType->isIncompleteType())
-return;
 
   Expr::EvalResult Result;
   if (!IndexExpr->EvaluateAsInt(Result, Context, Expr::SE_AllowSideEffects))
@@ -12405,6 +12399,15 @@ void Sema::CheckArrayAccess(const Expr *
 ND = ME->getMemberDecl();
 
   if (index.isUnsigned() || !index.isNegative()) {
+// It is possible that the type of the base expression after
+// IgnoreParenCasts is incomplete, even though the type of the base
+// expression before IgnoreParenCasts is complete (see PR39746 for an
+// example). In this case we have no information about whether the array
+// access exceeds the array bounds. However we can still diagnose an array
+// access which precedes the array bounds.
+if (BaseType->isIncompleteType())
+  return;
+
 llvm::APInt size = ArrayTy->getSize();
 if (!size.isStrictlyPositive())
   return;

Modified: cfe/trunk/test/SemaCXX/array-bounds.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/array-bounds.cpp?rev=350622&r1=350621&r2=350622&view=diff
==
--- cfe/trunk/test/SemaCXX/array-bounds.cpp (original)
+++ cfe/trunk/test/SemaCXX/array-bounds.cpp Tue Jan  8 05:52:54 2019
@@ -287,9 +287,12 @@ int test_struct_multiarray() {
 
 namespace PR39746 {
   struct S;
-  extern S xxx[2];
+  extern S xxx[2]; // expected-note {{array 'xxx' declared here}}
   class C {};
 
   C &f() { return reinterpret_cast(xxx)[1]; } // no-warning
+  // We have no info on whether this is out-of-bounds.
   C &g() { return reinterpret_cast(xxx)[2]; } // no-warning
+  // We can still diagnose this.
+  C &h() { return reinterpret_cast(xxx)[-1]; } // expected-warning 
{{array index -1 is before the beginning of the array}}
 }


___
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-08 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added inline comments.



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

MyDeveloperDay wrote:
> bernhardmgruber wrote:
> > 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.
> @bernhardmgruber I had the same comment given to me on a review recently with 
> regard to diag message, let me try and help you with what I though was the 
> rational... I think the premise is something like:
> 
> 1) "no FixIt provided" is implied by the fact it isn't fixed
> 2) "function type source info is missing"  doesn't tell the developer what 
> they have to do to have it be fixed
> 
> sure it helps you as the checker developer but probably that isn't much use 
> to a developer using the checker on their code and so might confuse them.
> 
> It also makes grepping for messages in a log file difficult because it means 
> multiple messages coming from your checker have a different pattern (although 
> there might be a common sub pattern)
> 
> For the most part where a fixit is not supplied where it should someone would 
> create a test case which you could consume in your tests
> 
> To be honest as a general observation as a newbie myself, what I've noticed 
> is that a lot of checker review comments are very similar, 
> 
> 
> 
>   - 80 characters in rst files
>   - clang-format
>   - alphabetic order
>   - Comments with proper puncuation
>   - code in comments in ``XXX``
>   - don't overly use auto
>   - don't use anonymous namespace functions use static functions
>   - run it on a big C++ project
>   - run it over all of LLVM
>   - consistency of coding style (elide unnecessary const)
>   - elide unnecessary braces/brackets/code/etc..
> 
> 
> 
> We really should try and write a "Writing a clang checker, and getting it 
> though review" primer, because I really feel for these "gaints" that we ask 
> to review all this code, they must go over the same thing and have to present 
> the same reasons time and time again...
> 
> which is why If you don't mind I'd like to try to help give something back by 
> filling in some of the reasoning gaps here to a fellow new starter
> 
> 
> 
> 
> 
> 
> 
> 
I would say that we should eat own dog food :-)

I'd love to see your documentation validation scripts as part of build!

We also should regularly run Clang-tidy on BuildBot. But first we must fix 
existing warnings and no everybody happy if such cleanups performed by 
outsiders.

See PR27267 for anonymous namespaces usage.

Clang-tidy has modernize-use-auto, but not check for LLVM guidelines 
conformance.

Braces should be checked by readability-braces-around-statements, but proper 
setup is needed.

Conformance to readability-else-after-return is another typical newbies problem.


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] D56391: Limit COFF 'common' emission to <=32 alignment types.

2019-01-08 Thread Erich Keane via Phabricator via cfe-commits
erichkeane updated this revision to Diff 180650.
erichkeane marked an inline comment as done.

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

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().isKnownWindowsMSVCEnvironment() &&
+  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().isKnownWindowsMSVCEnvironment() &&
+  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] D56391: Limit COFF 'common' emission to <=32 alignment types.

2019-01-08 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei accepted this revision.
pengfei added a comment.
This revision is now accepted and ready to land.

LGTM, thanks Erich.


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


r350625 - [AST] Pack CXXDependentScopeMemberExpr

2019-01-08 Thread Bruno Ricci via cfe-commits
Author: brunoricci
Date: Tue Jan  8 06:17:00 2019
New Revision: 350625

URL: http://llvm.org/viewvc/llvm-project?rev=350625&view=rev
Log:
[AST] Pack CXXDependentScopeMemberExpr

Use the newly available space in the bit-fields of Stmt. Additionally store
FirstQualifierFoundInScope as a trailing object since it is most of the time
null (non-null for 2 of the 35446 CXXDependentScopeMemberExpr when parsing
all of Boost).

It would be possible to move the data for the nested-name-specifier to a
trailing object too to save another 2 pointers, however doing so did actually
regress the time taken to parse all of Boost slightly.

This saves 8 bytes + 1 pointer per CXXDependentScopeMemberExpr in the vast
majority of cases.

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

Reviewed By: rjmccall


Modified:
cfe/trunk/include/clang/AST/ExprCXX.h
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/lib/AST/ExprCXX.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=350625&r1=350624&r2=350625&view=diff
==
--- cfe/trunk/include/clang/AST/ExprCXX.h (original)
+++ cfe/trunk/include/clang/AST/ExprCXX.h Tue Jan  8 06:17:00 2019
@@ -3306,7 +3306,11 @@ class CXXDependentScopeMemberExpr final
 : public Expr,
   private llvm::TrailingObjects {
+TemplateArgumentLoc, NamedDecl *> {
+  friend class ASTStmtReader;
+  friend class ASTStmtWriter;
+  friend TrailingObjects;
+
   /// The expression for the base pointer or class reference,
   /// e.g., the \c x in x.f.  Can be null in implicit accesses.
   Stmt *Base;
@@ -3315,40 +3319,53 @@ class CXXDependentScopeMemberExpr final
   /// implicit accesses.
   QualType BaseType;
 
-  /// Whether this member expression used the '->' operator or
-  /// the '.' operator.
-  bool IsArrow : 1;
-
-  /// Whether this member expression has info for explicit template
-  /// keyword and arguments.
-  bool HasTemplateKWAndArgsInfo : 1;
-
-  /// The location of the '->' or '.' operator.
-  SourceLocation OperatorLoc;
-
   /// The nested-name-specifier that precedes the member name, if any.
+  /// FIXME: This could be in principle store as a trailing object.
+  /// However the performance impact of doing so should be investigated first.
   NestedNameSpecifierLoc QualifierLoc;
 
-  /// In a qualified member access expression such as t->Base::f, this
-  /// member stores the resolves of name lookup in the context of the member
-  /// access expression, to be used at instantiation time.
-  ///
-  /// FIXME: This member, along with the QualifierLoc, could
-  /// be stuck into a structure that is optionally allocated at the end of
-  /// the CXXDependentScopeMemberExpr, to save space in the common case.
-  NamedDecl *FirstQualifierFoundInScope;
-
   /// The member to which this member expression refers, which
   /// can be name, overloaded operator, or destructor.
   ///
   /// FIXME: could also be a template-id
   DeclarationNameInfo MemberNameInfo;
 
-  size_t numTrailingObjects(OverloadToken) const {
-return HasTemplateKWAndArgsInfo ? 1 : 0;
+  // CXXDependentScopeMemberExpr is followed by several trailing objects,
+  // some of which optional. They are in order:
+  //
+  // * An optional ASTTemplateKWAndArgsInfo for the explicitly specified
+  //   template keyword and arguments. Present if and only if
+  //   hasTemplateKWAndArgsInfo().
+  //
+  // * An array of getNumTemplateArgs() TemplateArgumentLoc containing location
+  //   information for the explicitly specified template arguments.
+  //
+  // * An optional NamedDecl *. In a qualified member access expression such
+  //   as t->Base::f, this member stores the resolves of name lookup in the
+  //   context of the member access expression, to be used at instantiation
+  //   time. Present if and only if hasFirstQualifierFoundInScope().
+
+  bool hasTemplateKWAndArgsInfo() const {
+return CXXDependentScopeMemberExprBits.HasTemplateKWAndArgsInfo;
+  }
+
+  bool hasFirstQualifierFoundInScope() const {
+return CXXDependentScopeMemberExprBits.HasFirstQualifierFoundInScope;
+  }
+
+  unsigned numTrailingObjects(OverloadToken) const {
+return hasTemplateKWAndArgsInfo();
+  }
+
+  unsigned numTrailingObjects(OverloadToken) const {
+return getNumTemplateArgs();
   }
 
-  CXXDependentScopeMemberExpr(const ASTContext &C, Expr *Base,
+  unsigned numTrailingObjects(OverloadToken) const {
+return hasFirstQualifierFoundInScope();
+  }
+
+  CXXDependentScopeMemberExpr(const ASTContext &Ctx, Expr *Base,
   QualType BaseType, bool IsArrow,
   SourceLocation OperatorLoc,
   NestedNameSpecifierLoc QualifierLoc,
@@ -3357,33 +3374,29 @@ class CXXDepend

[PATCH] D56367: [AST] Pack CXXDependentScopeMemberExpr

2019-01-08 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC350625: [AST] Pack CXXDependentScopeMemberExpr (authored by 
brunoricci, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D56367?vs=180407&id=180651#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D56367

Files:
  include/clang/AST/ExprCXX.h
  include/clang/AST/Stmt.h
  lib/AST/ExprCXX.cpp
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp

Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -1584,22 +1584,37 @@
   E->SubExpr = Record.readSubExpr();
 }
 
-void
-ASTStmtReader::VisitCXXDependentScopeMemberExpr(CXXDependentScopeMemberExpr *E){
+void ASTStmtReader::VisitCXXDependentScopeMemberExpr(
+CXXDependentScopeMemberExpr *E) {
   VisitExpr(E);
 
-  if (Record.readInt()) // HasTemplateKWAndArgsInfo
+  bool HasTemplateKWAndArgsInfo = Record.readInt();
+  unsigned NumTemplateArgs = Record.readInt();
+  bool HasFirstQualifierFoundInScope = Record.readInt();
+
+  assert((HasTemplateKWAndArgsInfo == E->hasTemplateKWAndArgsInfo()) &&
+ "Wrong HasTemplateKWAndArgsInfo!");
+  assert(
+  (HasFirstQualifierFoundInScope == E->hasFirstQualifierFoundInScope()) &&
+  "Wrong HasFirstQualifierFoundInScope!");
+
+  if (HasTemplateKWAndArgsInfo)
 ReadTemplateKWAndArgsInfo(
 *E->getTrailingObjects(),
-E->getTrailingObjects(),
-/*NumTemplateArgs=*/Record.readInt());
+E->getTrailingObjects(), NumTemplateArgs);
 
-  E->Base = Record.readSubExpr();
+  assert((NumTemplateArgs == E->getNumTemplateArgs()) &&
+ "Wrong NumTemplateArgs!");
+
+  E->CXXDependentScopeMemberExprBits.IsArrow = Record.readInt();
+  E->CXXDependentScopeMemberExprBits.OperatorLoc = ReadSourceLocation();
   E->BaseType = Record.readType();
-  E->IsArrow = Record.readInt();
-  E->OperatorLoc = ReadSourceLocation();
   E->QualifierLoc = Record.readNestedNameSpecifierLoc();
-  E->FirstQualifierFoundInScope = ReadDeclAs();
+  E->Base = Record.readSubExpr();
+
+  if (HasFirstQualifierFoundInScope)
+*E->getTrailingObjects() = ReadDeclAs();
+
   ReadDeclarationNameInfo(E->MemberNameInfo);
 }
 
@@ -3224,11 +3239,12 @@
   break;
 
 case EXPR_CXX_DEPENDENT_SCOPE_MEMBER:
-  S = CXXDependentScopeMemberExpr::CreateEmpty(Context,
- /*HasTemplateKWAndArgsInfo=*/Record[ASTStmtReader::NumExprFields],
-  /*NumTemplateArgs=*/Record[ASTStmtReader::NumExprFields]
-   ? Record[ASTStmtReader::NumExprFields + 1]
-   : 0);
+  S = CXXDependentScopeMemberExpr::CreateEmpty(
+  Context,
+  /*HasTemplateKWAndArgsInfo=*/Record[ASTStmtReader::NumExprFields],
+  /*NumTemplateArgs=*/Record[ASTStmtReader::NumExprFields + 1],
+  /*HasFirstQualifierFoundInScope=*/
+  Record[ASTStmtReader::NumExprFields + 2]);
   break;
 
 case EXPR_CXX_DEPENDENT_SCOPE_DECL_REF:
Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -1554,31 +1554,36 @@
   Code = serialization::EXPR_EXPR_WITH_CLEANUPS;
 }
 
-void
-ASTStmtWriter::VisitCXXDependentScopeMemberExpr(CXXDependentScopeMemberExpr *E){
+void ASTStmtWriter::VisitCXXDependentScopeMemberExpr(
+CXXDependentScopeMemberExpr *E) {
   VisitExpr(E);
 
-  // Don't emit anything here, HasTemplateKWAndArgsInfo must be
-  // emitted first.
+  // Don't emit anything here (or if you do you will have to update
+  // the corresponding deserialization function).
 
-  Record.push_back(E->HasTemplateKWAndArgsInfo);
-  if (E->HasTemplateKWAndArgsInfo) {
+  Record.push_back(E->hasTemplateKWAndArgsInfo());
+  Record.push_back(E->getNumTemplateArgs());
+  Record.push_back(E->hasFirstQualifierFoundInScope());
+
+  if (E->hasTemplateKWAndArgsInfo()) {
 const ASTTemplateKWAndArgsInfo &ArgInfo =
 *E->getTrailingObjects();
-Record.push_back(ArgInfo.NumTemplateArgs);
 AddTemplateKWAndArgsInfo(ArgInfo,
  E->getTrailingObjects());
   }
 
+  Record.push_back(E->isArrow());
+  Record.AddSourceLocation(E->getOperatorLoc());
+  Record.AddTypeRef(E->getBaseType());
+  Record.AddNestedNameSpecifierLoc(E->getQualifierLoc());
   if (!E->isImplicitAccess())
 Record.AddStmt(E->getBase());
   else
 Record.AddStmt(nullptr);
-  Record.AddTypeRef(E->getBaseType());
-  Record.push_back(E->isArrow());
-  Record.AddSourceLocation(E->getOperatorLoc());
-  Record.AddNestedNameSpecifierLoc(E->getQualifierLoc());
-  Record.AddDeclRef(E->getFirstQualifierFoundInScope());
+
+  if (E->hasFirstQualifierFoundInScope())
+Record.AddDeclRef(E->getFirstQua

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

2019-01-08 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:
> 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.
> 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.

Ah, those are all good points!

> (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.)

I have a slight preference for this approach; it feels a bit more natural to 
me. However, do we want to spell it `delete-nonabstract-non-virtual-dtor` or 
`delete-non-abstract-non-virtual-dtor` or `delete-nonabstract-nonvirtual-dtor`? 
My preference is for anything but the first spelling. ;-)

> Instead / as well, we could address the false positives more directly: 

Yes, improving the fp rate that way would be a great change to make. That said, 
I would view it as "as well" rather than "instead" because these two diagnostic 
scenarios seem reasonably separable.


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] D56430: Incorrect implicit data-sharing for nested tasks

2019-01-08 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:680
+
+bool isParallelRegion(OpenMPDirectiveKind DKind) {
+  return isOpenMPParallelDirective(DKind) || isOpenMPTeamsDirective(DKind);

Better to rename it to `isImplicitTaskingRegion`


Repository:
  rC Clang

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

https://reviews.llvm.org/D56430



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


[PATCH] D56438: [Modules] Allow modulemap path change for implicitly built modules

2019-01-08 Thread Yuka Takahashi via Phabricator via cfe-commits
yamaguchi created this revision.
yamaguchi added reviewers: rsmith, dblaikie.

Previous code was comparing the location of "modulemap which
is currently loaded and gives a definition of current module"
and "the location of the modulemap where the current implicit module was built".

This check was problematic for the usecase when installing modulemaps and 
prebuilt pcms
to other (e.g install) directories.


https://reviews.llvm.org/D56438

Files:
  clang/lib/Serialization/ASTReader.cpp


Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -3632,7 +3632,8 @@
 
 // Check the primary module map file.
 const FileEntry *StoredModMap = FileMgr.getFile(F.ModuleMapPath);
-if (StoredModMap == nullptr || StoredModMap != ModMap) {
+if (!PP.getPreprocessorOpts().DisablePCHValidation &&
+(StoredModMap == nullptr || StoredModMap != ModMap)) {
   assert(ModMap && "found module is missing module map file");
   assert(ImportedBy && "top-level import should be verified");
   if ((ClientLoadCapabilities & ARR_OutOfDate) == 0)


Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -3632,7 +3632,8 @@
 
 // Check the primary module map file.
 const FileEntry *StoredModMap = FileMgr.getFile(F.ModuleMapPath);
-if (StoredModMap == nullptr || StoredModMap != ModMap) {
+if (!PP.getPreprocessorOpts().DisablePCHValidation &&
+(StoredModMap == nullptr || StoredModMap != ModMap)) {
   assert(ModMap && "found module is missing module map file");
   assert(ImportedBy && "top-level import should be verified");
   if ((ClientLoadCapabilities & ARR_OutOfDate) == 0)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r350627 - [AST][NFC] Pack CXXNoexceptExpr and SubstNonTypeTemplateParmExpr

2019-01-08 Thread Bruno Ricci via cfe-commits
Author: brunoricci
Date: Tue Jan  8 06:44:34 2019
New Revision: 350627

URL: http://llvm.org/viewvc/llvm-project?rev=350627&view=rev
Log:
[AST][NFC] Pack CXXNoexceptExpr and SubstNonTypeTemplateParmExpr

Use the newly available space in the bit-fields of Stmt.
This saves one pointer per CXXNoexceptExpr/SubstNonTypeTemplateParmExpr.

Use this opportunity to run clang-format on these two classes and
fix some style issues. NFC overall.


Modified:
cfe/trunk/include/clang/AST/ExprCXX.h
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/lib/Serialization/ASTReaderStmt.cpp

Modified: cfe/trunk/include/clang/AST/ExprCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprCXX.h?rev=350627&r1=350626&r2=350627&view=diff
==
--- cfe/trunk/include/clang/AST/ExprCXX.h (original)
+++ cfe/trunk/include/clang/AST/ExprCXX.h Tue Jan  8 06:44:34 2019
@@ -3720,7 +3720,6 @@ inline TemplateArgumentLoc *OverloadExpr
 class CXXNoexceptExpr : public Expr {
   friend class ASTStmtReader;
 
-  bool Value : 1;
   Stmt *Operand;
   SourceRange Range;
 
@@ -3728,21 +3727,23 @@ public:
   CXXNoexceptExpr(QualType Ty, Expr *Operand, CanThrowResult Val,
   SourceLocation Keyword, SourceLocation RParen)
   : Expr(CXXNoexceptExprClass, Ty, VK_RValue, OK_Ordinary,
- /*TypeDependent*/false,
- /*ValueDependent*/Val == CT_Dependent,
+ /*TypeDependent*/ false,
+ /*ValueDependent*/ Val == CT_Dependent,
  Val == CT_Dependent || Operand->isInstantiationDependent(),
  Operand->containsUnexpandedParameterPack()),
-Value(Val == CT_Cannot), Operand(Operand), Range(Keyword, RParen) {}
+Operand(Operand), Range(Keyword, RParen) {
+CXXNoexceptExprBits.Value = Val == CT_Cannot;
+  }
 
   CXXNoexceptExpr(EmptyShell Empty) : Expr(CXXNoexceptExprClass, Empty) {}
 
-  Expr *getOperand() const { return static_cast(Operand); }
+  Expr *getOperand() const { return static_cast(Operand); }
 
-  SourceLocation getBeginLoc() const LLVM_READONLY { return Range.getBegin(); }
-  SourceLocation getEndLoc() const LLVM_READONLY { return Range.getEnd(); }
-  SourceRange getSourceRange() const LLVM_READONLY { return Range; }
+  SourceLocation getBeginLoc() const { return Range.getBegin(); }
+  SourceLocation getEndLoc() const { return Range.getEnd(); }
+  SourceRange getSourceRange() const { return Range; }
 
-  bool getValue() const { return Value; }
+  bool getValue() const { return CXXNoexceptExprBits.Value; }
 
   static bool classof(const Stmt *T) {
 return T->getStmtClass() == CXXNoexceptExprClass;
@@ -3965,27 +3966,27 @@ class SubstNonTypeTemplateParmExpr : pub
   /// The replacement expression.
   Stmt *Replacement;
 
-  /// The location of the non-type template parameter reference.
-  SourceLocation NameLoc;
-
   explicit SubstNonTypeTemplateParmExpr(EmptyShell Empty)
   : Expr(SubstNonTypeTemplateParmExprClass, Empty) {}
 
 public:
-  SubstNonTypeTemplateParmExpr(QualType type,
-   ExprValueKind valueKind,
-   SourceLocation loc,
-   NonTypeTemplateParmDecl *param,
-   Expr *replacement)
-  : Expr(SubstNonTypeTemplateParmExprClass, type, valueKind, OK_Ordinary,
- replacement->isTypeDependent(), replacement->isValueDependent(),
- replacement->isInstantiationDependent(),
- replacement->containsUnexpandedParameterPack()),
-Param(param), Replacement(replacement), NameLoc(loc) {}
-
-  SourceLocation getNameLoc() const { return NameLoc; }
-  SourceLocation getBeginLoc() const LLVM_READONLY { return NameLoc; }
-  SourceLocation getEndLoc() const LLVM_READONLY { return NameLoc; }
+  SubstNonTypeTemplateParmExpr(QualType Ty, ExprValueKind ValueKind,
+   SourceLocation Loc,
+   NonTypeTemplateParmDecl *Param,
+   Expr *Replacement)
+  : Expr(SubstNonTypeTemplateParmExprClass, Ty, ValueKind, OK_Ordinary,
+ Replacement->isTypeDependent(), Replacement->isValueDependent(),
+ Replacement->isInstantiationDependent(),
+ Replacement->containsUnexpandedParameterPack()),
+Param(Param), Replacement(Replacement) {
+SubstNonTypeTemplateParmExprBits.NameLoc = Loc;
+  }
+
+  SourceLocation getNameLoc() const {
+return SubstNonTypeTemplateParmExprBits.NameLoc;
+  }
+  SourceLocation getBeginLoc() const { return getNameLoc(); }
+  SourceLocation getEndLoc() const { return getNameLoc(); }
 
   Expr *getReplacement() const { return cast(Replacement); }
 
@@ -3996,7 +3997,7 @@ public:
   }
 
   // Iterators
-  child_range children() { return child_range(&Replacement, &Replacement+1); }
+  child_range children() { return child_range(&Replacement, &Replacement + 1); 
}
 };
 
 /// Re

[PATCH] D56441: [analyzer][CrossTU][NFC] Generalize to external definitions instead of external functions

2019-01-08 Thread Rafael Stahl via Phabricator via cfe-commits
r.stahl created this revision.
r.stahl added reviewers: NoQ, xazax.hun, martong, a.sidorin.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, rnkovacs, szepet, baloghadamsoftware, whisperity, mgorny.
Herald added a reviewer: george.karpenkov.
Herald added a reviewer: serge-sans-paille.

This is just changing naming and documentation to be general about external 
definitions that can be imported for cross translation unit analysis. There is 
at least a plan to add VarDecls: D46421 


Repository:
  rC Clang

https://reviews.llvm.org/D56441

Files:
  include/clang/Basic/DiagnosticCrossTUKinds.td
  include/clang/CrossTU/CrossTranslationUnit.h
  include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
  lib/CrossTU/CrossTranslationUnit.cpp
  test/Analysis/Inputs/ctu-other.c.externalDefMap.txt
  test/Analysis/Inputs/ctu-other.c.externalFnMap.txt
  test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt
  test/Analysis/Inputs/ctu-other.cpp.externalFnMap.txt
  test/Analysis/analyzer-config.c
  test/Analysis/ctu-different-triples.cpp
  test/Analysis/ctu-main.c
  test/Analysis/ctu-main.cpp
  test/Analysis/ctu-unknown-parts-in-triples.cpp
  test/Analysis/func-mapping-test.cpp
  test/CMakeLists.txt
  test/lit.cfg.py
  tools/CMakeLists.txt
  tools/clang-extdef-mapping/
  tools/clang-extdef-mapping/CMakeLists.txt
  tools/clang-extdef-mapping/ClangExtDefMapGen.cpp
  tools/clang-func-mapping/CMakeLists.txt
  tools/clang-func-mapping/ClangFnMapGen.cpp
  tools/scan-build-py/README.md
  tools/scan-build-py/libscanbuild/__init__.py
  tools/scan-build-py/libscanbuild/analyze.py
  tools/scan-build-py/libscanbuild/arguments.py
  tools/scan-build-py/libscanbuild/clang.py
  tools/scan-build-py/tests/unit/test_analyze.py
  tools/scan-build-py/tests/unit/test_clang.py

Index: tools/scan-build-py/tests/unit/test_clang.py
===
--- tools/scan-build-py/tests/unit/test_clang.py
+++ tools/scan-build-py/tests/unit/test_clang.py
@@ -96,7 +96,7 @@
 
 class ClangIsCtuCapableTest(unittest.TestCase):
 def test_ctu_not_found(self):
-is_ctu = sut.is_ctu_capable('not-found-clang-func-mapping')
+is_ctu = sut.is_ctu_capable('not-found-clang-extdef-mapping')
 self.assertFalse(is_ctu)
 
 
Index: tools/scan-build-py/tests/unit/test_analyze.py
===
--- tools/scan-build-py/tests/unit/test_analyze.py
+++ tools/scan-build-py/tests/unit/test_analyze.py
@@ -349,14 +349,14 @@
 class MergeCtuMapTest(unittest.TestCase):
 
 def test_no_map_gives_empty(self):
-pairs = sut.create_global_ctu_function_map([])
+pairs = sut.create_global_ctu_extdef_map([])
 self.assertFalse(pairs)
 
 def test_multiple_maps_merged(self):
 concat_map = ['c:@F@fun1#I# ast/fun1.c.ast',
   'c:@F@fun2#I# ast/fun2.c.ast',
   'c:@F@fun3#I# ast/fun3.c.ast']
-pairs = sut.create_global_ctu_function_map(concat_map)
+pairs = sut.create_global_ctu_extdef_map(concat_map)
 self.assertTrue(('c:@F@fun1#I#', 'ast/fun1.c.ast') in pairs)
 self.assertTrue(('c:@F@fun2#I#', 'ast/fun2.c.ast') in pairs)
 self.assertTrue(('c:@F@fun3#I#', 'ast/fun3.c.ast') in pairs)
@@ -366,7 +366,7 @@
 concat_map = ['c:@F@fun1#I# ast/fun1.c.ast',
   'c:@F@fun2#I# ast/fun2.c.ast',
   'c:@F@fun1#I# ast/fun7.c.ast']
-pairs = sut.create_global_ctu_function_map(concat_map)
+pairs = sut.create_global_ctu_extdef_map(concat_map)
 self.assertFalse(('c:@F@fun1#I#', 'ast/fun1.c.ast') in pairs)
 self.assertFalse(('c:@F@fun1#I#', 'ast/fun7.c.ast') in pairs)
 self.assertTrue(('c:@F@fun2#I#', 'ast/fun2.c.ast') in pairs)
@@ -376,28 +376,28 @@
 concat_map = ['c:@F@fun1#I# ast/fun1.c.ast',
   'c:@F@fun2#I# ast/fun2.c.ast',
   'c:@F@fun1#I# ast/fun1.c.ast']
-pairs = sut.create_global_ctu_function_map(concat_map)
+pairs = sut.create_global_ctu_extdef_map(concat_map)
 self.assertTrue(('c:@F@fun1#I#', 'ast/fun1.c.ast') in pairs)
 self.assertTrue(('c:@F@fun2#I#', 'ast/fun2.c.ast') in pairs)
 self.assertEqual(2, len(pairs))
 
 def test_space_handled_in_source(self):
 concat_map = ['c:@F@fun1#I# ast/f un.c.ast']
-pairs = sut.create_global_ctu_function_map(concat_map)
+pairs = sut.create_global_ctu_extdef_map(concat_map)
 self.assertTrue(('c:@F@fun1#I#', 'ast/f un.c.ast') in pairs)
 self.assertEqual(1, len(pairs))
 
 
-class FuncMapSrcToAstTest(unittest.TestCase):
+class ExtdefMapSrcToAstTest(unittest.TestCase):
 
 def test_empty_gives_empty(self):
-fun_ast_lst = sut.func_map_list_src_to_ast([])
+fun_ast_lst = sut.extdef_map_list_src_to_ast([])
 self.assertFalse(fun_ast_lst)
 

[PATCH] D56442: [clangd] Fix a crash when reading an empty index file.

2019-01-08 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added a reviewer: ilya-biryukov.
Herald added subscribers: kadircet, arphaman, jkorous, MaskRay, ioeric.

Unfortunately, yaml::Input::setCurrentDocument() and 
yaml::Input::nextDocument() are
internal APIs, the way we use them may cause a nullptr accessing when
processing an empty YAML file.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D56442

Files:
  clangd/index/YAMLSerialization.cpp
  unittests/clangd/SerializationTests.cpp


Index: unittests/clangd/SerializationTests.cpp
===
--- unittests/clangd/SerializationTests.cpp
+++ unittests/clangd/SerializationTests.cpp
@@ -91,6 +91,10 @@
   return (arg.IncludeHeader == IncludeHeader) && (arg.References == 
References);
 }
 
+TEST(SerializationTest, NoCrashOnEmptyYAML) {
+  EXPECT_TRUE(bool(readIndexFile("")));
+}
+
 TEST(SerializationTest, YAMLConversions) {
   auto In = readIndexFile(YAML);
   EXPECT_TRUE(bool(In)) << In.takeError();
Index: clangd/index/YAMLSerialization.cpp
===
--- clangd/index/YAMLSerialization.cpp
+++ clangd/index/YAMLSerialization.cpp
@@ -314,17 +314,20 @@
   Arena; // store the underlying data of Position::FileURI.
   llvm::UniqueStringSaver Strings(Arena);
   llvm::yaml::Input Yin(Data, &Strings);
-  do {
+  while (Yin.setCurrentDocument()) {
+llvm::yaml::EmptyContext Ctx;
 VariantEntry Variant;
-Yin >> Variant;
+yamlize(Yin, Variant, true, Ctx);
 if (Yin.error())
   return llvm::errorCodeToError(Yin.error());
+
 if (Variant.Symbol)
   Symbols.insert(*Variant.Symbol);
 if (Variant.Refs)
   for (const auto &Ref : Variant.Refs->second)
 Refs.insert(Variant.Refs->first, Ref);
-  } while (Yin.nextDocument());
+Yin.nextDocument();
+  }
 
   IndexFileIn Result;
   Result.Symbols.emplace(std::move(Symbols).build());


Index: unittests/clangd/SerializationTests.cpp
===
--- unittests/clangd/SerializationTests.cpp
+++ unittests/clangd/SerializationTests.cpp
@@ -91,6 +91,10 @@
   return (arg.IncludeHeader == IncludeHeader) && (arg.References == References);
 }
 
+TEST(SerializationTest, NoCrashOnEmptyYAML) {
+  EXPECT_TRUE(bool(readIndexFile("")));
+}
+
 TEST(SerializationTest, YAMLConversions) {
   auto In = readIndexFile(YAML);
   EXPECT_TRUE(bool(In)) << In.takeError();
Index: clangd/index/YAMLSerialization.cpp
===
--- clangd/index/YAMLSerialization.cpp
+++ clangd/index/YAMLSerialization.cpp
@@ -314,17 +314,20 @@
   Arena; // store the underlying data of Position::FileURI.
   llvm::UniqueStringSaver Strings(Arena);
   llvm::yaml::Input Yin(Data, &Strings);
-  do {
+  while (Yin.setCurrentDocument()) {
+llvm::yaml::EmptyContext Ctx;
 VariantEntry Variant;
-Yin >> Variant;
+yamlize(Yin, Variant, true, Ctx);
 if (Yin.error())
   return llvm::errorCodeToError(Yin.error());
+
 if (Variant.Symbol)
   Symbols.insert(*Variant.Symbol);
 if (Variant.Refs)
   for (const auto &Ref : Variant.Refs->second)
 Refs.insert(Variant.Refs->first, Ref);
-  } while (Yin.nextDocument());
+Yin.nextDocument();
+  }
 
   IndexFileIn Result;
   Result.Symbols.emplace(std::move(Symbols).build());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D56442: [clangd] Fix a crash when reading an empty index file.

2019-01-08 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks for fixing this.

A few questions for the long-term:

- Should we consider removing the YAML support altogether?
- If we want to keep, are there non-private APIs that we could use? (I assume 
we need them to avoid keeping the whole parsed YAML tree in memory, right?)


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56442



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


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

2019-01-08 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.

I think this is a good approach to solving the problem, so let's go this route.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56407



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


[PATCH] D56441: [analyzer][CrossTU][NFC] Generalize to external definitions instead of external functions

2019-01-08 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun accepted this revision.
xazax.hun added a comment.
This revision is now accepted and ready to land.

Some nits inline. Otherwise looks good to me.




Comment at: include/clang/CrossTU/CrossTranslationUnit.h:32
 class FunctionDecl;
+class VarDecl;
 class NamedDecl;

Unrelated change?



Comment at: include/clang/CrossTU/CrossTranslationUnit.h:106
 
-  /// This function loads a function definition from an external AST
-  ///file and merge it into the original AST.
+  /// This function loads a function or variable definition from an
+  ///external AST file and merges it into the original AST.

These comment changes might better be in the next patch. 


Repository:
  rC Clang

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

https://reviews.llvm.org/D56441



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


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

2019-01-08 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D56407#1349672 , @aaron.ballman 
wrote:

> I think this is a good approach to solving the problem, so let's go this 
> route.


Yeah, I agree here. This ends up being a really clean solution.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56407



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


[PATCH] D56442: [clangd] Fix a crash when reading an empty index file.

2019-01-08 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

In D56442#1349666 , @ilya-biryukov 
wrote:

> LGTM. Thanks for fixing this.
>
> A few questions for the long-term:
>
> - Should we consider removing the YAML support altogether?


The motivation of the YAML is for debugging purpose (compared with the binary 
format), we might want to switch to another human-readable format like json.

> - If we want to keep, are there non-private APIs that we could use? (I assume 
> we need them to avoid keeping the whole parsed YAML tree in memory, right?)

This is the best way we've found so far. The public YAML APIs don't seem 
provide enough flexibility to read an `Variant` element (but I may miss 
something).


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56442



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


[clang-tools-extra] r350633 - [clangd] Fix a crash when reading an empty index file.

2019-01-08 Thread Haojian Wu via cfe-commits
Author: hokein
Date: Tue Jan  8 07:24:47 2019
New Revision: 350633

URL: http://llvm.org/viewvc/llvm-project?rev=350633&view=rev
Log:
[clangd] Fix a crash when reading an empty index file.

Summary:
Unfortunately, yaml::Input::setCurrentDocument() and 
yaml::Input::nextDocument() are
internal APIs, the way we use them may cause a nullptr accessing when
processing an empty YAML file.

Reviewers: ilya-biryukov

Subscribers: ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits

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

Modified:
clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp
clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp

Modified: clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp?rev=350633&r1=350632&r2=350633&view=diff
==
--- clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp (original)
+++ clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp Tue Jan  8 
07:24:47 2019
@@ -314,17 +314,20 @@ llvm::Expected readYAML(llv
   Arena; // store the underlying data of Position::FileURI.
   llvm::UniqueStringSaver Strings(Arena);
   llvm::yaml::Input Yin(Data, &Strings);
-  do {
+  while (Yin.setCurrentDocument()) {
+llvm::yaml::EmptyContext Ctx;
 VariantEntry Variant;
-Yin >> Variant;
+yamlize(Yin, Variant, true, Ctx);
 if (Yin.error())
   return llvm::errorCodeToError(Yin.error());
+
 if (Variant.Symbol)
   Symbols.insert(*Variant.Symbol);
 if (Variant.Refs)
   for (const auto &Ref : Variant.Refs->second)
 Refs.insert(Variant.Refs->first, Ref);
-  } while (Yin.nextDocument());
+Yin.nextDocument();
+  }
 
   IndexFileIn Result;
   Result.Symbols.emplace(std::move(Symbols).build());

Modified: clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp?rev=350633&r1=350632&r2=350633&view=diff
==
--- clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp (original)
+++ clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp Tue Jan  8 
07:24:47 2019
@@ -91,6 +91,10 @@ MATCHER_P2(IncludeHeaderWithRef, Include
   return (arg.IncludeHeader == IncludeHeader) && (arg.References == 
References);
 }
 
+TEST(SerializationTest, NoCrashOnEmptyYAML) {
+  EXPECT_TRUE(bool(readIndexFile("")));
+}
+
 TEST(SerializationTest, YAMLConversions) {
   auto In = readIndexFile(YAML);
   EXPECT_TRUE(bool(In)) << In.takeError();


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


[PATCH] D56442: [clangd] Fix a crash when reading an empty index file.

2019-01-08 Thread Haojian Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL350633: [clangd] Fix a crash when reading an empty index 
file. (authored by hokein, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56442

Files:
  clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp


Index: clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp
===
--- clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp
+++ clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp
@@ -91,6 +91,10 @@
   return (arg.IncludeHeader == IncludeHeader) && (arg.References == 
References);
 }
 
+TEST(SerializationTest, NoCrashOnEmptyYAML) {
+  EXPECT_TRUE(bool(readIndexFile("")));
+}
+
 TEST(SerializationTest, YAMLConversions) {
   auto In = readIndexFile(YAML);
   EXPECT_TRUE(bool(In)) << In.takeError();
Index: clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp
===
--- clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp
+++ clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp
@@ -314,17 +314,20 @@
   Arena; // store the underlying data of Position::FileURI.
   llvm::UniqueStringSaver Strings(Arena);
   llvm::yaml::Input Yin(Data, &Strings);
-  do {
+  while (Yin.setCurrentDocument()) {
+llvm::yaml::EmptyContext Ctx;
 VariantEntry Variant;
-Yin >> Variant;
+yamlize(Yin, Variant, true, Ctx);
 if (Yin.error())
   return llvm::errorCodeToError(Yin.error());
+
 if (Variant.Symbol)
   Symbols.insert(*Variant.Symbol);
 if (Variant.Refs)
   for (const auto &Ref : Variant.Refs->second)
 Refs.insert(Variant.Refs->first, Ref);
-  } while (Yin.nextDocument());
+Yin.nextDocument();
+  }
 
   IndexFileIn Result;
   Result.Symbols.emplace(std::move(Symbols).build());


Index: clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp
===
--- clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp
+++ clang-tools-extra/trunk/unittests/clangd/SerializationTests.cpp
@@ -91,6 +91,10 @@
   return (arg.IncludeHeader == IncludeHeader) && (arg.References == References);
 }
 
+TEST(SerializationTest, NoCrashOnEmptyYAML) {
+  EXPECT_TRUE(bool(readIndexFile("")));
+}
+
 TEST(SerializationTest, YAMLConversions) {
   auto In = readIndexFile(YAML);
   EXPECT_TRUE(bool(In)) << In.takeError();
Index: clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp
===
--- clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp
+++ clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp
@@ -314,17 +314,20 @@
   Arena; // store the underlying data of Position::FileURI.
   llvm::UniqueStringSaver Strings(Arena);
   llvm::yaml::Input Yin(Data, &Strings);
-  do {
+  while (Yin.setCurrentDocument()) {
+llvm::yaml::EmptyContext Ctx;
 VariantEntry Variant;
-Yin >> Variant;
+yamlize(Yin, Variant, true, Ctx);
 if (Yin.error())
   return llvm::errorCodeToError(Yin.error());
+
 if (Variant.Symbol)
   Symbols.insert(*Variant.Symbol);
 if (Variant.Refs)
   for (const auto &Ref : Variant.Refs->second)
 Refs.insert(Variant.Refs->first, Ref);
-  } while (Yin.nextDocument());
+Yin.nextDocument();
+  }
 
   IndexFileIn Result;
   Result.Symbols.emplace(std::move(Symbols).build());
___
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-08 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added a comment.

No problem, thats why we test on real projects first, because there is always 
something hidden in C++ :)

Is there a test for the lambdas?




Comment at: clang-tidy/modernize/UseNodiscardCheck.cpp:39
+AST_MATCHER(CXXMethodDecl, isConversionDecl) {
+  // Don't put ``[[nodiscard]]`` in front of a conversion decl
+  // like operator bool().

I would prefer `isConversionOperator`. Its consistent with 
`isOverloadedOperator` and uses the right word (`operator bool` is an operator)



Comment at: clang-tidy/modernize/UseNodiscardCheck.cpp:106
+isVariadic(), hasTemplateReturnType(),
+hasParent(cxxRecordDecl(isLambda())),
+hasClassMutableFields(),

what happens for nested lambdas?
`hasParent` should be avoided if possible, as the `clangd` folks are currently 
implementing partial traversal to only analyze "the latest change". If you can, 
please rewrite that without `hasParent`



Comment at: test/clang-tidy/modernize-use-nodiscard.cpp:141
+
+// Do not add ``[[nodiscard]]`` to paramaeter packs.
+template 

typo, paramaeter


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] D56314: [clangd] Don't store completion info if the symbol is not used for code completion.

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



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

hokein wrote:
> ilya-biryukov wrote:
> > 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)
> This is a good point.
> 
> For class member completions, we rely solely on Sema completions (no query 
> being queried). I'm not sure it is practical to query the index for member 
> completions.
> - this means for **every** code completion, we query the index, it may slow 
> down completions
> - `fuzzyFind` is not supported for class members in our internal index 
> service (due to the large number of them)
> 
> So it turns two possibilities:
> 
> 1) always store comments (`SymbolCollector` doesn't know whether it is used 
> in static index or dynamic index)
> 2) or drop them for now, this wouldn't break anything, and add it back when 
> we actually use them for class completions
> 
> I slightly prefer 2) at the moment. WDYT?
Yeah, instead of using `fuzzyFind()`, we'll call  `lookup()` to get details of 
the symbols we've discovered.
It's true that this is going to add some latency, but I hope we have the 
latency budget to handle this (these queries should be fast, e.g. we're doing 
this for signature help and I haven't seen any noticeable latency there from 
the index query, most of the running time is parsing C++).

I also like option 2, but unfortunately we already rely on this to get the 
comments in signature help, so this change would actually introduce regressions 
there (less used than code completion, but still not nice to break it)
Would the third option of having a config option (e.g. 
`SymbolCollector::Options::StoreAllComments`) work?  `clangd-indexer` and 
auto-indexer would set the option to false, `indexSymbols` would set the option 
to true. We'll both get the optimizations and avoid introducing any 
regressions. The plumbing should be no more than a few lines of code.


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] D56424: [clang-tidy] Add check for underscores in googletest names.

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



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:23
+
+constexpr char kDisabledTestPrefix[] = "DISABLED_";
+

Please use `llvm::StringLiteral`



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:45
+const MacroArgs *Args) override {
+auto IdentifierInfo = MacroNameToken.getIdentifierInfo();
+if (!IdentifierInfo) {

please dont use `auto` here, subjectiv as `IdentifierInfo` is the type, but new 
contributors might not know that, so i would prefer not-auto here.



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:49
+}
+const StringRef MacroName = IdentifierInfo->getName();
+if (!isGoogletestTestMacro(MacroName)) {

no `const` in this case, as its a value and those are not const'ed in LLVM.



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:50
+const StringRef MacroName = IdentifierInfo->getName();
+if (!isGoogletestTestMacro(MacroName)) {
+  return;

You can ellide the braces and merge these two ifs.



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:58
+const Token *TestNameToken = Args->getUnexpArgument(1);
+if (!TestCaseNameToken || !TestNameToken) {
+  return;

you can ellide the braces



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:62
+std::string TestCaseName = PP->getSpelling(*TestCaseNameToken);
+if (TestCaseName.find('_') != std::string::npos) {
+  Check->diag(TestCaseNameToken->getLocation(),

Maybe the duplicated `diag` call can be merged, you can store the diagnostic 
with `auto Diag = Check->diag(...)` and pass in the right location and 
arguments.



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:64
+  Check->diag(TestCaseNameToken->getLocation(),
+  "avoid using \"_\" in test case name \"%0\" according to "
+  "Googletest FAQ")

Duplicated message text, you can store it in a local 
variable/StringRef/StringLiteral,

ellide braces



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:69
+
+std::string TestName_maybe_disabled = PP->getSpelling(*TestNameToken);
+StringRef TestName = TestName_maybe_disabled;

Please use camel-case.


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] D56441: [analyzer][CrossTU][NFC] Generalize to external definitions instead of external functions

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

Thanks for the quick response! Will wait a couple days to see if someone else 
has something to add.

But I think something is wrong here...

When trying to "arc diff" I got the following error:

   Exception 
  Command failed with error #1!
  COMMAND
  svn propget 'svn:mime-type' 
'/data/work/commitllvm/llvm/tools/clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp'@
  
  STDOUT
  (empty)
  
  STDERR
  svn: warning: W200017: Property 'svn:mime-type' not found on 
'/data/work/commitllvm/llvm/tools/clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp@'
  svn: E20: A problem occurred; see other errors for details

So I did:

  svn propset svn:mime-type text/plain 
tools/clang-extdef-mapping/ClangExtDefMapGen.cpp 

This was on all the new/renamed files.

Now this diff shows some weird "svn:mime-type" changes which are probably 
unwanted. But only on two of the new files (?).

I only found this online, but weird that no one else is having this issue: 
https://secure.phabricator.com/T10608


Repository:
  rC Clang

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

https://reviews.llvm.org/D56441



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


[PATCH] D56441: [analyzer][CrossTU][NFC] Generalize to external definitions instead of external functions

2019-01-08 Thread Gabor Marton via Phabricator via cfe-commits
martong accepted this revision.
martong added a comment.

Looks good to me (but xazax's comments are valid)! Thank you.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56441



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


r350634 - [OPENMP]Fix PR40191: Do not allow orphaned cancellation constructs.

2019-01-08 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Tue Jan  8 07:53:42 2019
New Revision: 350634

URL: http://llvm.org/viewvc/llvm-project?rev=350634&view=rev
Log:
[OPENMP]Fix PR40191: Do not allow orphaned cancellation constructs.

Prohibited use of the orphaned cancellation directives.

Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/test/OpenMP/cancel_messages.cpp
cfe/trunk/test/OpenMP/cancellation_point_messages.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=350634&r1=350633&r2=350634&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Tue Jan  8 07:53:42 2019
@@ -3094,11 +3094,13 @@ static bool checkNestingOfRegions(Sema &
   }
   return false;
 }
-// Allow some constructs (except teams) to be orphaned (they could be
-// used in functions, called from OpenMP regions with the required
-// preconditions).
+// Allow some constructs (except teams and cancellation constructs) to be
+// orphaned (they could be used in functions, called from OpenMP regions
+// with the required preconditions).
 if (ParentRegion == OMPD_unknown &&
-!isOpenMPNestingTeamsDirective(CurrentRegion))
+!isOpenMPNestingTeamsDirective(CurrentRegion) &&
+CurrentRegion != OMPD_cancellation_point &&
+CurrentRegion != OMPD_cancel)
   return false;
 if (CurrentRegion == OMPD_cancellation_point ||
 CurrentRegion == OMPD_cancel) {
@@ -3127,6 +3129,7 @@ static bool checkNestingOfRegions(Sema &
 (CancelRegion == OMPD_sections &&
  (ParentRegion == OMPD_section || ParentRegion == OMPD_sections ||
   ParentRegion == OMPD_parallel_sections)));
+  OrphanSeen = ParentRegion == OMPD_unknown;
 } else if (CurrentRegion == OMPD_master) {
   // OpenMP [2.16, Nesting of Regions]
   // A master region may not be closely nested inside a worksharing,

Modified: cfe/trunk/test/OpenMP/cancel_messages.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/cancel_messages.cpp?rev=350634&r1=350633&r2=350634&view=diff
==
--- cfe/trunk/test/OpenMP/cancel_messages.cpp (original)
+++ cfe/trunk/test/OpenMP/cancel_messages.cpp Tue Jan  8 07:53:42 2019
@@ -10,18 +10,18 @@ int main(int argc, char **argv) {
   {
 #pragma omp cancel // expected-error {{one of 'for', 'parallel', 'sections' or 
'taskgroup' is expected}}
   }
-#pragma omp cancel parallel untied // expected-error {{unexpected OpenMP 
clause 'untied' in directive '#pragma omp cancel'}}
+#pragma omp cancel parallel untied // expected-error {{unexpected OpenMP 
clause 'untied' in directive '#pragma omp cancel'}} expected-error {{orphaned 
'omp cancel' directives are prohibited; perhaps you forget to enclose the 
directive into a region?}}
 #pragma omp cancel unknown // expected-error {{one of 'for', 
'parallel', 'sections' or 'taskgroup' is expected}}
 #pragma omp parallel
   {
 #pragma omp cancel unknown // expected-error {{one of 'for', 
'parallel', 'sections' or 'taskgroup' is expected}}
   }
-#pragma omp cancel sections(   // expected-warning {{extra tokens at the 
end of '#pragma omp cancel' are ignored}}
-#pragma omp cancel for, )  // expected-warning {{extra tokens at the 
end of '#pragma omp cancel' are ignored}}
-#pragma omp cancel taskgroup() // expected-warning {{extra tokens at the 
end of '#pragma omp cancel' are ignored}}
-#pragma omp cancel parallel, if// expected-warning {{extra tokens at the 
end of '#pragma omp cancel' are ignored}}
+#pragma omp cancel sections(   // expected-warning {{extra tokens at the 
end of '#pragma omp cancel' are ignored}} expected-error {{orphaned 'omp 
cancel' directives are prohibited; perhaps you forget to enclose the directive 
into a region?}}
+#pragma omp cancel for, )  // expected-warning {{extra tokens at the 
end of '#pragma omp cancel' are ignored}} expected-error {{orphaned 'omp 
cancel' directives are prohibited; perhaps you forget to enclose the directive 
into a region?}}
+#pragma omp cancel taskgroup() // expected-warning {{extra tokens at the 
end of '#pragma omp cancel' are ignored}} expected-error {{orphaned 'omp 
cancel' directives are prohibited; perhaps you forget to enclose the directive 
into a region?}}
+#pragma omp cancel parallel, if// expected-warning {{extra tokens at the 
end of '#pragma omp cancel' are ignored}} expected-error {{orphaned 'omp 
cancel' directives are prohibited; perhaps you forget to enclose the directive 
into a region?}}
   if (argc)
-#pragma omp cancel for // expected-error {{'#pragma omp cancel' cannot be an 
immediate substatement}}
+#pragma omp cancel for // expected-error {{'#pragma omp cancel' cannot be an 
immediate substatement}} expected-erro

[PATCH] D55646: [ASTImporter] Make ODR diagnostics warning by default

2019-01-08 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

Just a quick note. We are pretty sure that `StructuralEquivalency` can have 
false positive results, i.e. it can report two decls as nonequivalent falsely. 
My understanding is that we should report an error only if we are absolutely 
certain that an error has happened, this is not the case with 
`StructuralEquivalency`. Consequently this should be a warning in Sema 
(modules) too.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55646



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


Re: r350634 - [OPENMP]Fix PR40191: Do not allow orphaned cancellation constructs.

2019-01-08 Thread Roman Lebedev via cfe-commits
Thanks!

On Tue, Jan 8, 2019 at 6:57 PM Alexey Bataev via cfe-commits
 wrote:
>
> Author: abataev
> Date: Tue Jan  8 07:53:42 2019
> New Revision: 350634
>
> URL: http://llvm.org/viewvc/llvm-project?rev=350634&view=rev
> Log:
> [OPENMP]Fix PR40191: Do not allow orphaned cancellation constructs.
>
> Prohibited use of the orphaned cancellation directives.
>
> Modified:
> cfe/trunk/lib/Sema/SemaOpenMP.cpp
> cfe/trunk/test/OpenMP/cancel_messages.cpp
> cfe/trunk/test/OpenMP/cancellation_point_messages.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=350634&r1=350633&r2=350634&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Tue Jan  8 07:53:42 2019
> @@ -3094,11 +3094,13 @@ static bool checkNestingOfRegions(Sema &
>}
>return false;
>  }
> -// Allow some constructs (except teams) to be orphaned (they could be
> -// used in functions, called from OpenMP regions with the required
> -// preconditions).
> +// Allow some constructs (except teams and cancellation constructs) to be
> +// orphaned (they could be used in functions, called from OpenMP regions
> +// with the required preconditions).
>  if (ParentRegion == OMPD_unknown &&
> -!isOpenMPNestingTeamsDirective(CurrentRegion))
> +!isOpenMPNestingTeamsDirective(CurrentRegion) &&
> +CurrentRegion != OMPD_cancellation_point &&
> +CurrentRegion != OMPD_cancel)
>return false;
>  if (CurrentRegion == OMPD_cancellation_point ||
>  CurrentRegion == OMPD_cancel) {
> @@ -3127,6 +3129,7 @@ static bool checkNestingOfRegions(Sema &
>  (CancelRegion == OMPD_sections &&
>   (ParentRegion == OMPD_section || ParentRegion == OMPD_sections 
> ||
>ParentRegion == OMPD_parallel_sections)));
> +  OrphanSeen = ParentRegion == OMPD_unknown;
>  } else if (CurrentRegion == OMPD_master) {
>// OpenMP [2.16, Nesting of Regions]
>// A master region may not be closely nested inside a worksharing,
>
> Modified: cfe/trunk/test/OpenMP/cancel_messages.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/cancel_messages.cpp?rev=350634&r1=350633&r2=350634&view=diff
> ==
> --- cfe/trunk/test/OpenMP/cancel_messages.cpp (original)
> +++ cfe/trunk/test/OpenMP/cancel_messages.cpp Tue Jan  8 07:53:42 2019
> @@ -10,18 +10,18 @@ int main(int argc, char **argv) {
>{
>  #pragma omp cancel // expected-error {{one of 'for', 'parallel', 'sections' 
> or 'taskgroup' is expected}}
>}
> -#pragma omp cancel parallel untied // expected-error {{unexpected OpenMP 
> clause 'untied' in directive '#pragma omp cancel'}}
> +#pragma omp cancel parallel untied // expected-error {{unexpected OpenMP 
> clause 'untied' in directive '#pragma omp cancel'}} expected-error {{orphaned 
> 'omp cancel' directives are prohibited; perhaps you forget to enclose the 
> directive into a region?}}
>  #pragma omp cancel unknown // expected-error {{one of 'for', 
> 'parallel', 'sections' or 'taskgroup' is expected}}
>  #pragma omp parallel
>{
>  #pragma omp cancel unknown // expected-error {{one of 'for', 
> 'parallel', 'sections' or 'taskgroup' is expected}}
>}
> -#pragma omp cancel sections(   // expected-warning {{extra tokens at the 
> end of '#pragma omp cancel' are ignored}}
> -#pragma omp cancel for, )  // expected-warning {{extra tokens at the 
> end of '#pragma omp cancel' are ignored}}
> -#pragma omp cancel taskgroup() // expected-warning {{extra tokens at the 
> end of '#pragma omp cancel' are ignored}}
> -#pragma omp cancel parallel, if// expected-warning {{extra tokens at the 
> end of '#pragma omp cancel' are ignored}}
> +#pragma omp cancel sections(   // expected-warning {{extra tokens at the 
> end of '#pragma omp cancel' are ignored}} expected-error {{orphaned 'omp 
> cancel' directives are prohibited; perhaps you forget to enclose the 
> directive into a region?}}
> +#pragma omp cancel for, )  // expected-warning {{extra tokens at the 
> end of '#pragma omp cancel' are ignored}} expected-error {{orphaned 'omp 
> cancel' directives are prohibited; perhaps you forget to enclose the 
> directive into a region?}}
> +#pragma omp cancel taskgroup() // expected-warning {{extra tokens at the 
> end of '#pragma omp cancel' are ignored}} expected-error {{orphaned 'omp 
> cancel' directives are prohibited; perhaps you forget to enclose the 
> directive into a region?}}
> +#pragma omp cancel parallel, if// expected-warning {{extra tokens at the 
> end of '#pragma omp cancel' are ignored}} expected-error {{orphaned 'omp 
> cancel' directives are prohibited; perhaps you forget to enclos

[PATCH] D56415: NFC: Port QueryParser to StringRef

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



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

steveire wrote:
> kristina wrote:
> > I don't think this is the best way of handling it, in fact I'm pretty 
> > certain you're leaking memory here.
> Hmm, I didn't know we could get a mem leak with StringRef. Can you explain?
There's no memory leak here that I can see -- `StringRef` is non-owning.



Comment at: clang-query/QueryParser.cpp:33
+  if (Line.empty())
+return StringRef(Line.begin(), 0);
 

Why not just return `Line`?



Comment at: clang-query/QueryParser.cpp:37
+Line = {};
 return StringRef();
   }

Why not just return `Line` here as well?



Comment at: clang-query/QueryParser.cpp:40
 
-  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());

Can you use `Line.take_until(isWhitespace);`?


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


Re: r346652 - Make clang-based tools find libc++ on MacOS

2019-01-08 Thread Nico Weber via cfe-commits
It looks like clang now looks for libc++ headers in -internal-isystem
Release+Asserts/bin/include/c++/v1 , compared to -internal-isystem
Release+Asserts/include/c++/v1. `make install` puts the libc++ headers in
Release+Asserts/include, the old location. Was this an intentional change?

As-is, this seems to break chromium's clang ability to find libc++ headers (
https://crbug.com/919761) because we bundle libc++ headers in an "include"
directory that's a sibling to the "bin" directory (and have been doing so
for 4.5 years, since https://codereview.chromium.org/281753002).

On Mon, Nov 12, 2018 at 8:58 AM Ilya Biryukov via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ibiryukov
> Date: Mon Nov 12 05:55:55 2018
> New Revision: 346652
>
> URL: http://llvm.org/viewvc/llvm-project?rev=346652&view=rev
> Log:
> Make clang-based tools find libc++ on MacOS
>
> Summary:
> When they read compiler args from compile_commands.json.
> This change allows to run clang-based tools, like clang-tidy or clangd,
> built from head using the compile_commands.json file produced for XCode
> toolchains.
>
> On MacOS clang can find the C++ standard library relative to the
> compiler installation dir.
>
> The logic to do this was based on resource dir as an approximation of
> where the compiler is installed. This broke the tools that read
> 'compile_commands.json' and don't ship with the compiler, as they
> typically change resource dir.
>
> To workaround this, we now use compiler install dir detected by the driver
> to better mimic the behavior of the original compiler when replaying the
> compilations using other tools.
>
> Reviewers: sammccall, arphaman, EricWF
>
> Reviewed By: sammccall
>
> Subscribers: ioeric, christof, kadircet, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D54310
>
> Added:
> cfe/trunk/test/Tooling/Inputs/mock-libcxx/
> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/
> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/c++/
> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/c++/v1/
> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/c++/v1/mock_vector
> cfe/trunk/test/Tooling/clang-check-mac-libcxx-abspath.cpp
> cfe/trunk/test/Tooling/clang-check-mac-libcxx-relpath.cpp
> Modified:
> cfe/trunk/include/clang/Lex/HeaderSearchOptions.h
> cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp
> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
> cfe/trunk/lib/Tooling/Tooling.cpp
>
> Modified: cfe/trunk/include/clang/Lex/HeaderSearchOptions.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearchOptions.h?rev=346652&r1=346651&r2=346652&view=diff
>
> ==
> --- cfe/trunk/include/clang/Lex/HeaderSearchOptions.h (original)
> +++ cfe/trunk/include/clang/Lex/HeaderSearchOptions.h Mon Nov 12 05:55:55
> 2018
> @@ -108,6 +108,13 @@ public:
>/// etc.).
>std::string ResourceDir;
>
> +  /// Compiler install dir as detected by the Driver.
> +  /// This is typically the directory that contains the clang executable,
> i.e.
> +  /// the 'bin/' subdir of a clang distribution.
> +  /// Only used to add include dirs for libc++ on Darwin. Please avoid
> relying
> +  /// on this field for other purposes.
> +  std::string InstallDir;
> +
>/// The directory used for the module cache.
>std::string ModuleCachePath;
>
>
> Modified: cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp?rev=346652&r1=346651&r2=346652&view=diff
>
> ==
> --- cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp (original)
> +++ cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp Mon Nov 12
> 05:55:55 2018
> @@ -11,17 +11,18 @@
>  //
>
>  
> //===--===//
>
> -#include "clang/Frontend/Utils.h"
>  #include "clang/Basic/DiagnosticOptions.h"
> +#include "clang/Driver/Action.h"
>  #include "clang/Driver/Compilation.h"
>  #include "clang/Driver/Driver.h"
> -#include "clang/Driver/Action.h"
>  #include "clang/Driver/Options.h"
>  #include "clang/Driver/Tool.h"
>  #include "clang/Frontend/CompilerInstance.h"
>  #include "clang/Frontend/FrontendDiagnostic.h"
> +#include "clang/Frontend/Utils.h"
>  #include "llvm/Option/ArgList.h"
>  #include "llvm/Support/Host.h"
> +#include "llvm/Support/Path.h"
>  using namespace clang;
>  using namespace llvm::opt;
>
> @@ -102,5 +103,8 @@ std::unique_ptr clan
>   CCArgs.size(),
>   *Diags))
>  return nullptr;
> +  // Patch up the install dir, so we find the same standard library as the
> +  // original compiler on MacOS.
> +  CI->getHeaderSearchOpts().InstallDir = TheDriver.getInstalledDir();
>return CI;

r350635 - [AST][NFC] Pack CXXScalarValueInitExpr

2019-01-08 Thread Bruno Ricci via cfe-commits
Author: brunoricci
Date: Tue Jan  8 08:08:54 2019
New Revision: 350635

URL: http://llvm.org/viewvc/llvm-project?rev=350635&view=rev
Log:
[AST][NFC] Pack CXXScalarValueInitExpr

Use the newly available space in the bit-fields of Stmt.
This saves one pointer per CXXScalarValueInitExpr. NFC.


Modified:
cfe/trunk/include/clang/AST/ExprCXX.h
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/lib/AST/ExprCXX.cpp
cfe/trunk/lib/Serialization/ASTReaderStmt.cpp

Modified: cfe/trunk/include/clang/AST/ExprCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprCXX.h?rev=350635&r1=350634&r2=350635&view=diff
==
--- cfe/trunk/include/clang/AST/ExprCXX.h (original)
+++ cfe/trunk/include/clang/AST/ExprCXX.h Tue Jan  8 08:08:54 2019
@@ -1896,18 +1896,19 @@ public:
 class CXXScalarValueInitExpr : public Expr {
   friend class ASTStmtReader;
 
-  SourceLocation RParenLoc;
   TypeSourceInfo *TypeInfo;
 
 public:
   /// Create an explicitly-written scalar-value initialization
   /// expression.
   CXXScalarValueInitExpr(QualType Type, TypeSourceInfo *TypeInfo,
- SourceLocation rParenLoc)
-  : Expr(CXXScalarValueInitExprClass, Type, VK_RValue, OK_Ordinary,
- false, false, Type->isInstantiationDependentType(),
+ SourceLocation RParenLoc)
+  : Expr(CXXScalarValueInitExprClass, Type, VK_RValue, OK_Ordinary, false,
+ false, Type->isInstantiationDependentType(),
  Type->containsUnexpandedParameterPack()),
-RParenLoc(rParenLoc), TypeInfo(TypeInfo) {}
+TypeInfo(TypeInfo) {
+CXXScalarValueInitExprBits.RParenLoc = RParenLoc;
+  }
 
   explicit CXXScalarValueInitExpr(EmptyShell Shell)
   : Expr(CXXScalarValueInitExprClass, Shell) {}
@@ -1916,10 +1917,12 @@ public:
 return TypeInfo;
   }
 
-  SourceLocation getRParenLoc() const { return RParenLoc; }
+  SourceLocation getRParenLoc() const {
+return CXXScalarValueInitExprBits.RParenLoc;
+  }
 
   SourceLocation getBeginLoc() const LLVM_READONLY;
-  SourceLocation getEndLoc() const LLVM_READONLY { return RParenLoc; }
+  SourceLocation getEndLoc() const { return getRParenLoc(); }
 
   static bool classof(const Stmt *T) {
 return T->getStmtClass() == CXXScalarValueInitExprClass;

Modified: cfe/trunk/include/clang/AST/Stmt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Stmt.h?rev=350635&r1=350634&r2=350635&view=diff
==
--- cfe/trunk/include/clang/AST/Stmt.h (original)
+++ cfe/trunk/include/clang/AST/Stmt.h Tue Jan  8 08:08:54 2019
@@ -612,6 +612,15 @@ protected:
 SourceLocation Loc;
   };
 
+  class CXXScalarValueInitExprBitfields {
+friend class ASTStmtReader;
+friend class CXXScalarValueInitExpr;
+
+unsigned : NumExprBits;
+
+SourceLocation RParenLoc;
+  };
+
   class CXXNewExprBitfields {
 friend class ASTStmtReader;
 friend class ASTStmtWriter;
@@ -859,6 +868,7 @@ protected:
 CXXThrowExprBitfields CXXThrowExprBits;
 CXXDefaultArgExprBitfields CXXDefaultArgExprBits;
 CXXDefaultInitExprBitfields CXXDefaultInitExprBits;
+CXXScalarValueInitExprBitfields CXXScalarValueInitExprBits;
 CXXNewExprBitfields CXXNewExprBits;
 CXXDeleteExprBitfields CXXDeleteExprBits;
 TypeTraitExprBitfields TypeTraitExprBits;

Modified: cfe/trunk/lib/AST/ExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprCXX.cpp?rev=350635&r1=350634&r2=350635&view=diff
==
--- cfe/trunk/lib/AST/ExprCXX.cpp (original)
+++ cfe/trunk/lib/AST/ExprCXX.cpp Tue Jan  8 08:08:54 2019
@@ -90,7 +90,7 @@ QualType CXXUuidofExpr::getTypeOperand(A
 
 // CXXScalarValueInitExpr
 SourceLocation CXXScalarValueInitExpr::getBeginLoc() const {
-  return TypeInfo ? TypeInfo->getTypeLoc().getBeginLoc() : RParenLoc;
+  return TypeInfo ? TypeInfo->getTypeLoc().getBeginLoc() : getRParenLoc();
 }
 
 // CXXNewExpr

Modified: cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderStmt.cpp?rev=350635&r1=350634&r2=350635&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReaderStmt.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReaderStmt.cpp Tue Jan  8 08:08:54 2019
@@ -1502,7 +1502,7 @@ void ASTStmtReader::VisitCXXBindTemporar
 void ASTStmtReader::VisitCXXScalarValueInitExpr(CXXScalarValueInitExpr *E) {
   VisitExpr(E);
   E->TypeInfo = GetTypeSourceInfo();
-  E->RParenLoc = ReadSourceLocation();
+  E->CXXScalarValueInitExprBits.RParenLoc = ReadSourceLocation();
 }
 
 void ASTStmtReader::VisitCXXNewExpr(CXXNewExpr *E) {


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.ll

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

2019-01-08 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.



In D55433#1349709 , @JonasToth wrote:

> No problem, thats why we test on real projects first, because there is always 
> something hidden in C++ :)
>
> Is there a test for the lambdas?


test/clang-tidy/modernize-use-nodiscard.cpp line 158  (which is how it 
manifested inside LLVM) as a lambda assigned to an auto


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] D55337: NFC: Move dumpDeclRef to NodeDumper

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



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

steveire wrote:
> 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 > > TextNodeDumper> {
> > >   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

r350636 - Don't emit DW_AT_enum_class unless it's actually an 'enum class'.

2019-01-08 Thread Paul Robinson via cfe-commits
Author: probinson
Date: Tue Jan  8 08:28:11 2019
New Revision: 350636

URL: http://llvm.org/viewvc/llvm-project?rev=350636&view=rev
Log:
Don't emit DW_AT_enum_class unless it's actually an 'enum class'.

Finishes off the functional part of PR36168.

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

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/CodeGenCXX/debug-info-enum-class.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=350636&r1=350635&r2=350636&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Jan  8 08:28:11 2019
@@ -2711,7 +2711,7 @@ llvm::DIType *CGDebugInfo::CreateTypeDef
   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,

Modified: cfe/trunk/test/CodeGenCXX/debug-info-enum-class.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-enum-class.cpp?rev=350636&r1=350635&r2=350636&view=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-enum-class.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-enum-class.cpp Tue Jan  8 08:28:11 2019
@@ -52,6 +52,7 @@ namespace test2 {
 // 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 @@ namespace test3 {
 // 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 @@ void func(E *) {
 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"


___
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-08 Thread Paul Robinson 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 rC350636: Don't emit DW_AT_enum_class unless it's 
actually an 'enum class'. (authored by probinson, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D56393?vs=180501&id=180678#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D56393

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


Index: test/CodeGenCXX/debug-info-enum-class.cpp
===
--- test/CodeGenCXX/debug-info-enum-class.cpp
+++ 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: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ 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: test/CodeGenCXX/debug-info-enum-class.cpp
===
--- test/CodeGenCXX/debug-info-enum-class.cpp
+++ 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: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ 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] D56415: NFC: Port QueryParser to StringRef

2019-01-08 Thread Stephen Kelly via Phabricator via cfe-commits
steveire marked 2 inline comments as done.
steveire added inline comments.



Comment at: clang-query/QueryParser.cpp:33
+  if (Line.empty())
+return StringRef(Line.begin(), 0);
 

aaron.ballman wrote:
> Why not just return `Line`?
It is the pre-existing behavior to return a zero-length StringRef with a valid 
Begin pointer in this case. I think the reason is something to do with code 
completion. I can check later.



Comment at: clang-query/QueryParser.cpp:37
+Line = {};
 return StringRef();
   }

aaron.ballman wrote:
> Why not just return `Line` here as well?
That's pre-existing. Seems more clear to leave it as is.


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] D55433: [clang-tidy] Adding a new modernize use nodiscard checker

2019-01-08 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay marked an inline comment as done.
MyDeveloperDay added a comment.



In D55433#1349709 , @JonasToth wrote:

> No problem, thats why we test on real projects first, because there is always 
> something hidden in C++ :)
>
> Is there a test for the lambdas?


test/clang-tidy/modernize-use-nodiscard.cpp line 158  (which is how it 
manifested inside LLVM) as a lambda assigned to an auto




Comment at: clang-tidy/modernize/UseNodiscardCheck.cpp:106
+isVariadic(), hasTemplateReturnType(),
+hasParent(cxxRecordDecl(isLambda())),
+hasClassMutableFields(),

JonasToth wrote:
> what happens for nested lambdas?
> `hasParent` should be avoided if possible, as the `clangd` folks are 
> currently implementing partial traversal to only analyze "the latest change". 
> If you can, please rewrite that without `hasParent`
I'll not deny I wasn't sure how to do this one, and totally stole the idea from 
another checker

fuchsia/TrailingReturnCheck.cpp:
hasParent(cxxRecordDecl(isLambda())

> hasParent(cxxRecordDecl(isLambda())),

Given that the matcher is on all CXXMethodDecl, I couldn't quite see how I 
could determine the CXXMethodDecl was in a lambda, without going to the parent  

{F7804868}

without it I'd get

```
const auto nonConstReferenceType = [] {
   return true;
 };

``` 

transformed to


```
const auto nonConstReferenceType = [[nodiscard]] [] {
  return true;
};

```

Which whilst probably true, made for some ugly reading..

not sure about nested lambdas...sounds even harder!









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] D56415: NFC: Port QueryParser to StringRef

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



Comment at: clang-query/QueryParser.cpp:33
+  if (Line.empty())
+return StringRef(Line.begin(), 0);
 

steveire wrote:
> aaron.ballman wrote:
> > Why not just return `Line`?
> It is the pre-existing behavior to return a zero-length StringRef with a 
> valid Begin pointer in this case. I think the reason is something to do with 
> code completion. I can check later.
I believe returning `Line` is identical -- you should wind up with the same 
"begin" pointer for the returned string and a length of zero (because `Line` 
must be empty by this point).



Comment at: clang-query/QueryParser.cpp:37
+Line = {};
 return StringRef();
   }

steveire wrote:
> aaron.ballman wrote:
> > Why not just return `Line` here as well?
> That's pre-existing. Seems more clear to leave it as is.
I don't have a strong preference, but I raised the point because it seems odd 
to explicitly clear a `StringRef` and then return a new, different, empty 
`StringRef` on the next line.


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] D56415: NFC: Port QueryParser to StringRef

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



Comment at: clang-query/QueryParser.cpp:33
+  if (Line.empty())
+return StringRef(Line.begin(), 0);
 

aaron.ballman wrote:
> steveire wrote:
> > aaron.ballman wrote:
> > > Why not just return `Line`?
> > It is the pre-existing behavior to return a zero-length StringRef with a 
> > valid Begin pointer in this case. I think the reason is something to do 
> > with code completion. I can check later.
> I believe returning `Line` is identical -- you should wind up with the same 
> "begin" pointer for the returned string and a length of zero (because `Line` 
> must be empty by this point).
Actually, I can see it by reading the code - `P->CompletionPos <= Word.data()` 
in the `LexOrCompleteWord` ctor woudln't work anymore without this hack. 
(Working on removing the hack is out of scope of this change).


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] D56413: [OpenMP] Avoid remainder operations for loop index values on a collapsed loop nest.

2019-01-08 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:5520
+ExprResult Acc =
+  SemaRef.ActOnIntegerConstant(SourceLocation(), 0).get();
+for (unsigned int Cnt = 0; Cnt < NestedLoopCount; Cnt++) {

No need for `.get()` here



Comment at: lib/Sema/SemaOpenMP.cpp:5521
+  SemaRef.ActOnIntegerConstant(SourceLocation(), 0).get();
+for (unsigned int Cnt = 0; Cnt < NestedLoopCount; Cnt++) {
   LoopIterationSpace &IS = IterSpaces[Cnt];

Use preincrement



Comment at: lib/Sema/SemaOpenMP.cpp:5529
+  SemaRef.ActOnIntegerConstant(SourceLocation(), 1).get();
+  for (unsigned int K = Cnt+1; K < NestedLoopCount; K++)
+Prod =

1. Preincrement.
2. Format.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56413



___
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-08 Thread Stephen Kelly via Phabricator via cfe-commits
steveire marked an inline comment as done.
steveire added inline comments.



Comment at: clang-query/QueryParser.cpp:33
+  if (Line.empty())
+return StringRef(Line.begin(), 0);
 

steveire wrote:
> aaron.ballman wrote:
> > steveire wrote:
> > > aaron.ballman wrote:
> > > > Why not just return `Line`?
> > > It is the pre-existing behavior to return a zero-length StringRef with a 
> > > valid Begin pointer in this case. I think the reason is something to do 
> > > with code completion. I can check later.
> > I believe returning `Line` is identical -- you should wind up with the same 
> > "begin" pointer for the returned string and a length of zero (because 
> > `Line` must be empty by this point).
> Actually, I can see it by reading the code - `P->CompletionPos <= 
> Word.data()` in the `LexOrCompleteWord` ctor woudln't work anymore without 
> this hack. (Working on removing the hack is out of scope of this change).
Ok, I see your new comment now. I guess that will work. I don't know the 
behavior of `ltrim` and whether it preserves that property.


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] D56444: [AST] RecursiveASTVisitor visits lambda classes when implicit visitation is on.

2019-01-08 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added reviewers: aaron.ballman, JonasToth.
Herald added a subscriber: cfe-commits.

This fixes ASTContext's parent map for nodes in such classes (e.g. operator()).
https://bugs.llvm.org/show_bug.cgi?id=39949

In order to do this, we remove the TraverseLambdaBody hook. The problem is it's
hard/weird to ensure this hook is called when traversing via the implicit class.
There were just two users of this hook in-tree, who use it to skip bodies.
I replaced these with explicitly traversing the captures only. Another approach
would be recording the bodies when the lambda is visited, and then recognizing
them later.
I'd be open to suggestion on how to preserve this hook, instead.


Repository:
  rC Clang

https://reviews.llvm.org/D56444

Files:
  include/clang/AST/RecursiveASTVisitor.h
  lib/CodeGen/CodeGenPGO.cpp
  lib/Sema/AnalysisBasedWarnings.cpp
  unittests/AST/ASTContextParentMapTest.cpp
  unittests/Tooling/RecursiveASTVisitorTests/LambdaExpr.cpp

Index: unittests/Tooling/RecursiveASTVisitorTests/LambdaExpr.cpp
===
--- unittests/Tooling/RecursiveASTVisitorTests/LambdaExpr.cpp
+++ unittests/Tooling/RecursiveASTVisitorTests/LambdaExpr.cpp
@@ -17,25 +17,34 @@
 class LambdaExprVisitor : public ExpectedLocationVisitor {
 public:
   bool VisitLambdaExpr(LambdaExpr *Lambda) {
-PendingBodies.push(Lambda);
+llvm::errs() << "visitlambdaexpr\n";
+PendingBodies.push(Lambda->getBody());
+PendingClasses.push(Lambda->getLambdaClass());
 Match("", Lambda->getIntroducerRange().getBegin());
 return true;
   }
-  /// For each call to VisitLambdaExpr, we expect a subsequent call (with
-  /// proper nesting) to TraverseLambdaBody.
-  bool TraverseLambdaBody(LambdaExpr *Lambda) {
-EXPECT_FALSE(PendingBodies.empty());
-EXPECT_EQ(PendingBodies.top(), Lambda);
-PendingBodies.pop();
-return TraverseStmt(Lambda->getBody());
+  /// For each call to VisitLambdaExpr, we expect a subsequent call to visit
+  /// the body (and maybe the lambda class, which is implicit).
+  bool VisitStmt(Stmt *S) {
+if (!PendingBodies.empty() && S == PendingBodies.top())
+  PendingBodies.pop();
+return true;
   }
-  /// Determine whether TraverseLambdaBody has been called for every call to
-  /// VisitLambdaExpr.
-  bool allBodiesHaveBeenTraversed() const {
-return PendingBodies.empty();
+  bool VisitDecl(Decl *D) {
+if (!PendingClasses.empty() && D == PendingClasses.top())
+  PendingClasses.pop();
+return true;
   }
+  /// Determine whether parts of lambdas (VisitLambdaExpr) were later traversed.
+  bool allBodiesHaveBeenTraversed() const { return PendingBodies.empty(); }
+  bool allClassesHaveBeenTraversed() const { return PendingClasses.empty(); }
+
+  bool VisitImplicitCode = false;
+  bool shouldVisitImplicitCode() const { return VisitImplicitCode; }
+
 private:
-  std::stack PendingBodies;
+  std::stack PendingBodies;
+  std::stack PendingClasses;
 };
 
 TEST(RecursiveASTVisitor, VisitsLambdaExpr) {
@@ -43,13 +52,18 @@
   Visitor.ExpectMatch("", 1, 12);
   EXPECT_TRUE(Visitor.runOver("void f() { []{ return; }(); }",
   LambdaExprVisitor::Lang_CXX11));
+  EXPECT_TRUE(Visitor.allBodiesHaveBeenTraversed());
+  EXPECT_FALSE(Visitor.allClassesHaveBeenTraversed());
 }
 
-TEST(RecursiveASTVisitor, TraverseLambdaBodyCanBeOverridden) {
+TEST(RecursiveASTVisitor, VisitsLambdaExprAndImplicitClass) {
   LambdaExprVisitor Visitor;
+  Visitor.VisitImplicitCode = true;
+  Visitor.ExpectMatch("", 1, 12);
   EXPECT_TRUE(Visitor.runOver("void f() { []{ return; }(); }",
   LambdaExprVisitor::Lang_CXX11));
   EXPECT_TRUE(Visitor.allBodiesHaveBeenTraversed());
+  EXPECT_TRUE(Visitor.allClassesHaveBeenTraversed());
 }
 
 TEST(RecursiveASTVisitor, VisitsAttributedLambdaExpr) {
Index: unittests/AST/ASTContextParentMapTest.cpp
===
--- unittests/AST/ASTContextParentMapTest.cpp
+++ unittests/AST/ASTContextParentMapTest.cpp
@@ -106,5 +106,16 @@
   EXPECT_THAT(Ctx.getParents(Foo), ElementsAre(DynTypedNode::create(TU)));
 }
 
+TEST(GetParents, ImplicitLambdaNodes) {
+  MatchVerifier LambdaVerifier;
+  EXPECT_TRUE(LambdaVerifier.match(
+  "auto x = []{int y;};",
+  varDecl(hasName("y"), hasAncestor(functionDecl(
+hasOverloadedOperatorName("()"),
+hasParent(cxxRecordDecl(
+isImplicit(), hasParent(lambdaExpr())),
+  Lang_CXX11));
+}
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: lib/Sema/AnalysisBasedWarnings.cpp
===
--- lib/Sema/AnalysisBasedWarnings.cpp
+++ lib/Sema/AnalysisBasedWarnings.cpp
@@ -1153,7 +1153,12 @@
 bool TraverseDecl(Decl *D) { return true; }
 
 // We analyze lambda bodie

[PATCH] D56415: NFC: Port QueryParser to StringRef

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



Comment at: clang-query/QueryParser.cpp:37
+Line = {};
 return StringRef();
   }

aaron.ballman wrote:
> steveire wrote:
> > aaron.ballman wrote:
> > > Why not just return `Line` here as well?
> > That's pre-existing. Seems more clear to leave it as is.
> I don't have a strong preference, but I raised the point because it seems odd 
> to explicitly clear a `StringRef` and then return a new, different, empty 
> `StringRef` on the next line.
Well, code changes, and `Line` may not always be empty here. As it is, this 
communicates that we're returning an empty `StringRef` and always will (until 
this line has a reason to change).


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] D56415: NFC: Port QueryParser to StringRef

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



Comment at: clang-query/QueryParser.cpp:33
+  if (Line.empty())
+return StringRef(Line.begin(), 0);
 

steveire wrote:
> steveire wrote:
> > aaron.ballman wrote:
> > > steveire wrote:
> > > > aaron.ballman wrote:
> > > > > Why not just return `Line`?
> > > > It is the pre-existing behavior to return a zero-length StringRef with 
> > > > a valid Begin pointer in this case. I think the reason is something to 
> > > > do with code completion. I can check later.
> > > I believe returning `Line` is identical -- you should wind up with the 
> > > same "begin" pointer for the returned string and a length of zero 
> > > (because `Line` must be empty by this point).
> > Actually, I can see it by reading the code - `P->CompletionPos <= 
> > Word.data()` in the `LexOrCompleteWord` ctor woudln't work anymore without 
> > this hack. (Working on removing the hack is out of scope of this change).
> Ok, I see your new comment now. I guess that will work. I don't know the 
> behavior of `ltrim` and whether it preserves that property.
`StringRef`s are immutable and non-owning, so `ltrim()` returns `Line.begin + 
someOffset` in essence. That should preserve the behavior you need here.



Comment at: clang-query/QueryParser.cpp:37
+Line = {};
 return StringRef();
   }

steveire wrote:
> aaron.ballman wrote:
> > steveire wrote:
> > > aaron.ballman wrote:
> > > > Why not just return `Line` here as well?
> > > That's pre-existing. Seems more clear to leave it as is.
> > I don't have a strong preference, but I raised the point because it seems 
> > odd to explicitly clear a `StringRef` and then return a new, different, 
> > empty `StringRef` on the next line.
> Well, code changes, and `Line` may not always be empty here. As it is, this 
> communicates that we're returning an empty `StringRef` and always will (until 
> this line has a reason to change).
Okay, that's good enough for me, thanks!


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


r350638 - Fix use-after-free bug in Tooling.

2019-01-08 Thread Alexander Kornienko via cfe-commits
Author: alexfh
Date: Tue Jan  8 08:55:13 2019
New Revision: 350638

URL: http://llvm.org/viewvc/llvm-project?rev=350638&view=rev
Log:
Fix use-after-free bug in Tooling.

Summary:
`buildASTFromCodeWithArgs()` was creating a memory buffer referencing a
stack-allocated string.  This diff changes the implementation to copy the code
string into the memory buffer so that said buffer owns the memory.

Patch by Yitzhak Mandelbaum.

Reviewers: alexfh

Reviewed By: alexfh

Subscribers: cfe-commits, EricWF

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

Modified:
cfe/trunk/include/clang/Tooling/Tooling.h
cfe/trunk/lib/Tooling/Tooling.cpp
cfe/trunk/unittests/Analysis/ExprMutationAnalyzerTest.cpp

Modified: cfe/trunk/include/clang/Tooling/Tooling.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Tooling.h?rev=350638&r1=350637&r2=350638&view=diff
==
--- cfe/trunk/include/clang/Tooling/Tooling.h (original)
+++ cfe/trunk/include/clang/Tooling/Tooling.h Tue Jan  8 08:55:13 2019
@@ -205,7 +205,7 @@ bool runToolOnCodeWithArgs(
 ///
 /// \return The resulting AST or null if an error occurred.
 std::unique_ptr
-buildASTFromCode(const Twine &Code, const Twine &FileName = "input.cc",
+buildASTFromCode(StringRef Code, StringRef FileName = "input.cc",
  std::shared_ptr PCHContainerOps =
  std::make_shared());
 
@@ -223,10 +223,10 @@ buildASTFromCode(const Twine &Code, cons
 ///
 /// \return The resulting AST or null if an error occurred.
 std::unique_ptr buildASTFromCodeWithArgs(
-const Twine &Code, const std::vector &Args,
-const Twine &FileName = "input.cc", const Twine &ToolName = "clang-tool",
+StringRef Code, const std::vector &Args,
+StringRef FileName = "input.cc", StringRef ToolName = "clang-tool",
 std::shared_ptr PCHContainerOps =
-  std::make_shared(),
+std::make_shared(),
 ArgumentsAdjuster Adjuster = getClangStripDependencyFileAdjuster());
 
 /// Utility to run a FrontendAction in a single clang invocation.

Modified: cfe/trunk/lib/Tooling/Tooling.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Tooling.cpp?rev=350638&r1=350637&r2=350638&view=diff
==
--- cfe/trunk/lib/Tooling/Tooling.cpp (original)
+++ cfe/trunk/lib/Tooling/Tooling.cpp Tue Jan  8 08:55:13 2019
@@ -574,20 +574,16 @@ namespace clang {
 namespace tooling {
 
 std::unique_ptr
-buildASTFromCode(const Twine &Code, const Twine &FileName,
+buildASTFromCode(StringRef Code, StringRef FileName,
  std::shared_ptr PCHContainerOps) {
   return buildASTFromCodeWithArgs(Code, std::vector(), FileName,
   "clang-tool", std::move(PCHContainerOps));
 }
 
 std::unique_ptr buildASTFromCodeWithArgs(
-const Twine &Code, const std::vector &Args,
-const Twine &FileName, const Twine &ToolName,
-std::shared_ptr PCHContainerOps,
+StringRef Code, const std::vector &Args, StringRef FileName,
+StringRef ToolName, std::shared_ptr 
PCHContainerOps,
 ArgumentsAdjuster Adjuster) {
-  SmallString<16> FileNameStorage;
-  StringRef FileNameRef = FileName.toNullTerminatedStringRef(FileNameStorage);
-
   std::vector> ASTs;
   ASTBuilderAction Action(ASTs);
   llvm::IntrusiveRefCntPtr OverlayFileSystem(
@@ -599,13 +595,11 @@ std::unique_ptr buildASTFromCod
   new FileManager(FileSystemOptions(), OverlayFileSystem));
 
   ToolInvocation Invocation(
-  getSyntaxOnlyToolArgs(ToolName, Adjuster(Args, FileNameRef), 
FileNameRef),
+  getSyntaxOnlyToolArgs(ToolName, Adjuster(Args, FileName), FileName),
   &Action, Files.get(), std::move(PCHContainerOps));
 
-  SmallString<1024> CodeStorage;
-  InMemoryFileSystem->addFile(FileNameRef, 0,
-  llvm::MemoryBuffer::getMemBuffer(
-  
Code.toNullTerminatedStringRef(CodeStorage)));
+  InMemoryFileSystem->addFile(FileName, 0,
+  llvm::MemoryBuffer::getMemBufferCopy(Code));
   if (!Invocation.run())
 return nullptr;
 

Modified: cfe/trunk/unittests/Analysis/ExprMutationAnalyzerTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Analysis/ExprMutationAnalyzerTest.cpp?rev=350638&r1=350637&r2=350638&view=diff
==
--- cfe/trunk/unittests/Analysis/ExprMutationAnalyzerTest.cpp (original)
+++ cfe/trunk/unittests/Analysis/ExprMutationAnalyzerTest.cpp Tue Jan  8 
08:55:13 2019
@@ -11,6 +11,7 @@
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/SmallString.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
@@ -32,7 +33,9 @@ using StmtMatcher = internal::Matcher
 buildASTFromCodeWithArgs(const Twine &Code,
  

[PATCH] D55765: Fix use-after-free bug in Tooling.

2019-01-08 Thread Alexander Kornienko via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL350638: Fix use-after-free bug in Tooling. (authored by 
alexfh, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D55765

Files:
  cfe/trunk/include/clang/Tooling/Tooling.h
  cfe/trunk/lib/Tooling/Tooling.cpp
  cfe/trunk/unittests/Analysis/ExprMutationAnalyzerTest.cpp


Index: cfe/trunk/lib/Tooling/Tooling.cpp
===
--- cfe/trunk/lib/Tooling/Tooling.cpp
+++ cfe/trunk/lib/Tooling/Tooling.cpp
@@ -574,20 +574,16 @@
 namespace tooling {
 
 std::unique_ptr
-buildASTFromCode(const Twine &Code, const Twine &FileName,
+buildASTFromCode(StringRef Code, StringRef FileName,
  std::shared_ptr PCHContainerOps) {
   return buildASTFromCodeWithArgs(Code, std::vector(), FileName,
   "clang-tool", std::move(PCHContainerOps));
 }
 
 std::unique_ptr buildASTFromCodeWithArgs(
-const Twine &Code, const std::vector &Args,
-const Twine &FileName, const Twine &ToolName,
-std::shared_ptr PCHContainerOps,
+StringRef Code, const std::vector &Args, StringRef FileName,
+StringRef ToolName, std::shared_ptr 
PCHContainerOps,
 ArgumentsAdjuster Adjuster) {
-  SmallString<16> FileNameStorage;
-  StringRef FileNameRef = FileName.toNullTerminatedStringRef(FileNameStorage);
-
   std::vector> ASTs;
   ASTBuilderAction Action(ASTs);
   llvm::IntrusiveRefCntPtr OverlayFileSystem(
@@ -599,13 +595,11 @@
   new FileManager(FileSystemOptions(), OverlayFileSystem));
 
   ToolInvocation Invocation(
-  getSyntaxOnlyToolArgs(ToolName, Adjuster(Args, FileNameRef), 
FileNameRef),
+  getSyntaxOnlyToolArgs(ToolName, Adjuster(Args, FileName), FileName),
   &Action, Files.get(), std::move(PCHContainerOps));
 
-  SmallString<1024> CodeStorage;
-  InMemoryFileSystem->addFile(FileNameRef, 0,
-  llvm::MemoryBuffer::getMemBuffer(
-  
Code.toNullTerminatedStringRef(CodeStorage)));
+  InMemoryFileSystem->addFile(FileName, 0,
+  llvm::MemoryBuffer::getMemBufferCopy(Code));
   if (!Invocation.run())
 return nullptr;
 
Index: cfe/trunk/unittests/Analysis/ExprMutationAnalyzerTest.cpp
===
--- cfe/trunk/unittests/Analysis/ExprMutationAnalyzerTest.cpp
+++ cfe/trunk/unittests/Analysis/ExprMutationAnalyzerTest.cpp
@@ -11,6 +11,7 @@
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/SmallString.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
@@ -32,7 +33,9 @@
 std::unique_ptr
 buildASTFromCodeWithArgs(const Twine &Code,
  const std::vector &Args) {
-  auto AST = tooling::buildASTFromCodeWithArgs(Code, Args);
+  SmallString<1024> CodeStorage;
+  auto AST =
+  tooling::buildASTFromCodeWithArgs(Code.toStringRef(CodeStorage), Args);
   EXPECT_FALSE(AST->getDiagnostics().hasErrorOccurred());
   return AST;
 }
Index: cfe/trunk/include/clang/Tooling/Tooling.h
===
--- cfe/trunk/include/clang/Tooling/Tooling.h
+++ cfe/trunk/include/clang/Tooling/Tooling.h
@@ -205,7 +205,7 @@
 ///
 /// \return The resulting AST or null if an error occurred.
 std::unique_ptr
-buildASTFromCode(const Twine &Code, const Twine &FileName = "input.cc",
+buildASTFromCode(StringRef Code, StringRef FileName = "input.cc",
  std::shared_ptr PCHContainerOps =
  std::make_shared());
 
@@ -223,10 +223,10 @@
 ///
 /// \return The resulting AST or null if an error occurred.
 std::unique_ptr buildASTFromCodeWithArgs(
-const Twine &Code, const std::vector &Args,
-const Twine &FileName = "input.cc", const Twine &ToolName = "clang-tool",
+StringRef Code, const std::vector &Args,
+StringRef FileName = "input.cc", StringRef ToolName = "clang-tool",
 std::shared_ptr PCHContainerOps =
-  std::make_shared(),
+std::make_shared(),
 ArgumentsAdjuster Adjuster = getClangStripDependencyFileAdjuster());
 
 /// Utility to run a FrontendAction in a single clang invocation.


Index: cfe/trunk/lib/Tooling/Tooling.cpp
===
--- cfe/trunk/lib/Tooling/Tooling.cpp
+++ cfe/trunk/lib/Tooling/Tooling.cpp
@@ -574,20 +574,16 @@
 namespace tooling {
 
 std::unique_ptr
-buildASTFromCode(const Twine &Code, const Twine &FileName,
+buildASTFromCode(StringRef Code, StringRef FileName,
  std::shared_ptr PCHContainerOps) {
   return buildASTFromCodeWithArgs(Code, std::vector(), FileName,
   "clang-tool", std::move(PCHContainerOps));
 }
 
 std::unique_ptr buildA

r350639 - Revert "Split -Wdelete-non-virtual-dtor into -Wdelete-abstract-non-virtual-dtor"

2019-01-08 Thread Erik Pilkington via cfe-commits
Author: epilk
Date: Tue Jan  8 09:04:38 2019
New Revision: 350639

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

This reverts commit r350585. There was some late post-commit review
on phab.

Removed:
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=350639&r1=350638&r2=350639&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Tue Jan  8 09:04:38 2019
@@ -105,8 +105,6 @@ 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=350639&r1=350638&r2=350639&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Jan  8 09:04:38 
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;

Removed: cfe/trunk/test/SemaCXX/non-virtual-dtors.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/non-virtual-dtors.cpp?rev=350638&view=auto
==
--- cfe/trunk/test/SemaCXX/non-virtual-dtors.cpp (original)
+++ cfe/trunk/test/SemaCXX/non-virtual-dtors.cpp (removed)
@@ -1,32 +0,0 @@
-// 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] D56415: NFC: Port QueryParser to StringRef

2019-01-08 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 the nits pointed out; you can fix and commit without another 
round of review.


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] D55224: [clangd] Introduce loading of shards within auto-index

2019-01-08 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

Most comments are NITs, the major one that I'd suggest paying most attention to 
is about rewriting newer results with an older ones.




Comment at: clangd/index/Background.cpp:259
+  // if this thread sees the older version but finishes later. This should
+  // be rare in practice.
+  DigestIt.first->second = Hash;

kadircet wrote:
> ilya-biryukov wrote:
> > > "should be rare in practice"
> > And yet, can we avoid this altogether?
> > 
> > Also, I believe it won't be rare. When processing multiple different TUs, 
> > we can easily run into the same header multiple times, possibly with the 
> > different contents.
> > E.g. imagine the index for the whole of clang is being built and the user 
> > is editing `Sema.h` at the same time. We'll definitely be running into this 
> > case over and over again.
> Well I am open to ideas, but currently there is no way of knowing whether 
> this is the newer version for the file. Because only information we have is 
> the digest is different than what we currently have and this doesn't yield 
> any chronological information.
Do we know which request is "newer" when scheduling it?
If so, we could keep the map of the **latest** hashes of the files we've seen 
(in addition to the `IndexedFileDigests`, which correspond to the digest for 
which we built the index IIUC).

This would give us a simple invariant of the final state we want to bring the 
index to: `IndexedFileDigests` should correspond to the latest hashes seen so 
far. If not, we have to rebuild the index for the corresponding files. That, in 
turn, gives us a way to resolve conflicts: we should never replace with symbols 
built for the latest version (hash) of the file we've seen.

Would that work?



Comment at: clangd/index/Background.cpp:338
 std::lock_guard Lock(DigestsMu);
-if (IndexedFileDigests.lookup(AbsolutePath) == Hash) {
-  vlog("No need to index {0}, already up to date", AbsolutePath);

kadircet wrote:
> ilya-biryukov wrote:
> > This looks like an important optimization. Did we move it to some other 
> > place? Why should we remove it?
> We kind of moved it into loadShards logic by not running indexing for same 
> file multiple times. I needed to delete this check since we might wanna run 
> indexing on a TU, even if it is up-to-date, to get new symbols coming from 
> one of it's includes.
Thanks for the explanation, removing the optimization makes sense, we should 
check for dependency hashes in addition to the original file now.



Comment at: clangd/index/Background.cpp:481
+  if (!Buf)
+continue;
+  // If digests match then dependency doesn't need re-indexing.

kadircet wrote:
> ilya-biryukov wrote:
> > maybe log the error? would be nice to somehow recover too, but not sure 
> > what we can do here.
> Well, if this happens we don't have access to file's contents for some 
> reason. I don't think we can do anything. We might actually want to skip 
> loading these files into index, since they are most likely gone and symbols 
> coming from them won't be accessible. WDYT?
Logging the error is enough, thanks!

I think the ideal recovery is tracking whenever the files we were missing were 
added to the filesystem and rebuilding the index when that happens.
That probably requires more work than we'd like to put into it, though, so I 
don't think investing in this now makes any sense.



Comment at: clangd/index/Background.cpp:261
+  auto Hash = I.second.Digest;
+  std::lock_guard Lock(DigestsMu);
+  // Skip if file is already up to date.

This means lock/unlock on every iteration of the loop.
Could we move collecting the files we need to process into a separate loop that 
would only require a single lock over the whole loop?



Comment at: clangd/index/Background.cpp:414
+   BackgroundIndexStorage *IndexStorage,
+   llvm::StringSet<> &VisitedShards) {
+  // Adds the given shard's contents into BackgroundIndex.

NIT: s/VisitedShards/LoadedShards?
To better align with the name of the local var used in `loadShards()`



Comment at: clangd/index/Background.cpp:416
+  // Adds the given shard's contents into BackgroundIndex.
+  // Consumes Symbols and Refs in Shard.
+  auto AddShardToIndex = [this](llvm::StringRef AbsolutePath,

NIT: Instead of writing this comment, we could accept `IndexFileIn &&` as a 
parameter, which clearly states we're consuming it (this would require handling 
the `nullptr` case in the call sites, but that should be ok).



Comment at: clangd/index/Background.cpp:425
+if (Shard->Symbols)
+  SS = llvm::make_unique(std::move(*Shard->Symbols));
+if (Shard->Refs)

NIT: maybe init at the declaration site? i.e. `un

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

2019-01-08 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington reopened this revision.
erik.pilkington marked an inline comment as done.
erik.pilkington added a comment.
This revision is now accepted and ready to land.

I reverted my commit in r350639.




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:
> > 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.
> > 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.
> 
> Ah, those are all good points!
> 
> > (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.)
> 
> I have a slight preference for this approach; it feels a bit more natural to 
> me. However, do we want to spell it `delete-nonabstract-non-virtual-dtor` or 
> `delete-non-abstract-non-virtual-dtor` or 
> `delete-nonabstract-nonvirtual-dtor`? My preference is for anything but the 
> first spelling. ;-)
> 
> > Instead / as well, we could address the false positives more directly: 
> 
> Yes, improving the fp rate that way would be a great change to make. That 
> said, I would view it as "as well" rather than "instead" because these two 
> diagnostic scenarios seem reasonably separable.
> 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 
> t

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

2019-01-08 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 180687.
MyDeveloperDay marked 3 inline comments as done.
MyDeveloperDay added a comment.

Address review comments

- add more lambda tests
- add nested lambda test
- remove hasParent() call,  (seems isConversionOperator()) seems to detect the 
CXXMethodsDecls within a lambda that were causing [[nodiscard]] to be added 
before the []{... )


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

https://reviews.llvm.org/D55433

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/UseNodiscardCheck.cpp
  clang-tidy/modernize/UseNodiscardCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-use-nodiscard.rst
  test/clang-tidy/modernize-use-nodiscard-clang-unused.cpp
  test/clang-tidy/modernize-use-nodiscard-cxx11.cpp
  test/clang-tidy/modernize-use-nodiscard-gcc-unused.cpp
  test/clang-tidy/modernize-use-nodiscard-no-macro-inscope-cxx11.cpp
  test/clang-tidy/modernize-use-nodiscard-no-macro.cpp
  test/clang-tidy/modernize-use-nodiscard.cpp
  test/clang-tidy/modernize-use-nodiscard.h

Index: test/clang-tidy/modernize-use-nodiscard.h
===
--- /dev/null
+++ test/clang-tidy/modernize-use-nodiscard.h
@@ -0,0 +1,5 @@
+
+#define MUST_USE_RESULT __attribute__((warn_unused_result))
+#define NO_DISCARD [[nodiscard]]
+#define NO_RETURN [[noreturn]]
+
Index: test/clang-tidy/modernize-use-nodiscard.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-nodiscard.cpp
@@ -0,0 +1,256 @@
+// RUN: %check_clang_tidy %s modernize-use-nodiscard %t -- \
+// RUN:   -config="{CheckOptions: [{key: modernize-use-nodiscard.ReplacementString, value: 'NO_DISCARD'}]}" \
+// RUN: -- -std=c++17
+
+#include 
+
+namespace boost {
+template 
+class function;
+}
+
+#include "modernize-use-nodiscard.h"
+
+#define BOOLEAN_FUNC bool f23() const
+
+typedef unsigned my_unsigned;
+typedef unsigned &my_unsigned_reference;
+typedef const unsigned &my_unsigned_const_reference;
+
+class Foo {
+public:
+using size_type = unsigned;
+
+bool f1() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f1' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD bool f1() const;
+
+bool f2(int) const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f2' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD bool f2(int) const;
+
+bool f3(const int &) const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f3' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD bool f3(const int &) const;
+
+bool f4(void) const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f4' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD bool f4(void) const;
+
+// negative tests
+
+void f5() const;
+
+bool f6();
+
+bool f7(int &);
+
+bool f8(int &) const;
+
+bool f9(int *) const;
+
+bool f10(const int &, int &) const;
+
+NO_DISCARD bool f12() const;
+
+MUST_USE_RESULT bool f13() const;
+
+[[nodiscard]] bool f11() const;
+
+[[clang::warn_unused_result]] bool f11a() const;
+
+[[gnu::warn_unused_result]] bool f11b() const;
+
+bool _f20() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function '_f20' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD bool _f20() const;
+
+NO_RETURN bool f21() const;
+
+~Foo();
+
+bool operator+=(int) const;
+
+// extra keywords (virtual,inline,const) on return type
+
+virtual bool f14() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f14' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD virtual bool f14() const;
+
+const bool f15() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f15' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD const bool f15() const;
+
+inline const bool f16() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f16' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD inline const bool f16() const;
+
+inline const std::string &f45() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f45' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD inline const std::string &f45() const;
+
+inline virtual const bool f17() const;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: function 'f17' should be marked NO_DISCARD [modernize-use-nodiscard]
+// CHECK-FIXES: NO_DISCARD inline virtual const bool f17() const;
+
+// inline with body
+bool f18() const 
+

[PATCH] D56445: [Sema] Teach Clang that aligned allocation is not supported with macosx10.13

2019-01-08 Thread Louis Dionne via Phabricator via cfe-commits
ldionne created this revision.
ldionne added a reviewer: ahatanak.
Herald added subscribers: cfe-commits, dexonsmith, jkorous, christof.

r306722 added diagnostics when aligned allocation is used with deployment
targets that do not support it, but the first macosx supporting aligned
allocation was incorrectly set to 10.13. In reality, the dylib shipped
with macosx10.13 does not support aligned allocation, but the dylib
shipped with macosx10.14 does.


Repository:
  rC Clang

https://reviews.llvm.org/D56445

Files:
  clang/include/clang/Basic/AlignedAllocation.h
  clang/test/Driver/unavailable_aligned_allocation.cpp
  clang/test/SemaCXX/unavailable_aligned_allocation.cpp
  libcxx/test/libcxx/language.support/support.dynamic/libcpp_deallocate.sh.cpp
  libcxx/test/libcxx/memory/aligned_allocation_macro.pass.cpp

Index: libcxx/test/libcxx/memory/aligned_allocation_macro.pass.cpp
===
--- libcxx/test/libcxx/memory/aligned_allocation_macro.pass.cpp
+++ libcxx/test/libcxx/memory/aligned_allocation_macro.pass.cpp
@@ -9,8 +9,9 @@
 
 // UNSUPPORTED: c++98, c++03, c++11, c++14
 
-// Aligned allocation functions are not provided prior to macosx10.13, but
+// Aligned allocation functions are not provided prior to macosx10.14, but
 // AppleClang <= 10 does not know about this restriction and always enables them.
+// XFAIL: !(apple-clang-9 || apple-clang-10) && availability=macosx10.13
 // XFAIL: !(apple-clang-9 || apple-clang-10) && availability=macosx10.12
 // XFAIL: !(apple-clang-9 || apple-clang-10) && availability=macosx10.11
 // XFAIL: !(apple-clang-9 || apple-clang-10) && availability=macosx10.10
Index: libcxx/test/libcxx/language.support/support.dynamic/libcpp_deallocate.sh.cpp
===
--- libcxx/test/libcxx/language.support/support.dynamic/libcpp_deallocate.sh.cpp
+++ libcxx/test/libcxx/language.support/support.dynamic/libcpp_deallocate.sh.cpp
@@ -14,9 +14,15 @@
 // definitions, which does not yet provide aligned allocation
 // XFAIL: LIBCXX-WINDOWS-FIXME
 
-// Clang 10 (and older) will trigger an availability error when the deployment
+// AppleClang 10 (and older) will trigger an availability error when the deployment
 // target does not support aligned allocation, even if we pass `-faligned-allocation`.
+// XFAIL: apple-clang-10 && availability=macosx10.13
 // XFAIL: apple-clang-10 && availability=macosx10.12
+// XFAIL: apple-clang-10 && availability=macosx10.11
+// XFAIL: apple-clang-10 && availability=macosx10.10
+// XFAIL: apple-clang-10 && availability=macosx10.9
+// XFAIL: apple-clang-10 && availability=macosx10.8
+// XFAIL: apple-clang-10 && availability=macosx10.7
 
 // The dylibs shipped before macosx10.14 do not contain the aligned allocation
 // functions, so trying to force using those with -faligned-allocation results
Index: clang/test/SemaCXX/unavailable_aligned_allocation.cpp
===
--- clang/test/SemaCXX/unavailable_aligned_allocation.cpp
+++ clang/test/SemaCXX/unavailable_aligned_allocation.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.12.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify %s
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.12.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.12.0 -fexceptions -faligned-allocation -faligned-alloc-unavailable -std=c++14 -verify %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.13.0 -fexceptions -faligned-allocation -faligned-alloc-unavailable -std=c++14 -verify %s
 // RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DIOS %s
 // RUN: %clang_cc1 -triple arm64-apple-ios10.0.0 -fexceptions -std=c++1z -verify -DNO_ERRORS %s
 // RUN: %clang_cc1 -triple arm64-apple-tvos10.0.0 -fexceptions -faligned-alloc-unavailable -std=c++1z -verify -DTVOS %s
@@ -117,8 +117,8 @@
 // expected-error@-13 {{aligned allocation function of type 'void *(unsigned long, enum std::align_val_t)' is only available on watchOS 4 or newer}}}
 // expected-error@-14 {{aligned deallocation function of type 'void (void *, enum std::align_val_t) noexcept' is only available on watchOS 4 or newer}}}
 #else
-// expected-error@-16 {{aligned allocation function of type 'void *(unsigned long, enum std::align_val_t)' is only available on macOS 10.13 or newer}}}
-// expected-error@-17 {{aligned deallocation function of type 'void (void *, enum std::align_val_t) noexcept' is only available on macOS 10.13 or newer}}}
+// expected-error@-16 {{aligned allocation function of type 'void *(unsigned long, enum std::align_val_t)' is only available on macOS 10.14 or

[PATCH] D56062: [compiler-rt] [test] Detect glibc-2.27+ and XFAIL appropriate tests

2019-01-08 Thread Michał Górny via Phabricator via cfe-commits
mgorny added a comment.

Ping.


Repository:
  rCRT Compiler Runtime

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

https://reviews.llvm.org/D56062



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


[PATCH] D47817: [compiler-rt] [sanitizer_common] Remove support for tirpc/rpc/xdr.h

2019-01-08 Thread Michał Górny via Phabricator via cfe-commits
mgorny added a comment.

Ping again.


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

https://reviews.llvm.org/D47817



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


[PATCH] D56109: [sanitizer_common] Define __sanitizer_FILE on NetBSD

2019-01-08 Thread Michał Górny via Phabricator via cfe-commits
mgorny added a comment.

Ping.


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

https://reviews.llvm.org/D56109



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


r350641 - Rename DIFlagFixedEnum to DIFlagEnumClass. NFC

2019-01-08 Thread Paul Robinson via cfe-commits
Author: probinson
Date: Tue Jan  8 09:52:29 2019
New Revision: 350641

URL: http://llvm.org/viewvc/llvm-project?rev=350641&view=rev
Log:
Rename DIFlagFixedEnum to DIFlagEnumClass. NFC

Modified:
cfe/trunk/test/CodeGen/debug-info-enum.cpp
cfe/trunk/test/CodeGenCXX/debug-info-enum-class.cpp

Modified: cfe/trunk/test/CodeGen/debug-info-enum.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/debug-info-enum.cpp?rev=350641&r1=350640&r2=350641&view=diff
==
--- cfe/trunk/test/CodeGen/debug-info-enum.cpp (original)
+++ cfe/trunk/test/CodeGen/debug-info-enum.cpp Tue Jan  8 09:52:29 2019
@@ -12,7 +12,7 @@ enum class E0 : signed char {
 } x0;
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E0"
 // CHECK-SAME: baseType: ![[SCHAR:[0-9]+]]
-// CHECK-SAME: DIFlagFixedEnum
+// CHECK-SAME: DIFlagEnumClass
 // CHECK-SAME: elements: ![[ELTS0:[0-9]+]]
 // CHECK: ![[SCHAR]] = !DIBasicType(name: "signed char", size: 8, encoding: 
DW_ATE_signed_char)
 // CHECK: ![[ELTS0]] = !{![[A0:[0-9]+]], ![[B0:[0-9]+]]}
@@ -22,7 +22,7 @@ enum class E0 : signed char {
 enum class E1 : unsigned char { A1 = 255 } x1;
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E1"
 // CHECK-SAME: baseType: ![[UCHAR:[0-9]+]]
-// CHECK-SAME: DIFlagFixedEnum
+// CHECK-SAME: DIFlagEnumClass
 // CHECK-SAME: elements: ![[ELTS1:[0-9]+]]
 // CHECK: ![[UCHAR]] = !DIBasicType(name: "unsigned char", size: 8, encoding: 
DW_ATE_unsigned_char)
 // CHECK: ![[ELTS1]] = !{![[A1:[0-9]+]]}
@@ -34,7 +34,7 @@ enum class E2 : signed short {
 } x2;
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E2"
 // CHECK-SAME: baseType: ![[SHORT:[0-9]+]]
-// CHECK-SAME: DIFlagFixedEnum
+// CHECK-SAME: DIFlagEnumClass
 // CHECK-SAME: elements: ![[ELTS2:[0-9]+]]
 // CHECK: ![[SHORT]] = !DIBasicType(name: "short", size: 16, encoding: 
DW_ATE_signed)
 // CHECK: ![[ELTS2]] = !{![[A2:[0-9]+]], ![[B2:[0-9]+]]}
@@ -44,7 +44,7 @@ enum class E2 : signed short {
 enum class E3 : unsigned short { A3 = 65535 } x3;
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E3"
 // CHECK-SAME: baseType: ![[USHORT:[0-9]+]]
-// CHECK-SAME: DIFlagFixedEnum
+// CHECK-SAME: DIFlagEnumClass
 // CHECK-SAME: elements: ![[ELTS3:[0-9]+]]
 // CHECK: ![[USHORT]] = !DIBasicType(name: "unsigned short", size: 16, 
encoding: DW_ATE_unsigned)
 // CHECK: ![[ELTS3]] = !{![[A3:[0-9]+]]}
@@ -53,7 +53,7 @@ enum class E3 : unsigned short { A3 = 65
 enum class E4 : signed int { A4 = -2147483648, B4 = 2147483647 } x4;
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E4"
 // CHECK-SAME: baseType: ![[INT:[0-9]+]]
-// CHECK-SAME: DIFlagFixedEnum
+// CHECK-SAME: DIFlagEnumClass
 // CHECK-SAME: elements: ![[ELTS4:[0-9]+]]
 // CHECK: ![[INT]] = !DIBasicType(name: "int", size: 32, encoding: 
DW_ATE_signed)
 // CHECK: ![[ELTS4]] = !{![[A4:[0-9]+]], ![[B4:[0-9]+]]}
@@ -63,7 +63,7 @@ enum class E4 : signed int { A4 = -21474
 enum class E5 : unsigned int { A5 = 4294967295 } x5;
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E5"
 // CHECK-SAME: baseType: ![[UINT:[0-9]+]]
-// CHECK-SAME: DIFlagFixedEnum
+// CHECK-SAME: DIFlagEnumClass
 // CHECK-SAME: elements: ![[ELTS5:[0-9]+]]
 // CHECK: ![[UINT]] = !DIBasicType(name: "unsigned int", size: 32, encoding: 
DW_ATE_unsigned)
 // CHECK: ![[ELTS5]] = !{![[A5:[0-9]+]]}
@@ -75,7 +75,7 @@ enum class E6 : signed long long {
 } x6;
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E6"
 // CHECK-SAME: baseType: ![[LONG:[0-9]+]]
-// CHECK-SAME: DIFlagFixedEnum
+// CHECK-SAME: DIFlagEnumClass
 // CHECK-SAME: elements: ![[ELTS6:[0-9]+]]
 // CHECK: ![[LONG]] = !DIBasicType(name: "long long int", size: 64, encoding: 
DW_ATE_signed)
 // CHECK: ![[ELTS6]] = !{![[A6:[0-9]+]], ![[B6:[0-9]+]]}
@@ -85,7 +85,7 @@ enum class E6 : signed long long {
 enum class E7 : unsigned long long { A7 = 18446744073709551615ULL } x7;
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E7"
 // CHECK-SAME: baseType: ![[ULONG:[0-9]+]]
-// CHECK-SAME: DIFlagFixedEnum
+// CHECK-SAME: DIFlagEnumClass
 // CHECK-SAME: elements: ![[ELTS7:[0-9]+]]
 // CHECK: ![[ULONG]] = !DIBasicType(name: "long long unsigned int", size: 64, 
encoding: DW_ATE_unsigned)
 // CHECK: ![[ELTS7]] = !{![[A7:[0-9]+]]}
@@ -95,6 +95,6 @@ enum class E7 : unsigned long long { A7
 enum E8 { A8 = -128, B8 = 127 } x8;
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E8"
 // CHECK-SAME: baseType: ![[INT]]
-// CHECK-NOT: DIFlagFixedEnum
+// CHECK-NOT: DIFlagEnumClass
 // CHECK: !DIEnumerator(name: "A8", value: -128)
 

Modified: cfe/trunk/test/CodeGenCXX/debug-info-enum-class.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-enum-class.cpp?rev=350641&r1=350640&r2=350641&view=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-enum-class.

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

2019-01-08 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington updated this revision to Diff 180690.
erik.pilkington added a comment.
This revision is now accepted and ready to land.

Split -Wdelete-non-virtual-dtor into -Wdelete-non-abstract-non-virtual-dtor and 
-Wdelete-abstract-non-virtual-dtor.


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

https://reviews.llvm.org/D56405

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


Index: clang/test/SemaCXX/delete-non-virtual-dtor.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/delete-non-virtual-dtor.cpp
@@ -0,0 +1,30 @@
+// 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-abstract-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -DDIAG2 -Wmost 
-Wno-delete-abstract-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -Wmost 
-Wno-delete-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 S2 {
+  ~S2() {}
+  virtual void real() {}
+};
+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
@@ -6455,12 +6455,12 @@
 def warn_delete_non_virtual_dtor : Warning<
   "%select{delete|destructor}0 called on non-final %1 that has "
   "virtual functions but non-virtual destructor">,
-  InGroup, DefaultIgnore, ShowInSystemHeader;
+  InGroup, DefaultIgnore, ShowInSystemHeader;
 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;
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -104,7 +104,11 @@
 def MissingNoEscape : DiagGroup<"missing-noescape">;
 
 def DeleteIncomplete : DiagGroup<"delete-incomplete">;
-def DeleteNonVirtualDtor : DiagGroup<"delete-non-virtual-dtor">;
+def DeleteNonAbstractNonVirtualDtor : 
DiagGroup<"delete-non-abstract-non-virtual-dtor">;
+def DeleteAbstractNonVirtualDtor : 
DiagGroup<"delete-abstract-non-virtual-dtor">;
+def DeleteNonVirtualDtor : DiagGroup<"delete-non-virtual-dtor",
+ [DeleteNonAbstractNonVirtualDtor,
+  DeleteAbstractNonVirtualDtor]>;
 def AbstractFinalClass : DiagGroup<"abstract-final-class">;
 
 def CXX11CompatDeprecatedWritableStr :


Index: clang/test/SemaCXX/delete-non-virtual-dtor.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/delete-non-virtual-dtor.cpp
@@ -0,0 +1,30 @@
+// 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-abstract-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -DDIAG2 -Wmost -Wno-delete-abstract-non-virtual-dtor
+// RUN: %clang_cc1 %s -verify -Wmost -Wno-delete-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 S2 {
+  ~S2() {}
+  virtual void real() {}
+};
+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
@@ -6455,12 +6455,12 @@
 def warn_delete_non_virtual_dtor : Warning<
   "%select{delete|destructor}0 called on non-final %1 that has "
   "virtual functions but non-virtual de

[PATCH] D56446: [Driver] Fix libcxx detection on Darwin with clang run as ./clang

2019-01-08 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov created this revision.
ilya-biryukov added reviewers: arphaman, thakis.
Herald added a reviewer: EricWF.
Herald added a subscriber: christof.

By using '..' instead of fs::parent_path.

The intention of the code was to go from 'path/to/clang/bin' to
'path/to/clang/include'. In most cases parent_path works, however it
would fail when clang is run as './clang'.

This was noticed in Chromium's bug tracker, see
https://bugs.chromium.org/p/chromium/issues/detail?id=919761


Repository:
  rC Clang

https://reviews.llvm.org/D56446

Files:
  lib/Driver/ToolChains/Darwin.cpp
  test/Driver/darwin-stdlib.cpp
  test/Tooling/Inputs/mock-libcxx/bin/clang


Index: test/Tooling/Inputs/mock-libcxx/bin/clang
===
--- /dev/null
+++ test/Tooling/Inputs/mock-libcxx/bin/clang
@@ -0,0 +1 @@
+This file is a placeholder to keep its parent directory in git.
Index: test/Driver/darwin-stdlib.cpp
===
--- test/Driver/darwin-stdlib.cpp
+++ test/Driver/darwin-stdlib.cpp
@@ -14,7 +14,7 @@
 // optional absolute include for libc++ from InitHeaderSearch.cpp also fires.
 
 // CHECK-LIBCXX: "-stdlib=libc++"
-// CHECK-LIBCXX: "-internal-isystem" 
"{{[^"]*}}{{/|}}Inputs{{/|}}darwin_toolchain_tree{{/|}}bin{{/|}}include{{/|}}c++{{/|}}v1"
+// CHECK-LIBCXX: "-internal-isystem" 
"{{[^"]*}}{{/|}}Inputs{{/|}}darwin_toolchain_tree{{/|}}bin{{/|}}..{{/|}}include{{/|}}c++{{/|}}v1"
 
 // CHECK-LIBSTDCXX-NOT: -stdlib=libc++
 // CHECK-LIBSTDCXX-NOT: -stdlib=libstdc++
Index: lib/Driver/ToolChains/Darwin.cpp
===
--- lib/Driver/ToolChains/Darwin.cpp
+++ lib/Driver/ToolChains/Darwin.cpp
@@ -1752,10 +1752,11 @@
   break;
 // On Darwin, libc++ may be installed alongside the compiler in
 // include/c++/v1.
-// Get from 'foo/bin' to 'foo'.
-SmallString<128> P = llvm::sys::path::parent_path(InstallDir);
-// Get to 'foo/include/c++/v1'.
-llvm::sys::path::append(P, "include", "c++", "v1");
+// Get from 'foo/bin' to 'foo/include/c++/v1'.
+SmallString<128> P = InstallDir;
+// Note that InstallDir can be relative, so we have to '..' and not
+// parent_path.
+llvm::sys::path::append(P, "..", "include", "c++", "v1");
 addSystemInclude(DriverArgs, CC1Args, P);
 break;
   }


Index: test/Tooling/Inputs/mock-libcxx/bin/clang
===
--- /dev/null
+++ test/Tooling/Inputs/mock-libcxx/bin/clang
@@ -0,0 +1 @@
+This file is a placeholder to keep its parent directory in git.
Index: test/Driver/darwin-stdlib.cpp
===
--- test/Driver/darwin-stdlib.cpp
+++ test/Driver/darwin-stdlib.cpp
@@ -14,7 +14,7 @@
 // optional absolute include for libc++ from InitHeaderSearch.cpp also fires.
 
 // CHECK-LIBCXX: "-stdlib=libc++"
-// CHECK-LIBCXX: "-internal-isystem" "{{[^"]*}}{{/|}}Inputs{{/|}}darwin_toolchain_tree{{/|}}bin{{/|}}include{{/|}}c++{{/|}}v1"
+// CHECK-LIBCXX: "-internal-isystem" "{{[^"]*}}{{/|}}Inputs{{/|}}darwin_toolchain_tree{{/|}}bin{{/|}}..{{/|}}include{{/|}}c++{{/|}}v1"
 
 // CHECK-LIBSTDCXX-NOT: -stdlib=libc++
 // CHECK-LIBSTDCXX-NOT: -stdlib=libstdc++
Index: lib/Driver/ToolChains/Darwin.cpp
===
--- lib/Driver/ToolChains/Darwin.cpp
+++ lib/Driver/ToolChains/Darwin.cpp
@@ -1752,10 +1752,11 @@
   break;
 // On Darwin, libc++ may be installed alongside the compiler in
 // include/c++/v1.
-// Get from 'foo/bin' to 'foo'.
-SmallString<128> P = llvm::sys::path::parent_path(InstallDir);
-// Get to 'foo/include/c++/v1'.
-llvm::sys::path::append(P, "include", "c++", "v1");
+// Get from 'foo/bin' to 'foo/include/c++/v1'.
+SmallString<128> P = InstallDir;
+// Note that InstallDir can be relative, so we have to '..' and not
+// parent_path.
+llvm::sys::path::append(P, "..", "include", "c++", "v1");
 addSystemInclude(DriverArgs, CC1Args, P);
 break;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r346652 - Make clang-based tools find libc++ on MacOS

2019-01-08 Thread Ilya Biryukov via cfe-commits
Hi Nico,

This is clearly a bug, it's supposed to search in a sibling directory.
Are you running clang as './clang' in the scripts?  The code seems to break
in that case, https://reviews.llvm.org/D56446 should fix this.

On Tue, Jan 8, 2019 at 5:12 PM Nico Weber  wrote:

> It looks like clang now looks for libc++ headers in -internal-isystem
> Release+Asserts/bin/include/c++/v1 , compared to -internal-isystem
> Release+Asserts/include/c++/v1. `make install` puts the libc++ headers in
> Release+Asserts/include, the old location. Was this an intentional change?
>
> As-is, this seems to break chromium's clang ability to find libc++ headers
> (https://crbug.com/919761) because we bundle libc++ headers in an
> "include" directory that's a sibling to the "bin" directory (and have been
> doing so for 4.5 years, since https://codereview.chromium.org/281753002).
>
> On Mon, Nov 12, 2018 at 8:58 AM Ilya Biryukov via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: ibiryukov
>> Date: Mon Nov 12 05:55:55 2018
>> New Revision: 346652
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=346652&view=rev
>> Log:
>> Make clang-based tools find libc++ on MacOS
>>
>> Summary:
>> When they read compiler args from compile_commands.json.
>> This change allows to run clang-based tools, like clang-tidy or clangd,
>> built from head using the compile_commands.json file produced for XCode
>> toolchains.
>>
>> On MacOS clang can find the C++ standard library relative to the
>> compiler installation dir.
>>
>> The logic to do this was based on resource dir as an approximation of
>> where the compiler is installed. This broke the tools that read
>> 'compile_commands.json' and don't ship with the compiler, as they
>> typically change resource dir.
>>
>> To workaround this, we now use compiler install dir detected by the driver
>> to better mimic the behavior of the original compiler when replaying the
>> compilations using other tools.
>>
>> Reviewers: sammccall, arphaman, EricWF
>>
>> Reviewed By: sammccall
>>
>> Subscribers: ioeric, christof, kadircet, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D54310
>>
>> Added:
>> cfe/trunk/test/Tooling/Inputs/mock-libcxx/
>> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/
>> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/c++/
>> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/c++/v1/
>> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/c++/v1/mock_vector
>> cfe/trunk/test/Tooling/clang-check-mac-libcxx-abspath.cpp
>> cfe/trunk/test/Tooling/clang-check-mac-libcxx-relpath.cpp
>> Modified:
>> cfe/trunk/include/clang/Lex/HeaderSearchOptions.h
>> cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp
>> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
>> cfe/trunk/lib/Tooling/Tooling.cpp
>>
>> Modified: cfe/trunk/include/clang/Lex/HeaderSearchOptions.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearchOptions.h?rev=346652&r1=346651&r2=346652&view=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Lex/HeaderSearchOptions.h (original)
>> +++ cfe/trunk/include/clang/Lex/HeaderSearchOptions.h Mon Nov 12 05:55:55
>> 2018
>> @@ -108,6 +108,13 @@ public:
>>/// etc.).
>>std::string ResourceDir;
>>
>> +  /// Compiler install dir as detected by the Driver.
>> +  /// This is typically the directory that contains the clang
>> executable, i.e.
>> +  /// the 'bin/' subdir of a clang distribution.
>> +  /// Only used to add include dirs for libc++ on Darwin. Please avoid
>> relying
>> +  /// on this field for other purposes.
>> +  std::string InstallDir;
>> +
>>/// The directory used for the module cache.
>>std::string ModuleCachePath;
>>
>>
>> Modified: cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp?rev=346652&r1=346651&r2=346652&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp (original)
>> +++ cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp Mon Nov 12
>> 05:55:55 2018
>> @@ -11,17 +11,18 @@
>>  //
>>
>>  
>> //===--===//
>>
>> -#include "clang/Frontend/Utils.h"
>>  #include "clang/Basic/DiagnosticOptions.h"
>> +#include "clang/Driver/Action.h"
>>  #include "clang/Driver/Compilation.h"
>>  #include "clang/Driver/Driver.h"
>> -#include "clang/Driver/Action.h"
>>  #include "clang/Driver/Options.h"
>>  #include "clang/Driver/Tool.h"
>>  #include "clang/Frontend/CompilerInstance.h"
>>  #include "clang/Frontend/FrontendDiagnostic.h"
>> +#include "clang/Frontend/Utils.h"
>>  #include "llvm/Option/ArgList.h"
>>  #include "llvm/Support/Host.h"
>> +#include "llvm/Support/Path.h"
>>  using namespace clang;
>>  usin

r350642 - __has_feature(pragma_clang_attribute_namespaces) should be __has_extension

2019-01-08 Thread Erik Pilkington via cfe-commits
Author: epilk
Date: Tue Jan  8 10:24:39 2019
New Revision: 350642

URL: http://llvm.org/viewvc/llvm-project?rev=350642&view=rev
Log:
__has_feature(pragma_clang_attribute_namespaces) should be __has_extension

Thanks to Richard Smith for pointing this out.

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=350642&r1=350641&r2=350642&view=diff
==
--- cfe/trunk/docs/LanguageExtensions.rst (original)
+++ cfe/trunk/docs/LanguageExtensions.rst Tue Jan  8 10:24:39 2019
@@ -2727,7 +2727,7 @@ Without the namespaces on the macros, ``
 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. You can test if
 your version of clang supports namespaces on ``#pragma clang attribute`` with
-``__has_feature(pragma_clang_attribute_namespaces)``.
+``__has_extension(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=350642&r1=350641&r2=350642&view=diff
==
--- cfe/trunk/include/clang/Basic/Features.def (original)
+++ cfe/trunk/include/clang/Basic/Features.def Tue Jan  8 10:24:39 2019
@@ -17,6 +17,12 @@
 //
 // The Predicate field dictates the conditions under which the feature or
 // extension will be made available.
+//
+// FEATURE(...) should be used to advertise support for standard language
+// features, whereas EXTENSION(...) should be used for clang extensions. Note
+// that many of the identifiers in this file don't follow this rule for 
backward
+// compatibility reasons.
+//
 
//===--===//
 
 #if !defined(FEATURE) && !defined(EXTENSION)
@@ -69,7 +75,6 @@ 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)
@@ -241,6 +246,7 @@ EXTENSION(cxx_init_captures, LangOpts.CP
 EXTENSION(cxx_variable_templates, LangOpts.CPlusPlus)
 // Miscellaneous language extensions
 EXTENSION(overloadable_unmarked, true)
+EXTENSION(pragma_clang_attribute_namespaces, true)
 
 #undef EXTENSION
 #undef FEATURE

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=350642&r1=350641&r2=350642&view=diff
==
--- cfe/trunk/test/Sema/pragma-attribute-namespace.c (original)
+++ cfe/trunk/test/Sema/pragma-attribute-namespace.c Tue Jan  8 10:24:39 2019
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
 
-#if !__has_feature(pragma_clang_attribute_namespaces)
+#if !__has_extension(pragma_clang_attribute_namespaces)
 #error
 #endif
 


___
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-08 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.



In D55433#1349709 , @JonasToth wrote:

> No problem, thats why we test on real projects first, because there is always 
> something hidden in C++ :)
>
> Is there a test for the lambdas?


test/clang-tidy/modernize-use-nodiscard.cpp line 158  (which is how it 
manifested inside LLVM) as a lambda assigned to an auto


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


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

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


On 1/7/19 4:43 PM, Richard Smith wrote:
On Mon, 7 Jan 2019 at 16:12, Erik Pilkington via cfe-commits 
mailto: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
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?

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.



Yeah, it doesn't really seem like a useful distinction. Anyways, I added 
a comment to this file and fixed this in r350642. Thanks!




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/

[PATCH] D55337: NFC: Move dumpDeclRef to NodeDumper

2019-01-08 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.

Once D56407  lands, the rebased changes here 
LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D55337



___
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-08 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added inline comments.



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:46
+auto IdentifierInfo = MacroNameToken.getIdentifierInfo();
+if (!IdentifierInfo) {
+  return;

Please elide braces.


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] D56446: [Driver] Fix libcxx detection on Darwin with clang run as ./clang

2019-01-08 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman accepted this revision.
arphaman added a comment.
This revision is now accepted and ready to land.

That makes sense, LGTM. Thanks!


Repository:
  rC Clang

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

https://reviews.llvm.org/D56446



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


Re: r346652 - Make clang-based tools find libc++ on MacOS

2019-01-08 Thread Nico Weber via cfe-commits
That looks like it should help. Thanks for the quick fix!

On Tue, Jan 8, 2019 at 1:11 PM Ilya Biryukov  wrote:

> Hi Nico,
>
> This is clearly a bug, it's supposed to search in a sibling directory.
> Are you running clang as './clang' in the scripts?  The code seems to
> break in that case, https://reviews.llvm.org/D56446 should fix this.
>
> On Tue, Jan 8, 2019 at 5:12 PM Nico Weber  wrote:
>
>> It looks like clang now looks for libc++ headers in -internal-isystem
>> Release+Asserts/bin/include/c++/v1 , compared to -internal-isystem
>> Release+Asserts/include/c++/v1. `make install` puts the libc++ headers in
>> Release+Asserts/include, the old location. Was this an intentional change?
>>
>> As-is, this seems to break chromium's clang ability to find libc++
>> headers (https://crbug.com/919761) because we bundle libc++ headers in
>> an "include" directory that's a sibling to the "bin" directory (and have
>> been doing so for 4.5 years, since
>> https://codereview.chromium.org/281753002).
>>
>> On Mon, Nov 12, 2018 at 8:58 AM Ilya Biryukov via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: ibiryukov
>>> Date: Mon Nov 12 05:55:55 2018
>>> New Revision: 346652
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=346652&view=rev
>>> Log:
>>> Make clang-based tools find libc++ on MacOS
>>>
>>> Summary:
>>> When they read compiler args from compile_commands.json.
>>> This change allows to run clang-based tools, like clang-tidy or clangd,
>>> built from head using the compile_commands.json file produced for XCode
>>> toolchains.
>>>
>>> On MacOS clang can find the C++ standard library relative to the
>>> compiler installation dir.
>>>
>>> The logic to do this was based on resource dir as an approximation of
>>> where the compiler is installed. This broke the tools that read
>>> 'compile_commands.json' and don't ship with the compiler, as they
>>> typically change resource dir.
>>>
>>> To workaround this, we now use compiler install dir detected by the
>>> driver
>>> to better mimic the behavior of the original compiler when replaying the
>>> compilations using other tools.
>>>
>>> Reviewers: sammccall, arphaman, EricWF
>>>
>>> Reviewed By: sammccall
>>>
>>> Subscribers: ioeric, christof, kadircet, cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D54310
>>>
>>> Added:
>>> cfe/trunk/test/Tooling/Inputs/mock-libcxx/
>>> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/
>>> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/c++/
>>> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/c++/v1/
>>> cfe/trunk/test/Tooling/Inputs/mock-libcxx/include/c++/v1/mock_vector
>>> cfe/trunk/test/Tooling/clang-check-mac-libcxx-abspath.cpp
>>> cfe/trunk/test/Tooling/clang-check-mac-libcxx-relpath.cpp
>>> Modified:
>>> cfe/trunk/include/clang/Lex/HeaderSearchOptions.h
>>> cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp
>>> cfe/trunk/lib/Frontend/InitHeaderSearch.cpp
>>> cfe/trunk/lib/Tooling/Tooling.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Lex/HeaderSearchOptions.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearchOptions.h?rev=346652&r1=346651&r2=346652&view=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Lex/HeaderSearchOptions.h (original)
>>> +++ cfe/trunk/include/clang/Lex/HeaderSearchOptions.h Mon Nov 12
>>> 05:55:55 2018
>>> @@ -108,6 +108,13 @@ public:
>>>/// etc.).
>>>std::string ResourceDir;
>>>
>>> +  /// Compiler install dir as detected by the Driver.
>>> +  /// This is typically the directory that contains the clang
>>> executable, i.e.
>>> +  /// the 'bin/' subdir of a clang distribution.
>>> +  /// Only used to add include dirs for libc++ on Darwin. Please avoid
>>> relying
>>> +  /// on this field for other purposes.
>>> +  std::string InstallDir;
>>> +
>>>/// The directory used for the module cache.
>>>std::string ModuleCachePath;
>>>
>>>
>>> Modified: cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp?rev=346652&r1=346651&r2=346652&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp (original)
>>> +++ cfe/trunk/lib/Frontend/CreateInvocationFromCommandLine.cpp Mon Nov
>>> 12 05:55:55 2018
>>> @@ -11,17 +11,18 @@
>>>  //
>>>
>>>  
>>> //===--===//
>>>
>>> -#include "clang/Frontend/Utils.h"
>>>  #include "clang/Basic/DiagnosticOptions.h"
>>> +#include "clang/Driver/Action.h"
>>>  #include "clang/Driver/Compilation.h"
>>>  #include "clang/Driver/Driver.h"
>>> -#include "clang/Driver/Action.h"
>>>  #include "clang/Driver/Options.h"
>>>  #include "clang/Driver/Tool.h"
>>>  #include "clang/Frontend/CompilerI

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

2019-01-08 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added inline comments.



Comment at: clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp:27
+static bool isGoogletestTestMacro(StringRef MacroName) {
+  static const llvm::StringSet<> MacroNames = {"TEST", "TEST_F", "TEST_P",
+   "TYPED_TEST", "TYPED_TEST_P"};

Is there value in making the list of macros and option?, I've worked with other 
unit testing packages (some inhouse) that use the same format as google test, 
but don't use TEST() itself

e.g.  (to name a few)

```
TEST_CASE(testclass, testname)
BOOST_TEST(statement, floating_point_comparison_manipulation);
BOOST_DATA_TEST_CASE(test_case_name, dataset)
BOOST_FIXTURE_TEST_CASE( test_case2, F )
BOOST_AUTO_TEST_CASE( test_case3 )

```

too many for you to capture in the checker...but a nice addition for those who 
use alternative frameworks and would like to benefit from similar  "no 
underscore" naming conventions



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] D56391: Limit COFF 'common' emission to <=32 alignment types.

2019-01-08 Thread Erich Keane via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC350643: Limit COFF 'common' emission to <=32 
alignment types. (authored by erichkeane, committed by ).

Repository:
  rC Clang

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

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
===
--- test/CodeGen/microsoft-no-common-align.c
+++ 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().isKnownWindowsMSVCEnvironment() &&
+  Context.getTypeAlignIfKnown(D->getType()) > 32)
+return true;
 
   return false;
 }


Index: test/CodeGen/microsoft-no-common-align.c
===
--- test/CodeGen/microsoft-no-common-align.c
+++ 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().isKnownWindowsMSVCEnvironment() &&
+  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


r350644 - [NFC] Don't over-eagerly check block alignment

2019-01-08 Thread JF Bastien via cfe-commits
Author: jfb
Date: Tue Jan  8 10:51:38 2019
New Revision: 350644

URL: http://llvm.org/viewvc/llvm-project?rev=350644&view=rev
Log:
[NFC] Don't over-eagerly check block alignment

Alignment of __block isn't relevant to this test, remove its checking.

Modified:
cfe/trunk/test/CodeGenCXX/trivial-auto-var-init.cpp

Modified: cfe/trunk/test/CodeGenCXX/trivial-auto-var-init.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/trivial-auto-var-init.cpp?rev=350644&r1=350643&r2=350644&view=diff
==
--- cfe/trunk/test/CodeGenCXX/trivial-auto-var-init.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/trivial-auto-var-init.cpp Tue Jan  8 10:51:38 2019
@@ -22,9 +22,9 @@ void test_selfinit() {
 
 // UNINIT-LABEL:  test_block(
 // ZERO-LABEL:test_block(
-// ZERO: store i32 0, i32* %block, align 4
+// ZERO: store i32 0, i32* %block
 // PATTERN-LABEL: test_block(
-// PATTERN: store i32 -1431655766, i32* %block, align 4
+// PATTERN: store i32 -1431655766, i32* %block
 void test_block() {
   __block int block;
   used(block);


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


r350643 - Limit COFF 'common' emission to <=32 alignment types.

2019-01-08 Thread Erich Keane via cfe-commits
Author: erichkeane
Date: Tue Jan  8 10:44:22 2019
New Revision: 350643

URL: http://llvm.org/viewvc/llvm-project?rev=350643&view=rev
Log:
Limit COFF 'common' emission to <=32 alignment types.

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

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

Change-Id: I48609289753b7f3b58c5e2bc1712756750fbd45a

Added:
cfe/trunk/test/CodeGen/microsoft-no-common-align.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=350643&r1=350642&r2=350643&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Jan  8 10:44:22 2019
@@ -3761,6 +3761,11 @@ static bool isVarDeclStrongDefinition(co
   }
 }
   }
+  // COFF doesn't support alignments greater than 32, so these cannot be
+  // in common.
+  if (Context.getTargetInfo().getTriple().isKnownWindowsMSVCEnvironment() &&
+  Context.getTypeAlignIfKnown(D->getType()) > 32)
+return true;
 
   return false;
 }

Added: cfe/trunk/test/CodeGen/microsoft-no-common-align.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/microsoft-no-common-align.c?rev=350643&view=auto
==
--- cfe/trunk/test/CodeGen/microsoft-no-common-align.c (added)
+++ cfe/trunk/test/CodeGen/microsoft-no-common-align.c Tue Jan  8 10:44:22 2019
@@ -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


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


r350645 - Fix opencl test broken on windows by r350643.

2019-01-08 Thread Erich Keane via cfe-commits
Author: erichkeane
Date: Tue Jan  8 11:10:43 2019
New Revision: 350645

URL: http://llvm.org/viewvc/llvm-project?rev=350645&view=rev
Log:
Fix opencl test broken on windows by r350643.

Windows doesn't allow common with alignment >32 bits, so these tests
were broken in windows mode.  This patch makes 'common' optional in
these cases.

Change-Id: I4d5fdd07ecdafc3570ef9b09cd816c2e5e4ed15e

Modified:
cfe/trunk/test/CodeGenOpenCL/address-spaces.cl

Modified: cfe/trunk/test/CodeGenOpenCL/address-spaces.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/address-spaces.cl?rev=350645&r1=350644&r2=350645&view=diff
==
--- cfe/trunk/test/CodeGenOpenCL/address-spaces.cl (original)
+++ cfe/trunk/test/CodeGenOpenCL/address-spaces.cl Tue Jan  8 11:10:43 2019
@@ -19,7 +19,7 @@ struct S {
 // CL20-DAG: @g_static_var = internal addrspace(1) global float 0.00e+00
 
 #ifdef CL20
-// CL20-DAG: @g_s = common {{(dso_local )?}}addrspace(1) global %struct.S 
zeroinitializer
+// CL20-DAG: @g_s = {{(common )?}}{{(dso_local )?}}addrspace(1) global 
%struct.S zeroinitializer
 struct S g_s;
 #endif
 
@@ -55,7 +55,7 @@ void fc(constant int *arg) {}
 int i;
 // CL20-DAG: @i = common {{(dso_local )?}}addrspace(1) global i32 0
 int *ptr;
-// CL20SPIR-DAG: @ptr = common {{(dso_local )?}}addrspace(1) global i32 
addrspace(4)* null
+// CL20SPIR-DAG: @ptr = {{(common )?}}{{(dso_local )?}}addrspace(1) global i32 
addrspace(4)* null
 // CL20AMDGCN-DAG: @ptr = common {{(dso_local )?}}addrspace(1) global i32* null
 #endif
 


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


[PATCH] D56445: [Sema] Teach Clang that aligned allocation is not supported with macosx10.13

2019-01-08 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak accepted this revision.
ahatanak added a comment.
This revision is now accepted and ready to land.

LGTM.

We should probably check that alignedAllocMinVersion returns the correct 
versions for other OSes too, but this patch is fine.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56445



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


[PATCH] D55224: [clangd] Introduce loading of shards within auto-index

2019-01-08 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 180706.
kadircet marked 23 inline comments as done.
kadircet added a comment.

Address comments


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D55224

Files:
  clangd/SourceCode.cpp
  clangd/SourceCode.h
  clangd/index/Background.cpp
  clangd/index/Background.h
  clangd/index/SymbolCollector.cpp
  test/clangd/background-index.test
  unittests/clangd/BackgroundIndexTests.cpp

Index: unittests/clangd/BackgroundIndexTests.cpp
===
--- unittests/clangd/BackgroundIndexTests.cpp
+++ unittests/clangd/BackgroundIndexTests.cpp
@@ -7,6 +7,7 @@
 
 using testing::_;
 using testing::AllOf;
+using testing::Contains;
 using testing::Not;
 using testing::UnorderedElementsAre;
 
@@ -125,7 +126,7 @@
FileURI("unittest:///root/B.cc")}));
 }
 
-TEST_F(BackgroundIndexTest, ShardStorageWriteTest) {
+TEST_F(BackgroundIndexTest, ShardStorageTest) {
   MockFSProvider FS;
   FS.Files[testPath("root/A.h")] = R"cpp(
   void common();
@@ -154,6 +155,16 @@
   EXPECT_EQ(CacheHits, 0U);
   EXPECT_EQ(Storage.size(), 2U);
 
+  {
+OverlayCDB CDB(/*Base=*/nullptr);
+BackgroundIndex Idx(Context::empty(), "", FS, CDB,
+[&](llvm::StringRef) { return &MSS; });
+CDB.setCompileCommand(testPath("root"), Cmd);
+ASSERT_TRUE(Idx.blockUntilIdleForTest());
+  }
+  EXPECT_EQ(CacheHits, 2U); // Check both A.cc and A.h loaded from cache.
+  EXPECT_EQ(Storage.size(), 2U);
+
   auto ShardHeader = MSS.loadShard(testPath("root/A.h"));
   EXPECT_NE(ShardHeader, nullptr);
   EXPECT_THAT(
@@ -221,5 +232,73 @@
   EmptyIncludeNode());
 }
 
+TEST_F(BackgroundIndexTest, ShardStorageLoad) {
+  MockFSProvider FS;
+  FS.Files[testPath("root/A.h")] = R"cpp(
+  void common();
+  void f_b();
+  class A_CC {};
+  )cpp";
+  FS.Files[testPath("root/A.cc")] =
+  "#include \"A.h\"\nvoid g() { (void)common; }";
+
+  llvm::StringMap Storage;
+  size_t CacheHits = 0;
+  MemoryShardStorage MSS(Storage, CacheHits);
+
+  tooling::CompileCommand Cmd;
+  Cmd.Filename = testPath("root/A.cc");
+  Cmd.Directory = testPath("root");
+  Cmd.CommandLine = {"clang++", testPath("root/A.cc")};
+  // Check nothing is loaded from Storage, but A.cc and A.h has been stored.
+  {
+OverlayCDB CDB(/*Base=*/nullptr);
+BackgroundIndex Idx(Context::empty(), "", FS, CDB,
+[&](llvm::StringRef) { return &MSS; });
+CDB.setCompileCommand(testPath("root/A.cc"), Cmd);
+ASSERT_TRUE(Idx.blockUntilIdleForTest());
+  }
+
+  // Change header.
+  FS.Files[testPath("root/A.h")] = R"cpp(
+  void common();
+  void f_b();
+  class A_CC {};
+  class A_CCnew {};
+  )cpp";
+  {
+OverlayCDB CDB(/*Base=*/nullptr);
+BackgroundIndex Idx(Context::empty(), "", FS, CDB,
+[&](llvm::StringRef) { return &MSS; });
+CDB.setCompileCommand(testPath("root"), Cmd);
+ASSERT_TRUE(Idx.blockUntilIdleForTest());
+  }
+  EXPECT_EQ(CacheHits, 2U); // Check both A.cc and A.h loaded from cache.
+
+  // Check if the new symbol has arrived.
+  auto ShardHeader = MSS.loadShard(testPath("root/A.h"));
+  EXPECT_NE(ShardHeader, nullptr);
+  EXPECT_THAT(*ShardHeader->Symbols, Contains(Named("A_CCnew")));
+
+  // Change source.
+  FS.Files[testPath("root/A.cc")] =
+  "#include \"A.h\"\nvoid g() { (void)common; }\nvoid f_b() {}";
+  {
+CacheHits = 0;
+OverlayCDB CDB(/*Base=*/nullptr);
+BackgroundIndex Idx(Context::empty(), "", FS, CDB,
+[&](llvm::StringRef) { return &MSS; });
+CDB.setCompileCommand(testPath("root"), Cmd);
+ASSERT_TRUE(Idx.blockUntilIdleForTest());
+  }
+  EXPECT_EQ(CacheHits, 2U); // Check both A.cc and A.h loaded from cache.
+
+  // Check if the new symbol has arrived.
+  auto ShardSource = MSS.loadShard(testPath("root/A.cc"));
+  EXPECT_NE(ShardHeader, nullptr);
+  EXPECT_THAT(*ShardSource->Symbols,
+  Contains(AllOf(Named("f_b"), Declared(), Defined(;
+}
+
 } // namespace clangd
 } // namespace clang
Index: test/clangd/background-index.test
===
--- test/clangd/background-index.test
+++ test/clangd/background-index.test
@@ -16,6 +16,5 @@
 # RUN: ls %t/.clangd-index/foo.cpp.*.idx
 
 # Test the index is read from disk: delete code and restart clangd.
-# FIXME: This test currently fails as we don't read the index yet.
 # RUN: rm %t/foo.cpp
-# RUN: clangd -background-index -lit-test < %t/definition.jsonrpc | not FileCheck %t/definition.jsonrpc
+# RUN: clangd -background-index -lit-test < %t/definition.jsonrpc | FileCheck %t/definition.jsonrpc
Index: clangd/index/SymbolCollector.cpp
===
--- clangd/index/SymbolCollector.cpp
+++ clangd/index/SymbolCollector.cpp
@@ -58,29 +58,10 @@

[PATCH] D55224: [clangd] Introduce loading of shards within auto-index

2019-01-08 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clangd/index/Background.cpp:259
+  // if this thread sees the older version but finishes later. This should
+  // be rare in practice.
+  DigestIt.first->second = Hash;

ilya-biryukov wrote:
> kadircet wrote:
> > ilya-biryukov wrote:
> > > > "should be rare in practice"
> > > And yet, can we avoid this altogether?
> > > 
> > > Also, I believe it won't be rare. When processing multiple different TUs, 
> > > we can easily run into the same header multiple times, possibly with the 
> > > different contents.
> > > E.g. imagine the index for the whole of clang is being built and the user 
> > > is editing `Sema.h` at the same time. We'll definitely be running into 
> > > this case over and over again.
> > Well I am open to ideas, but currently there is no way of knowing whether 
> > this is the newer version for the file. Because only information we have is 
> > the digest is different than what we currently have and this doesn't yield 
> > any chronological information.
> Do we know which request is "newer" when scheduling it?
> If so, we could keep the map of the **latest** hashes of the files we've seen 
> (in addition to the `IndexedFileDigests`, which correspond to the digest for 
> which we built the index IIUC).
> 
> This would give us a simple invariant of the final state we want to bring the 
> index to: `IndexedFileDigests` should correspond to the latest hashes seen so 
> far. If not, we have to rebuild the index for the corresponding files. That, 
> in turn, gives us a way to resolve conflicts: we should never replace with 
> symbols built for the latest version (hash) of the file we've seen.
> 
> Would that work?
I am not sure if it would work for non-main files. We update the Hash for the 
main files at each indexing action, so we can safely keep track of the latest 
versions. But we collect hashes for dependencies while performing the indexing 
which happens in parallel. Therefore an indexing action triggered earlier might 
get an up-to-date version of a dependency than an action triggered later-on.



Comment at: clangd/index/Background.cpp:468
+if (!Shard || !Shard->Sources) {
+  vlog("Failed to load shard: {0}", CurDependencyPath);
+  continue;

ilya-biryukov wrote:
> Should we mark the file as requiring re-indexing at this point?
> Not sure how that might happen in practice, but still...
All files are marked as requiring re-indexing by default 
`Dependencies.push_back({AbsolutePath, true})`. The second element is always 
true, and we only mark it as false if we are sure file is up-to-date.



Comment at: clangd/index/Background.cpp:475
+if (auto AbsolutePath = URI::resolve(*U, CurDependencyPath)) {
+  if (*AbsolutePath != CurDependencyPath) {
+if (InQueue.try_emplace(*AbsolutePath).second)

ilya-biryukov wrote:
> Why do we need an extra check for self-edges here? Shouldn't 
> `InQueue.try_emplace` handle this too?
It is not looking for a self-edge. It is trying to find source information 
related to current file(which contains symbols, refs and hash). The nesting 
seems to be confusing it was just to prevent one redundant try_emplace seems 
like making the code less readable taking it out.



Comment at: clangd/index/Background.h:108
   BackgroundIndexStorage::Factory IndexStorageFactory;
+  // Loads the shards for all the sources and headers of the Cmd. Returns the
+  // list of dependencies for this Cmd and whether they need to be re-indexed.

ilya-biryukov wrote:
> Could you elaborate what are the "sources and headers of the Cmd"? The 
> compile command is typically created for a **single** source file, so this 
> comment looks a bit confusing.
It seems like comment become out-dated marking as done.



Comment at: clangd/index/Background.h:121
+  std::vector>
+  &NeedsReIndexing);
+  void enqueue(tooling::CompileCommand Cmd, BackgroundIndexStorage *Storage);

ilya-biryukov wrote:
> Maybe return `Expected>` instead of using an out parameter?
Actually this function can no longer fail, therefore directly returning the 
vector


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D55224



___
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-08 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits
gtbercea updated this revision to Diff 180709.
gtbercea added a comment.

  Invert accumulation direction.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56413

Files:
  docs/OpenMPSupport.rst
  include/clang/Basic/LangOptions.def
  include/clang/Driver/Options.td
  lib/Driver/ToolChains/Clang.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/for_codegen.cpp
  test/OpenMP/for_simd_codegen.cpp
  test/OpenMP/nvptx_target_teams_distribute_parallel_for_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,8 +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-NEXT: [[J_2:%.+]] = mul nsw i64 [[J_1]], 2
+// CHECK: [[IV2_1:%.+]] = load i64, i64* [[T1_OMP_IV]]{{.*}}!llvm.mem.parallel_loop_access ![[T1_ID]]
+// CHECK-NEXT: [[I_1_DIV1:%.+]] = sdiv i64 [[IV2_1]], 4
+// CHECK-NEXT: [[I_1_MUL1:%.+]] = mul nsw i64 [[I_1_DIV1]], 4
+// CHECK-NEXT: [[I_1_SUB0:%.+]] = sub nsw i64 [[IV2]], [[I_1_MUL1]]
+// CHECK-NEXT: [[J_2:%.+]] = mul nsw i64 [[I_1_SUB0]], 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]]
 // simd.for.inc:
@@ -393,22 +396,70 @@
 // 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: [[SUB_3:%.+]] = sub i32 [[IV1_2]], [[MUL_1]]
+// 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:%.+]] = sub i32 [[IV1_3]], [[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: [[SUB_6:%.+]] = sub i32 [[IV1_4]], [[MUL_3]]
+// CHECK-NEXT: [[DIV_3:%.+]] = udiv i32 [[SUB_6]], 20
+// CHECK-NEXT: [[MUL_4:%.+]] = mul i32 [[DIV_3]], 20
+// CHECK-NEXT: [[ADD_5:%.+]] = sub i32 [[ADD_3]], [[MUL_4]]
+// CHECK-NEXT: [[DIV_4:%.+]] = udiv i32 [[ADD_5]], 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: [[SUB_7:%.+]] = sub i32 [[IV1_5]], [[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
+// CHECK-NEXT: [[SUB_10:%.+]] = sub i32 [[IV1_

[PATCH] D55483: Introduce the callback attribute and emit !callback metadata

2019-01-08 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert updated this revision to Diff 180710.
jdoerfert marked 3 inline comments as done.
jdoerfert added a comment.

Update encoding, rebase to HEAD


Repository:
  rC Clang

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

https://reviews.llvm.org/D55483

Files:
  include/clang/AST/ASTContext.h
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/Builtins.def
  include/clang/Basic/Builtins.h
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/AST/ASTContext.cpp
  lib/Basic/Builtins.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/Analysis/retain-release.m
  test/CodeGen/attr-callback.c
  test/CodeGen/callback_annotated.c
  test/CodeGen/callback_openmp.c
  test/CodeGen/callback_pthread_create.c
  test/CodeGenCXX/attr-callback.cpp
  test/Misc/pragma-attribute-supported-attributes-list.test
  test/OpenMP/parallel_codegen.cpp
  test/Sema/attr-callback-broken.c
  test/Sema/attr-callback.c
  test/SemaCXX/attr-callback-broken.cpp
  test/SemaCXX/attr-callback.cpp
  utils/TableGen/ClangAttrEmitter.cpp

Index: utils/TableGen/ClangAttrEmitter.cpp
===
--- utils/TableGen/ClangAttrEmitter.cpp
+++ utils/TableGen/ClangAttrEmitter.cpp
@@ -1275,6 +1275,8 @@
 Ptr = llvm::make_unique(Arg, Attr, "unsigned");
   else if (ArgName == "VariadicUnsignedArgument")
 Ptr = llvm::make_unique(Arg, Attr, "unsigned");
+  else if (ArgName == "VariadicSignedArgument")
+Ptr = llvm::make_unique(Arg, Attr, "int");
   else if (ArgName == "VariadicStringArgument")
 Ptr = llvm::make_unique(Arg, Attr);
   else if (ArgName == "VariadicEnumArgument")
Index: test/SemaCXX/attr-callback.cpp
===
--- /dev/null
+++ test/SemaCXX/attr-callback.cpp
@@ -0,0 +1,67 @@
+// RUN: %clang_cc1 %s -verify -fsyntax-only
+
+// expected-no-diagnostics
+
+class C_in_class {
+#include "../Sema/attr-callback.c"
+};
+
+struct Base {
+
+  void no_args_1(void (*callback)(void));
+  __attribute__((callback(1))) void no_args_2(void (*callback)(void));
+  __attribute__((callback(1))) void no_args_3(void (*callback)(void)) {}
+
+  __attribute__((callback(1, 0))) virtual void
+  this_tr(void (*callback)(Base *));
+
+  __attribute__((callback(1, 0, -1, 0))) virtual void
+  this_unknown_this(void (*callback)(Base *, Base *, Base *));
+
+  __attribute__((callback(1))) virtual void
+  virtual_1(void (*callback)(void));
+
+  __attribute__((callback(1))) virtual void
+  virtual_2(void (*callback)(void));
+
+  __attribute__((callback(1))) virtual void
+  virtual_3(void (*callback)(void));
+};
+
+__attribute__((callback(1))) void
+Base::no_args_1(void (*callback)(void)) {
+}
+
+void Base::no_args_2(void (*callback)(void)) {
+}
+
+struct Derived_1 : public Base {
+
+  __attribute__((callback(1, 0))) virtual void
+  this_tr(void (*callback)(Base *)) override;
+
+  __attribute__((callback(1))) virtual void
+  virtual_1(void (*callback)(void)) override {}
+
+  virtual void
+  virtual_3(void (*callback)(void)) override {}
+};
+
+struct Derived_2 : public Base {
+
+  __attribute__((callback(1))) virtual void
+  virtual_1(void (*callback)(void)) override;
+
+  virtual void
+  virtual_2(void (*callback)(void)) override;
+
+  virtual void
+  virtual_3(void (*callback)(void)) override;
+};
+
+void Derived_2::virtual_1(void (*callback)(void)) {}
+
+__attribute__((callback(1))) void
+Derived_2::virtual_2(void (*callback)(void)) {}
+
+void Derived_2::virtual_3(void (*callback)(void)) {}
Index: test/SemaCXX/attr-callback-broken.cpp
===
--- /dev/null
+++ test/SemaCXX/attr-callback-broken.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 %s -verify -fsyntax-only
+
+class C_in_class {
+#define HAS_THIS
+#include "../Sema/attr-callback-broken.c"
+#undef HAS_THIS
+};
Index: test/Sema/attr-callback.c
===
--- /dev/null
+++ test/Sema/attr-callback.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -verify -fsyntax-only
+
+// expected-no-diagnostics
+
+__attribute__((callback(1))) void no_args(void (*callback)(void));
+__attribute__((callback(1, 2, 3)))   void args_1(void (*callback)(int, double), int a, double b);
+__attribute__((callback(2, 3, 3)))   void args_2(int a, void (*callback)(double, double), double b);
+__attribute__((callback(2, -1, -1))) void args_3(int a, void (*callback)(double, double), double b);
Index: test/Sema/attr-callback-broken.c
===
--- /dev/null
+++ test/Sema/attr-callback-broken.c
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 %s -verify -fsyntax-only
+
+__attribute__((callback())) void no_callee(void (*callback)(void)); // expected-error {{'callback' attribute takes at least 1 argument}}
+
+__attribute__((callback(1, 1)))void too_many_args_1

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

2019-01-08 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits
gtbercea updated this revision to Diff 180711.
gtbercea added a comment.

Fix update.


Repository:
  rC Clang

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

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,8 +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-NEXT: [[J_2:%.+]] = mul nsw i64 [[J_1]], 2
+// CHECK: [[IV2_1:%.+]] = load i64, i64* [[T1_OMP_IV]]{{.*}}!llvm.mem.parallel_loop_access ![[T1_ID]]
+// CHECK-NEXT: [[I_1_DIV1:%.+]] = sdiv i64 [[IV2_1]], 4
+// CHECK-NEXT: [[I_1_MUL1:%.+]] = mul nsw i64 [[I_1_DIV1]], 4
+// CHECK-NEXT: [[I_1_SUB0:%.+]] = sub nsw i64 [[IV2]], [[I_1_MUL1]]
+// CHECK-NEXT: [[J_2:%.+]] = mul nsw i64 [[I_1_SUB0]], 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]]
 // simd.for.inc:
@@ -393,22 +396,70 @@
 // 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: [[SUB_3:%.+]] = sub i32 [[IV1_2]], [[MUL_1]]
+// 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:%.+]] = sub i32 [[IV1_3]], [[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: [[SUB_6:%.+]] = sub i32 [[IV1_4]], [[MUL_3]]
+// CHECK-NEXT: [[DIV_3:%.+]] = udiv i32 [[SUB_6]], 20
+// CHECK-NEXT: [[MUL_4:%.+]] = mul i32 [[DIV_3]], 20
+// CHECK-NEXT: [[ADD_5:%.+]] = sub i32 [[ADD_3]], [[MUL_4]]
+// CHECK-NEXT: [[DIV_4:%.+]] = udiv i32 [[ADD_5]], 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: [[SUB_7:%.+]] = sub i32 [[IV1_5]], [[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
+// CHECK-NEXT: [[SUB_10:%.+]] = sub i32 [[IV1_6]], [[MUL_7]]
+// CHECK-NEXT: [[DIV_7:%.+]] = udiv i32 [[SUB_10]], 20
+// CHECK-NEXT: [[MUL_8:%.+]] = mul i32 [[DIV_7]], 20
+// CHECK-NEXT: [[SUB_11:%.+]] = sub i32 [[SUB_7]], [[MUL_8]]
+
+// CHECK: [[IV1_7:%.+]] = load i32, i32* [[OMP_IV]]
+// CHECK: [[IV1_

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

2019-01-08 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:5523
   SourceLocation UpdLoc = IS.IncSrcRange.getBegin();
-  // Build: Iter = (IV / Div) % IS.NumIters
-  // where Div is product of previous iterations' IS.NumIters.
-  ExprResult Iter;
-  if (Div.isUsable()) {
-Iter =
-SemaRef.BuildBinOp(CurScope, UpdLoc, BO_Div, IV.get(), Div.get());
-  } else {
-Iter = IV;
-assert((Cnt == (int)NestedLoopCount - 1) &&
-   "unusable div expected on first iteration only");
-  }
-
-  if (Cnt != 0 && Iter.isUsable())
-Iter = SemaRef.BuildBinOp(CurScope, UpdLoc, BO_Rem, Iter.get(),
-  IS.NumIterations);
+  ExprResult Iter = IV;
+

Do you need to initialize `Iter` here?


Repository:
  rC Clang

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

https://reviews.llvm.org/D56413



___
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-08 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits
gtbercea updated this revision to Diff 180713.
gtbercea added a comment.

Remove redundant initalization.


Repository:
  rC Clang

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

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,8 +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-NEXT: [[J_2:%.+]] = mul nsw i64 [[J_1]], 2
+// CHECK: [[IV2_1:%.+]] = load i64, i64* [[T1_OMP_IV]]{{.*}}!llvm.mem.parallel_loop_access ![[T1_ID]]
+// CHECK-NEXT: [[I_1_DIV1:%.+]] = sdiv i64 [[IV2_1]], 4
+// CHECK-NEXT: [[I_1_MUL1:%.+]] = mul nsw i64 [[I_1_DIV1]], 4
+// CHECK-NEXT: [[I_1_SUB0:%.+]] = sub nsw i64 [[IV2]], [[I_1_MUL1]]
+// CHECK-NEXT: [[J_2:%.+]] = mul nsw i64 [[I_1_SUB0]], 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]]
 // simd.for.inc:
@@ -393,22 +396,70 @@
 // 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: [[SUB_3:%.+]] = sub i32 [[IV1_2]], [[MUL_1]]
+// 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:%.+]] = sub i32 [[IV1_3]], [[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: [[SUB_6:%.+]] = sub i32 [[IV1_4]], [[MUL_3]]
+// CHECK-NEXT: [[DIV_3:%.+]] = udiv i32 [[SUB_6]], 20
+// CHECK-NEXT: [[MUL_4:%.+]] = mul i32 [[DIV_3]], 20
+// CHECK-NEXT: [[ADD_5:%.+]] = sub i32 [[ADD_3]], [[MUL_4]]
+// CHECK-NEXT: [[DIV_4:%.+]] = udiv i32 [[ADD_5]], 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: [[SUB_7:%.+]] = sub i32 [[IV1_5]], [[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
+// CHECK-NEXT: [[SUB_10:%.+]] = sub i32 [[IV1_6]], [[MUL_7]]
+// CHECK-NEXT: [[DIV_7:%.+]] = udiv i32 [[SUB_10]], 20
+// CHECK-NEXT: [[MUL_8:%.+]] = mul i32 [[DIV_7]], 20
+// CHECK-NEXT: [[SUB_11:%.+]] = sub i32 [[SUB_7]], [[MUL_8]]
+
+// CHECK: [[IV1_7:%.+]] = load i32, i32* [[OMP_IV

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

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

LG


Repository:
  rC Clang

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

https://reviews.llvm.org/D56413



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


  1   2   >