[PATCH] D60539: Add -std=c++14 language standard option to tests that require C++14 default

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D60539#1464097 , @sammccall wrote:

> Adding `-std=c++14` doesn't work in general as it has side-effects: `clang 
> -std=c++14 foo.c` is a warning, `clang -std=c++14 -x c-header foo.h` is an 
> error. It would be nice if clang had a flag to specify the default c++ 
> language version without also forcing the file to be parsed as C++, but AFAIK 
> it does not.


Hmm. We have `-std-default`, but apparently it only works in C. :( Shouldn't be 
too hard to fix that.


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

https://reviews.llvm.org/D60539



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

r358326 - [verify] Add support for location markers in directives.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Fri Apr 12 21:33:39 2019
New Revision: 358326

URL: http://llvm.org/viewvc/llvm-project?rev=358326=rev
Log:
[verify] Add support for location markers in directives.

A marker (matching /#[A-Za-z0-9_-]/) is specified by attaching a comment
containing the marker to the line at which the diagnostic is expected,
and then can be referenced from an expected-* directive after an @:

  foo // #1
  // expected-error@#1 {{undeclared identifier 'foo'}}

The intent is for markers to be used in situations where relative line
numbers are currently used, to avoid the need to renumber when the test
case is rearranged.

Added:
cfe/trunk/test/Frontend/verify-marker.c
cfe/trunk/test/Frontend/verify-marker.h
Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/include/clang/Frontend/VerifyDiagnosticConsumer.h
cfe/trunk/lib/Frontend/VerifyDiagnosticConsumer.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=358326=358325=358326=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Fri Apr 12 
21:33:39 2019
@@ -121,6 +121,12 @@ def err_verify_missing_file : Error<
 "file '%0' could not be located in expected %1">;
 def err_verify_invalid_range : Error<
 "invalid range following '-' in expected %0">;
+def err_verify_ambiguous_marker : Error<
+"reference to marker '%0' is ambiguous">;
+def note_verify_ambiguous_marker : Note<
+"ambiguous marker '%0' is defined here">;
+def err_verify_no_such_marker : Error<
+"use of undefined marker '%0'">;
 def err_verify_missing_start : Error<
 "cannot find start ('{{') of expected %0">;
 def err_verify_missing_end : Error<

Modified: cfe/trunk/include/clang/Frontend/VerifyDiagnosticConsumer.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/VerifyDiagnosticConsumer.h?rev=358326=358325=358326=diff
==
--- cfe/trunk/include/clang/Frontend/VerifyDiagnosticConsumer.h (original)
+++ cfe/trunk/include/clang/Frontend/VerifyDiagnosticConsumer.h Fri Apr 12 
21:33:39 2019
@@ -81,6 +81,19 @@ class TextDiagnosticBuffer;
 /// the included file is, for example, a system header where the actual line
 /// number may change and is not critical).
 ///
+/// As an alternative to specifying a fixed line number, the location of a
+/// diagnostic can instead be indicated by a marker of the form "#".
+/// Markers are specified by including them in a comment, and then referenced
+/// by appending the marker to the diagnostic with "@#":
+///
+/// \code
+///   #warning some text  // #1
+///   // expected-warning@#1 {{some text}}
+/// \endcode
+///
+/// The name of a marker used in a directive must be unique within the
+/// compilation.
+///
 /// The simple syntax above allows each specification to match exactly one
 /// error.  You can use the extended syntax to customize this. The extended
 /// syntax is "expected-  {{diag text}}", where \ is one of
@@ -212,11 +225,14 @@ public:
 HasOtherExpectedDirectives
   };
 
+  class MarkerTracker;
+
 private:
   DiagnosticsEngine 
   DiagnosticConsumer *PrimaryClient;
   std::unique_ptr PrimaryClientOwner;
   std::unique_ptr Buffer;
+  std::unique_ptr Markers;
   const Preprocessor *CurrentPreprocessor = nullptr;
   const LangOptions *LangOpts = nullptr;
   SourceManager *SrcManager = nullptr;

Modified: cfe/trunk/lib/Frontend/VerifyDiagnosticConsumer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/VerifyDiagnosticConsumer.cpp?rev=358326=358325=358326=diff
==
--- cfe/trunk/lib/Frontend/VerifyDiagnosticConsumer.cpp (original)
+++ cfe/trunk/lib/Frontend/VerifyDiagnosticConsumer.cpp Fri Apr 12 21:33:39 2019
@@ -50,23 +50,6 @@ using Directive = VerifyDiagnosticConsum
 using DirectiveList = VerifyDiagnosticConsumer::DirectiveList;
 using ExpectedData = VerifyDiagnosticConsumer::ExpectedData;
 
-VerifyDiagnosticConsumer::VerifyDiagnosticConsumer(DiagnosticsEngine _)
-: Diags(Diags_), PrimaryClient(Diags.getClient()),
-  PrimaryClientOwner(Diags.takeClient()),
-  Buffer(new TextDiagnosticBuffer()), Status(HasNoDirectives) {
-  if (Diags.hasSourceManager())
-setSourceManager(Diags.getSourceManager());
-}
-
-VerifyDiagnosticConsumer::~VerifyDiagnosticConsumer() {
-  assert(!ActiveSourceFiles && "Incomplete parsing of source files!");
-  assert(!CurrentPreprocessor && "CurrentPreprocessor should be invalid!");
-  SrcManager = nullptr;
-  CheckDiagnostics();
-  assert(!Diags.ownsClient() &&
- "The VerifyDiagnosticConsumer takes over ownership of the client!");
-}
-
 #ifndef NDEBUG
 
 namespace {
@@ 

[PATCH] D59806: [clang-tidy] Add a check for [super self] in initializers 

[Stephane Moore via Phabricator via cfe-commits]

stephanemoore updated this revision to Diff 194998.
stephanemoore added a comment.

Fix some formatting issues.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59806

Files:
  clang-tools-extra/clang-tidy/objc/CMakeLists.txt
  clang-tools-extra/clang-tidy/objc/ObjCTidyModule.cpp
  clang-tools-extra/clang-tidy/objc/SuperSelfCheck.cpp
  clang-tools-extra/clang-tidy/objc/SuperSelfCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
  clang-tools-extra/test/clang-tidy/objc-super-self.m

Index: clang-tools-extra/test/clang-tidy/objc-super-self.m
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/objc-super-self.m
@@ -0,0 +1,86 @@
+// RUN: %check_clang_tidy %s objc-super-self %t
+
+@interface NSObject
+- (instancetype)init;
+- (instancetype)self;
+@end
+
+@interface NSObjectDerivedClass : NSObject
+@end
+
+@implementation NSObjectDerivedClass
+
+- (instancetype)init {
+  return [super self];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return [super init];
+}
+
+- (instancetype)initWithObject:(NSObject *)obj {
+  self = [super self];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: self = [super init];
+  if (self) {
+// ...
+  }
+  return self;
+}
+
+#define INITIALIZE() [super self]
+
+- (instancetype)initWithObject:(NSObject *)objc a:(int)a {
+  return INITIALIZE();
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return INITIALIZE();
+}
+
+#define INITIALIZER_IMPL() return [super self]
+
+- (instancetype)initWithObject:(NSObject *)objc b:(int)b {
+  INITIALIZER_IMPL();
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: INITIALIZER_IMPL();
+}
+
+#define INITIALIZER_METHOD self
+
+- (instancetype)initWithObject:(NSObject *)objc c:(int)c {
+  return [super INITIALIZER_METHOD];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return [super INITIALIZER_METHOD];
+}
+
+#define RECEIVER super
+
+- (instancetype)initWithObject:(NSObject *)objc d:(int)d {
+  return [RECEIVER self];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return [RECEIVER self];
+}
+
+- (instancetype)foo {
+  return [super self];
+}
+
+- (instancetype)bar {
+  return [self self];
+}
+
+@end
+
+@interface RootClass
+- (instancetype)init;
+- (instancetype)self;
+@end
+
+@interface NotNSObjectDerivedClass : RootClass
+@end
+
+@implementation NotNSObjectDerivedClass
+
+- (instancetype)init {
+  return [super self];
+}
+
+@end
+
Index: clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
@@ -0,0 +1,13 @@
+.. title:: clang-tidy - objc-super-self
+
+objc-super-self
+===
+
+Finds invocations of ``-self`` on super instances in initializers of subclasses
+of ``NSObject`` and recommends calling a superclass initializer instead.
+
+Invoking ``-self`` on super instances in initializers is a common programmer
+error when the programmer's original intent is to call a superclass
+initializer. Failing to call a superclass initializer breaks initializer
+chaining and can result in invalid object initialization.
+
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -227,6 +227,7 @@
objc-avoid-spinlock
objc-forbidden-subclassing
objc-property-declaration
+   objc-super-self
openmp-exception-escape
openmp-use-default-none
performance-faster-string-find
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -108,6 +108,12 @@
   Checks whether there are underscores in googletest test and test case names in
   test macros, which is prohibited by the Googletest FAQ.
 
+- New :doc:`objc-super-self ` check.
+
+  Finds 

[PATCH] D59806: [clang-tidy] Add a check for [super self] in initializers 

[Stephane Moore via Phabricator via cfe-commits]

stephanemoore updated this revision to Diff 194997.
stephanemoore marked 4 inline comments as done.
stephanemoore added a comment.

Check if either the receiver or selector are in macro locations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59806

Files:
  clang-tools-extra/clang-tidy/objc/CMakeLists.txt
  clang-tools-extra/clang-tidy/objc/ObjCTidyModule.cpp
  clang-tools-extra/clang-tidy/objc/SuperSelfCheck.cpp
  clang-tools-extra/clang-tidy/objc/SuperSelfCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
  clang-tools-extra/test/clang-tidy/objc-super-self.m

Index: clang-tools-extra/test/clang-tidy/objc-super-self.m
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/objc-super-self.m
@@ -0,0 +1,87 @@
+// RUN: %check_clang_tidy %s objc-super-self %t
+
+@interface NSObject
+- (instancetype)init;
+- (instancetype)self;
+@end
+
+@interface NSObjectDerivedClass : NSObject
+@end
+
+@implementation NSObjectDerivedClass
+
+- (instancetype)init {
+  return [super self];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return [super init];
+}
+
+- (instancetype)initWithObject:(NSObject *)obj {
+  self = [super self];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: self = [super init];
+  if (self) {
+// ...
+  }
+  return self;
+}
+
+#define INITIALIZE() [super self]
+
+- (instancetype)initWithObject:(NSObject *)objc a:(int)a {
+  return INITIALIZE();
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return INITIALIZE();
+}
+
+#define INITIALIZER_IMPL() return [super self]
+
+- (instancetype)initWithObject:(NSObject *)objc b:(int)b {
+  INITIALIZER_IMPL();
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: INITIALIZER_IMPL();
+}
+
+#define INITIALIZER_METHOD self
+
+- (instancetype)initWithObject:(NSObject *)objc c:(int)c {
+  return [super INITIALIZER_METHOD];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return [super INITIALIZER_METHOD];
+}
+
+
+#define RECEIVER super
+
+- (instancetype)initWithObject:(NSObject *)objc d:(int)d {
+  return [RECEIVER self];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return [RECEIVER self];
+}
+
+- (instancetype)foo {
+  return [super self];
+}
+
+- (instancetype)bar {
+  return [self self];
+}
+
+@end
+
+@interface RootClass
+- (instancetype)init;
+- (instancetype)self;
+@end
+
+@interface NotNSObjectDerivedClass : RootClass
+@end
+
+@implementation NotNSObjectDerivedClass
+
+- (instancetype)init {
+  return [super self];
+}
+
+@end
+
Index: clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
@@ -0,0 +1,13 @@
+.. title:: clang-tidy - objc-super-self
+
+objc-super-self
+===
+
+Finds invocations of ``-self`` on super instances in initializers of subclasses
+of ``NSObject`` and recommends calling a superclass initializer instead.
+
+Invoking ``-self`` on super instances in initializers is a common programmer
+error when the programmer's original intent is to call a superclass
+initializer. Failing to call a superclass initializer breaks initializer
+chaining and can result in invalid object initialization.
+
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -227,6 +227,7 @@
objc-avoid-spinlock
objc-forbidden-subclassing
objc-property-declaration
+   objc-super-self
openmp-exception-escape
openmp-use-default-none
performance-faster-string-find
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -108,6 +108,12 @@
   Checks whether there are underscores in googletest test and test case names in
   test macros, which is 

[PATCH] D59806: [clang-tidy] Add a check for [super self] in initializers 

[Stephane Moore via Phabricator via cfe-commits]

stephanemoore updated this revision to Diff 194996.
stephanemoore marked 3 inline comments as done.
stephanemoore added a comment.

Add `CHECK-FIXES` to verify code is preserved for scenarios that should not 
have fixes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59806

Files:
  clang-tools-extra/clang-tidy/objc/CMakeLists.txt
  clang-tools-extra/clang-tidy/objc/ObjCTidyModule.cpp
  clang-tools-extra/clang-tidy/objc/SuperSelfCheck.cpp
  clang-tools-extra/clang-tidy/objc/SuperSelfCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
  clang-tools-extra/test/clang-tidy/objc-super-self.m

Index: clang-tools-extra/test/clang-tidy/objc-super-self.m
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/objc-super-self.m
@@ -0,0 +1,78 @@
+// RUN: %check_clang_tidy %s objc-super-self %t
+
+@interface NSObject
+- (instancetype)init;
+- (instancetype)self;
+@end
+
+@interface NSObjectDerivedClass : NSObject
+@end
+
+@implementation NSObjectDerivedClass
+
+- (instancetype)init {
+  return [super self];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return [super init];
+}
+
+- (instancetype)initWithObject:(NSObject *)obj {
+  self = [super self];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: self = [super init];
+  if (self) {
+// ...
+  }
+  return self;
+}
+
+#define INITIALIZE() [super self]
+
+- (instancetype)initWithObject:(NSObject *)objc a:(int)a {
+  return INITIALIZE();
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return INITIALIZE();
+}
+
+#define INITIALIZER_IMPL() return [super self]
+
+- (instancetype)initWithObject:(NSObject *)objc b:(int)b {
+  INITIALIZER_IMPL();
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: INITIALIZER_IMPL();
+}
+
+#define INITIALIZER_METHOD self
+
+- (instancetype)initWithObject:(NSObject *)objc c:(int)c {
+  return [super INITIALIZER_METHOD];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return [super init];
+}
+
+- (instancetype)foo {
+  return [super self];
+}
+
+- (instancetype)bar {
+  return [self self];
+}
+
+@end
+
+@interface RootClass
+- (instancetype)init;
+- (instancetype)self;
+@end
+
+@interface NotNSObjectDerivedClass : RootClass
+@end
+
+@implementation NotNSObjectDerivedClass
+
+- (instancetype)init {
+  return [super self];
+}
+
+@end
+
Index: clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
@@ -0,0 +1,13 @@
+.. title:: clang-tidy - objc-super-self
+
+objc-super-self
+===
+
+Finds invocations of ``-self`` on super instances in initializers of subclasses
+of ``NSObject`` and recommends calling a superclass initializer instead.
+
+Invoking ``-self`` on super instances in initializers is a common programmer
+error when the programmer's original intent is to call a superclass
+initializer. Failing to call a superclass initializer breaks initializer
+chaining and can result in invalid object initialization.
+
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -227,6 +227,7 @@
objc-avoid-spinlock
objc-forbidden-subclassing
objc-property-declaration
+   objc-super-self
openmp-exception-escape
openmp-use-default-none
performance-faster-string-find
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -108,6 +108,12 @@
   Checks whether there are underscores in googletest test and test case names in
   test macros, which is prohibited by the Googletest FAQ.
 
+- New :doc:`objc-super-self ` check.
+
+  Finds invocations of ``-self`` on super instances in initializers of
+  subclasses of ``NSObject`` and recommends calling a superclass initializer
+  instead.
+
 - New alias :doc:`cppcoreguidelines-explicit-virtual-functions
   ` to
   

[PATCH] D59806: [clang-tidy] Add a check for [super self] in initializers 

[Stephane Moore via Phabricator via cfe-commits]

stephanemoore updated this revision to Diff 194995.
stephanemoore added a comment.

Update check to avoid emitting a fix if the expression is in a macro.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59806

Files:
  clang-tools-extra/clang-tidy/objc/CMakeLists.txt
  clang-tools-extra/clang-tidy/objc/ObjCTidyModule.cpp
  clang-tools-extra/clang-tidy/objc/SuperSelfCheck.cpp
  clang-tools-extra/clang-tidy/objc/SuperSelfCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
  clang-tools-extra/test/clang-tidy/objc-super-self.m

Index: clang-tools-extra/test/clang-tidy/objc-super-self.m
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/objc-super-self.m
@@ -0,0 +1,76 @@
+// RUN: %check_clang_tidy %s objc-super-self %t
+
+@interface NSObject
+- (instancetype)init;
+- (instancetype)self;
+@end
+
+@interface NSObjectDerivedClass : NSObject
+@end
+
+@implementation NSObjectDerivedClass
+
+- (instancetype)init {
+  return [super self];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return [super init];
+}
+
+- (instancetype)initWithObject:(NSObject *)obj {
+  self = [super self];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: self = [super init];
+  if (self) {
+// ...
+  }
+  return self;
+}
+
+#define INITIALIZE() [super self]
+
+- (instancetype)initWithObject:(NSObject *)objc a:(int)a {
+  return INITIALIZE();
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+}
+
+#define INITIALIZER_IMPL() return [super self]
+
+- (instancetype)initWithObject:(NSObject *)objc b:(int)b {
+  INITIALIZER_IMPL();
+// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+}
+
+#define INITIALIZER_METHOD self
+
+- (instancetype)initWithObject:(NSObject *)objc c:(int)c {
+  return [super INITIALIZER_METHOD];
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: suspicious invocation of 'self' in initializer; did you mean to invoke a superclass initializer? [objc-super-self]
+// CHECK-FIXES: return [super init];
+}
+
+- (instancetype)foo {
+  return [super self];
+}
+
+- (instancetype)bar {
+  return [self self];
+}
+
+@end
+
+@interface RootClass
+- (instancetype)init;
+- (instancetype)self;
+@end
+
+@interface NotNSObjectDerivedClass : RootClass
+@end
+
+@implementation NotNSObjectDerivedClass
+
+- (instancetype)init {
+  return [super self];
+}
+
+@end
+
Index: clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/objc-super-self.rst
@@ -0,0 +1,13 @@
+.. title:: clang-tidy - objc-super-self
+
+objc-super-self
+===
+
+Finds invocations of ``-self`` on super instances in initializers of subclasses
+of ``NSObject`` and recommends calling a superclass initializer instead.
+
+Invoking ``-self`` on super instances in initializers is a common programmer
+error when the programmer's original intent is to call a superclass
+initializer. Failing to call a superclass initializer breaks initializer
+chaining and can result in invalid object initialization.
+
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -227,6 +227,7 @@
objc-avoid-spinlock
objc-forbidden-subclassing
objc-property-declaration
+   objc-super-self
openmp-exception-escape
openmp-use-default-none
performance-faster-string-find
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -108,6 +108,12 @@
   Checks whether there are underscores in googletest test and test case names in
   test macros, which is prohibited by the Googletest FAQ.
 
+- New :doc:`objc-super-self ` check.
+
+  Finds invocations of ``-self`` on super instances in initializers of
+  subclasses of ``NSObject`` and recommends calling a superclass initializer
+  instead.
+
 - New alias :doc:`cppcoreguidelines-explicit-virtual-functions
   ` to
   :doc:`modernize-use-override
Index: clang-tools-extra/clang-tidy/objc/SuperSelfCheck.h

[PATCH] D60629: [clang-tidy] Change the namespace for llvm checkers from 'llvm' to 'llvm_checker'

[Don Hinton via Phabricator via cfe-commits]

hintonda added a comment.

In D60629#1464945 , @Eugene.Zelenko 
wrote:

> Please use check for consistency with rest of Clang-tidy.


Thanks for taking a look — I’ll Fix that on the next upload.  So are you okay 
with llvm_check?  I sorta like it, but happy to use anything other than llvm, 
which caused the initial problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60629



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

[PATCH] D60112: [analyzer] Treat write into a top-level parameter variable with destructor as escape.

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC358321: [analyzer] Escape pointers stored into top-level 
parameters with destructors. (authored by dergachev, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D60112?vs=193229=194993#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D60112

Files:
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  test/Analysis/malloc.cpp

Index: test/Analysis/malloc.cpp
===
--- test/Analysis/malloc.cpp
+++ test/Analysis/malloc.cpp
@@ -141,3 +141,26 @@
   }
   return funcname; // no-warning
 }
+
+namespace argument_leak {
+class A {
+  char *name;
+
+public:
+  char *getName() {
+if (!name) {
+  name = static_cast(malloc(10));
+}
+return name;
+  }
+  ~A() {
+if (name) {
+  delete[] name;
+}
+  }
+};
+
+void test(A a) {
+  (void)a.getName();
+}
+} // namespace argument_leak
Index: lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -2621,43 +2621,39 @@
   getCheckerManager().runCheckersForPostStmt(Dst, AfterInvalidateSet, AE, *this);
 }
 
-// A value escapes in three possible cases:
+// A value escapes in four possible cases:
 // (1) We are binding to something that is not a memory region.
-// (2) We are binding to a MemrRegion that does not have stack storage.
-// (3) We are binding to a MemRegion with stack storage that the store
+// (2) We are binding to a MemRegion that does not have stack storage.
+// (3) We are binding to a top-level parameter region with a non-trivial
+// destructor. We won't see the destructor during analysis, but it's there.
+// (4) We are binding to a MemRegion with stack storage that the store
 // does not understand.
-ProgramStateRef ExprEngine::processPointerEscapedOnBind(ProgramStateRef State,
-SVal Loc,
-SVal Val,
-const LocationContext *LCtx) {
-  // Are we storing to something that causes the value to "escape"?
-  bool escapes = true;
-
-  // TODO: Move to StoreManager.
-  if (Optional regionLoc = Loc.getAs()) {
-escapes = !regionLoc->getRegion()->hasStackStorage();
-
-if (!escapes) {
-  // To test (3), generate a new state with the binding added.  If it is
-  // the same state, then it escapes (since the store cannot represent
-  // the binding).
-  // Do this only if we know that the store is not supposed to generate the
-  // same state.
-  SVal StoredVal = State->getSVal(regionLoc->getRegion());
-  if (StoredVal != Val)
-escapes = (State == (State->bindLoc(*regionLoc, Val, LCtx)));
-}
-  }
+ProgramStateRef
+ExprEngine::processPointerEscapedOnBind(ProgramStateRef State, SVal Loc,
+SVal Val, const LocationContext *LCtx) {
 
-  // If our store can represent the binding and we aren't storing to something
-  // that doesn't have local storage then just return and have the simulation
-  // state continue as is.
-  if (!escapes)
-return State;
+  // Cases (1) and (2).
+  const MemRegion *MR = Loc.getAsRegion();
+  if (!MR || !MR->hasStackStorage())
+return escapeValue(State, Val, PSK_EscapeOnBind);
+
+  // Case (3).
+  if (const auto *VR = dyn_cast(MR->getBaseRegion()))
+if (VR->hasStackParametersStorage() && VR->getStackFrame()->inTopFrame())
+  if (const auto *RD = VR->getValueType()->getAsCXXRecordDecl())
+if (!RD->hasTrivialDestructor())
+  return escapeValue(State, Val, PSK_EscapeOnBind);
+
+  // Case (4): in order to test that, generate a new state with the binding
+  // added. If it is the same state, then it escapes (since the store cannot
+  // represent the binding).
+  // Do this only if we know that the store is not supposed to generate the
+  // same state.
+  SVal StoredVal = State->getSVal(MR);
+  if (StoredVal != Val)
+if (State == (State->bindLoc(loc::MemRegionVal(MR), Val, LCtx)))
+  return escapeValue(State, Val, PSK_EscapeOnBind);
 
-  // Otherwise, find all symbols referenced by 'val' that we are tracking
-  // and stop tracking them.
-  State = escapeValue(State, Val, PSK_EscapeOnBind);
   return State;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r358321 - [analyzer] Escape pointers stored into top-level parameters with destructors.

[Artem Dergachev via cfe-commits]

Author: dergachev
Date: Fri Apr 12 19:01:45 2019
New Revision: 358321

URL: http://llvm.org/viewvc/llvm-project?rev=358321=rev
Log:
[analyzer] Escape pointers stored into top-level parameters with destructors.

Writing stuff into an argument variable is usually equivalent to writing stuff
to a local variable: it will have no effect outside of the function.
There's an important exception from this rule: if the argument variable has
a non-trivial destructor, the destructor would be invoked on
the parent stack frame, exposing contents of the otherwise dead
argument variable to the caller.

If such argument is the last place where a pointer is stored before the function
exits and the function is the one we've started our analysis from (i.e., we have
no caller context for it), we currently diagnose a leak. This is incorrect
because the destructor of the argument still has access to the pointer.
The destructor may deallocate the pointer or even pass it further.

Treat writes into such argument regions as "escapes" instead, suppressing
spurious memory leak reports but not messing with dead symbol removal.

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

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
cfe/trunk/test/Analysis/malloc.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp?rev=358321=358320=358321=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp Fri Apr 12 19:01:45 2019
@@ -2621,43 +2621,39 @@ void ExprEngine::VisitAtomicExpr(const A
   getCheckerManager().runCheckersForPostStmt(Dst, AfterInvalidateSet, AE, 
*this);
 }
 
-// A value escapes in three possible cases:
+// A value escapes in four possible cases:
 // (1) We are binding to something that is not a memory region.
-// (2) We are binding to a MemrRegion that does not have stack storage.
-// (3) We are binding to a MemRegion with stack storage that the store
+// (2) We are binding to a MemRegion that does not have stack storage.
+// (3) We are binding to a top-level parameter region with a non-trivial
+// destructor. We won't see the destructor during analysis, but it's there.
+// (4) We are binding to a MemRegion with stack storage that the store
 // does not understand.
-ProgramStateRef ExprEngine::processPointerEscapedOnBind(ProgramStateRef State,
-SVal Loc,
-SVal Val,
-const LocationContext 
*LCtx) {
-  // Are we storing to something that causes the value to "escape"?
-  bool escapes = true;
-
-  // TODO: Move to StoreManager.
-  if (Optional regionLoc = Loc.getAs()) {
-escapes = !regionLoc->getRegion()->hasStackStorage();
-
-if (!escapes) {
-  // To test (3), generate a new state with the binding added.  If it is
-  // the same state, then it escapes (since the store cannot represent
-  // the binding).
-  // Do this only if we know that the store is not supposed to generate the
-  // same state.
-  SVal StoredVal = State->getSVal(regionLoc->getRegion());
-  if (StoredVal != Val)
-escapes = (State == (State->bindLoc(*regionLoc, Val, LCtx)));
-}
-  }
-
-  // If our store can represent the binding and we aren't storing to something
-  // that doesn't have local storage then just return and have the simulation
-  // state continue as is.
-  if (!escapes)
-return State;
-
-  // Otherwise, find all symbols referenced by 'val' that we are tracking
-  // and stop tracking them.
-  State = escapeValue(State, Val, PSK_EscapeOnBind);
+ProgramStateRef
+ExprEngine::processPointerEscapedOnBind(ProgramStateRef State, SVal Loc,
+SVal Val, const LocationContext *LCtx) 
{
+
+  // Cases (1) and (2).
+  const MemRegion *MR = Loc.getAsRegion();
+  if (!MR || !MR->hasStackStorage())
+return escapeValue(State, Val, PSK_EscapeOnBind);
+
+  // Case (3).
+  if (const auto *VR = dyn_cast(MR->getBaseRegion()))
+if (VR->hasStackParametersStorage() && VR->getStackFrame()->inTopFrame())
+  if (const auto *RD = VR->getValueType()->getAsCXXRecordDecl())
+if (!RD->hasTrivialDestructor())
+  return escapeValue(State, Val, PSK_EscapeOnBind);
+
+  // Case (4): in order to test that, generate a new state with the binding
+  // added. If it is the same state, then it escapes (since the store cannot
+  // represent the binding).
+  // Do this only if we know that the store is not supposed to generate the
+  // same state.
+  SVal StoredVal = State->getSVal(MR);
+  if (StoredVal != Val)
+if (State == (State->bindLoc(loc::MemRegionVal(MR), Val, LCtx)))
+  return escapeValue(State, Val, PSK_EscapeOnBind);
+
  

[PATCH] D60281: [analyzer] Add docs for cplusplus.InnerPointer

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: docs/analyzer/checkers.rst:225-226
+``std::string``s, by recognizing member functions that may re/deallocate the 
buffer
+before use. In the future, it would be great to add support for other STL and
+non-STL containers, and most notably, ``std::string_view``s.
+

Szelethus wrote:
> dkrupp wrote:
> > Szelethus wrote:
> > > Hmm. While this page is a documentation, I would still expect regular 
> > > users to browse through it -- are we sure that we want to add future 
> > > plans for a non-alpha checker? I'm not against it, just a question.
> > I think it is a good idea. A non-alpha checker can also be further 
> > developed, by anyone else. It is good that we don't forget about further 
> > features. This note also highlights the limitations of the checker.
> How about this: "Future plans include to add support for blahblah". The 
> current statement should rather be a TODO in the code.
I suggest presenting it as "The checker is currently limited to `std::string`s 
and doesn't recognize some of the more sophisticated approaches to passing 
unowned pointers around, such as `std::string_view`s". It sounds a bit more 
negative than it deserves to sound, but that's the most documentation-like text 
i managed to come up with so far >.< Maybe put it under a "Known Limitations:" 
marker and/or expand the main part of the documentation in order to keep the 
reader's impression balanced, eg. "Many container methods in the C++ standard 
library are known to invalidate "references" (including actual references, 
iterators and raw pointers) to elements of the container. Using such references 
after they are invalidated causes undefined behavior, which is a common source 
of memory errors in C++ that this checker is capable of finding."

> While this page is a documentation, I would still expect regular users to 
> browse through it

I'd love our users to browse it! Maybe we should consider adding a 
documentation link to our HTML report headers as the documentation gets good 
enough.



Comment at: docs/analyzer/checkers.rst:232
+
+ void test_deref_after_equals() {
+   std::string s = "llvm";

The `test_` part doesn't add much here, maybe drop it?


Repository:
  rC Clang

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

https://reviews.llvm.org/D60281



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

Buildbot numbers for the last week of 03/31/2019 - 04/06/2019

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 03/31/2019 -
04/06/2019.

Please see the same data in attached csv files:

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

Thanks

Galina


The longest time each builder was red during the week:
  buildername  |  was_red
---+--
 llvm-sphinx-docs  | 129:04:24
 clang-cuda-build  | 82:28:23
 lldb-x64-windows-ninja| 58:48:32
 clang-cmake-aarch64-global-isel   | 20:02:29
 clang-cmake-aarch64-quick | 20:02:11
 sanitizer-x86_64-linux-autoconf   | 16:56:42
 sanitizer-x86_64-linux| 15:02:09
 clang-s390x-linux-multistage  | 13:14:51
 llvm-clang-x86_64-expensive-checks-win| 11:39:18
 clang-lld-x86_64-2stage   | 10:33:55
 clang-s390x-linux | 10:02:30
 clang-cmake-aarch64-lld   | 09:42:08
 clang-ppc64be-linux   | 09:32:54
 clang-ppc64be-linux-lnt   | 09:23:48
 clang-with-thin-lto-ubuntu| 06:41:32
 clang-cmake-aarch64-full  | 06:30:31
 clang-ppc64le-linux-multistage| 06:19:32
 clang-cmake-thumbv7-full-sh   | 06:17:19
 clang-ppc64be-linux-multistage| 04:49:37
 clang-x64-windows-msvc| 04:49:30
 ppc64le-lld-multistage-test   | 04:46:35
 polly-amd64-linux | 04:34:06
 sanitizer-ppc64le-linux   | 04:29:03
 clang-cmake-armv8-lld | 04:22:18
 clang-cmake-armv7-lnt | 04:07:45
 libcxx-libcxxabi-libunwind-armv8-linux-noexceptions   | 04:03:56
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 04:02:46
 clang-hexagon-elf | 03:42:54
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11| 03:09:13
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03| 03:06:10
 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc5-cxx11   | 03:05:32
 clang-with-lto-ubuntu | 03:00:43
 sanitizer-ppc64be-linux   | 02:58:50
 clang-ppc64le-linux-lnt   | 02:55:36
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14| 02:49:07
 clang-cmake-armv7-full| 02:43:52
 reverse-iteration | 02:40:36
 clang-ppc64le-linux   | 02:40:22
 sanitizer-x86_64-linux-bootstrap-ubsan| 02:38:45
 clang-cmake-armv8-lnt | 02:30:56
 sanitizer-x86_64-linux-fast   | 02:28:45
 clang-atom-d525-fedora-rel| 02:27:02
 sanitizer-x86_64-linux-fuzzer | 02:26:00
 llvm-hexagon-elf  | 02:19:35
 clang-cmake-armv7-global-isel | 02:16:54
 clang-cmake-armv8-full| 02:12:32
 clang-cmake-thumbv8-full-sh   | 02:06:43
 clang-s390x-linux-lnt | 02:06:36
 clang-cmake-armv8-global-isel | 01:36:36
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 01:19:59
 clang-cmake-x86_64-sde-avx512-linux   | 01:16:08
 clang-cmake-armv7-quick   | 01:02:21
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 00:55:19
 clang-cmake-x86_64-avx2-linux | 00:49:35
 clang-cmake-armv8-quick   | 00:45:24
 sanitizer-x86_64-linux-bootstrap-msan | 00:44:22
 sanitizer-x86_64-linux-android| 00:42:03
 polly-arm-linux   | 00:41:58
 lld-perf-testsuite| 00:40:01
 lld-x86_64-win7   | 00:37:53
 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan| 00:36:13
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17| 00:35:56
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 00:34:43
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan | 00:34:16
 

Buildbot numbers for the week of 03/24/2019 - 03/30/2019

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the week of 03/24/2019 - 03/30/2019.

Please see the same data in attached csv files:

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

Thanks

Galina


The longest time each builder was red during the week:
   buildername   | was_red
-+-
 clang-cmake-armv7-selfhost-neon | 46:03:00
 clang-cmake-armv7-selfhost  | 45:44:50
 clang-cmake-thumbv7-full-sh | 44:30:28
 clang-x64-windows-msvc  | 33:06:33
 lld-x86_64-win7 | 32:46:17
 clang-atom-d525-fedora-rel  | 30:25:20
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast| 27:15:57
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a  | 22:30:50
 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan   | 22:29:26
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17  | 22:28:08
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11  | 22:27:12
 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc5-cxx11 | 22:26:00
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan   | 22:24:55
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan   | 22:24:51
 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std | 22:20:38
 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu  | 22:20:23
 libcxx-libcxxabi-x86_64-linux-ubuntu-32bit  | 20:25:43
 clang-cmake-aarch64-lld | 20:23:45
 ppc64le-lld-multistage-test | 09:57:29
 clang-cmake-aarch64-full| 08:07:38
 llvm-clang-x86_64-expensive-checks-win  | 05:43:14
 clang-cmake-armv8-lld   | 05:25:11
 clang-s390x-linux   | 05:09:38
 lldb-x64-windows-ninja  | 04:55:50
 clang-lld-x86_64-2stage | 04:32:02
 clang-with-lto-ubuntu   | 04:18:31
 clang-s390x-linux-multistage| 04:07:46
 clang-ppc64le-linux-multistage  | 04:06:01
 clang-cmake-thumbv8-full-sh | 03:40:50
 sanitizer-ppc64le-linux | 03:37:52
 clang-s390x-linux-lnt   | 02:48:57
 clang-tools-sphinx-docs | 02:43:04
 clang-ppc64le-linux | 02:42:15
 sanitizer-x86_64-linux-bootstrap-ubsan  | 02:33:59
 clang-ppc64be-linux-multistage  | 02:24:30
 clang-cmake-armv7-full  | 02:21:35
 clang-cmake-aarch64-global-isel | 02:19:46
 clang-cmake-aarch64-quick   | 02:19:45
 clang-with-thin-lto-ubuntu  | 02:19:22
 clang-ppc64le-linux-lnt | 02:15:55
 clang-cmake-x86_64-avx2-linux-perf  | 02:08:03
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14  | 02:01:53
 libcxx-libcxxabi-libunwind-armv8-linux  | 02:01:40
 libcxx-libcxxabi-libunwind-armv8-linux-noexceptions | 02:00:47
 libcxx-libcxxabi-libunwind-armv7-linux-noexceptions | 02:00:18
 libcxx-libcxxabi-libunwind-aarch64-linux| 02:00:16
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions   | 02:00:14
 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan  | 01:58:53
 libcxx-libcxxabi-libunwind-armv7-linux  | 01:58:07
 sanitizer-ppc64be-linux | 01:56:18
 clang-ppc64be-linux-lnt | 01:49:07
 clang-cmake-armv8-lnt   | 01:46:05
 sanitizer-x86_64-linux-bootstrap-msan   | 01:40:59
 sanitizer-x86_64-linux-bootstrap| 01:32:33
 sanitizer-x86_64-linux  | 01:28:43
 clang-ppc64be-linux | 01:27:42
 sanitizer-x86_64-linux-fast | 01:25:41
 clang-cmake-x86_64-avx2-linux   | 01:19:14
 clang-cmake-x86_64-sde-avx512-linux | 01:16:47
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast  | 01:15:25
 sanitizer-x86_64-linux-autoconf | 01:07:05
 sanitizer-windows   | 01:06:42
 reverse-iteration  

[PATCH] D59555: [analyzer] Add yaml parser to GenericTaintChecker

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

This new approach is clearly useful to other checkers as well, not only the 
Taint checker. I believe we should strongly consider generalizing it somehow, 
it's just too awesome to restrict to a single checker.

There's also a closely related technology called "API Notes" that allows you to 
inject annotations into system headers by shipping .yaml files with the 
compiler. It was actively pushed for for the Analyzer in particular but ended 
up never getting upstreamed:

- http://lists.llvm.org/pipermail/cfe-dev/2015-December/046335.html
- http://lists.llvm.org/pipermail/cfe-dev/2017-May/053860.html

I suspect that it'll make perfect sense for your use case to define a clang 
attribute for taint sources and sinks and then define an API notes definition 
that'll inject this attribute into headers. If only API notes were available, 
this would have been a perfect use case for them. I think it might be a good 
idea to ping the mailing lists about API notes one more time, announce that you 
*are* going for a similar technology anyway, and see if anybody suggests 
something.

Pros/cons:

- The attributes/API notes solution is very comfy because it both allows users 
to address their false positives / false negatives by adding annotations in 
their source *and* allows us to annotate system headers via yaml files, and (if 
i understand correctly) both sorts of annotations are accessible uniformly via 
`Decl->getAttr<...>()`.
  - If we decide to go for our own yaml format that doesn't work on top of 
attributes, we'll either get only one of these, or double up our implementation 
burden in checkers.
- Implementation burden should not be that high, but it will be annoying.
  - If we don't want users to annotate their headers with source-level 
annotations, it sounds easier to go for a custom yaml parser, because defining 
attributes is annoying.
- But i believe we do want them to in this case.

Does any of this make any sense within the bigger plans that you have for this 
checker?


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

https://reviews.llvm.org/D59555



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

[PATCH] D55463: Introduce a source minimizer that reduces source to directives that might affect the dependency list for a compilation

[Michael Spencer via Phabricator via cfe-commits]

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

I have a bit more review to do, but this is what I've found so far.  The naming 
comments are just suggestions, but the digit separators' are actually an issue.




Comment at: include/clang/Lex/DependencyDirectivesSourceMinimizer.h:25
+namespace clang {
+namespace minimize_source_to_dependency_directives {
+

This is a really long namespace name, not sure what else to call it though.



Comment at: include/clang/Lex/DependencyDirectivesSourceMinimizer.h:36
+  pp_import,
+  pp_at_import,
+  pp_pragma_import,

Is `@import` actually a preprocessor directive? For C++20 modules all the 
modules bits end up being declarations.



Comment at: lib/Frontend/FrontendActions.cpp:923-924
+   Toks)) {
+CI.getDiagnostics().Report(
+diag::err_minimize_source_to_dependency_directives_failed);
+return;

Can we give better error messages here?  Should 
`minimizeSourceToDependencyDirectives` take a `DiagnosticEngine`?



Comment at: lib/Lex/DependencyDirectivesSourceMinimizer.cpp:28
+
+struct Lexer {
+  SmallVectorImpl 

I'm not sure `Lexer` is the best name for this class.  It's really a combined 
lexer and minimizer and I was a bit confused by some things until I realized 
that.  I think it would make more sense to name this `Minimizer` and the 
associated `lex` as `minimize`.



Comment at: lib/Lex/DependencyDirectivesSourceMinimizer.cpp:203
+
+static const char *reverseOverSpaces(const char *First, const char *Last) {
+  while (First != Last && isHorizontalWhitespace(Last[-1]))

`assert(First <= Last)` to match the other checks?



Comment at: lib/Lex/DependencyDirectivesSourceMinimizer.cpp:241
+  // Iterate over strings correctly to avoid comments and newlines.
+  if (*First == '\"' || *First == '\'') {
+if (isRawStringLiteral(Start, First))

I don't think this handles digit separators correctly.
```
#include 
int a = 0'1;
#include 
```


Repository:
  rC Clang

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

https://reviews.llvm.org/D55463



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

[PATCH] D41284: [Concepts] Associated constraints infrastructure.

[Saar Raz via Phabricator via cfe-commits]

saar.raz updated this revision to Diff 194984.
saar.raz added a comment.

Rebase onto trunk


Repository:
  rC Clang

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

https://reviews.llvm.org/D41284

Files:
  include/clang/AST/DeclTemplate.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Sema/Sema.h
  lib/AST/ASTContext.cpp
  lib/AST/DeclTemplate.cpp
  lib/Sema/SemaConcept.cpp
  lib/Sema/SemaTemplate.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriter.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/CXX/concepts-ts/temp/concept/p4.cpp
  test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/class-template-decl.cpp
  test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/func-template-decl.cpp
  test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/var-template-decl.cpp

Index: test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/var-template-decl.cpp
===
--- /dev/null
+++ test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/var-template-decl.cpp
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -std=c++2a -fconcepts-ts -x c++ -verify %s
+
+namespace nodiag {
+
+struct B {
+template  requires bool(T())
+static int A;
+};
+
+template  requires bool(U())
+int B::A = int(U());
+
+} // end namespace nodiag
+
+namespace diag {
+
+struct B {
+template  requires bool(T()) // expected-note{{previous template declaration is here}}
+static int A;
+};
+
+template  requires !bool(U())  // expected-error{{associated constraints differ in template redeclaration}}
+int B::A = int(U());
+
+} // end namespace diag
\ No newline at end of file
Index: test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/func-template-decl.cpp
===
--- test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/func-template-decl.cpp
+++ test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/func-template-decl.cpp
@@ -1,28 +1,28 @@
-// RUN: %clang_cc1 -std=c++14 -fconcepts-ts -x c++ -verify %s
+// RUN: %clang_cc1 -std=c++2a -fconcepts-ts -x c++ -verify %s
 
 namespace nodiag {
 
 template  requires bool(T())
-struct A;
+int A();
 template  requires bool(U())
-struct A;
+int A();
 
 } // end namespace nodiag
 
 namespace diag {
 
 template  requires true // expected-note{{previous template declaration is here}}
-struct A;
-template  struct A; // expected-error{{associated constraints differ in template redeclaration}}
+int A();
+template  int A(); // expected-error{{associated constraints differ in template redeclaration}}
 
-template  struct B; // expected-note{{previous template declaration is here}}
+template  int B(); // expected-note{{previous template declaration is here}}
 template  requires true // expected-error{{associated constraints differ in template redeclaration}}
-struct B;
+int B();
 
 template  requires true // expected-note{{previous template declaration is here}}
-struct C;
+int C();
 template  requires !0 // expected-error{{associated constraints differ in template redeclaration}}
-struct C;
+int C();
 
 } // end namespace diag
 
@@ -30,16 +30,11 @@
 
 struct AA {
   template  requires someFunc(T())
-  struct A;
+  int A();
 };
 
 template  requires someFunc(T())
-struct AA::A { };
-
-struct AAF {
-  template  requires someFunc(T())
-  friend struct AA::A;
-};
+int AA::A() { return sizeof(T); }
 
 } // end namespace nodiag
 
@@ -47,19 +42,11 @@
 
 template 
 struct TA {
-  template  class TT> requires TT::happy // expected-note 2{{previous template declaration is here}}
-  struct A;
-
-  struct AF;
+  template  class TT> requires TT::happy // expected-note{{previous template declaration is here}}
+  int A();
 };
 
 template 
-template  class TT> struct TA::A { }; // expected-error{{associated constraints differ in template redeclaration}}
-
-template 
-struct TA::AF {
-  template  class TT> requires TT::happy // expected-error{{associated constraints differ in template redeclaration}}
-  friend struct TA::A;
-};
+template  class TT> int TA::A() { return sizeof(TT); } // expected-error{{associated constraints differ in template redeclaration}}
 
 } // end namespace diag
Index: test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/class-template-decl.cpp
===
--- test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/class-template-decl.cpp
+++ test/CXX/concepts-ts/temp/temp.constr/temp.constr.decl/class-template-decl.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++14 -fconcepts-ts -x c++ -verify %s
+// RUN: %clang_cc1 -std=c++2a -fconcepts-ts -x c++ -verify %s
 
 namespace nodiag {
 
@@ -33,7 +33,7 @@
   struct A;
 };
 
-template  requires someFunc(T())
+template  requires someFunc(U())
 struct AA::A { };
 
 struct AAF {
@@ -47,18 +47,26 @@
 
 template 
 struct TA {
-  template  class TT> requires TT::happy // 

[PATCH] D60626: [clang] Aligned allocation is actually supported in macosx 10.13

[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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60626



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

[PATCH] D41217: [Concepts] Concept Specialization Expressions

[Saar Raz via Phabricator via cfe-commits]

saar.raz updated this revision to Diff 194979.
saar.raz added a comment.

Fix wrong patch uploaded


Repository:
  rC Clang

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

https://reviews.llvm.org/D41217

Files:
  include/clang/AST/DeclTemplate.h
  include/clang/AST/ExprCXX.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/StmtNodes.td
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/Expr.cpp
  lib/AST/ExprCXX.cpp
  lib/AST/ExprClassification.cpp
  lib/AST/ExprConstant.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/CodeGen/CGExprScalar.cpp
  lib/Frontend/FrontendActions.cpp
  lib/Parse/ParseExpr.cpp
  lib/Sema/CMakeLists.txt
  lib/Sema/SemaConcept.cpp
  lib/Sema/SemaExceptionSpec.cpp
  lib/Sema/SemaTemplate.cpp
  lib/Sema/SemaTemplateInstantiate.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  test/CXX/concepts-ts/expr/expr.prim/expr.prim.id/p3.cpp
  test/Parser/cxx2a-concept-declaration.cpp
  tools/libclang/CXCursor.cpp

Index: tools/libclang/CXCursor.cpp
===
--- tools/libclang/CXCursor.cpp
+++ tools/libclang/CXCursor.cpp
@@ -256,6 +256,7 @@
   case Stmt::BinaryConditionalOperatorClass:
   case Stmt::TypeTraitExprClass:
   case Stmt::CoawaitExprClass:
+  case Stmt::ConceptSpecializationExprClass:
   case Stmt::DependentCoawaitExprClass:
   case Stmt::CoyieldExprClass:
   case Stmt::CXXBindTemporaryExprClass:
Index: test/Parser/cxx2a-concept-declaration.cpp
===
--- test/Parser/cxx2a-concept-declaration.cpp
+++ test/Parser/cxx2a-concept-declaration.cpp
@@ -14,8 +14,6 @@
 // expected-error@-2{{template template parameter requires 'class' after the parameter list}}
 // expected-error@-3{{concept template parameter list must have at least one parameter; explicit specialization of concepts is not allowed, did you attempt this?}}
 
-template concept C2 = 0.f; // expected-error {{constraint expression must be of type 'bool' but is of type 'float'}}
-
 struct S1 {
   template concept C1 = true; // expected-error {{concept declarations may only appear in global or namespace scope}}
 };
@@ -26,15 +24,15 @@
 
 template
 template
-concept C4 = true; // expected-error {{extraneous template parameter list in concept definition}}
+concept C2 = true; // expected-error {{extraneous template parameter list in concept definition}}
 
-template concept C5 = true; // expected-note {{previous}} expected-note {{previous}}
-int C5; // expected-error {{redefinition}}
-struct C5 {}; // expected-error {{redefinition}}
+template concept C3 = true; // expected-note {{previous}} expected-note {{previous}}
+int C3; // expected-error {{redefinition}}
+struct C3 {}; // expected-error {{redefinition}}
 
-struct C6 {}; // expected-note{{previous definition is here}}
-template concept C6 = true;
-// expected-error@-1{{redefinition of 'C6' as different kind of symbol}}
+struct C4 {}; // expected-note{{previous definition is here}}
+template concept C4 = true;
+// expected-error@-1{{redefinition of 'C4' as different kind of symbol}}
 
 // TODO: Add test to prevent explicit specialization, partial specialization
 // and explicit instantiation of concepts.
@@ -43,31 +41,55 @@
 struct integral_constant { static constexpr T value = v; };
 
 namespace N {
-  template concept C7 = true;
+  template concept C5 = true;
 }
-using N::C7;
+using N::C5;
 
-template  concept C8 = integral_constant::value;
+template  concept C6 = integral_constant::value;
 // expected-error@-1{{use of undeclared identifier 'wor'; did you mean 'word'?}}
 // expected-note@-2{{'word' declared here}}
 
-template concept bool C9 = true;
+template concept bool C7 = true;
 // expected-error@-1{{'bool' keyword after 'concept' is no longer valid in C++2a; remove it}}
 
-template<> concept C10 = false;
+template<> concept C8 = false;
 // expected-error@-1{{concept template parameter list must have at least one parameter; explicit specialization of concepts is not allowed, did you attempt this?}}
 
-template<> concept C9 = false;
+template<> concept C7 = false;
 // expected-error@-1{{name defined in concept definition must be an identifier}}
 
-template concept N::C11 = false;
+template concept N::C9 = false;
 // expected-error@-1{{unexpected namespace scope before concept name; concepts must be defined inside their namespace, if any}}
 
 class A { };
 // expected-note@-1{{'A' declared here}}
 
-template concept A::C12 = false;
+template concept A::C10 = false;
 // expected-error@-1{{expected namespace name}}
 
 template concept operator int = false;
 // expected-error@-1{{name defined in concept definition must be an identifier}}
+
+template concept C11 = 2; // expected-error {{atomic constraint must be of 

[PATCH] D41217: [Concepts] Concept Specialization Expressions

[Saar Raz via Phabricator via cfe-commits]

saar.raz updated this revision to Diff 194978.
saar.raz added a comment.

Add new CodeSynthesisContexts to switch where they were missing


Repository:
  rC Clang

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

https://reviews.llvm.org/D41217

Files:
  lib/Frontend/FrontendActions.cpp
  test/Parser/cxx2a-concept-declaration.cpp

Index: test/Parser/cxx2a-concept-declaration.cpp
===
--- test/Parser/cxx2a-concept-declaration.cpp
+++ test/Parser/cxx2a-concept-declaration.cpp
@@ -27,12 +27,12 @@
 concept C2 = true; // expected-error {{extraneous template parameter list in concept definition}}
 
 template concept C3 = true; // expected-note {{previous}} expected-note {{previous}}
-int C4; // expected-error {{redefinition}}
-struct C4 {}; // expected-error {{redefinition}}
+int C3; // expected-error {{redefinition}}
+struct C3 {}; // expected-error {{redefinition}}
 
-struct C5 {}; // expected-note{{previous definition is here}}
-template concept C5 = true;
-// expected-error@-1{{redefinition of 'C5' as different kind of symbol}}
+struct C4 {}; // expected-note{{previous definition is here}}
+template concept C4 = true;
+// expected-error@-1{{redefinition of 'C4' as different kind of symbol}}
 
 // TODO: Add test to prevent explicit specialization, partial specialization
 // and explicit instantiation of concepts.
@@ -41,55 +41,55 @@
 struct integral_constant { static constexpr T value = v; };
 
 namespace N {
-  template concept C6 = true;
+  template concept C5 = true;
 }
-using N::C6;
+using N::C5;
 
-template  concept C7 = integral_constant::value;
+template  concept C6 = integral_constant::value;
 // expected-error@-1{{use of undeclared identifier 'wor'; did you mean 'word'?}}
 // expected-note@-2{{'word' declared here}}
 
-template concept bool C8 = true;
+template concept bool C7 = true;
 // expected-error@-1{{'bool' keyword after 'concept' is no longer valid in C++2a; remove it}}
 
-template<> concept C9 = false;
+template<> concept C8 = false;
 // expected-error@-1{{concept template parameter list must have at least one parameter; explicit specialization of concepts is not allowed, did you attempt this?}}
 
-template<> concept C8 = false;
+template<> concept C7 = false;
 // expected-error@-1{{name defined in concept definition must be an identifier}}
 
-template concept N::C12 = false;
+template concept N::C9 = false;
 // expected-error@-1{{unexpected namespace scope before concept name; concepts must be defined inside their namespace, if any}}
 
 class A { };
 // expected-note@-1{{'A' declared here}}
 
-template concept A::C13 = false;
+template concept A::C10 = false;
 // expected-error@-1{{expected namespace name}}
 
 template concept operator int = false;
 // expected-error@-1{{name defined in concept definition must be an identifier}}
 
-template concept C14 = 2; // expected-error {{atomic constraint must be of type 'bool' (found 'int')}}
-template concept C15 = 2 && x; // expected-error {{atomic constraint must be of type 'bool' (found 'int')}}
-template concept C16 = x || 2 || x; // expected-error {{atomic constraint must be of type 'bool' (found 'int')}}
-template concept C17 = 8ull && x || x; // expected-error {{atomic constraint must be of type 'bool' (found 'unsigned long long')}}
-template concept C18 = sizeof(T); // expected-error {{atomic constraint must be of type 'bool' (found 'unsigned long')}}
-template concept C19 = T{};
-static_assert(!C19);
-template concept C20 = (bool&&)true;
-static_assert(C20);
-template concept C21 = (const bool&)true;
-static_assert(C21);
-template concept C22 = (const bool)true;
-static_assert(C22);
-template  concept C23 = integral_constant::value && true;
-static_assert(C23);
-static_assert(!C23);
-template  concept C24 = integral_constant::value;
-static_assert(C24);
-static_assert(!C24);
-
-template  concept C25 = integral_constant::value;
+template concept C11 = 2; // expected-error {{atomic constraint must be of type 'bool' (found 'int')}}
+template concept C12 = 2 && x; // expected-error {{atomic constraint must be of type 'bool' (found 'int')}}
+template concept C13 = x || 2 || x; // expected-error {{atomic constraint must be of type 'bool' (found 'int')}}
+template concept C14 = 8ull && x || x; // expected-error {{atomic constraint must be of type 'bool' (found 'unsigned long long')}}
+template concept C15 = sizeof(T); // expected-error {{atomic constraint must be of type 'bool' (found 'unsigned long')}}
+template concept C16 = T{};
+static_assert(!C16);
+template concept C17 = (bool&&)true;
+static_assert(C17);
+template concept C18 = (const bool&)true;
+static_assert(C18);
+template concept C19 = (const bool)true;
+static_assert(C19);
+template  concept C20 = integral_constant::value && true;
+static_assert(C20);
+static_assert(!C20);
+template  concept C21 = integral_constant::value;
+static_assert(C21);
+static_assert(!C21);
+
+template  concept C22 = 

[PATCH] D59425: Explicitly Craft a Path to Compiler-RT Builtins on Bare Metal Targets

[Petr Hosek via Phabricator via cfe-commits]

phosek added inline comments.



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:173
+  }
+
+  // Builds of compiler-rt on bare-metal targets are specialized by specific

Would it be possible to support the [per-target runtimes directory 
layout](https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChain.cpp#L391)
 as well?


Repository:
  rC Clang

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

https://reviews.llvm.org/D59425



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

[PATCH] D60349: [COFF, ARM64] Fix ABI implementation of struct returns

[Mandeep Singh Grang via Phabricator via cfe-commits]

mgrang marked an inline comment as done.
mgrang added a comment.

In D60349#1462638 , @ostannard wrote:

> The document you linked in the LLVM change 
> (https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#return-values)
>  says that small POD types are returned directly in X0 or X0 and X1, but this 
> looks like it will always return them indirectly. I think we also need to 
> check the size of the type, and fall back the the plain C ABI for small types.





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

https://reviews.llvm.org/D60349



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

[PATCH] D60349: [COFF, ARM64] Fix ABI implementation of struct returns

[Mandeep Singh Grang via Phabricator via cfe-commits]

mgrang updated this revision to Diff 194954.

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

https://reviews.llvm.org/D60349

Files:
  include/clang/CodeGen/CGFunctionInfo.h
  lib/CodeGen/CGCall.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGen/arm64-microsoft-arguments.cpp

Index: test/CodeGen/arm64-microsoft-arguments.cpp
===
--- test/CodeGen/arm64-microsoft-arguments.cpp
+++ test/CodeGen/arm64-microsoft-arguments.cpp
@@ -14,7 +14,7 @@
 struct pod bar() { return s; }
 struct non_pod foo() { return t; }
 // CHECK: define {{.*}} void @{{.*}}bar{{.*}}(%struct.pod* noalias sret %agg.result)
-// CHECK: define {{.*}} void @{{.*}}foo{{.*}}(%struct.non_pod* noalias %agg.result)
+// CHECK: define {{.*}} void @{{.*}}foo{{.*}}(%struct.non_pod* inreg noalias sret %agg.result)
 
 
 // Check instance methods.
@@ -22,4 +22,4 @@
 struct Baz { pod2 baz(); };
 
 int qux() { return Baz().baz().x; }
-// CHECK: declare {{.*}} void @{{.*}}baz@Baz{{.*}}(%struct.Baz*, %struct.pod2*)
+// CHECK: declare {{.*}} void @{{.*}}baz@Baz{{.*}}(%struct.Baz*, %struct.pod2* sret)
Index: lib/CodeGen/MicrosoftCXXABI.cpp
===
--- lib/CodeGen/MicrosoftCXXABI.cpp
+++ lib/CodeGen/MicrosoftCXXABI.cpp
@@ -1052,32 +1052,43 @@
 }
 
 bool MicrosoftCXXABI::classifyReturnType(CGFunctionInfo ) const {
+  // For AArch64 see:
+  // https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#return-values
+
+  // 1. For return types <= 16 bytes, use the C return semantics.
+
+  // 2. For instance methods, "this" is passed to the callee in X0 and the
+  // struct address in X1. So the callee needs to copy X1 to X0 before
+  // returning.
+
+  // 3. For non-instance methods which return a non-POD struct, the address of
+  // the struct is passed to the callee in X0. We use the "inreg" attribute on
+  // a parameter to indicate a non-POD struct.
+
+  // 4. Example of POD struct: struct pod { int x; }
+  //Example of non-POD struct: struct nonpod { int x; nonpod() {} }
+
+  bool isAArch64 = CGM.getTarget().getTriple().isAArch64();
+
+  if (isAArch64) {
+uint64_t RetTySize = getContext().getTypeSize(FI.getReturnType());
+if (RetTySize <= 16)
+  return false;
+  }
+
   const CXXRecordDecl *RD = FI.getReturnType()->getAsCXXRecordDecl();
   if (!RD)
 return false;
 
-  CharUnits Align = CGM.getContext().getTypeAlignInChars(FI.getReturnType());
-  if (FI.isInstanceMethod()) {
-// If it's an instance method, aggregates are always returned indirectly via
-// the second parameter.
-FI.getReturnInfo() = ABIArgInfo::getIndirect(Align, /*ByVal=*/false);
-FI.getReturnInfo().setSRetAfterThis(FI.isInstanceMethod());
+  bool isIndirectReturn = !RD->isPOD();
+  bool isInstanceMethod = FI.isInstanceMethod();
 
-// aarch64-windows requires that instance methods use X1 for the return
-// address. So for aarch64-windows we do not mark the
-// return as SRet.
-FI.getReturnInfo().setSuppressSRet(CGM.getTarget().getTriple().getArch() ==
-   llvm::Triple::aarch64);
-return true;
-  } else if (!RD->isPOD()) {
-// If it's a free function, non-POD types are returned indirectly.
+  CharUnits Align = CGM.getContext().getTypeAlignInChars(FI.getReturnType());
+  if (isIndirectReturn || isInstanceMethod) {
 FI.getReturnInfo() = ABIArgInfo::getIndirect(Align, /*ByVal=*/false);
+FI.getReturnInfo().setSRetAfterThis(isInstanceMethod);
+FI.getReturnInfo().setInReg(isAArch64 && isIndirectReturn);
 
-// aarch64-windows requires that non-POD, non-instance returns use X0 for
-// the return address. So for aarch64-windows we do not mark the return as
-// SRet.
-FI.getReturnInfo().setSuppressSRet(CGM.getTarget().getTriple().getArch() ==
-   llvm::Triple::aarch64);
 return true;
   }
 
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1999,8 +1999,7 @@
   // Attach attributes to sret.
   if (IRFunctionArgs.hasSRetArg()) {
 llvm::AttrBuilder SRETAttrs;
-if (!RetAI.getSuppressSRet())
-  SRETAttrs.addAttribute(llvm::Attribute::StructRet);
+SRETAttrs.addAttribute(llvm::Attribute::StructRet);
 hasUsedSRet = true;
 if (RetAI.getInReg())
   SRETAttrs.addAttribute(llvm::Attribute::InReg);
Index: include/clang/CodeGen/CGFunctionInfo.h
===
--- include/clang/CodeGen/CGFunctionInfo.h
+++ include/clang/CodeGen/CGFunctionInfo.h
@@ -95,7 +95,6 @@
   bool InReg : 1;   // isDirect() || isExtend() || isIndirect()
   bool CanBeFlattened: 1;   // isDirect()
   bool SignExt : 1; // isExtend()
-  bool SuppressSRet : 1;// isIndirect()
 
   bool canHavePaddingType() const {
 

r358307 - Relanding r357928 with fixed debuginfo check.

[Amy Huang via cfe-commits]

Author: akhuang
Date: Fri Apr 12 13:25:30 2019
New Revision: 358307

URL: http://llvm.org/viewvc/llvm-project?rev=358307=rev
Log:
Relanding r357928 with fixed debuginfo check.

[MS] Add metadata for __declspec(allocator)

Original summary:
Emit !heapallocsite in the metadata for calls to functions marked with
__declspec(allocator). Eventually this will be emitted as S_HEAPALLOCSITE debug
info in codeview.

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

Added:
cfe/trunk/test/CodeGen/debug-info-codeview-heapallocsite.c
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=358307=358306=358307=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Fri Apr 12 13:25:30 2019
@@ -3791,6 +3791,8 @@ RValue CodeGenFunction::EmitCall(const C
 
   llvm::FunctionType *IRFuncTy = getTypes().GetFunctionType(CallInfo);
 
+  const Decl *TargetDecl = Callee.getAbstractInfo().getCalleeDecl().getDecl();
+
 #ifndef NDEBUG
   if (!(CallInfo.isVariadic() && CallInfo.getArgStruct())) {
 // For an inalloca varargs function, we don't expect CallInfo to match the
@@ -4279,11 +4281,7 @@ RValue CodeGenFunction::EmitCall(const C
   // Apply always_inline to all calls within flatten functions.
   // FIXME: should this really take priority over __try, below?
   if (CurCodeDecl && CurCodeDecl->hasAttr() &&
-  !(Callee.getAbstractInfo().getCalleeDecl().getDecl() &&
-Callee.getAbstractInfo()
-.getCalleeDecl()
-.getDecl()
-->hasAttr())) {
+  !(TargetDecl && TargetDecl->hasAttr())) {
 Attrs =
 Attrs.addAttribute(getLLVMContext(), 
llvm::AttributeList::FunctionIndex,
llvm::Attribute::AlwaysInline);
@@ -4367,11 +4365,16 @@ RValue CodeGenFunction::EmitCall(const C
 
   // Suppress tail calls if requested.
   if (llvm::CallInst *Call = dyn_cast(CI)) {
-const Decl *TargetDecl = 
Callee.getAbstractInfo().getCalleeDecl().getDecl();
 if (TargetDecl && TargetDecl->hasAttr())
   Call->setTailCallKind(llvm::CallInst::TCK_NoTail);
   }
 
+  // Add metadata for calls to MSAllocator functions
+  // FIXME: Get the type that the return value is cast to.
+  if (getDebugInfo() && TargetDecl &&
+  TargetDecl->hasAttr())
+getDebugInfo()->addHeapAllocSiteMetadata(CI, RetTy, Loc);
+
   // 4. Finish the call.
 
   // If the call doesn't return, finish the basic block and clear the
@@ -4528,7 +4531,6 @@ RValue CodeGenFunction::EmitCall(const C
   } ();
 
   // Emit the assume_aligned check on the return value.
-  const Decl *TargetDecl = Callee.getAbstractInfo().getCalleeDecl().getDecl();
   if (Ret.isScalar() && TargetDecl) {
 if (const auto *AA = TargetDecl->getAttr()) {
   llvm::Value *OffsetValue = nullptr;

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=358307=358306=358307=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Apr 12 13:25:30 2019
@@ -1959,6 +1959,20 @@ llvm::DIType *CGDebugInfo::getOrCreateSt
   return T;
 }
 
+void CGDebugInfo::addHeapAllocSiteMetadata(llvm::Instruction *CI,
+   QualType D,
+   SourceLocation Loc) {
+  llvm::MDNode *node;
+  if (D.getTypePtr()->isVoidPointerType()) {
+node = llvm::MDNode::get(CGM.getLLVMContext(), None);
+  } else {
+QualType PointeeTy = D.getTypePtr()->getPointeeType();
+node = getOrCreateType(PointeeTy, getOrCreateFile(Loc));
+  }
+
+  CI->setMetadata("heapallocsite", node);
+}
+
 void CGDebugInfo::completeType(const EnumDecl *ED) {
   if (DebugKind <= codegenoptions::DebugLineTablesOnly)
 return;

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=358307=358306=358307=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.h (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.h Fri Apr 12 13:25:30 2019
@@ -476,6 +476,10 @@ public:
   /// Emit standalone debug info for a type.
   llvm::DIType *getOrCreateStandaloneType(QualType Ty, SourceLocation Loc);
 
+  /// Add heapallocsite metadata for MSAllocator calls.
+  void addHeapAllocSiteMetadata(llvm::Instruction *CallSite, QualType Ty,
+SourceLocation Loc);
+
   void completeType(const EnumDecl *ED);
   void completeType(const RecordDecl *RD);
   void completeRequiredType(const RecordDecl *RD);

Added: 

[PATCH] D60629: [clang-tidy] Change the namespace for llvm checkers from 'llvm' to 'llvm_checker'

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added a comment.

Please use check for consistency with rest of Clang-tidy.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60629



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

[PATCH] D60408: [LibTooling] Extend Transformer to support multiple simultaneous changes.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added inline comments.



Comment at: clang/include/clang/Tooling/Refactoring/Transformer.h:80
+// \endcode
+struct TextChange {
+  // The (bound) id of the node whose source will be replaced.  This id should

ilya-biryukov wrote:
> ymandel wrote:
> > ilya-biryukov wrote:
> > > `MatchChange` or something similar might be a better name.
> > > This actually tries to change the matched AST node to a textual 
> > > replacement.
> > I chose this to contrast with an AST change.  The idea being that we're 
> > specifying a replacement relative to source code locations (informed by the 
> > ast). If we later, say, integrate with your library I could imagine 
> > specifying changes to AST nodes.  But, maybe I'm overthinking... If we're 
> > going to drop "text", what about "source?" be clearer than "text"? E.g, 
> > `SourceChange` or (my preference) `SourceEdit`?
> The reasons I find `TextChange` confusing is because I immediately think of 
> something super-simple (a range of text + the replaced text), and I 
> definitely don't think of the AST.
> 
> `SourceChange` and `SourceEdit` does not cause this confusion for me 
> personally, so both look ok. Although they do look pretty similar.
> Also, it's not actually a final edit, rather a description of it. So 
> something like `EditDescription` could work too.
Right, I'm now tending way from the whole focus on text/source/etc. I agree 
with your point that this is operating at the AST level, especially in light of 
the discussion below on applyRewriteRule.  Given that these are all anchored by 
an AST node, let's go with `ASTEdit`, unless that will conflict with the 
library that you're developing?

I agree that "Description" is more apt, but I feel like this is (somewhat) 
implicit in the fact that its a struct versus a function (which would actually 
be carrying out the action). I'm also afraid that "EditDescription" will read 
like an action, which may be a bit confusing (although the casing should help 
distinguish).



Comment at: clang/include/clang/Tooling/Refactoring/Transformer.h:87
+  TextGenerator Replacement;
+  TextGenerator Explanation;
+};

ilya-biryukov wrote:
> ymandel wrote:
> > ilya-biryukov wrote:
> > > I would've expected explanation to be the trait of the rewrite rule, 
> > > since all changes have to be applied.
> > > What's the reasoning behind having it at the level of separate changes? 
> > > How would this explanation be used? For debugging purposes or displaying 
> > > that to the user?
> > I think that for most cases, one explanation sufficies for the whole 
> > transformation. However, there are some tidies that emit multiple diagnoses 
> > (for example if changing before a declaration and a definition).   Would it 
> > help if I clarify in the comments?
> Yeah, absolutely! Please document what it's used for and that would clear 
> that up for me.
> I actually thing that explaining every part of the transformation is probably 
> too complicated, so most of the time you would want to have an explanation 
> for the `RewriteRule`, not for each individual change.
> 
> The other challenge that I see is show to display these explanations to the 
> user, i.e. how should the clients combine these explanations in order to get 
> the full one? Should the `RewriteRule` have an explanation of the full 
> transformation too?
I've revised the comments, changed the name to "Note" and put "Explanation" 
back into RewriteRule.

As for how to display these, I imagine an interface like clang tidy's fixit 
hints.  The Explanation (if any) will be associated with the span of the entire 
match.  The Notes will be associated with the target node span of each 
annotated change.  WDYT?



Comment at: clang/include/clang/Tooling/Refactoring/Transformer.h:190
 struct Transformation {
+  // Trivial constructor to enable `emplace_back()` and the like.
+  Transformation(CharSourceRange Range, std::string Replacement)

ilya-biryukov wrote:
> NIT: I'd suggest just paying a few extra lines for initializing the struct 
> instead of using the ctor.
> ```
> Transformation T;
> T.Range = ...;
> T.Replacement = ...;
> 
> v.push_back(std::move(T));
> ```
> or 
> ```
> v.emplace_back();
> v.back().Range = ...;
> v.back().Replacement = ...;
> ```
> 
> But I can see why you might want a ctor instead. If you decide to leave it, 
> consider re-adding the default ctor that got implicitly deleted as you 
> defined this other one.
Agreed. I only use it one place, hardly worth the cost. thanks



Comment at: clang/include/clang/Tooling/Refactoring/Transformer.h:204
+applyRewriteRule(const ast_matchers::MatchFinder::MatchResult ,
+ llvm::ArrayRef Changes);
 

ilya-biryukov wrote:
> Why would we change the interface here? Rewrite rule seemed like a perfect 
> input to this function
Good point.  For the name, you're right -- but I think 

[PATCH] D60408: [LibTooling] Extend Transformer to support multiple simultaneous changes.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 194944.
ymandel marked 8 inline comments as done.
ymandel added a comment.

Responses to comments, including renaming TextChange and applyRewriteRule.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60408

Files:
  clang/include/clang/Tooling/Refactoring/Transformer.h
  clang/lib/Tooling/Refactoring/Transformer.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -13,36 +13,11 @@
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
-namespace clang {
-namespace tooling {
-namespace {
-using ast_matchers::anyOf;
-using ast_matchers::argumentCountIs;
-using ast_matchers::callee;
-using ast_matchers::callExpr;
-using ast_matchers::cxxMemberCallExpr;
-using ast_matchers::cxxMethodDecl;
-using ast_matchers::cxxRecordDecl;
-using ast_matchers::declRefExpr;
-using ast_matchers::expr;
-using ast_matchers::functionDecl;
-using ast_matchers::hasAnyName;
-using ast_matchers::hasArgument;
-using ast_matchers::hasDeclaration;
-using ast_matchers::hasElse;
-using ast_matchers::hasName;
-using ast_matchers::hasType;
-using ast_matchers::ifStmt;
-using ast_matchers::member;
-using ast_matchers::memberExpr;
-using ast_matchers::namedDecl;
-using ast_matchers::on;
-using ast_matchers::pointsTo;
-using ast_matchers::to;
-using ast_matchers::unless;
-
-using llvm::StringRef;
+using namespace clang;
+using namespace tooling;
+using namespace ast_matchers;
 
+namespace {
 constexpr char KHeaderContents[] = R"cc(
   struct string {
 string(const char*);
@@ -59,6 +34,9 @@
 PCFProto& GetProto();
   };
   }  // namespace proto
+  class Logger {};
+  void operator<<(Logger& l, string msg);
+  Logger& log(int level);
 )cc";
 
 static ast_matchers::internal::Matcher
@@ -141,18 +119,16 @@
 static RewriteRule ruleStrlenSize() {
   StringRef StringExpr = "strexpr";
   auto StringType = namedDecl(hasAnyName("::basic_string", "::string"));
-  return buildRule(
- callExpr(
- callee(functionDecl(hasName("strlen"))),
- hasArgument(0, cxxMemberCallExpr(
-on(expr(hasType(isOrPointsTo(StringType)))
-   .bind(StringExpr)),
-callee(cxxMethodDecl(hasName("c_str")))
-  // Specify the intended type explicitly, because the matcher "type" of
-  // `callExpr()` is `Stmt`, not `Expr`.
-  .as()
-  .replaceWith("REPLACED")
-  .because("Use size() method directly on string.");
+  auto R = makeRule(
+  callExpr(callee(functionDecl(hasName("strlen"))),
+   hasArgument(0, cxxMemberCallExpr(
+  on(expr(hasType(isOrPointsTo(StringType)))
+ .bind(StringExpr)),
+  callee(cxxMethodDecl(hasName("c_str")),
+  changeRoot()
+  .to("REPLACED"));
+  R.Explanation = text("Use size() method directly on string.");
+  return R;
 }
 
 TEST_F(TransformerTest, StrlenSize) {
@@ -181,15 +157,12 @@
 // Tests replacing an expression.
 TEST_F(TransformerTest, Flag) {
   StringRef Flag = "flag";
-  RewriteRule Rule =
-  buildRule(
-  cxxMemberCallExpr(on(expr(hasType(cxxRecordDecl(hasName(
-"proto::ProtoCommandLineFlag"
-   .bind(Flag)),
-unless(callee(cxxMethodDecl(hasName("GetProto"))
-  .change(Flag)
-  .replaceWith("EXPR")
-  .because("Use GetProto() to access proto fields.");
+  RewriteRule Rule = makeRule(
+  cxxMemberCallExpr(on(expr(hasType(cxxRecordDecl(
+hasName("proto::ProtoCommandLineFlag"
+   .bind(Flag)),
+unless(callee(cxxMethodDecl(hasName("GetProto"),
+  change(Flag).to("EXPR"));
 
   std::string Input = R"cc(
 proto::ProtoCommandLineFlag flag;
@@ -207,9 +180,9 @@
 
 TEST_F(TransformerTest, NodePartNameNamedDecl) {
   StringRef Fun = "fun";
-  RewriteRule Rule = buildRule(functionDecl(hasName("bad")).bind(Fun))
- .change(Fun, NodePart::Name)
- .replaceWith("good");
+  RewriteRule Rule =
+  makeRule(functionDecl(hasName("bad")).bind(Fun),
+   change(Fun, NodePart::Name).to("good"));
 
   std::string Input = R"cc(
 int bad(int x);
@@ -240,9 +213,8 @@
   )cc";
 
   StringRef Ref = "ref";
-  testRule(buildRule(declRefExpr(to(functionDecl(hasName("bad".bind(Ref))
-   .change(Ref, NodePart::Name)
-   .replaceWith("good"),
+  

[PATCH] D60629: [clang-tidy] Change the namespace for llvm checkers from 'llvm' to 'llvm_checker'

[Don Hinton via Phabricator via cfe-commits]

hintonda updated this revision to Diff 194940.
hintonda added a comment.

- Remove leftover comments, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60629

Files:
  clang-tools-extra/clang-tidy/add_new_check.py
  clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
  clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.h
  clang-tools-extra/clang-tidy/llvm/IncludeOrderCheck.cpp
  clang-tools-extra/clang-tidy/llvm/IncludeOrderCheck.h
  clang-tools-extra/clang-tidy/llvm/LLVMTidyModule.cpp
  clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.cpp
  clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.h
  clang-tools-extra/clang-tidy/rename_check.py
  clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
@@ -3,7 +3,7 @@
 #include "llvm/IncludeOrderCheck.h"
 #include "gtest/gtest.h"
 
-using namespace clang::tidy::llvm;
+using namespace clang::tidy::llvm_checker;
 
 namespace clang {
 namespace tidy {
Index: clang-tools-extra/clang-tidy/rename_check.py
===
--- clang-tools-extra/clang-tidy/rename_check.py
+++ clang-tools-extra/clang-tidy/rename_check.py
@@ -14,6 +14,18 @@
 import re
 
 
+def replaceInFileRegex(fileName, sFrom, sTo):
+  if sFrom == sTo:
+return
+  txt = None
+  with open(fileName, "r") as f:
+txt = f.read()
+
+  txt = re.sub(sFrom, sTo, txt)
+  print("Replacing '%s' -> '%s' in '%s'..." % (sFrom, sTo, fileName))
+  with open(fileName, "w") as f:
+f.write(txt)
+
 def replaceInFile(fileName, sFrom, sTo):
   if sFrom == sTo:
 return
@@ -203,6 +215,8 @@
   clang_tidy_path = os.path.dirname(__file__)
 
   header_guard_variants = [
+  (args.old_check_name.replace('-', '_') + '_Check').upper(),
+  (old_module + '_' + check_name_camel).upper(),
   (old_module + '_' + new_check_name_camel).upper(),
   args.old_check_name.replace('-', '_').upper()]
   header_guard_new = (new_module + '_' + new_check_name_camel).upper()
@@ -210,18 +224,19 @@
   old_module_path = os.path.join(clang_tidy_path, old_module)
   new_module_path = os.path.join(clang_tidy_path, new_module)
 
-  # Remove the check from the old module.
-  cmake_lists = os.path.join(old_module_path, 'CMakeLists.txt')
-  check_found = deleteMatchingLines(cmake_lists, '\\b' + check_name_camel)
-  if not check_found:
-print("Check name '%s' not found in %s. Exiting." %
+  if (args.old_check_name != args.new_check_name):
+# Remove the check from the old module.
+cmake_lists = os.path.join(old_module_path, 'CMakeLists.txt')
+check_found = deleteMatchingLines(cmake_lists, '\\b' + check_name_camel)
+if not check_found:
+  print("Check name '%s' not found in %s. Exiting." %
 (check_name_camel, cmake_lists))
-return 1
+  return 1
 
-  modulecpp = filter(
-  lambda p: p.lower() == old_module.lower() + 'tidymodule.cpp',
-  os.listdir(old_module_path))[0]
-  deleteMatchingLines(os.path.join(old_module_path, modulecpp),
+modulecpp = filter(
+lambda p: p.lower() == old_module.lower() + 'tidymodule.cpp',
+os.listdir(old_module_path))[0]
+deleteMatchingLines(os.path.join(old_module_path, modulecpp),
   '\\b' + check_name_camel + '|\\b' + args.old_check_name)
 
   for filename in getListOfFiles(clang_tidy_path):
@@ -249,14 +264,21 @@
   new_module + '/' + new_check_name_camel)
 replaceInFile(filename, check_name_camel, new_check_name_camel)
 
-  if old_module != new_module:
+  if old_module != new_module or new_module == 'llvm' or new_module == 'clang':
+if new_module == 'llvm':
+  new_namespace = new_module + '_checker'
+else:
+  new_namespace = new_module
 check_implementation_files = glob.glob(
 os.path.join(old_module_path, new_check_name_camel + '*'))
 for filename in check_implementation_files:
   # Move check implementation to the directory of the new module.
   filename = fileRename(filename, old_module_path, new_module_path)
-  replaceInFile(filename, 'namespace ' + old_module,
-'namespace ' + new_module)
+  replaceInFileRegex(filename, 'namespace ' + old_module + '[^ \n]*',
+ 'namespace ' + new_namespace)
+
+  if (args.old_check_name == args.new_check_name):
+return
 
   # Add check to the new module.
   adapt_cmake(new_module_path, new_check_name_camel)
Index: clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.h
===
--- clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.h
+++ clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.h
@@ -6,14 +6,14 @@
 //
 

[PATCH] D60349: [COFF, ARM64] Fix ABI implementation of struct returns

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: lib/CodeGen/MicrosoftCXXABI.cpp:1062
+  bool sretInX0 = (CGM.getTarget().getTriple().getArch() ==
+   llvm::Triple::aarch64) && !RD->isPOD();
+

ostannard wrote:
> This should also check aarch64_be.
aarch64_be-windows isn't a thing; it doesn't make sense to check for that 
explicitly.

That said, there is an isAArch64() helper which is probably more readable 
anyway.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60349



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

[PATCH] D60629: [clang-tidy] Change the namespace for llvm checkers from 'llvm' to 'llvm_checker'

[Don Hinton via Phabricator via cfe-commits]

hintonda updated this revision to Diff 194941.
hintonda added a comment.

- Add missing 'clang'.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60629

Files:
  clang-tools-extra/clang-tidy/add_new_check.py
  clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
  clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.h
  clang-tools-extra/clang-tidy/llvm/IncludeOrderCheck.cpp
  clang-tools-extra/clang-tidy/llvm/IncludeOrderCheck.h
  clang-tools-extra/clang-tidy/llvm/LLVMTidyModule.cpp
  clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.cpp
  clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.h
  clang-tools-extra/clang-tidy/rename_check.py
  clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
@@ -3,7 +3,7 @@
 #include "llvm/IncludeOrderCheck.h"
 #include "gtest/gtest.h"
 
-using namespace clang::tidy::llvm;
+using namespace clang::tidy::llvm_checker;
 
 namespace clang {
 namespace tidy {
Index: clang-tools-extra/clang-tidy/rename_check.py
===
--- clang-tools-extra/clang-tidy/rename_check.py
+++ clang-tools-extra/clang-tidy/rename_check.py
@@ -14,6 +14,18 @@
 import re
 
 
+def replaceInFileRegex(fileName, sFrom, sTo):
+  if sFrom == sTo:
+return
+  txt = None
+  with open(fileName, "r") as f:
+txt = f.read()
+
+  txt = re.sub(sFrom, sTo, txt)
+  print("Replacing '%s' -> '%s' in '%s'..." % (sFrom, sTo, fileName))
+  with open(fileName, "w") as f:
+f.write(txt)
+
 def replaceInFile(fileName, sFrom, sTo):
   if sFrom == sTo:
 return
@@ -203,6 +215,8 @@
   clang_tidy_path = os.path.dirname(__file__)
 
   header_guard_variants = [
+  (args.old_check_name.replace('-', '_') + '_Check').upper(),
+  (old_module + '_' + check_name_camel).upper(),
   (old_module + '_' + new_check_name_camel).upper(),
   args.old_check_name.replace('-', '_').upper()]
   header_guard_new = (new_module + '_' + new_check_name_camel).upper()
@@ -210,18 +224,19 @@
   old_module_path = os.path.join(clang_tidy_path, old_module)
   new_module_path = os.path.join(clang_tidy_path, new_module)
 
-  # Remove the check from the old module.
-  cmake_lists = os.path.join(old_module_path, 'CMakeLists.txt')
-  check_found = deleteMatchingLines(cmake_lists, '\\b' + check_name_camel)
-  if not check_found:
-print("Check name '%s' not found in %s. Exiting." %
+  if (args.old_check_name != args.new_check_name):
+# Remove the check from the old module.
+cmake_lists = os.path.join(old_module_path, 'CMakeLists.txt')
+check_found = deleteMatchingLines(cmake_lists, '\\b' + check_name_camel)
+if not check_found:
+  print("Check name '%s' not found in %s. Exiting." %
 (check_name_camel, cmake_lists))
-return 1
+  return 1
 
-  modulecpp = filter(
-  lambda p: p.lower() == old_module.lower() + 'tidymodule.cpp',
-  os.listdir(old_module_path))[0]
-  deleteMatchingLines(os.path.join(old_module_path, modulecpp),
+modulecpp = filter(
+lambda p: p.lower() == old_module.lower() + 'tidymodule.cpp',
+os.listdir(old_module_path))[0]
+deleteMatchingLines(os.path.join(old_module_path, modulecpp),
   '\\b' + check_name_camel + '|\\b' + args.old_check_name)
 
   for filename in getListOfFiles(clang_tidy_path):
@@ -249,14 +264,21 @@
   new_module + '/' + new_check_name_camel)
 replaceInFile(filename, check_name_camel, new_check_name_camel)
 
-  if old_module != new_module:
+  if old_module != new_module or new_module == 'llvm' or new_module == 'clang':
+if new_module == 'llvm' or new_module -- 'clang':
+  new_namespace = new_module + '_checker'
+else:
+  new_namespace = new_module
 check_implementation_files = glob.glob(
 os.path.join(old_module_path, new_check_name_camel + '*'))
 for filename in check_implementation_files:
   # Move check implementation to the directory of the new module.
   filename = fileRename(filename, old_module_path, new_module_path)
-  replaceInFile(filename, 'namespace ' + old_module,
-'namespace ' + new_module)
+  replaceInFileRegex(filename, 'namespace ' + old_module + '[^ \n]*',
+ 'namespace ' + new_namespace)
+
+  if (args.old_check_name == args.new_check_name):
+return
 
   # Add check to the new module.
   adapt_cmake(new_module_path, new_check_name_camel)
Index: clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.h
===
--- clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.h
+++ clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.h
@@ -6,14 

[PATCH] D60629: [clang-tidy] Change the namespace for llvm checkers from 'llvm' to 'llvm_checker'

[Don Hinton via Phabricator via cfe-commits]

hintonda created this revision.
hintonda added reviewers: alexfh, aaron.ballman.
Herald added a subscriber: xazax.hun.
Herald added a project: clang.

Change the namespace for llvm checkers from 'llvm' to
'llvm_checker', and modify add_new_check.py and rename_check.py to
support the new namespace. Checker, file, and directory names remain
unchanged.

Used new version of rename_check.py to make the change in existing
llvm checkers, but had to fix LLVMTidyModule.cpp and
LLVMModuleTest.cpp by hand.

The changes to rename_check.py are idempotent, so if accidently
run multiple times, it won't do anything.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D60629

Files:
  clang-tools-extra/clang-tidy/add_new_check.py
  clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
  clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.h
  clang-tools-extra/clang-tidy/llvm/IncludeOrderCheck.cpp
  clang-tools-extra/clang-tidy/llvm/IncludeOrderCheck.h
  clang-tools-extra/clang-tidy/llvm/LLVMTidyModule.cpp
  clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.cpp
  clang-tools-extra/clang-tidy/llvm/TwineLocalCheck.h
  clang-tools-extra/clang-tidy/rename_check.py
  clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
@@ -3,7 +3,7 @@
 #include "llvm/IncludeOrderCheck.h"
 #include "gtest/gtest.h"
 
-using namespace clang::tidy::llvm;
+using namespace clang::tidy::llvm_checker;
 
 namespace clang {
 namespace tidy {
Index: clang-tools-extra/clang-tidy/rename_check.py
===
--- clang-tools-extra/clang-tidy/rename_check.py
+++ clang-tools-extra/clang-tidy/rename_check.py
@@ -14,6 +14,23 @@
 import re
 
 
+def replaceInFileRegex(fileName, sFrom, sTo):
+  if sFrom == sTo:
+return
+  txt = None
+  with open(fileName, "r") as f:
+txt = f.read()
+
+  txt = re.sub(sFrom, sTo, txt)
+
+  #if sFrom not in txt:
+  #  return
+
+  #txt = txt.replace(sFrom, sTo)
+  print("Replacing '%s' -> '%s' in '%s'..." % (sFrom, sTo, fileName))
+  with open(fileName, "w") as f:
+f.write(txt)
+
 def replaceInFile(fileName, sFrom, sTo):
   if sFrom == sTo:
 return
@@ -203,25 +220,27 @@
   clang_tidy_path = os.path.dirname(__file__)
 
   header_guard_variants = [
-  (old_module + '_' + new_check_name_camel).upper(),
+  (args.old_check_name.replace('-', '_') + '_Check').upper(),
+  (old_module + '_' + check_name_camel).upper(),
   args.old_check_name.replace('-', '_').upper()]
   header_guard_new = (new_module + '_' + new_check_name_camel).upper()
 
   old_module_path = os.path.join(clang_tidy_path, old_module)
   new_module_path = os.path.join(clang_tidy_path, new_module)
 
-  # Remove the check from the old module.
-  cmake_lists = os.path.join(old_module_path, 'CMakeLists.txt')
-  check_found = deleteMatchingLines(cmake_lists, '\\b' + check_name_camel)
-  if not check_found:
-print("Check name '%s' not found in %s. Exiting." %
+  if (args.old_check_name != args.new_check_name):
+# Remove the check from the old module.
+cmake_lists = os.path.join(old_module_path, 'CMakeLists.txt')
+check_found = deleteMatchingLines(cmake_lists, '\\b' + check_name_camel)
+if not check_found:
+  print("Check name '%s' not found in %s. Exiting." %
 (check_name_camel, cmake_lists))
-return 1
+  return 1
 
-  modulecpp = filter(
-  lambda p: p.lower() == old_module.lower() + 'tidymodule.cpp',
-  os.listdir(old_module_path))[0]
-  deleteMatchingLines(os.path.join(old_module_path, modulecpp),
+modulecpp = filter(
+lambda p: p.lower() == old_module.lower() + 'tidymodule.cpp',
+os.listdir(old_module_path))[0]
+deleteMatchingLines(os.path.join(old_module_path, modulecpp),
   '\\b' + check_name_camel + '|\\b' + args.old_check_name)
 
   for filename in getListOfFiles(clang_tidy_path):
@@ -249,14 +268,23 @@
   new_module + '/' + new_check_name_camel)
 replaceInFile(filename, check_name_camel, new_check_name_camel)
 
-  if old_module != new_module:
+  if old_module != new_module or new_module == 'llvm' or new_module == 'clang':
+if new_module == 'llvm':
+  new_namespace = new_module + '_checker'
+else:
+  new_namespace = new_module
 check_implementation_files = glob.glob(
 os.path.join(old_module_path, new_check_name_camel + '*'))
 for filename in check_implementation_files:
   # Move check implementation to the directory of the new module.
   filename = fileRename(filename, old_module_path, new_module_path)
-  replaceInFile(filename, 'namespace ' + old_module,
-'namespace ' + new_module)
+  #replaceInFile(filename, 'namespace ' + old_module,

[PATCH] D60151: [clang-tidy] Rename llvm checkers to llvm-project

[Don Hinton via Phabricator via cfe-commits]

hintonda abandoned this revision.
hintonda added a comment.

Replaced by D60629 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60151



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

[PATCH] D60627: [MSVC] Use the correct casing of HostX64/HostX86

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo created this revision.
mstorsjo added a reviewer: rnk.
Herald added a project: clang.

If accessing the MSVC installation root directly on a case sensitive 
filesystem, these details matter.


Repository:
  rC Clang

https://reviews.llvm.org/D60627

Files:
  lib/Driver/ToolChains/MSVC.cpp


Index: lib/Driver/ToolChains/MSVC.cpp
===
--- lib/Driver/ToolChains/MSVC.cpp
+++ lib/Driver/ToolChains/MSVC.cpp
@@ -506,7 +506,7 @@
 // its containing bin directory at the top of PATH, followed by the
 // native target bin directory.
 // e.g. when compiling for x86 on an x64 host, PATH should start with:
-// /bin/HostX64/x86;/bin/HostX64/x64
+// /bin/Hostx64/x86;/bin/Hostx64/x64
 // This doesn't attempt to handle ToolsetLayout::DevDivInternal.
 if (TC.getIsVS2017OrNewer() &&
 llvm::Triple(llvm::sys::getProcessTriple()).getArch() != TC.getArch()) 
{
@@ -848,7 +848,7 @@
 if (VSLayout == ToolsetLayout::VS2017OrNewer) {
   const bool HostIsX64 =
   llvm::Triple(llvm::sys::getProcessTriple()).isArch64Bit();
-  const char *const HostName = HostIsX64 ? "HostX64" : "HostX86";
+  const char *const HostName = HostIsX64 ? "Hostx64" : "Hostx86";
   llvm::sys::path::append(Path, "bin", HostName, SubdirName);
 } else { // OlderVS or DevDivInternal
   llvm::sys::path::append(Path, "bin", SubdirName);


Index: lib/Driver/ToolChains/MSVC.cpp
===
--- lib/Driver/ToolChains/MSVC.cpp
+++ lib/Driver/ToolChains/MSVC.cpp
@@ -506,7 +506,7 @@
 // its containing bin directory at the top of PATH, followed by the
 // native target bin directory.
 // e.g. when compiling for x86 on an x64 host, PATH should start with:
-// /bin/HostX64/x86;/bin/HostX64/x64
+// /bin/Hostx64/x86;/bin/Hostx64/x64
 // This doesn't attempt to handle ToolsetLayout::DevDivInternal.
 if (TC.getIsVS2017OrNewer() &&
 llvm::Triple(llvm::sys::getProcessTriple()).getArch() != TC.getArch()) {
@@ -848,7 +848,7 @@
 if (VSLayout == ToolsetLayout::VS2017OrNewer) {
   const bool HostIsX64 =
   llvm::Triple(llvm::sys::getProcessTriple()).isArch64Bit();
-  const char *const HostName = HostIsX64 ? "HostX64" : "HostX86";
+  const char *const HostName = HostIsX64 ? "Hostx64" : "Hostx86";
   llvm::sys::path::append(Path, "bin", HostName, SubdirName);
 } else { // OlderVS or DevDivInternal
   llvm::sys::path::append(Path, "bin", SubdirName);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D60094: [MSVC] If unable to find link.exe from a MSVC installation, look for link.exe next to cl.exe

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo updated this revision to Diff 194928.
mstorsjo added a comment.

Removed other local experiments from the patch context.


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

https://reviews.llvm.org/D60094

Files:
  lib/Driver/ToolChains/MSVC.cpp


Index: lib/Driver/ToolChains/MSVC.cpp
===
--- lib/Driver/ToolChains/MSVC.cpp
+++ lib/Driver/ToolChains/MSVC.cpp
@@ -488,8 +488,18 @@
 // their own link.exe which may come first.
 linkPath = FindVisualStudioExecutable(TC, "link.exe");
 
-if (!TC.FoundMSVCInstall() && !llvm::sys::fs::can_execute(linkPath))
-  C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+if (!TC.FoundMSVCInstall() && !llvm::sys::fs::can_execute(linkPath)) {
+  llvm::SmallString<128> ClPath;
+  ClPath = TC.GetProgramPath("cl.exe");
+  if (llvm::sys::fs::can_execute(ClPath)) {
+linkPath = llvm::sys::path::parent_path(ClPath);
+llvm::sys::path::append(linkPath, "link.exe");
+if (!llvm::sys::fs::can_execute(linkPath))
+  C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+  } else {
+C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+  }
+}
 
 #ifdef _WIN32
 // When cross-compiling with VS2017 or newer, link.exe expects to have


Index: lib/Driver/ToolChains/MSVC.cpp
===
--- lib/Driver/ToolChains/MSVC.cpp
+++ lib/Driver/ToolChains/MSVC.cpp
@@ -488,8 +488,18 @@
 // their own link.exe which may come first.
 linkPath = FindVisualStudioExecutable(TC, "link.exe");
 
-if (!TC.FoundMSVCInstall() && !llvm::sys::fs::can_execute(linkPath))
-  C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+if (!TC.FoundMSVCInstall() && !llvm::sys::fs::can_execute(linkPath)) {
+  llvm::SmallString<128> ClPath;
+  ClPath = TC.GetProgramPath("cl.exe");
+  if (llvm::sys::fs::can_execute(ClPath)) {
+linkPath = llvm::sys::path::parent_path(ClPath);
+llvm::sys::path::append(linkPath, "link.exe");
+if (!llvm::sys::fs::can_execute(linkPath))
+  C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+  } else {
+C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+  }
+}
 
 #ifdef _WIN32
 // When cross-compiling with VS2017 or newer, link.exe expects to have
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40577: Clang support for simd functions

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:9615
+
+  std::string Buffer;
+  if (Fn->hasFnAttribute("vector-variants")) {

mmasten wrote:
> ABataev wrote:
> > 1. Why this change is required?
> > 2. Why not a `SmallString`?
> This change is required to more clearly indicate which function names 
> represent simd function variants of the original scalar function. Previously, 
> these function names were just represented as individual strings. Example: 
> "_ZGVbM4l8__Z5add_1Pf", "_ZGVbN4l8__Z5add_1Pf", ... The attributes are now 
> represented as a key/value pair: "vector-variants"="_ZGVbM4l8__Z5add_1Pf, 
> _ZGVbN4l8__Z5add_1Pf, ...". Because the length of the string can now be quite 
> a bit longer, I used std::string. Is SmallString still appropriate?
1. I would suggest to try to change this part of the compiler only after the 
LLVM part is accepted to avoid double work here. 
2. Yes, SmallString, SmallVector, etc. are dynamically resized if the 
preallocated space is not enough.


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

https://reviews.llvm.org/D40577



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

[PATCH] D60094: [MSVC] If unable to find link.exe from a MSVC installation, look for link.exe next to cl.exe

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo updated this revision to Diff 194926.
mstorsjo retitled this revision from "[MSVC] If unable to find link.exe 
relative to MSVC, look for link.exe in the path" to "[MSVC] If unable to find 
link.exe from a MSVC installation, look for link.exe next to cl.exe".
mstorsjo edited the summary of this revision.
mstorsjo added a comment.

Updated to not look blindly for link(.exe) in the PATH, but look for cl.exe and 
look for link.exe next to it.


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

https://reviews.llvm.org/D60094

Files:
  lib/Driver/ToolChains/MSVC.cpp


Index: lib/Driver/ToolChains/MSVC.cpp
===
--- lib/Driver/ToolChains/MSVC.cpp
+++ lib/Driver/ToolChains/MSVC.cpp
@@ -488,8 +488,18 @@
 // their own link.exe which may come first.
 linkPath = FindVisualStudioExecutable(TC, "link.exe");
 
-if (!TC.FoundMSVCInstall() && !llvm::sys::fs::can_execute(linkPath))
-  C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+if (!TC.FoundMSVCInstall() && !llvm::sys::fs::can_execute(linkPath)) {
+  llvm::SmallString<128> ClPath;
+  ClPath = TC.GetProgramPath("cl.exe");
+  if (llvm::sys::fs::can_execute(ClPath)) {
+linkPath = llvm::sys::path::parent_path(ClPath);
+llvm::sys::path::append(linkPath, "link.exe");
+if (!llvm::sys::fs::can_execute(linkPath))
+  C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+  } else {
+C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+  }
+}
 
 #ifdef _WIN32
 // When cross-compiling with VS2017 or newer, link.exe expects to have


Index: lib/Driver/ToolChains/MSVC.cpp
===
--- lib/Driver/ToolChains/MSVC.cpp
+++ lib/Driver/ToolChains/MSVC.cpp
@@ -488,8 +488,18 @@
 // their own link.exe which may come first.
 linkPath = FindVisualStudioExecutable(TC, "link.exe");
 
-if (!TC.FoundMSVCInstall() && !llvm::sys::fs::can_execute(linkPath))
-  C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+if (!TC.FoundMSVCInstall() && !llvm::sys::fs::can_execute(linkPath)) {
+  llvm::SmallString<128> ClPath;
+  ClPath = TC.GetProgramPath("cl.exe");
+  if (llvm::sys::fs::can_execute(ClPath)) {
+linkPath = llvm::sys::path::parent_path(ClPath);
+llvm::sys::path::append(linkPath, "link.exe");
+if (!llvm::sys::fs::can_execute(linkPath))
+  C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+  } else {
+C.getDriver().Diag(clang::diag::warn_drv_msvc_not_found);
+  }
+}
 
 #ifdef _WIN32
 // When cross-compiling with VS2017 or newer, link.exe expects to have
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D60561: [clang] fixing diagnostics of constexpr callstack

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added a comment.

In D60561#1464740 , @Tyker wrote:

> @rsmith i don't think collecting theses values is expansive compared to 
> evaluating the expression.
>  but i agree that we can disable the collection of these values when no 
> diagnostics can be emited.


To help make an informed decision you can grab a big TU (I usually use 
`SemaDecl.cpp` or all of Boost) and then run `-fsyntax-only` on it. With a tool 
like `perf stat` you can get pretty good results.


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

https://reviews.llvm.org/D60561



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

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Eric Liu via Phabricator via cfe-commits]

ioeric marked an inline comment as done.
ioeric added inline comments.



Comment at: clangd/TUScheduler.cpp:552
+const tooling::CompileCommand ::getCurrentCompileCommand() const {
+  return FileInputs.CompileCommand;
+}

ioeric wrote:
> ilya-biryukov wrote:
> > ioeric wrote:
> > > ilya-biryukov wrote:
> > > > ioeric wrote:
> > > > > ilya-biryukov wrote:
> > > > > > ioeric wrote:
> > > > > > > ilya-biryukov wrote:
> > > > > > > > This is racy, `FileInputs` is only accessed from a worker 
> > > > > > > > thread now.
> > > > > > > > I'm afraid we'll need a separate variable with a lock around it 
> > > > > > > > (could reuse one lock for preamble and compile command, 
> > > > > > > > probably)
> > > > > > > It looks like we could also guard `FileInputs`? Adding another 
> > > > > > > variable seems to make the state more complicated. 
> > > > > > `FileInputs` are currently accessed without locks in a bunch of 
> > > > > > places and it'd be nice to keep it that way (the alternative is 
> > > > > > more complicated code).
> > > > > > Doing the same thing we do for preamble looks like the best 
> > > > > > alternative here.
> > > > > The reason I think it would be easier to guard `FileInputs` with 
> > > > > mutex instead of pulling a new variable is that CompileCommand is 
> > > > > usually used along with other fields in `FileInputs`.  I think we 
> > > > > could manage this with relatively few changes. Please take a look at 
> > > > > the new changes.
> > > > Unfortunately we can't share `Inputs.FS` safely as the vfs 
> > > > implementations are not thread-safe.
> > > It seems to me that the behavior for `FS` hasn't change in this patch. 
> > > And `FileInputs` (incl. `Inputs.FS`) has always been available/shared 
> > > across worker threads. We don't seem to have systematic way to prevent 
> > > raciness before this patch, and it would be good to have it somehow, but 
> > > it's probably out of the scope.  
> > > 
> > > Maybe I'm missing something or misinterpreting. Could you elaborate?  
> > > And FileInputs (incl. Inputs.FS) has always been available/shared across 
> > > worker threads
> > I don't think that's the case, we did not a public API to get the hands on 
> > `ASTWorker::FileInputs.FS` and we're getting one now.
> > Even though the current patch does not add such racy accesses, it certainly 
> > makes it much easier to do it accidentally from the clients of `ASTWorker` 
> > in the future (one just needs to access `getCurrentInputs().FS`).
> > 
> > The (not very) systematic way to prevent raciness that we use now is to 
> > **not** protect the members which are potentially racy with locks and 
> > document they are accessed only from a worker thread.
> > Having a separate copy of the compile command is a small price to pay (both 
> > in terms of performance and complexity) to avoid exposing non-thread-safe 
> > members of `ASTWorker` in its public interface.
> I don't think that makes a fundamental difference as `FileInputs.FS` is 
> already racy. But if "public" API is the concern, we could simply restrict 
> the scope of the API and make return `CompileCommand` only.
Inside `ASTWorker`, `FileInputs` can still be guarded with `Mutex` as a whole. 


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607



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

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Eric Liu via Phabricator via cfe-commits]

ioeric marked an inline comment as done.
ioeric added inline comments.



Comment at: clangd/TUScheduler.cpp:552
+const tooling::CompileCommand ::getCurrentCompileCommand() const {
+  return FileInputs.CompileCommand;
+}

ilya-biryukov wrote:
> ioeric wrote:
> > ilya-biryukov wrote:
> > > ioeric wrote:
> > > > ilya-biryukov wrote:
> > > > > ioeric wrote:
> > > > > > ilya-biryukov wrote:
> > > > > > > This is racy, `FileInputs` is only accessed from a worker thread 
> > > > > > > now.
> > > > > > > I'm afraid we'll need a separate variable with a lock around it 
> > > > > > > (could reuse one lock for preamble and compile command, probably)
> > > > > > It looks like we could also guard `FileInputs`? Adding another 
> > > > > > variable seems to make the state more complicated. 
> > > > > `FileInputs` are currently accessed without locks in a bunch of 
> > > > > places and it'd be nice to keep it that way (the alternative is more 
> > > > > complicated code).
> > > > > Doing the same thing we do for preamble looks like the best 
> > > > > alternative here.
> > > > The reason I think it would be easier to guard `FileInputs` with mutex 
> > > > instead of pulling a new variable is that CompileCommand is usually 
> > > > used along with other fields in `FileInputs`.  I think we could manage 
> > > > this with relatively few changes. Please take a look at the new changes.
> > > Unfortunately we can't share `Inputs.FS` safely as the vfs 
> > > implementations are not thread-safe.
> > It seems to me that the behavior for `FS` hasn't change in this patch. And 
> > `FileInputs` (incl. `Inputs.FS`) has always been available/shared across 
> > worker threads. We don't seem to have systematic way to prevent raciness 
> > before this patch, and it would be good to have it somehow, but it's 
> > probably out of the scope.  
> > 
> > Maybe I'm missing something or misinterpreting. Could you elaborate?  
> > And FileInputs (incl. Inputs.FS) has always been available/shared across 
> > worker threads
> I don't think that's the case, we did not a public API to get the hands on 
> `ASTWorker::FileInputs.FS` and we're getting one now.
> Even though the current patch does not add such racy accesses, it certainly 
> makes it much easier to do it accidentally from the clients of `ASTWorker` in 
> the future (one just needs to access `getCurrentInputs().FS`).
> 
> The (not very) systematic way to prevent raciness that we use now is to 
> **not** protect the members which are potentially racy with locks and 
> document they are accessed only from a worker thread.
> Having a separate copy of the compile command is a small price to pay (both 
> in terms of performance and complexity) to avoid exposing non-thread-safe 
> members of `ASTWorker` in its public interface.
I don't think that makes a fundamental difference as `FileInputs.FS` is already 
racy. But if "public" API is the concern, we could simply restrict the scope of 
the API and make return `CompileCommand` only.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607



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

RE: r357877 - [clang-format] Fix bug https://bugs.llvm.org/show_bug.cgi?id=41413

[via cfe-commits]

Hi Owen,

FYI, putting a URL in the headline of the commit message takes up
space and doesn't really describe the fix to a casual reader. The
subject line of your Phabricator review looks like it would have
been perfectly fine to use for the commit as well.

Citing the bug in the body of the commit message is enough to let
people track down the original report, although even there we usually 
abbreviate it to 'PR' (so PR41413 in this example).

Thanks!
--paulr

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Owen Pan via cfe-commits
> Sent: Sunday, April 07, 2019 5:06 PM
> To: cfe-commits@lists.llvm.org
> Subject: r357877 - [clang-format] Fix bug
> https://bugs.llvm.org/show_bug.cgi?id=41413
> 
> Author: owenpan
> Date: Sun Apr  7 14:05:52 2019
> New Revision: 357877
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=357877=rev
> Log:
> [clang-format] Fix bug https://bugs.llvm.org/show_bug.cgi?id=41413
> 
> Differential Revision: https://reviews.llvm.org/D60374
> 
> Modified:
> cfe/trunk/lib/Format/ContinuationIndenter.cpp
> cfe/trunk/unittests/Format/FormatTest.cpp
> 
> Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=357877=357876
> =357877=diff
> ==
> 
> --- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
> +++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Sun Apr  7 14:05:52 2019
> @@ -945,18 +945,24 @@ unsigned ContinuationIndenter::getNewLin
>return State.Stack[State.Stack.size() - 2].LastSpace;
>  return State.FirstIndent;
>}
> -  // Indent a closing parenthesis at the previous level if followed by a
> semi or
> -  // opening brace. This allows indentations such as:
> +  // Indent a closing parenthesis at the previous level if followed by a
> semi,
> +  // const, or opening brace. This allows indentations such as:
>// foo(
>//   a,
>// );
> +  // int Foo::getter(
> +  // //
> +  // ) const {
> +  //   return foo;
> +  // }
>// function foo(
>//   a,
>// ) {
>//   code(); //
>// }
>if (Current.is(tok::r_paren) && State.Stack.size() > 1 &&
> -  (!Current.Next || Current.Next->isOneOf(tok::semi, tok::l_brace)))
> +  (!Current.Next ||
> +   Current.Next->isOneOf(tok::semi, tok::kw_const, tok::l_brace)))
>  return State.Stack[State.Stack.size() - 2].LastSpace;
>if (NextNonComment->is(TT_TemplateString) && NextNonComment-
> >closesScope())
>  return State.Stack[State.Stack.size() - 2].LastSpace;
> 
> Modified: cfe/trunk/unittests/Format/FormatTest.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=357877=357876=
> 357877=diff
> ==
> 
> --- cfe/trunk/unittests/Format/FormatTest.cpp (original)
> +++ cfe/trunk/unittests/Format/FormatTest.cpp Sun Apr  7 14:05:52 2019
> @@ -12822,6 +12822,24 @@ TEST_F(FormatTest, ConfigurableContinuat
>  format("int i = longFunction(arg);", SixIndent));
>  }
> 
> +TEST_F(FormatTest, WrappedClosingParenthesisIndent) {
> +  FormatStyle Style = getLLVMStyle();
> +  verifyFormat(
> +  "int Foo::getter(\n"
> +  "//\n"
> +  ") const {\n"
> +  "  return foo;\n"
> +  "}",
> +  Style);
> +  verifyFormat(
> +  "void Foo::setter(\n"
> +  "//\n"
> +  ") {\n"
> +  "  foo = 1;\n"
> +  "}",
> +  Style);
> +}
> +
>  TEST_F(FormatTest, SpacesInAngles) {
>FormatStyle Spaces = getLLVMStyle();
>Spaces.SpacesInAngles = true;
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D60561: [clang] fixing diagnostics of constexpr callstack

[Gauthier via Phabricator via cfe-commits]

Tyker added a comment.

@rsmith i don't think collecting theses values is expansive compared to 
evaluating the expression.
but i agree that we can disable the collection of these values when it isn't 
needed.


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

https://reviews.llvm.org/D60561



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

[PATCH] D60507: [clang-tidy] new check: bugprone-unhandled-self-assignment

[Tamás Zolnai via Phabricator via cfe-commits]

ztamas updated this revision to Diff 194925.
ztamas marked an inline comment as done.
ztamas added a comment.

Documentation fixes.


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

https://reviews.llvm.org/D60507

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/UnhandledSelfAssignmentCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/UnhandledSelfAssignmentCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-self-assignment.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-oop54-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/bugprone-unhandled-self-assignment.cpp

Index: clang-tools-extra/test/clang-tidy/bugprone-unhandled-self-assignment.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/bugprone-unhandled-self-assignment.cpp
@@ -0,0 +1,434 @@
+// RUN: %check_clang_tidy %s bugprone-unhandled-self-assignment %t
+
+namespace std {
+
+template 
+void swap(T x, T y) {
+}
+
+template 
+T &(T x) {
+}
+
+template 
+class unique_ptr {
+};
+
+template 
+class shared_ptr {
+};
+
+template 
+class weak_ptr {
+};
+
+template 
+class auto_ptr {
+};
+
+} // namespace std
+
+void assert(int expression){};
+
+///
+/// Test cases correctly caught by the check.
+
+class PtrField {
+public:
+  PtrField =(const PtrField );
+
+private:
+  int *p;
+};
+
+PtrField ::operator=(const PtrField ) {
+  // CHECK-MESSAGES: [[@LINE-1]]:21: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+  // ...
+  return *this;
+}
+
+// Class with an inline operator definition.
+class InlineDefinition {
+public:
+  InlineDefinition =(const InlineDefinition ) {
+// CHECK-MESSAGES: [[@LINE-1]]:21: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  int *p;
+};
+
+class UniquePtrField {
+public:
+  UniquePtrField =(const UniquePtrField ) {
+// CHECK-MESSAGES: [[@LINE-1]]:19: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  std::unique_ptr p;
+};
+
+class SharedPtrField {
+public:
+  SharedPtrField =(const SharedPtrField ) {
+// CHECK-MESSAGES: [[@LINE-1]]:19: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  std::shared_ptr p;
+};
+
+class WeakPtrField {
+public:
+  WeakPtrField =(const WeakPtrField ) {
+// CHECK-MESSAGES: [[@LINE-1]]:17: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  std::weak_ptr p;
+};
+
+class AutoPtrField {
+public:
+  AutoPtrField =(const AutoPtrField ) {
+// CHECK-MESSAGES: [[@LINE-1]]:17: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  std::auto_ptr p;
+};
+
+// Class with C array field.
+class CArrayField {
+public:
+  CArrayField =(const CArrayField ) {
+// CHECK-MESSAGES: [[@LINE-1]]:16: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  int array[256];
+};
+
+// Make sure to not ignore cases when the operator definition calls
+// a copy constructor of another class.
+class CopyConstruct {
+public:
+  CopyConstruct =(const CopyConstruct ) {
+// CHECK-MESSAGES: [[@LINE-1]]:18: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+WeakPtrField a;
+WeakPtrField b(a);
+// ...
+return *this;
+  }
+
+private:
+  int *p;
+};
+
+// Make sure to not ignore cases when the operator definition calls
+// a copy assignment operator of another class.
+class AssignOperator {
+public:
+  AssignOperator =(const AssignOperator ) {
+// CHECK-MESSAGES: [[@LINE-1]]:19: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+a.operator=(object.a);
+// ...
+return *this;
+  }
+
+private:
+  int *p;
+  WeakPtrField a;
+};
+
+///
+/// Test cases correctly ignored by the check.
+
+// Self-assignment is checked using the equality operator.
+class SelfCheck1 {
+public:
+  SelfCheck1 =(const SelfCheck1 ) {
+if (this == )
+  return *this;
+// ...
+return *this;
+  }
+
+private:
+  int *p;
+};
+
+class SelfCheck2 {
+public:
+  SelfCheck2 =(const SelfCheck2 ) {
+if ( == this)
+  return *this;
+

[PATCH] D60507: [clang-tidy] new check: bugprone-unhandled-self-assignment

[Tamás Zolnai via Phabricator via cfe-commits]

ztamas marked 13 inline comments as done.
ztamas added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-self-assignment.rst:10
+
+This check corresponds to the CERT C++ Coding Standard rule
+`OOP54-CPP. Gracefully handle self-copy assignment

aaron.ballman wrote:
> Eugene.Zelenko wrote:
> > alexfh wrote:
> > > JonasToth wrote:
> > > > It is worth an alias into the cert module. Please add this with this 
> > > > revision already.
> > > Please add a corresponding alias into the cert module.
> > See also other aliased checks for documentation examples.
> I kind of wonder whether we want it as an alias in the CERT module or just 
> move it into the CERT module directly (and maybe provide an alias to 
> bugprone, if we think the fp rate is reasonable enough).
Now, I just added a cert alias. I can move this check to cert module entirely 
if needed. In general, I prefer a meaningful name over a cert number, that's 
why it might be more useful to have also a bugprone prefixed check for this. 
And it seems to me cert checks used to be the aliases.



Comment at: 
clang-tools-extra/test/clang-tidy/bugprone-unhandled-self-assignment.cpp:351
+  int *p;
+};

JonasToth wrote:
> Please add tests with templated classes and self-assignment.
I tested with template classes, but TemplateCopyAndSwap test case, for example, 
was wrongly caught by the check. So I just changed the code to ignore template 
classes. I did not find any template class related catch either in LibreOffice 
or LLVM when I run the first version of this check, so we don't lose too much 
with ignoring template classes, I think.


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

https://reviews.llvm.org/D60507



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

[libunwind] r358301 - [NFC] Move the export attribute after extern "C".

[Nicolas Lesser via cfe-commits]

Author: rakete
Date: Fri Apr 12 11:34:19 2019
New Revision: 358301

URL: http://llvm.org/viewvc/llvm-project?rev=358301=rev
Log:
[NFC] Move the export attribute after extern "C".

Not all compilers support attributes before `extern "C"`. gcc is the main one
that doesn't support it.

Modified:
libunwind/trunk/src/config.h

Modified: libunwind/trunk/src/config.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/config.h?rev=358301=358300=358301=diff
==
--- libunwind/trunk/src/config.h (original)
+++ libunwind/trunk/src/config.h Fri Apr 12 11:34:19 2019
@@ -70,23 +70,22 @@
 #define _LIBUNWIND_WEAK_ALIAS(name, aliasname) 
\
   __asm__(".globl " SYMBOL_NAME(aliasname));   
\
   __asm__(SYMBOL_NAME(aliasname) " = " SYMBOL_NAME(name)); 
\
-  _LIBUNWIND_EXPORT
\
-  extern "C" __typeof(name) aliasname __attribute__((weak_import));
+  extern "C" _LIBUNWIND_EXPORT __typeof(name) aliasname
\
+  __attribute__((weak_import));
 #elif defined(__ELF__)
 #define _LIBUNWIND_WEAK_ALIAS(name, aliasname) 
\
-  _LIBUNWIND_EXPORT
\
-  extern "C" __typeof(name) aliasname __attribute__((weak, alias(#name)));
+  extern "C" _LIBUNWIND_EXPORT __typeof(name) aliasname
\
+  __attribute__((weak, alias(#name)));
 #elif defined(_WIN32)
 #if defined(__MINGW32__)
 #define _LIBUNWIND_WEAK_ALIAS(name, aliasname) 
\
-  _LIBUNWIND_EXPORT
\
-  extern "C" __typeof(name) aliasname __attribute__((alias(#name)));
+  extern "C" _LIBUNWIND_EXPORT __typeof(name) aliasname
\
+  __attribute__((alias(#name)));
 #else
 #define _LIBUNWIND_WEAK_ALIAS(name, aliasname) 
\
   __pragma(comment(linker, "/alternatename:" SYMBOL_NAME(aliasname) "="
\
  SYMBOL_NAME(name)))   
\
-  _LIBUNWIND_EXPORT \
-  extern "C" __typeof(name) aliasname;
+  extern "C" _LIBUNWIND_EXPORT __typeof(name) aliasname;
 #endif
 #else
 #error Unsupported target


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

[PATCH] D60507: [clang-tidy] new check: bugprone-unhandled-self-assignment

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-self-assignment.rst:6
+
+"cert-oop54-cpp" redirects here as an alias for this check.
+

Please use back-tick to highlight cert-oop54-cpp.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-self-assignment.rst:12
+
+This check corresponds to the CERT C++ Coding Standard rule
+`OOP54-CPP. Gracefully handle self-copy assignment

Should be removed, since it's in cert-oop54-cpp.rst now.


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

https://reviews.llvm.org/D60507



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

[PATCH] D60507: [clang-tidy] new check: bugprone-unhandled-self-assignment

[Tamás Zolnai via Phabricator via cfe-commits]

ztamas updated this revision to Diff 194921.
ztamas added a comment.

Updated the code based on reviewer comments:

- Alphabetical order in `BugproneTidyModule.cpp`
- Handling of `auto_ptr`
- Test cases for template classes (I made the check ignore these case otherwise 
this can lead to false positives)
- Added cert alias
- Simplified the matcher as requested (`hasAnyName()`, 
`has(ignoringParenCasts(cxxThisExpr())`
- Remove empty lines and synchronized the corresponding comment with the 
Release Notes.


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

https://reviews.llvm.org/D60507

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/UnhandledSelfAssignmentCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/UnhandledSelfAssignmentCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-self-assignment.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-oop54-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/bugprone-unhandled-self-assignment.cpp

Index: clang-tools-extra/test/clang-tidy/bugprone-unhandled-self-assignment.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/bugprone-unhandled-self-assignment.cpp
@@ -0,0 +1,434 @@
+// RUN: %check_clang_tidy %s bugprone-unhandled-self-assignment %t
+
+namespace std {
+
+template 
+void swap(T x, T y) {
+}
+
+template 
+T &(T x) {
+}
+
+template 
+class unique_ptr {
+};
+
+template 
+class shared_ptr {
+};
+
+template 
+class weak_ptr {
+};
+
+template 
+class auto_ptr {
+};
+
+} // namespace std
+
+void assert(int expression){};
+
+///
+/// Test cases correctly caught by the check.
+
+class PtrField {
+public:
+  PtrField =(const PtrField );
+
+private:
+  int *p;
+};
+
+PtrField ::operator=(const PtrField ) {
+  // CHECK-MESSAGES: [[@LINE-1]]:21: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+  // ...
+  return *this;
+}
+
+// Class with an inline operator definition.
+class InlineDefinition {
+public:
+  InlineDefinition =(const InlineDefinition ) {
+// CHECK-MESSAGES: [[@LINE-1]]:21: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  int *p;
+};
+
+class UniquePtrField {
+public:
+  UniquePtrField =(const UniquePtrField ) {
+// CHECK-MESSAGES: [[@LINE-1]]:19: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  std::unique_ptr p;
+};
+
+class SharedPtrField {
+public:
+  SharedPtrField =(const SharedPtrField ) {
+// CHECK-MESSAGES: [[@LINE-1]]:19: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  std::shared_ptr p;
+};
+
+class WeakPtrField {
+public:
+  WeakPtrField =(const WeakPtrField ) {
+// CHECK-MESSAGES: [[@LINE-1]]:17: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  std::weak_ptr p;
+};
+
+class AutoPtrField {
+public:
+  AutoPtrField =(const AutoPtrField ) {
+// CHECK-MESSAGES: [[@LINE-1]]:17: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  std::auto_ptr p;
+};
+
+// Class with C array field.
+class CArrayField {
+public:
+  CArrayField =(const CArrayField ) {
+// CHECK-MESSAGES: [[@LINE-1]]:16: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+// ...
+return *this;
+  }
+
+private:
+  int array[256];
+};
+
+// Make sure to not ignore cases when the operator definition calls
+// a copy constructor of another class.
+class CopyConstruct {
+public:
+  CopyConstruct =(const CopyConstruct ) {
+// CHECK-MESSAGES: [[@LINE-1]]:18: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+WeakPtrField a;
+WeakPtrField b(a);
+// ...
+return *this;
+  }
+
+private:
+  int *p;
+};
+
+// Make sure to not ignore cases when the operator definition calls
+// a copy assignment operator of another class.
+class AssignOperator {
+public:
+  AssignOperator =(const AssignOperator ) {
+// CHECK-MESSAGES: [[@LINE-1]]:19: warning: operator=() might not handle self-assignment properly [bugprone-unhandled-self-assignment]
+a.operator=(object.a);
+// ...
+return *this;
+  }
+
+private:
+  int *p;
+  WeakPtrField a;
+};
+
+///
+/// Test cases 

[PATCH] D40577: Clang support for simd functions

[Matt via Phabricator via cfe-commits]

mmasten marked 2 inline comments as done.
mmasten added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:9615
+
+  std::string Buffer;
+  if (Fn->hasFnAttribute("vector-variants")) {

ABataev wrote:
> 1. Why this change is required?
> 2. Why not a `SmallString`?
This change is required to more clearly indicate which function names represent 
simd function variants of the original scalar function. Previously, these 
function names were just represented as individual strings. Example: 
"_ZGVbM4l8__Z5add_1Pf", "_ZGVbN4l8__Z5add_1Pf", ... The attributes are now 
represented as a key/value pair: "vector-variants"="_ZGVbM4l8__Z5add_1Pf, 
_ZGVbN4l8__Z5add_1Pf, ...". Because the length of the string can now be quite a 
bit longer, I used std::string. Is SmallString still appropriate?



Comment at: clang/test/OpenMP/declare_simd_codegen.cpp:323
+
+// CHECK-NOT: _ZGV{{.+}}__Z1fRA_i
 

ABataev wrote:
> Hmm, a very strange update of the test, just quotes are removed and nothing 
> else.
I can probably change the test to be more explicit in checking for 
"vector-variants", if you think this would be better. The quotes were removed 
because of the change to the attribute formatting. E.g., the function names 
will no longer appear as individual strings, but as the key/value pair where 
all function names will now appear within a single string.


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

https://reviews.llvm.org/D40577



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

[PATCH] D60626: [clang] Aligned allocation is actually supported in macosx 10.13

[Louis Dionne via Phabricator via cfe-commits]

ldionne created this revision.
ldionne added a reviewer: ahatanak.
Herald added subscribers: cfe-commits, dexonsmith, jkorous.
Herald added a project: clang.

In r350649, I changed aligned allocation from being available starting
in macosx10.13 to macosx10.14. However, aligned allocation is indeed
available starting with macosx10.13, my investigation had been based
on the wrong libc++abi dylib.

This means that Clang before the fix will be more stringent when it
comes to aligned allocation -- it will not allow it when back-deploying
to macosx 10.13, when it would actually be safe to do so.

Note that a companion change will be coming to fix the libc++ tests.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D60626

Files:
  clang/include/clang/Basic/AlignedAllocation.h
  clang/test/Driver/unavailable_aligned_allocation.cpp
  clang/test/SemaCXX/unavailable_aligned_allocation.cpp


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.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 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 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.14 or newer}}}
-// expected-error@-17 {{aligned deallocation function of type 'void (void *, 
enum std::align_val_t) noexcept' is only available on macOS 10.14 or newer}}}
+// 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}}}
 #endif
 
 // expected-note@-20 2 {{if you supply your own aligned allocation functions}}
@@ -146,7 +146,7 @@
 // expected-error@-12 {{aligned deallocation function of type 'void (void *, 
enum std::align_val_t) noexcept' is only available on watchOS 4 or newer}}}
 // expected-note@-13 {{if you supply your own aligned allocation functions}}
 #else
-// expected-error@-15 {{aligned deallocation function of type 'void (void *, 
enum std::align_val_t) noexcept' is only available on macOS 10.14 or newer}}}
+// expected-error@-15 {{aligned deallocation function of type 'void (void *, 
enum std::align_val_t) noexcept' is only available on macOS 10.13 or newer}}}
 // expected-note@-16 {{if you supply your own aligned allocation functions}}
 #endif
 #endif
Index: clang/test/Driver/unavailable_aligned_allocation.cpp
===
--- clang/test/Driver/unavailable_aligned_allocation.cpp
+++ clang/test/Driver/unavailable_aligned_allocation.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang -target x86_64-apple-macosx10.13 -c -### %s 2>&1 \
+// RUN: %clang -target x86_64-apple-macosx10.12 -c -### %s 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=UNAVAILABLE
 //
 // RUN: %clang -target arm64-apple-ios10 -c -### %s 2>&1 \
@@ -24,7 +24,7 @@
 //
 // UNAVAILABLE: "-faligned-alloc-unavailable"
 
-// RUN: %clang -target x86_64-apple-macosx10.14 -c -### %s 2>&1 \
+// RUN: %clang -target x86_64-apple-macosx10.13 -c -### %s 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=AVAILABLE
 //
 // RUN: %clang -target arm64-apple-ios11 -c -### %s 2>&1 \
@@ -54,10 +54,10 @@
 // Check that passing -faligned-allocation or -fno-aligned-allocation stops the
 // driver from passing -faligned-alloc-unavailable to cc1.
 //
-// RUN: %clang -target x86_64-apple-macosx10.13 

[PATCH] D40577: Clang support for simd functions

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:9615
+
+  std::string Buffer;
+  if (Fn->hasFnAttribute("vector-variants")) {

1. Why this change is required?
2. Why not a `SmallString`?



Comment at: clang/test/OpenMP/declare_simd_codegen.cpp:323
+
+// CHECK-NOT: _ZGV{{.+}}__Z1fRA_i
 

Hmm, a very strange update of the test, just quotes are removed and nothing 
else.


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

https://reviews.llvm.org/D40577



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

[PATCH] D40577: Clang support for simd functions

[Matt via Phabricator via cfe-commits]

mmasten updated this revision to Diff 194917.
mmasten added a comment.

Rebased and updated test.


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

https://reviews.llvm.org/D40577

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/declare_simd_codegen.cpp

Index: clang/test/OpenMP/declare_simd_codegen.cpp
===
--- clang/test/OpenMP/declare_simd_codegen.cpp
+++ clang/test/OpenMP/declare_simd_codegen.cpp
@@ -132,194 +132,194 @@
 // CHECK-DAG: define {{.+}}@_Z3food(
 // CHECK-DAG: declare {{.+}}@_Z5add_2Pf(
 
-// CHECK-DAG: "_ZGVbM4l8__Z5add_1Pf"
-// CHECK-DAG: "_ZGVbN4l8__Z5add_1Pf"
-// CHECK-DAG: "_ZGVcM8l8__Z5add_1Pf"
-// CHECK-DAG: "_ZGVcN8l8__Z5add_1Pf"
-// CHECK-DAG: "_ZGVdM8l8__Z5add_1Pf"
-// CHECK-DAG: "_ZGVdN8l8__Z5add_1Pf"
-// CHECK-DAG: "_ZGVeM16l8__Z5add_1Pf"
-// CHECK-DAG: "_ZGVeN16l8__Z5add_1Pf"
-// CHECK-DAG: "_ZGVbM32v__Z5add_1Pf"
-// CHECK-DAG: "_ZGVcM32v__Z5add_1Pf"
-// CHECK-DAG: "_ZGVdM32v__Z5add_1Pf"
-// CHECK-DAG: "_ZGVeM32v__Z5add_1Pf"
-// CHECK-DAG: "_ZGVbN2v__Z5add_1Pf"
-// CHECK-DAG: "_ZGVcN4v__Z5add_1Pf"
-// CHECK-DAG: "_ZGVdN4v__Z5add_1Pf"
-// CHECK-DAG: "_ZGVeN8v__Z5add_1Pf"
-
-// CHECK-DAG: "_ZGVbM2va16va16vv__Z1hIiEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVbN2va16va16vv__Z1hIiEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVcM4va16va16vv__Z1hIiEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVcN4va16va16vv__Z1hIiEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVdM4va16va16vv__Z1hIiEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVdN4va16va16vv__Z1hIiEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVeM8va16va16vv__Z1hIiEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVeN8va16va16vv__Z1hIiEvPT_S1_S1_S1_"
-
-// CHECK-DAG: "_ZGVbM2va16va16vv__Z1hIfEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVbN2va16va16vv__Z1hIfEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVcM4va16va16vv__Z1hIfEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVcN4va16va16vv__Z1hIfEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVdM4va16va16vv__Z1hIfEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVdN4va16va16vv__Z1hIfEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVeM8va16va16vv__Z1hIfEvPT_S1_S1_S1_"
-// CHECK-DAG: "_ZGVeN8va16va16vv__Z1hIfEvPT_S1_S1_S1_"
-
-// CHECK-DAG: "_ZGVbM4uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVbN4uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVcM8uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVcN8uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVdM8uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVdN8uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVeM16uus1__ZN2VV3addEii"
-// CHECK-DAG: "_ZGVeN16uus1__ZN2VV3addEii"
-
-// CHECK-DAG: "_ZGVbM4lla16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVbN4lla16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVcM8lla16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVcN8lla16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVdM8lla16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVdN8lla16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVeM16lla16l4a4__ZN2VV6taddpfEPfRS0_"
-// CHECK-DAG: "_ZGVeN16lla16l4a4__ZN2VV6taddpfEPfRS0_"
-
-// CHECK-DAG: "_ZGVbM4vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVbN4vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVcM8vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVcN8vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVdM8vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVdN8vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVeM16vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVeN16vvl8__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVbM4vva8v__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVbN4vva8v__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVcM8vva8v__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVcN8vva8v__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVdM8vva8v__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVdN8vva8v__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVeM16vva8v__ZN2VV4taddERA_iRi"
-// CHECK-DAG: "_ZGVeN16vva8v__ZN2VV4taddERA_iRi"
-
-// CHECK-DAG: "_ZGVbM4vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-// CHECK-DAG: "_ZGVbN4vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-// CHECK-DAG: "_ZGVcM8vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-// CHECK-DAG: "_ZGVcN8vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-// CHECK-DAG: "_ZGVdM8vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-// CHECK-DAG: "_ZGVdN8vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-// CHECK-DAG: "_ZGVeM16vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-// CHECK-DAG: "_ZGVeN16vva32l16a16__ZN3TVVILi16EfE6taddpfEPfRS1_"
-
-// CHECK-DAG: "_ZGVbM4uu__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVbN4uu__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVcM8uu__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVcN8uu__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVdM8uu__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVdN8uu__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVeM16uu__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVeN16uu__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVbM4vv__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVbN4vv__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVcM8vv__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVcN8vv__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVdM8vv__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVdN8vv__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: "_ZGVeM16vv__ZN3TVVILi16EfE4taddEi"
-// CHECK-DAG: 

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clangd/TUScheduler.cpp:552
+const tooling::CompileCommand ::getCurrentCompileCommand() const {
+  return FileInputs.CompileCommand;
+}

ioeric wrote:
> ilya-biryukov wrote:
> > ioeric wrote:
> > > ilya-biryukov wrote:
> > > > ioeric wrote:
> > > > > ilya-biryukov wrote:
> > > > > > This is racy, `FileInputs` is only accessed from a worker thread 
> > > > > > now.
> > > > > > I'm afraid we'll need a separate variable with a lock around it 
> > > > > > (could reuse one lock for preamble and compile command, probably)
> > > > > It looks like we could also guard `FileInputs`? Adding another 
> > > > > variable seems to make the state more complicated. 
> > > > `FileInputs` are currently accessed without locks in a bunch of places 
> > > > and it'd be nice to keep it that way (the alternative is more 
> > > > complicated code).
> > > > Doing the same thing we do for preamble looks like the best alternative 
> > > > here.
> > > The reason I think it would be easier to guard `FileInputs` with mutex 
> > > instead of pulling a new variable is that CompileCommand is usually used 
> > > along with other fields in `FileInputs`.  I think we could manage this 
> > > with relatively few changes. Please take a look at the new changes.
> > Unfortunately we can't share `Inputs.FS` safely as the vfs implementations 
> > are not thread-safe.
> It seems to me that the behavior for `FS` hasn't change in this patch. And 
> `FileInputs` (incl. `Inputs.FS`) has always been available/shared across 
> worker threads. We don't seem to have systematic way to prevent raciness 
> before this patch, and it would be good to have it somehow, but it's probably 
> out of the scope.  
> 
> Maybe I'm missing something or misinterpreting. Could you elaborate?  
> And FileInputs (incl. Inputs.FS) has always been available/shared across 
> worker threads
I don't think that's the case, we did not a public API to get the hands on 
`ASTWorker::FileInputs.FS` and we're getting one now.
Even though the current patch does not add such racy accesses, it certainly 
makes it much easier to do it accidentally from the clients of `ASTWorker` in 
the future (one just needs to access `getCurrentInputs().FS`).

The (not very) systematic way to prevent raciness that we use now is to **not** 
protect the members which are potentially racy with locks and document they are 
accessed only from a worker thread.
Having a separate copy of the compile command is a small price to pay (both in 
terms of performance and complexity) to avoid exposing non-thread-safe members 
of `ASTWorker` in its public interface.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607



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

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Eric Liu via Phabricator via cfe-commits]

ioeric marked an inline comment as done.
ioeric added inline comments.



Comment at: clangd/TUScheduler.cpp:552
+const tooling::CompileCommand ::getCurrentCompileCommand() const {
+  return FileInputs.CompileCommand;
+}

ilya-biryukov wrote:
> ioeric wrote:
> > ilya-biryukov wrote:
> > > ioeric wrote:
> > > > ilya-biryukov wrote:
> > > > > This is racy, `FileInputs` is only accessed from a worker thread now.
> > > > > I'm afraid we'll need a separate variable with a lock around it 
> > > > > (could reuse one lock for preamble and compile command, probably)
> > > > It looks like we could also guard `FileInputs`? Adding another variable 
> > > > seems to make the state more complicated. 
> > > `FileInputs` are currently accessed without locks in a bunch of places 
> > > and it'd be nice to keep it that way (the alternative is more complicated 
> > > code).
> > > Doing the same thing we do for preamble looks like the best alternative 
> > > here.
> > The reason I think it would be easier to guard `FileInputs` with mutex 
> > instead of pulling a new variable is that CompileCommand is usually used 
> > along with other fields in `FileInputs`.  I think we could manage this with 
> > relatively few changes. Please take a look at the new changes.
> Unfortunately we can't share `Inputs.FS` safely as the vfs implementations 
> are not thread-safe.
It seems to me that the behavior for `FS` hasn't change in this patch. And 
`FileInputs` (incl. `Inputs.FS`) has always been available/shared across worker 
threads. We don't seem to have systematic way to prevent raciness before this 
patch, and it would be good to have it somehow, but it's probably out of the 
scope.  

Maybe I'm missing something or misinterpreting. Could you elaborate?  


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607



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

[PATCH] D60620: [HIP] Support -offloading-target-id

[Artem Belevich via Phabricator via cfe-commits]

tra added a subscriber: arsenm.
tra added a comment.

@arsenm Matt, FYI, this patch seems to be a continuation of D59863 
 you've commented on.


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

https://reviews.llvm.org/D60620



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

[PATCH] D60620: [HIP] Support -offloading-target-id

[Artem Belevich via Phabricator via cfe-commits]

tra added a subscriber: echristo.
tra added a comment.

It looks like you are solving two problems here.
a) you want to create multiple device passes for the same GPU, but with 
different options.
b) you may want to pass different compiler options to different device 
compilations.
The patch effectively hard-codes {gpu, options} tuple into 
--offloading-target-id variant.
Is that correct?

This looks essentially the same as your previous patch D59863 
.

We have a limited way to deal with (b), but there's currently no way to deal 
with (a).

For (a), I think, the real problem is that until now we've assumed that there's 
only one device-side compilation per target GPU arch. If we need multiple 
device-side compilations, we need a way to name them.  Using 
`offloading-target-id` as  a super-set of `--cuda-gpu-arch` is OK with me. 
However, I'm on the fence about the option serving a double-duty of setting 
magic compiler flags. On one hand, that's what driver does, so it may be OK. On 
the other hand, it's unnecessarily strict. I.e. if we provide ability to create 
multiple compilation passes for the same GPU arch, why limit that to only 
changing those hard-coded options? A general approach would allow a way to 
create more than one device-side compilation and provide arbitrary compiler 
options only to *that* compilation. Thiw will also help solving number of 
issues we have right now when some host-side compilation options break 
device-side compilation and we have to work around that by filtering out some 
of them in the driver.

A while back @echristo and I have discussed how it could be handled in a more 
generic way.
IIRC we ended up with a strawman proposal that looked roughly like this:

Currently we have rudimentary -Xarch_smXX options implemented for various 
toolchains in the driver.
E.g. for HIP: 
https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChains/HIP.cpp#L341
We want to generalize it and make it less awkward to use. One way to do it 
would be to introduce a `-Xarch TARGET` flag where the option(s) following the 
flag would apply only to the compilation for that particular target. `TARGET` 
could have special values like `HOST` and `DEVICE` and `ALL` which would widen 
the option scope to host/device/all compilation. The `-Xarch` flag could be 
either sticky (all following options are affected by it, until the next -Xarch 
option) or only affect one option (the way -X options work now). Make option 
parser aware of the current compilation target, and it should be fairly 
straightforward to control compilation options for particular target.

We could add `--offloading-target-id=X` to create and name a device-side 
compilation and then use that name in `-Xarch X` or `-Xtarget X` to pass 
appropriate options.
`--cuda-gpu-arch=GPU` would be treated as `--offloading-target-id=GPU -mcpu 
GPU`. If we had something like that, then your goal could be achieved with 
something like this:

  ... --offloading-target-id=foo -Xtarget foo -mcpu gfx906 
  ... --offloading-target-id=bar -Xtarget bar -mcpu gfx906 -mxnack -msram-ecc

We could also provide target aliases for the 'standard' offloading targets, so 
users do not have to type *all* options specific to the target, but would still 
have a way to override them.

This would also give us a flexible way to avoid passing some host-only options 
to device-side compilation without having to hard code every special case.

That may be a somewhat larger chunk of work.


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

https://reviews.llvm.org/D60620



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

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clangd/TUScheduler.cpp:552
+const tooling::CompileCommand ::getCurrentCompileCommand() const {
+  return FileInputs.CompileCommand;
+}

ioeric wrote:
> ilya-biryukov wrote:
> > ioeric wrote:
> > > ilya-biryukov wrote:
> > > > This is racy, `FileInputs` is only accessed from a worker thread now.
> > > > I'm afraid we'll need a separate variable with a lock around it (could 
> > > > reuse one lock for preamble and compile command, probably)
> > > It looks like we could also guard `FileInputs`? Adding another variable 
> > > seems to make the state more complicated. 
> > `FileInputs` are currently accessed without locks in a bunch of places and 
> > it'd be nice to keep it that way (the alternative is more complicated code).
> > Doing the same thing we do for preamble looks like the best alternative 
> > here.
> The reason I think it would be easier to guard `FileInputs` with mutex 
> instead of pulling a new variable is that CompileCommand is usually used 
> along with other fields in `FileInputs`.  I think we could manage this with 
> relatively few changes. Please take a look at the new changes.
Unfortunately we can't share `Inputs.FS` safely as the vfs implementations are 
not thread-safe.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607



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

[PATCH] D60408: [LibTooling] Extend Transformer to support multiple simultaneous changes.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

In D60408#1464364 , @ymandel wrote:

> I've done that as far as I can tell. Please let me know if I've missed 
> anything.


Many thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60408



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

[PATCH] D60408: [LibTooling] Extend Transformer to support multiple simultaneous changes.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang/include/clang/Tooling/Refactoring/Transformer.h:80
+// \endcode
+struct TextChange {
+  // The (bound) id of the node whose source will be replaced.  This id should

ymandel wrote:
> ilya-biryukov wrote:
> > `MatchChange` or something similar might be a better name.
> > This actually tries to change the matched AST node to a textual replacement.
> I chose this to contrast with an AST change.  The idea being that we're 
> specifying a replacement relative to source code locations (informed by the 
> ast). If we later, say, integrate with your library I could imagine 
> specifying changes to AST nodes.  But, maybe I'm overthinking... If we're 
> going to drop "text", what about "source?" be clearer than "text"? E.g, 
> `SourceChange` or (my preference) `SourceEdit`?
The reasons I find `TextChange` confusing is because I immediately think of 
something super-simple (a range of text + the replaced text), and I definitely 
don't think of the AST.

`SourceChange` and `SourceEdit` does not cause this confusion for me 
personally, so both look ok. Although they do look pretty similar.
Also, it's not actually a final edit, rather a description of it. So something 
like `EditDescription` could work too.



Comment at: clang/include/clang/Tooling/Refactoring/Transformer.h:87
+  TextGenerator Replacement;
+  TextGenerator Explanation;
+};

ymandel wrote:
> ilya-biryukov wrote:
> > I would've expected explanation to be the trait of the rewrite rule, since 
> > all changes have to be applied.
> > What's the reasoning behind having it at the level of separate changes? How 
> > would this explanation be used? For debugging purposes or displaying that 
> > to the user?
> I think that for most cases, one explanation sufficies for the whole 
> transformation. However, there are some tidies that emit multiple diagnoses 
> (for example if changing before a declaration and a definition).   Would it 
> help if I clarify in the comments?
Yeah, absolutely! Please document what it's used for and that would clear that 
up for me.
I actually thing that explaining every part of the transformation is probably 
too complicated, so most of the time you would want to have an explanation for 
the `RewriteRule`, not for each individual change.

The other challenge that I see is show to display these explanations to the 
user, i.e. how should the clients combine these explanations in order to get 
the full one? Should the `RewriteRule` have an explanation of the full 
transformation too?



Comment at: clang/include/clang/Tooling/Refactoring/Transformer.h:190
 struct Transformation {
+  // Trivial constructor to enable `emplace_back()` and the like.
+  Transformation(CharSourceRange Range, std::string Replacement)

NIT: I'd suggest just paying a few extra lines for initializing the struct 
instead of using the ctor.
```
Transformation T;
T.Range = ...;
T.Replacement = ...;

v.push_back(std::move(T));
```
or 
```
v.emplace_back();
v.back().Range = ...;
v.back().Replacement = ...;
```

But I can see why you might want a ctor instead. If you decide to leave it, 
consider re-adding the default ctor that got implicitly deleted as you defined 
this other one.



Comment at: clang/include/clang/Tooling/Refactoring/Transformer.h:204
+applyRewriteRule(const ast_matchers::MatchFinder::MatchResult ,
+ llvm::ArrayRef Changes);
 

Why would we change the interface here? Rewrite rule seemed like a perfect 
input to this function



Comment at: clang/lib/Tooling/Refactoring/Transformer.cpp:164
+  return SmallVector();
+Transformations.emplace_back(TargetRange, Change.Replacement(Result));
+  }

What if the changes intersect? I'd expect this function to handle this somehow, 
handling this is complicated and I feel we shouldn't rely on the clients to 
make it fast.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60408



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

Re: [clangd] Print template arguments helper

[Kadir Çetinkaya via cfe-commits]

Thanks Bruno, sent out rL358293 to address the issue.

On Fri, Apr 12, 2019 at 5:21 PM Bruno Ricci  wrote:

> Hi,
>
> It seems that one of r358272, r358273 or r358274 is causing some asan
> failure on my machine. Not sure why it is not spotted by the bots.
>
> Failure log attached.
>
> Bruno
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r358293 - [clangd] Fix an overflow inside a test

[Kadir Cetinkaya via cfe-commits]

Author: kadircet
Date: Fri Apr 12 09:40:54 2019
New Revision: 358293

URL: http://llvm.org/viewvc/llvm-project?rev=358293=rev
Log:
[clangd] Fix an overflow inside a test

Modified:
clang-tools-extra/trunk/unittests/clangd/PrintASTTests.cpp

Modified: clang-tools-extra/trunk/unittests/clangd/PrintASTTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/PrintASTTests.cpp?rev=358293=358292=358293=diff
==
--- clang-tools-extra/trunk/unittests/clangd/PrintASTTests.cpp (original)
+++ clang-tools-extra/trunk/unittests/clangd/PrintASTTests.cpp Fri Apr 12 
09:40:54 2019
@@ -37,6 +37,8 @@ TEST_P(ASTUtils, PrintTemplateArgs) {
   struct Visitor : RecursiveASTVisitor {
 Visitor(std::vector Points) : Points(std::move(Points)) {}
 bool VisitNamedDecl(const NamedDecl *ND) {
+  if (TemplateArgsAtPoints.size() == Points.size())
+return true;
   auto Pos = sourceLocToPosition(ND->getASTContext().getSourceManager(),
  ND->getLocation());
   if (Pos != Points[TemplateArgsAtPoints.size()])


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

[PATCH] D58579: [Sema] SequenceChecker: C++17 sequencing rule for call expression.

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added a comment.

Friendly ping.


Repository:
  rC Clang

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

https://reviews.llvm.org/D58579



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

[PATCH] D60513: [HIP] Use -mlink-builtin-bitcode to link device library

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL358290: [HIP] Use -mlink-builtin-bitcode to link device 
library (authored by yaxunl, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D60513?vs=194517=194904#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D60513

Files:
  cfe/trunk/lib/Driver/ToolChains/HIP.cpp
  cfe/trunk/test/Driver/hip-device-libs.hip
  cfe/trunk/test/Driver/hip-toolchain-no-rdc.hip
  cfe/trunk/test/Driver/hip-toolchain-rdc.hip

Index: cfe/trunk/test/Driver/hip-toolchain-rdc.hip
===
--- cfe/trunk/test/Driver/hip-toolchain-rdc.hip
+++ cfe/trunk/test/Driver/hip-toolchain-rdc.hip
@@ -18,6 +18,7 @@
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu" {{.*}} "-target-cpu" "gfx803"
 // CHECK-SAME: "-fcuda-is-device" "-fgpu-rdc" "-fvisibility" "hidden"
 // CHECK-SAME: "-fapply-global-visibility-to-externs"
+// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: {{.*}} "-o" [[A_BC:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC:".*a.cu"]]
 
@@ -27,11 +28,11 @@
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip" {{.*}} "-target-cpu" "gfx803"
 // CHECK-SAME: "-fcuda-is-device" "-fgpu-rdc" "-fvisibility" "hidden"
 // CHECK-SAME: "-fapply-global-visibility-to-externs"
+// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: {{.*}} "-o" [[B_BC:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[B_SRC:".*b.hip"]]
 
 // CHECK: [[LLVM_LINK:"*.llvm-link"]] [[A_BC]] [[B_BC]]
-// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: "-o" [[LINKED_BC_DEV1:".*-gfx803-linked-.*bc"]]
 
 // CHECK: [[OPT:".*opt"]] [[LINKED_BC_DEV1]] "-mtriple=amdgcn-amd-amdhsa"
@@ -49,18 +50,21 @@
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu" {{.*}} "-target-cpu" "gfx900"
-// CHECK-SAME: "-fcuda-is-device" {{.*}} "-o" [[A_BC:".*bc"]] "-x" "hip"
+// CHECK-SAME: "-fcuda-is-device" "-fgpu-rdc"
+// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
+// CHECK-SAME: {{.*}} "-o" [[A_BC:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
 // CHECK: [[CLANG]] "-cc1" "-triple" "amdgcn-amd-amdhsa"
 // CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-emit-llvm-bc"
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip" {{.*}} "-target-cpu" "gfx900"
-// CHECK-SAME: "-fcuda-is-device" {{.*}} "-o" [[B_BC:".*bc"]] "-x" "hip"
+// CHECK-SAME: "-fcuda-is-device" "-fgpu-rdc"
+// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
+// CHECK-SAME: {{.*}} "-o" [[B_BC:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[B_SRC]]
 
 // CHECK: [[LLVM_LINK]] [[A_BC]] [[B_BC]]
-// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: "-o" [[LINKED_BC_DEV2:".*-gfx900-linked-.*bc"]]
 
 // CHECK: [[OPT]] [[LINKED_BC_DEV2]] "-mtriple=amdgcn-amd-amdhsa"
Index: cfe/trunk/test/Driver/hip-toolchain-no-rdc.hip
===
--- cfe/trunk/test/Driver/hip-toolchain-no-rdc.hip
+++ cfe/trunk/test/Driver/hip-toolchain-no-rdc.hip
@@ -22,11 +22,11 @@
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu" {{.*}} "-target-cpu" "gfx803"
 // CHECK-SAME: "-fcuda-is-device" "-fvisibility" "hidden"
 // CHECK-SAME: "-fapply-global-visibility-to-externs"
+// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: {{.*}} "-o" [[A_BC_803:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC:".*a.cu"]]
 
 // CHECK: [[LLVM_LINK:"*.llvm-link"]] [[A_BC_803]]
-// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: "-o" [[LINKED_BC_DEV_A_803:".*-gfx803-linked-.*bc"]]
 
 // CHECK: [[OPT:".*opt"]] [[LINKED_BC_DEV_A_803]] "-mtriple=amdgcn-amd-amdhsa"
@@ -50,11 +50,11 @@
 // CHECK-SAME: {{.*}} "-main-file-name" "a.cu" {{.*}} "-target-cpu" "gfx900"
 // CHECK-SAME: "-fcuda-is-device" "-fvisibility" "hidden"
 // CHECK-SAME: "-fapply-global-visibility-to-externs"
+// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: {{.*}} "-o" [[A_BC_900:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[A_SRC]]
 
 // CHECK: [[LLVM_LINK:"*.llvm-link"]] [[A_BC_900]]
-// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: "-o" [[LINKED_BC_DEV_A_900:".*-gfx900-linked-.*bc"]]
 
 // CHECK: [[OPT:".*opt"]] [[LINKED_BC_DEV_A_900]] "-mtriple=amdgcn-amd-amdhsa"
@@ -94,11 +94,11 @@
 // CHECK-SAME: {{.*}} "-main-file-name" "b.hip" {{.*}} "-target-cpu" "gfx803"
 // CHECK-SAME: "-fcuda-is-device" "-fvisibility" "hidden"
 // CHECK-SAME: "-fapply-global-visibility-to-externs"
+// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: {{.*}} "-o" [[B_BC_803:".*bc"]] "-x" "hip"
 // CHECK-SAME: {{.*}} [[B_SRC:".*b.hip"]]
 
 // CHECK: [[LLVM_LINK:"*.llvm-link"]] [[B_BC_803]]
-// CHECK-SAME: "{{.*}}lib1.bc" "{{.*}}lib2.bc"
 // CHECK-SAME: "-o" [[LINKED_BC_DEV_B_803:".*-gfx803-linked-.*bc"]]
 
 

r358290 - [HIP] Use -mlink-builtin-bitcode to link device library

[Yaxun Liu via cfe-commits]

Author: yaxunl
Date: Fri Apr 12 09:23:31 2019
New Revision: 358290

URL: http://llvm.org/viewvc/llvm-project?rev=358290=rev
Log:
[HIP] Use -mlink-builtin-bitcode to link device library

Use -mlink-builtin-bitcode instead of llvm-link to link
device library so that device library bitcode and user
device code can be compiled in a consistent way.

This is the same approach used by CUDA and OpenMP.

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

Modified:
cfe/trunk/lib/Driver/ToolChains/HIP.cpp
cfe/trunk/test/Driver/hip-device-libs.hip
cfe/trunk/test/Driver/hip-toolchain-no-rdc.hip
cfe/trunk/test/Driver/hip-toolchain-rdc.hip

Modified: cfe/trunk/lib/Driver/ToolChains/HIP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/HIP.cpp?rev=358290=358289=358290=diff
==
--- cfe/trunk/lib/Driver/ToolChains/HIP.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/HIP.cpp Fri Apr 12 09:23:31 2019
@@ -31,7 +31,7 @@ using namespace llvm::opt;
 
 namespace {
 
-static void addBCLib(Compilation , const ArgList ,
+static void addBCLib(const Driver , const ArgList ,
  ArgStringList , ArgStringList LibraryPaths,
  StringRef BCName) {
   StringRef FullName;
@@ -40,11 +40,12 @@ static void addBCLib(Compilation , con
 llvm::sys::path::append(Path, BCName);
 FullName = Path;
 if (llvm::sys::fs::exists(FullName)) {
+  CmdArgs.push_back("-mlink-builtin-bitcode");
   CmdArgs.push_back(Args.MakeArgString(FullName));
   return;
 }
   }
-  C.getDriver().Diag(diag::err_drv_no_such_file) << BCName;
+  D.Diag(diag::err_drv_no_such_file) << BCName;
 }
 
 } // namespace
@@ -58,44 +59,6 @@ const char *AMDGCN::Linker::constructLLV
   for (const auto  : Inputs)
 CmdArgs.push_back(II.getFilename());
 
-  ArgStringList LibraryPaths;
-
-  // Find in --hip-device-lib-path and HIP_LIBRARY_PATH.
-  for (auto Path : Args.getAllArgValues(options::OPT_hip_device_lib_path_EQ))
-LibraryPaths.push_back(Args.MakeArgString(Path));
-
-  addDirectoryList(Args, LibraryPaths, "-L", "HIP_DEVICE_LIB_PATH");
-
-  llvm::SmallVector BCLibs;
-
-  // Add bitcode library in --hip-device-lib.
-  for (auto Lib : Args.getAllArgValues(options::OPT_hip_device_lib_EQ)) {
-BCLibs.push_back(Args.MakeArgString(Lib));
-  }
-
-  // If --hip-device-lib is not set, add the default bitcode libraries.
-  if (BCLibs.empty()) {
-// Get the bc lib file name for ISA version. For example,
-// gfx803 => oclc_isa_version_803.amdgcn.bc.
-std::string ISAVerBC =
-"oclc_isa_version_" + SubArchName.drop_front(3).str() + ".amdgcn.bc";
-
-llvm::StringRef FlushDenormalControlBC;
-if (Args.hasArg(options::OPT_fcuda_flush_denormals_to_zero))
-  FlushDenormalControlBC = "oclc_daz_opt_on.amdgcn.bc";
-else
-  FlushDenormalControlBC = "oclc_daz_opt_off.amdgcn.bc";
-
-BCLibs.append({"hip.amdgcn.bc", "opencl.amdgcn.bc",
-   "ocml.amdgcn.bc", "ockl.amdgcn.bc",
-   "oclc_finite_only_off.amdgcn.bc",
-   FlushDenormalControlBC,
-   "oclc_correctly_rounded_sqrt_on.amdgcn.bc",
-   "oclc_unsafe_math_off.amdgcn.bc", ISAVerBC});
-  }
-  for (auto Lib : BCLibs)
-addBCLib(C, Args, CmdArgs, LibraryPaths, Lib);
-
   // Add an intermediate output file.
   CmdArgs.push_back("-o");
   std::string TmpName =
@@ -324,6 +287,44 @@ void HIPToolChain::addClangTargetOptions
 CC1Args.append({"-fvisibility", "hidden"});
 CC1Args.push_back("-fapply-global-visibility-to-externs");
   }
+  ArgStringList LibraryPaths;
+
+  // Find in --hip-device-lib-path and HIP_LIBRARY_PATH.
+  for (auto Path :
+   DriverArgs.getAllArgValues(options::OPT_hip_device_lib_path_EQ))
+LibraryPaths.push_back(DriverArgs.MakeArgString(Path));
+
+  addDirectoryList(DriverArgs, LibraryPaths, "-L", "HIP_DEVICE_LIB_PATH");
+
+  llvm::SmallVector BCLibs;
+
+  // Add bitcode library in --hip-device-lib.
+  for (auto Lib : DriverArgs.getAllArgValues(options::OPT_hip_device_lib_EQ)) {
+BCLibs.push_back(DriverArgs.MakeArgString(Lib));
+  }
+
+  // If --hip-device-lib is not set, add the default bitcode libraries.
+  if (BCLibs.empty()) {
+// Get the bc lib file name for ISA version. For example,
+// gfx803 => oclc_isa_version_803.amdgcn.bc.
+std::string ISAVerBC =
+"oclc_isa_version_" + GpuArch.drop_front(3).str() + ".amdgcn.bc";
+
+llvm::StringRef FlushDenormalControlBC;
+if (DriverArgs.hasArg(options::OPT_fcuda_flush_denormals_to_zero))
+  FlushDenormalControlBC = "oclc_daz_opt_on.amdgcn.bc";
+else
+  FlushDenormalControlBC = "oclc_daz_opt_off.amdgcn.bc";
+
+BCLibs.append({"hip.amdgcn.bc", "opencl.amdgcn.bc", "ocml.amdgcn.bc",
+   "ockl.amdgcn.bc", "oclc_finite_only_off.amdgcn.bc",
+   FlushDenormalControlBC,
+   

[PATCH] D60274: [ELF] Implement Dependent Libraries Feature

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd added inline comments.



Comment at: lld/ELF/InputFiles.cpp:662
   }
+  case SHT_LLVM_DEPLIBS: {
+if (Config->Relocatable)

Can you make the flag here reflect the name as well?  
(`SHT_LLVM_DEPENDENT_LIBRARIES`)



Comment at: lld/ELF/Options.td:74
 
+defm deplibs: B<"deplibs",
+"Process dependent library specifiers from input files (default)",

I think that I prefer the `--dependent-libraries` flag which is similar to the 
recent additions to the linker options.


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

https://reviews.llvm.org/D60274



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

[PATCH] D59746: [CommandLineParser] Add DefaultOption flag

[Don Hinton via Phabricator via cfe-commits]

hintonda updated this revision to Diff 194899.
hintonda added a comment.

- Fix comments and add isDefaultOption per review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59746

Files:
  clang/lib/Tooling/CommonOptionsParser.cpp
  llvm/docs/CommandLine.rst
  llvm/include/llvm/Support/CommandLine.h
  llvm/lib/Support/CommandLine.cpp
  llvm/test/Support/check-default-options.txt
  llvm/tools/llvm-opt-report/OptReport.cpp
  llvm/unittests/Support/CommandLineTest.cpp

Index: llvm/unittests/Support/CommandLineTest.cpp
===
--- llvm/unittests/Support/CommandLineTest.cpp
+++ llvm/unittests/Support/CommandLineTest.cpp
@@ -620,6 +620,67 @@
   }
 }
 
+TEST(CommandLineTest, DefaultOptions) {
+  cl::ResetCommandLineParser();
+
+  StackOption Bar("bar", cl::sub(*cl::AllSubCommands),
+   cl::DefaultOption);
+  StackOption Bar_Alias(
+  "b", cl::desc("Alias for -bar"), cl::aliasopt(Bar), cl::DefaultOption);
+
+  StackOption Foo("foo", cl::init(false), cl::sub(*cl::AllSubCommands),
+cl::DefaultOption);
+  StackOption Foo_Alias("f", cl::desc("Alias for -foo"),
+ cl::aliasopt(Foo), cl::DefaultOption);
+
+  StackSubCommand SC1("sc1", "First Subcommand");
+  // Override "-b" and change type in sc1 SubCommand.
+  StackOption SC1_B("b", cl::sub(SC1), cl::init(false));
+  StackSubCommand SC2("sc2", "Second subcommand");
+  // Override "-foo" and change type in sc2 SubCommand.  Note that this does not
+  // affect "-f" alias, which continues to work correctly.
+  StackOption SC2_Foo("foo", cl::sub(SC2));
+
+  const char *args0[] = {"prog", "-b", "args0 bar string", "-f"};
+  EXPECT_TRUE(cl::ParseCommandLineOptions(sizeof(args0) / sizeof(char *), args0,
+  StringRef(), ::nulls()));
+  EXPECT_TRUE(Bar == "args0 bar string");
+  EXPECT_TRUE(Foo);
+  EXPECT_FALSE(SC1_B);
+  EXPECT_TRUE(SC2_Foo.empty());
+
+  cl::ResetAllOptionOccurrences();
+
+  const char *args1[] = {"prog", "sc1", "-b", "-bar", "args1 bar string", "-f"};
+  EXPECT_TRUE(cl::ParseCommandLineOptions(sizeof(args1) / sizeof(char *), args1,
+  StringRef(), ::nulls()));
+  EXPECT_TRUE(Bar == "args1 bar string");
+  EXPECT_TRUE(Foo);
+  EXPECT_TRUE(SC1_B);
+  EXPECT_TRUE(SC2_Foo.empty());
+  for (auto *S : cl::getRegisteredSubcommands()) {
+if (*S) {
+  EXPECT_EQ("sc1", S->getName());
+}
+  }
+
+  cl::ResetAllOptionOccurrences();
+
+  const char *args2[] = {"prog", "sc2", "-b", "args2 bar string",
+ "-f", "-foo", "foo string"};
+  EXPECT_TRUE(cl::ParseCommandLineOptions(sizeof(args2) / sizeof(char *), args2,
+  StringRef(), ::nulls()));
+  EXPECT_TRUE(Bar == "args2 bar string");
+  EXPECT_TRUE(Foo);
+  EXPECT_FALSE(SC1_B);
+  EXPECT_TRUE(SC2_Foo == "foo string");
+  for (auto *S : cl::getRegisteredSubcommands()) {
+if (*S) {
+  EXPECT_EQ("sc2", S->getName());
+}
+  }
+}
+
 TEST(CommandLineTest, ArgumentLimit) {
   std::string args(32 * 4096, 'a');
   EXPECT_FALSE(llvm::sys::commandLineFitsWithinSystemLimits("cl", args.data()));
Index: llvm/tools/llvm-opt-report/OptReport.cpp
===
--- llvm/tools/llvm-opt-report/OptReport.cpp
+++ llvm/tools/llvm-opt-report/OptReport.cpp
@@ -36,8 +36,6 @@
 using namespace llvm;
 using namespace llvm::yaml;
 
-static cl::opt Help("h", cl::desc("Alias for -help"), cl::Hidden);
-
 // Mark all our options with this category, everything else (except for -version
 // and -help) will be hidden.
 static cl::OptionCategory
@@ -440,11 +438,6 @@
   "A tool to generate an optimization report from YAML optimization"
   " record files.\n");
 
-  if (Help) {
-cl::PrintHelpMessage();
-return 0;
-  }
-
   LocationInfoTy LocationInfo;
   if (!readLocationInfo(LocationInfo))
 return 1;
Index: llvm/test/Support/check-default-options.txt
===
--- /dev/null
+++ llvm/test/Support/check-default-options.txt
@@ -0,0 +1,18 @@
+# RUN: llvm-objdump -help-hidden %t | FileCheck --check-prefix=CHECK-OBJDUMP %s
+# RUN: llvm-readobj -help-hidden %t | FileCheck --check-prefix=CHECK-READOBJ %s
+# RUN: llvm-tblgen -help-hidden %t | FileCheck --check-prefix=CHECK-TBLGEN %s
+# RUN: llvm-opt-report -help-hidden %t | FileCheck --check-prefix=CHECK-OPT-RPT %s
+# RUN: llvm-dwarfdump -help-hidden %t | FileCheck --check-prefix=CHECK-DWARF %s
+# RUN: llvm-dwarfdump -h %t | FileCheck --check-prefix=CHECK-DWARF-H %s
+
+
+# CHECK-OBJDUMP: -h  - Alias for --section-headers
+# CHECK-READOBJ: -h  - Alias for --file-headers
+# CHECK-TBLGEN:  -h  - Alias for -help
+# CHECK-OPT-RPT: -h  - Alias for -help
+# CHECK-DWARF:   -h  - Alias for 

[PATCH] D60620: [HIP] Support -offloading-target-id

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added reviewers: tra, b-sumner, ashi1, scchan, t-tye.
Herald added a subscriber: mgorny.

This patch introduces a new option -offloading-target-id for HIP.

Offloading target id is a generalization of CUDA/HIP GPU arch.
It is a device name plus optional feature strings delimited by
plus sign, e.g. gfx906+xnack+sram-ecc. GPU arch is the degenerated
case of offloading target id where there is no feature string. For
each device name, there is a limited number of predefined feature
strings which are allowed to show up in offloading target it. When
feature strings show up in offloading target id, they must follow
predefined order. Therefore offloading target id is a unique id
to convey device name and enabled target feature.

For each offloading target id, a device compilation will be performed
by the driver. If the device compilation results in a device object,
the offloading target id is used in the fat binary to uniquely identify
the device object. This is to allow runtime to load the device
object suitable for the device configuration.

This patches changes HIP action builder to handle -offloading-target-id
option. It generalizes GPUArchList in CUDA/HIP action builder so that
it can handle both CUDA GPU arch and HIP offloading target id. It changes
HIP toolchain to handle offloading target id as bound arch.

This patch is NFC for CUDA toolchain.


https://reviews.llvm.org/D60620

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/Basic/HIP.h
  include/clang/Driver/Options.td
  lib/Basic/CMakeLists.txt
  lib/Basic/HIP.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChains/HIP.cpp
  test/Driver/hip-invalid-offloading-target-id.hip
  test/Driver/hip-offloading-target-id.hip

Index: test/Driver/hip-offloading-target-id.hip
===
--- /dev/null
+++ test/Driver/hip-offloading-target-id.hip
@@ -0,0 +1,55 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang -### -target x86_64-linux-gnu \
+// RUN:   -x hip --offloading-target-id=gfx906 \
+// RUN:   --offloading-target-id=gfx906+xnack \
+// RUN:   --offloading-target-id=gfx906+xnack+sram-ecc \
+// RUN:   --hip-device-lib-path=%S/Inputs/hip_dev_lib \
+// RUN:   %s 2>&1 | FileCheck %s
+
+// CHECK: [[CLANG:".*clang.*"]] "-cc1" "-triple" "amdgcn-amd-amdhsa"
+// CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
+// CHECK-SAME: "-emit-llvm-bc"
+// CHECK-SAME: {{.*}} "-target-cpu" "gfx906" "-mno-xnack" "-mno-sram-ecc"
+
+// CHECK: [[OPT:".*opt"]] {{".*-gfx906-linked.*bc"}} "-mtriple=amdgcn-amd-amdhsa"
+// CHECK-SAME: "-mcpu=gfx906"
+// CHECK-SAME: "-o" [[OPT_906_BC:".*-gfx906-optimized.*bc"]]
+
+// CHECK: [[LLC: ".*llc"]] [[OPT_906_BC]]
+// CHECK-SAME: "-mtriple=amdgcn-amd-amdhsa" "-filetype=obj"
+// CHECK-SAME: {{.*}} "-mcpu=gfx906"
+// CHECK-SAME: "-o" {{".*-gfx906-.*o"}}
+
+// CHECK: [[CLANG]] "-cc1" "-triple" "amdgcn-amd-amdhsa"
+// CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
+// CHECK-SAME: "-emit-llvm-bc"
+// CHECK-SAME: {{.*}} "-target-cpu" "gfx906" "-mxnack" "-mno-sram-ecc"
+
+// CHECK: [[OPT]] {{".*-gfx906\+xnack.*bc"}} "-mtriple=amdgcn-amd-amdhsa"
+// CHECK-SAME: "-mcpu=gfx906"
+// CHECK-SAME: "-o" [[OPT_906XN_BC:".*-gfx906\+xnack.*bc"]]
+
+// CHECK: [[LLC]] [[OPT_906XN_BC]]
+// CHECK-SAME: "-mtriple=amdgcn-amd-amdhsa" "-filetype=obj"
+// CHECK-SAME: {{.*}} "-mcpu=gfx906"
+// CHECK-SAME: "-o" {{".*-gfx906\+xnack.*o"}}
+
+// CHECK: [[CLANG]] "-cc1" "-triple" "amdgcn-amd-amdhsa"
+// CHECK-SAME: "-aux-triple" "x86_64-unknown-linux-gnu"
+// CHECK-SAME: "-emit-llvm-bc"
+// CHECK-SAME: {{.*}} "-target-cpu" "gfx906" "-mxnack" "-msram-ecc"
+
+// CHECK: [[OPT]] {{".*-gfx906\+xnack\+sram-ecc.*bc"}} "-mtriple=amdgcn-amd-amdhsa"
+// CHECK-SAME: "-mcpu=gfx906"
+// CHECK-SAME: "-o" [[OPT_906XE_BC:".*-gfx906\+xnack\+sram-ecc.*bc"]]
+
+// CHECK: [[LLC]] [[OPT_906XE_BC]]
+// CHECK-SAME: "-mtriple=amdgcn-amd-amdhsa" "-filetype=obj"
+// CHECK-SAME: {{.*}} "-mcpu=gfx906"
+// CHECK-SAME: "-o" {{".*-gfx906\+xnack\+sram-ecc.*o"}}
+
+// CHECK: {{".*clang-offload-bundler"}}
+// CHECK-SAME: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa-gfx906,hip-amdgcn-amd-amdhsa-gfx906+xnack,hip-amdgcn-amd-amdhsa-gfx906+xnack+sram-ecc"
Index: test/Driver/hip-invalid-offloading-target-id.hip
===
--- /dev/null
+++ test/Driver/hip-invalid-offloading-target-id.hip
@@ -0,0 +1,48 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang -### -target x86_64-linux-gnu \
+// RUN:   -x hip --offloading-target-id=gfx906 \
+// RUN:   --offloading-target-id=gfx906xnack \
+// RUN:   --hip-device-lib-path=%S/Inputs/hip_dev_lib \
+// RUN:   %s 2>&1 | FileCheck -check-prefix=NOPLUS %s
+
+// NOPLUS: error: Invalid HIP offloading target id: gfx906xnack
+
+// RUN: %clang -### -target 

[PATCH] D60029: Add const children() accessors to all AST nodes.

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC358288: [AST][NFC] Add const children() accessors to all AST 
nodes (authored by brunoricci, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D60029?vs=193288=194897#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D60029

Files:
  include/clang/AST/Expr.h
  include/clang/AST/ExprCXX.h
  include/clang/AST/ExprObjC.h
  include/clang/AST/ExprOpenMP.h
  include/clang/AST/OpenMPClause.h
  include/clang/AST/Stmt.h
  include/clang/AST/StmtCXX.h
  include/clang/AST/StmtObjC.h
  include/clang/AST/StmtOpenMP.h
  lib/AST/ExprObjC.cpp
  lib/AST/Stmt.cpp

Index: include/clang/AST/ExprCXX.h
===
--- include/clang/AST/ExprCXX.h
+++ include/clang/AST/ExprCXX.h
@@ -587,6 +587,10 @@
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 /// The null pointer literal (C++11 [lex.nullptr])
@@ -616,6 +620,10 @@
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 /// Implicit construction of a std::initializer_list object from an
@@ -658,6 +666,10 @@
   }
 
   child_range children() { return child_range(,  + 1); }
+
+  const_child_range children() const {
+return const_child_range(,  + 1);
+  }
 };
 
 /// A C++ \c typeid expression (C++ [expr.typeid]), which gets
@@ -748,6 +760,15 @@
 auto **begin = reinterpret_cast();
 return child_range(begin, begin + 1);
   }
+
+  const_child_range children() const {
+if (isTypeOperand())
+  return const_child_range(const_child_iterator(), const_child_iterator());
+
+auto **begin =
+reinterpret_cast(_cast(this)->Operand);
+return const_child_range(begin, begin + 1);
+  }
 };
 
 /// A member reference to an MSPropertyDecl.
@@ -802,6 +823,11 @@
 return child_range((Stmt**), (Stmt**) + 1);
   }
 
+  const_child_range children() const {
+auto Children = const_cast(this)->children();
+return const_child_range(Children.begin(), Children.end());
+  }
+
   static bool classof(const Stmt *T) {
 return T->getStmtClass() == MSPropertyRefExprClass;
   }
@@ -877,6 +903,10 @@
   child_range children() {
 return child_range([0], [0] + NUM_SUBEXPRS);
   }
+
+  const_child_range children() const {
+return const_child_range([0], [0] + NUM_SUBEXPRS);
+  }
 };
 
 /// A Microsoft C++ @c __uuidof expression, which gets
@@ -958,6 +988,14 @@
 auto **begin = reinterpret_cast();
 return child_range(begin, begin + 1);
   }
+
+  const_child_range children() const {
+if (isTypeOperand())
+  return const_child_range(const_child_iterator(), const_child_iterator());
+auto **begin =
+reinterpret_cast(_cast(this)->Operand);
+return const_child_range(begin, begin + 1);
+  }
 };
 
 /// Represents the \c this expression in C++.
@@ -1004,6 +1042,10 @@
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 /// A C++ throw-expression (C++ [except.throw]).
@@ -1062,6 +1104,10 @@
   child_range children() {
 return child_range(, Operand ?  + 1 : );
   }
+
+  const_child_range children() const {
+return const_child_range(, Operand ?  + 1 : );
+  }
 };
 
 /// A default argument (C++ [dcl.fct.default]).
@@ -1123,6 +1169,10 @@
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 /// A use of a default initializer in a constructor or in aggregate
@@ -1178,6 +1228,10 @@
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 /// Represents a C++ temporary.
@@ -1255,6 +1309,10 @@
 
   // Iterators
   child_range children() { return child_range(,  + 1); }
+
+  const_child_range children() const {
+return const_child_range(,  + 1);
+  }
 };
 
 /// Represents a call to a C++ constructor.
@@ -1438,6 +1496,11 @@
   child_range children() {
 return child_range(getTrailingArgs(), getTrailingArgs() + getNumArgs());
   }
+
+  const_child_range children() const {
+auto Children = const_cast(this)->children();
+return const_child_range(Children.begin(), Children.end());
+  }
 };
 
 /// Represents a call to an inherited base class constructor from 

r358288 - [AST][NFC] Add const children() accessors to all AST nodes

[Bruno Ricci via cfe-commits]

Author: brunoricci
Date: Fri Apr 12 08:36:02 2019
New Revision: 358288

URL: http://llvm.org/viewvc/llvm-project?rev=358288=rev
Log:
[AST][NFC] Add const children() accessors to all AST nodes

Systematically add the const-qualified version of children()
to all statement/expression nodes. Previously the const-qualified
variant was only defined for some nodes. NFC.

Patch by: Nicolas Manichon

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

Reviewed By: riccibruno


Modified:
cfe/trunk/include/clang/AST/Expr.h
cfe/trunk/include/clang/AST/ExprCXX.h
cfe/trunk/include/clang/AST/ExprObjC.h
cfe/trunk/include/clang/AST/ExprOpenMP.h
cfe/trunk/include/clang/AST/OpenMPClause.h
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/include/clang/AST/StmtCXX.h
cfe/trunk/include/clang/AST/StmtObjC.h
cfe/trunk/include/clang/AST/StmtOpenMP.h
cfe/trunk/lib/AST/ExprObjC.cpp
cfe/trunk/lib/AST/Stmt.cpp

Modified: cfe/trunk/include/clang/AST/Expr.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Expr.h?rev=358288=358287=358288=diff
==
--- cfe/trunk/include/clang/AST/Expr.h (original)
+++ cfe/trunk/include/clang/AST/Expr.h Fri Apr 12 08:36:02 2019
@@ -1870,6 +1870,11 @@ public:
 return child_range(getTrailingObjects(),
getTrailingObjects() + hasFunctionName());
   }
+
+  const_child_range children() const {
+return const_child_range(getTrailingObjects(),
+ getTrailingObjects() + hasFunctionName());
+  }
 };
 
 /// ParenExpr - This represents a parethesized expression, e.g. "(1)".  This

Modified: cfe/trunk/include/clang/AST/ExprCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprCXX.h?rev=358288=358287=358288=diff
==
--- cfe/trunk/include/clang/AST/ExprCXX.h (original)
+++ cfe/trunk/include/clang/AST/ExprCXX.h Fri Apr 12 08:36:02 2019
@@ -587,6 +587,10 @@ public:
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 /// The null pointer literal (C++11 [lex.nullptr])
@@ -616,6 +620,10 @@ public:
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 /// Implicit construction of a std::initializer_list object from an
@@ -658,6 +666,10 @@ public:
   }
 
   child_range children() { return child_range(,  + 1); }
+
+  const_child_range children() const {
+return const_child_range(,  + 1);
+  }
 };
 
 /// A C++ \c typeid expression (C++ [expr.typeid]), which gets
@@ -748,6 +760,15 @@ public:
 auto **begin = reinterpret_cast();
 return child_range(begin, begin + 1);
   }
+
+  const_child_range children() const {
+if (isTypeOperand())
+  return const_child_range(const_child_iterator(), const_child_iterator());
+
+auto **begin =
+reinterpret_cast(_cast(this)->Operand);
+return const_child_range(begin, begin + 1);
+  }
 };
 
 /// A member reference to an MSPropertyDecl.
@@ -802,6 +823,11 @@ public:
 return child_range((Stmt**), (Stmt**) + 1);
   }
 
+  const_child_range children() const {
+auto Children = const_cast(this)->children();
+return const_child_range(Children.begin(), Children.end());
+  }
+
   static bool classof(const Stmt *T) {
 return T->getStmtClass() == MSPropertyRefExprClass;
   }
@@ -877,6 +903,10 @@ public:
   child_range children() {
 return child_range([0], [0] + NUM_SUBEXPRS);
   }
+
+  const_child_range children() const {
+return const_child_range([0], [0] + NUM_SUBEXPRS);
+  }
 };
 
 /// A Microsoft C++ @c __uuidof expression, which gets
@@ -958,6 +988,14 @@ public:
 auto **begin = reinterpret_cast();
 return child_range(begin, begin + 1);
   }
+
+  const_child_range children() const {
+if (isTypeOperand())
+  return const_child_range(const_child_iterator(), const_child_iterator());
+auto **begin =
+reinterpret_cast(_cast(this)->Operand);
+return const_child_range(begin, begin + 1);
+  }
 };
 
 /// Represents the \c this expression in C++.
@@ -1004,6 +1042,10 @@ public:
   child_range children() {
 return child_range(child_iterator(), child_iterator());
   }
+
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
 };
 
 /// A C++ throw-expression (C++ [except.throw]).
@@ -1062,6 +1104,10 @@ public:
   child_range children() {
 return child_range(, Operand ?  + 1 : );
   }
+
+  const_child_range children() const {
+return const_child_range(, Operand ?  + 1 : );
+  }
 };
 
 /// A default argument (C++ 

Re: [clangd] Print template arguments helper

[Bruno Ricci via cfe-commits]

Hi,

It seems that one of r358272, r358273 or r358274 is causing some asan
failure on my machine. Not sure why it is not spotted by the bots.

Failure log attached.

Bruno
FAIL: Extra Tools Unit Tests :: 
clangd/./ClangdTests/ASTUtilsTests/ASTUtils.PrintTemplateArgs/1 (878 of 1313)
 TEST 'Extra Tools Unit Tests :: 
clangd/./ClangdTests/ASTUtilsTests/ASTUtils.PrintTemplateArgs/1' FAILED 

Note: Google Test filter = ASTUtilsTests/ASTUtils.PrintTemplateArgs/1
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from ASTUtilsTests/ASTUtils
[ RUN  ] ASTUtilsTests/ASTUtils.PrintTemplateArgs/1
Preamble for file /clangd-test/TestTU.cpp cannot be reused. Attempting to 
rebuild it.
Built preamble of size 199084 for file /clangd-test/TestTU.cpp
=
==14611==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x602075a0 at pc 0x020df0e5 bp 0x7ffd01321e30 sp 0x7ffd01321e28
READ of size 4 at 0x602075a0 thread T0
#0 0x20df0e4 in __eq 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/tuple:1388:36
#1 0x20df0e4 in operator== /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/tuple:1421
#2 0x20df0e4 in operator== 
/home/bruno/software/llvm/tools/clang/tools/extra/clangd/Protocol.h:136
#3 0x20df0e4 in operator!= 
/home/bruno/software/llvm/tools/clang/tools/extra/clangd/Protocol.h:140
#4 0x20df0e4 in VisitNamedDecl 
/home/bruno/software/llvm/tools/clang/tools/extra/unittests/clangd/PrintASTTests.cpp:42
#5 0x20df0e4 in clang::RecursiveASTVisitor::WalkUpFromNamedDecl(clang::NamedDecl*)
 /mnt/data/llvm-asan-build/tools/clang/include/clang/AST/DeclNodes.inc:95
#6 0x20a7307 in WalkUpFromTypeDecl 
/mnt/data/llvm-asan-build/tools/clang/include/clang/AST/DeclNodes.inc:233:1
#7 0x20a7307 in WalkUpFromTemplateTypeParmDecl 
/mnt/data/llvm-asan-build/tools/clang/include/clang/AST/DeclNodes.inc:281
#8 0x20a7307 in TraverseTemplateTypeParmDecl 
/home/bruno/software/llvm/tools/clang/include/clang/AST/RecursiveASTVisitor.h:1770
#9 0x20a7307 in clang::RecursiveASTVisitor::TraverseDecl(clang::Decl*)
 /mnt/data/llvm-asan-build/tools/clang/include/clang/AST/DeclNodes.inc:281
#10 0x20a7685 in TraverseClassTemplatePartialSpecializationDecl 
/home/bruno/software/llvm/tools/clang/include/clang/AST/RecursiveASTVisitor.h:1910:1
#11 0x20a7685 in clang::RecursiveASTVisitor::TraverseDecl(clang::Decl*)
 /mnt/data/llvm-asan-build/tools/clang/include/clang/AST/DeclNodes.inc:259
#12 0x20ad76a in clang::RecursiveASTVisitor::TraverseDeclContextHelper(clang::DeclContext*)
 
/home/bruno/software/llvm/tools/clang/include/clang/AST/RecursiveASTVisitor.h:1387:7
#13 0x20a7116 in clang::RecursiveASTVisitor::TraverseDecl(clang::Decl*)
 /home/bruno/software/llvm/tools/clang/include/clang/AST/Decl.h
#14 0x20a5cf9 in clang::clangd::(anonymous 
namespace)::ASTUtils_PrintTemplateArgs_Test::TestBody() 
/home/bruno/software/llvm/tools/clang/tools/extra/unittests/clangd/PrintASTTests.cpp:51:5
#15 0x2d17dd8 in testing::Test::Run() 
/home/bruno/software/llvm/utils/unittest/googletest/src/gtest.cc
#16 0x2d1ca4a in testing::TestInfo::Run() 
/home/bruno/software/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
#17 0x2d1e280 in testing::TestCase::Run() 
/home/bruno/software/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
#18 0x2d37d9d in testing::internal::UnitTestImpl::RunAllTests() 
/home/bruno/software/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
#19 0x2d365b6 in testing::UnitTest::Run() 
/home/bruno/software/llvm/utils/unittest/googletest/src/gtest.cc
#20 0x2cfef66 in RUN_ALL_TESTS 
/home/bruno/software/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
#21 0x2cfef66 in main 
/home/bruno/software/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50
#22 0x7f04a1a8a09a in __libc_start_main 
/build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:308:16
#23 0x1f97029 in _start 
(/mnt/data/llvm-asan-build/tools/clang/tools/extra/unittests/clangd/ClangdTests+0x1f97029)

0x602075a0 is located 0 bytes to the right of 16-byte region 
[0x60207590,0x602075a0)
allocated by thread T0 here:
#0 0x20984c0 in operator new(unsigned long) 
(/mnt/data/llvm-asan-build/tools/clang/tools/extra/unittests/clangd/ClangdTests+0x20984c0)
#1 0x209ec66 in allocate 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/ext/new_allocator.h:111:27
#2 0x209ec66 in allocate 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/alloc_traits.h:436
#3 0x209ec66 in _M_allocate 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_vector.h:296
#4 0x209ec66 in _M_range_initialize 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_vector.h:1466
#5 0x209ec66 in _M_initialize_dispatch 

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Eric Liu via Phabricator via cfe-commits]

ioeric added inline comments.



Comment at: clangd/TUScheduler.cpp:338
+  Barrier(Barrier), Done(false) {
+  FileInputs.CompileCommand = CDB.getFallbackCommand(FileName);
+}

ilya-biryukov wrote:
> ioeric wrote:
> > ilya-biryukov wrote:
> > > The command is filled with a fallback by `ClangdServer`, right? Why do we 
> > > need to repeat this here?
> > `ASTWorker::FileInputs` is not set until ASTWorker runs update and gets 
> > compile command. Before that, `FileInputs` contains empty compile command 
> > that can be used by `runWithPreamble`/`runWithAST` (afaict). Initializing 
> > it to fallback command seems to be a better alternative.
> That makes sense. Could we remove the `getFallbackCommand` call from the 
> `ClangdServer::addDocument`?
> Let's make the `TUScheduler` fully responsible for the compile command.
Sounds good. 



Comment at: clangd/TUScheduler.cpp:552
+const tooling::CompileCommand ::getCurrentCompileCommand() const {
+  return FileInputs.CompileCommand;
+}

ilya-biryukov wrote:
> ioeric wrote:
> > ilya-biryukov wrote:
> > > This is racy, `FileInputs` is only accessed from a worker thread now.
> > > I'm afraid we'll need a separate variable with a lock around it (could 
> > > reuse one lock for preamble and compile command, probably)
> > It looks like we could also guard `FileInputs`? Adding another variable 
> > seems to make the state more complicated. 
> `FileInputs` are currently accessed without locks in a bunch of places and 
> it'd be nice to keep it that way (the alternative is more complicated code).
> Doing the same thing we do for preamble looks like the best alternative here.
The reason I think it would be easier to guard `FileInputs` with mutex instead 
of pulling a new variable is that CompileCommand is usually used along with 
other fields in `FileInputs`.  I think we could manage this with relatively few 
changes. Please take a look at the new changes.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607



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

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Eric Liu via Phabricator via cfe-commits]

ioeric updated this revision to Diff 194891.
ioeric marked 5 inline comments as done.
ioeric added a comment.

- address comments


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607

Files:
  clangd/ClangdServer.cpp
  clangd/ClangdServer.h
  clangd/Compiler.h
  clangd/GlobalCompilationDatabase.cpp
  clangd/TUScheduler.cpp
  clangd/TUScheduler.h
  unittests/clangd/ClangdTests.cpp
  unittests/clangd/CodeCompleteTests.cpp
  unittests/clangd/TUSchedulerTests.cpp

Index: unittests/clangd/TUSchedulerTests.cpp
===
--- unittests/clangd/TUSchedulerTests.cpp
+++ unittests/clangd/TUSchedulerTests.cpp
@@ -21,8 +21,6 @@
 namespace clangd {
 namespace {
 
-using ::testing::_;
-using ::testing::AllOf;
 using ::testing::AnyOf;
 using ::testing::Each;
 using ::testing::ElementsAre;
@@ -103,7 +101,7 @@
 TUSchedulerTests::DiagsCallbackKey;
 
 TEST_F(TUSchedulerTests, MissingFiles) {
-  TUScheduler S(getDefaultAsyncThreadsCount(),
+  TUScheduler S(CDB, getDefaultAsyncThreadsCount(),
 /*StorePreamblesInMemory=*/true, /*ASTCallbacks=*/nullptr,
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -154,7 +152,7 @@
 // thread until we've scheduled them all.
 Notification Ready;
 TUScheduler S(
-getDefaultAsyncThreadsCount(),
+CDB, getDefaultAsyncThreadsCount(),
 /*StorePreamblesInMemory=*/true, captureDiags(),
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -184,7 +182,7 @@
 TEST_F(TUSchedulerTests, Debounce) {
   std::atomic CallbackCount(0);
   {
-TUScheduler S(getDefaultAsyncThreadsCount(),
+TUScheduler S(CDB, getDefaultAsyncThreadsCount(),
   /*StorePreamblesInMemory=*/true, captureDiags(),
   /*UpdateDebounce=*/std::chrono::seconds(1),
   ASTRetentionPolicy());
@@ -220,7 +218,7 @@
   {
 Notification InconsistentReadDone; // Must live longest.
 TUScheduler S(
-getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
+CDB, getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
 /*ASTCallbacks=*/nullptr,
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -277,7 +275,7 @@
   {
 Notification Proceed; // Ensure we schedule everything.
 TUScheduler S(
-getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
+CDB, getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
 /*ASTCallbacks=*/captureDiags(),
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -346,7 +344,7 @@
 
   // Run TUScheduler and collect some stats.
   {
-TUScheduler S(getDefaultAsyncThreadsCount(),
+TUScheduler S(CDB, getDefaultAsyncThreadsCount(),
   /*StorePreamblesInMemory=*/true, captureDiags(),
   /*UpdateDebounce=*/std::chrono::milliseconds(50),
   ASTRetentionPolicy());
@@ -437,10 +435,11 @@
   std::atomic BuiltASTCounter(0);
   ASTRetentionPolicy Policy;
   Policy.MaxRetainedASTs = 2;
-  TUScheduler S(
-  /*AsyncThreadsCount=*/1, /*StorePreambleInMemory=*/true,
-  /*ASTCallbacks=*/nullptr,
-  /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(), Policy);
+  TUScheduler S(CDB,
+/*AsyncThreadsCount=*/1, /*StorePreambleInMemory=*/true,
+/*ASTCallbacks=*/nullptr,
+/*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
+Policy);
 
   llvm::StringLiteral SourceContents = R"cpp(
 int* a;
@@ -487,11 +486,11 @@
 }
 
 TEST_F(TUSchedulerTests, EmptyPreamble) {
-  TUScheduler S(
-  /*AsyncThreadsCount=*/4, /*StorePreambleInMemory=*/true,
-  /*ASTCallbacks=*/nullptr,
-  /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
-  ASTRetentionPolicy());
+  TUScheduler S(CDB,
+/*AsyncThreadsCount=*/4, /*StorePreambleInMemory=*/true,
+/*ASTCallbacks=*/nullptr,
+/*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
+ASTRetentionPolicy());
 
   auto Foo = testPath("foo.cpp");
   auto Header = testPath("foo.h");
@@ -532,11 +531,11 @@
 TEST_F(TUSchedulerTests, RunWaitsForPreamble) {
   // Testing strategy: we update the file and schedule a few preamble reads at
   // the same time. All reads should get the same non-null preamble.
-  TUScheduler S(
-  /*AsyncThreadsCount=*/4, /*StorePreambleInMemory=*/true,
-  /*ASTCallbacks=*/nullptr,
-  /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
-  ASTRetentionPolicy());
+  TUScheduler S(CDB,
+/*AsyncThreadsCount=*/4, /*StorePreambleInMemory=*/true,
+   

[PATCH] D60568: [OpenMP] Add support for registering requires directives with the runtime

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:473
+  /// atomic_default_mem_order seq_cst clause.
+  OMP_REQ_ATOMIC_DEFAULT_SEQ_CST  = 0x008,
+  /// atomic_default_mem_order acq_rel clause.

YOu don't need al these flags, add only target-specific.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:1254
+
+  HasRequiresUnifiedSharedMemory = false;
 }

No need to do this initialization here



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8978
+if (Clause->getClauseKind() == OMPC_unified_shared_memory) {
+  CGM.getOpenMPRuntime().HasRequiresUnifiedSharedMemory = true;
+  break;

Just `HasRequiresUnifiedSharedMemory = true;`



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:9045
+  // don't need to do anything.
+  if (CGM.getLangOpts().OpenMPIsDevice || OffloadEntriesInfoManager.empty())
+return nullptr;

Just add a check for OpenMPSimd mode here and do not emit anything in this case.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:9061
+//TODO: check for other requires clauses.
+if (HasRequiresUnifiedSharedMemory) {
+  Flags |= OMP_REQ_UNIFIED_SHARED_MEMORY;

No need for braces



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:9065
+CGF.EmitRuntimeCall(createRuntimeFunction(OMPRTL__tgt_register_requires),
+llvm::ConstantInt::get(CGF.CGM.Int64Ty, Flags));
+CGF.FinishFunction();

`CGF.CGM.Int64Ty`->`CGM.Int64Ty`



Comment at: lib/CodeGen/CGOpenMPRuntime.h:1438
+  /// requires directives was used in the current module.
+  virtual llvm::Function *emitRequiresDirectiveRegFun();
+

Why do you need this vertual funtion? I think static local is going to be enough



Comment at: lib/CodeGen/CodeGenModule.cpp:415
+OpenMPRuntime->emitRequiresDirectiveRegFun()) {
+  AddGlobalCtor(OpenMPRequiresDirectiveRegFun, 0, nullptr);
+}

You can remove the third `nullptr` argument


Repository:
  rC Clang

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

https://reviews.llvm.org/D60568



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

[PATCH] D60029: Add const children() accessors to all AST nodes.

[Nicolas Manichon via Phabricator via cfe-commits]

nicolas added a comment.

Yes, thank you very much!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60029



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

[PATCH] D60455: [SYCL] Add support for SYCL device attributes

[Alexey Bader via Phabricator via cfe-commits]

bader accepted this revision.
bader added inline comments.



Comment at: clang/test/SemaSYCL/device-attributes-on-non-sycl.cpp:5
+
+#if defined(EXPECT_WARNINGS)
+// expected-warning@+8 {{'sycl_kernel' attribute ignored}}

I think you can use `__SYCL_DEVICE_ONLY__` define instead.



Comment at: clang/test/SemaSYCL/device-attrubutes.cpp:8-11
+__attribute((sycl_kernel)) void foo();
+__attribute((sycl_device)) void foo1();
+[[clang::sycl_kernel]] void foo2();
+[[clang::sycl_device]] void foo3();

This duplicates clang/test/SemaSYCL/device-attributes-on-non-sycl.cpp.
Maybe it make sense to test case when both attributes are applied to the same 
function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60455



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

[PATCH] D60408: [LibTooling] Extend Transformer to support multiple simultaneous changes.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 194887.
ymandel added a comment.

Final code shifting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60408

Files:
  clang/include/clang/Tooling/Refactoring/Transformer.h
  clang/lib/Tooling/Refactoring/Transformer.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -13,36 +13,12 @@
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
-namespace clang {
-namespace tooling {
-namespace {
-using ast_matchers::anyOf;
-using ast_matchers::argumentCountIs;
-using ast_matchers::callee;
-using ast_matchers::callExpr;
-using ast_matchers::cxxMemberCallExpr;
-using ast_matchers::cxxMethodDecl;
-using ast_matchers::cxxRecordDecl;
-using ast_matchers::declRefExpr;
-using ast_matchers::expr;
-using ast_matchers::functionDecl;
-using ast_matchers::hasAnyName;
-using ast_matchers::hasArgument;
-using ast_matchers::hasDeclaration;
-using ast_matchers::hasElse;
-using ast_matchers::hasName;
-using ast_matchers::hasType;
-using ast_matchers::ifStmt;
-using ast_matchers::member;
-using ast_matchers::memberExpr;
-using ast_matchers::namedDecl;
-using ast_matchers::on;
-using ast_matchers::pointsTo;
-using ast_matchers::to;
-using ast_matchers::unless;
-
-using llvm::StringRef;
 
+using namespace clang;
+using namespace tooling;
+using namespace ast_matchers;
+
+namespace {
 constexpr char KHeaderContents[] = R"cc(
   struct string {
 string(const char*);
@@ -59,6 +35,9 @@
 PCFProto& GetProto();
   };
   }  // namespace proto
+  class Logger {};
+  void operator<<(Logger& l, string msg);
+  Logger& log(int level);
 )cc";
 
 static ast_matchers::internal::Matcher
@@ -141,18 +120,15 @@
 static RewriteRule ruleStrlenSize() {
   StringRef StringExpr = "strexpr";
   auto StringType = namedDecl(hasAnyName("::basic_string", "::string"));
-  return buildRule(
- callExpr(
- callee(functionDecl(hasName("strlen"))),
- hasArgument(0, cxxMemberCallExpr(
-on(expr(hasType(isOrPointsTo(StringType)))
-   .bind(StringExpr)),
-callee(cxxMethodDecl(hasName("c_str")))
-  // Specify the intended type explicitly, because the matcher "type" of
-  // `callExpr()` is `Stmt`, not `Expr`.
-  .as()
-  .replaceWith("REPLACED")
-  .because("Use size() method directly on string.");
+  return makeRule(
+  callExpr(callee(functionDecl(hasName("strlen"))),
+   hasArgument(0, cxxMemberCallExpr(
+  on(expr(hasType(isOrPointsTo(StringType)))
+ .bind(StringExpr)),
+  callee(cxxMethodDecl(hasName("c_str")),
+  changeRoot()
+  .to("REPLACED")
+  .because("Use size() method directly on string."));
 }
 
 TEST_F(TransformerTest, StrlenSize) {
@@ -181,15 +157,13 @@
 // Tests replacing an expression.
 TEST_F(TransformerTest, Flag) {
   StringRef Flag = "flag";
-  RewriteRule Rule =
-  buildRule(
-  cxxMemberCallExpr(on(expr(hasType(cxxRecordDecl(hasName(
-"proto::ProtoCommandLineFlag"
-   .bind(Flag)),
-unless(callee(cxxMethodDecl(hasName("GetProto"))
-  .change(Flag)
-  .replaceWith("EXPR")
-  .because("Use GetProto() to access proto fields.");
+  RewriteRule Rule = makeRule(
+  cxxMemberCallExpr(on(expr(hasType(cxxRecordDecl(
+hasName("proto::ProtoCommandLineFlag"
+   .bind(Flag)),
+unless(callee(cxxMethodDecl(hasName("GetProto"),
+  changeTextOf(Flag).to("EXPR").because(
+  "Use GetProto() to access proto fields."));
 
   std::string Input = R"cc(
 proto::ProtoCommandLineFlag flag;
@@ -207,9 +181,9 @@
 
 TEST_F(TransformerTest, NodePartNameNamedDecl) {
   StringRef Fun = "fun";
-  RewriteRule Rule = buildRule(functionDecl(hasName("bad")).bind(Fun))
- .change(Fun, NodePart::Name)
- .replaceWith("good");
+  RewriteRule Rule = makeRule(
+  functionDecl(hasName("bad")).bind(Fun),
+  changeTextOf(Fun, NodePart::Name).to("good"));
 
   std::string Input = R"cc(
 int bad(int x);
@@ -240,9 +214,8 @@
   )cc";
 
   StringRef Ref = "ref";
-  testRule(buildRule(declRefExpr(to(functionDecl(hasName("bad".bind(Ref))
-   .change(Ref, NodePart::Name)
-   .replaceWith("good"),
+  testRule(makeRule(declRefExpr(to(functionDecl(hasName("bad".bind(Ref),
+

[PATCH] D60408: [LibTooling] Extend Transformer to support multiple simultaneous changes.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

In D60408#1463909 , @ilya-biryukov 
wrote:

> Sorry for the delay.
>  There seem to be a few changes that are unrelated to the actual patch. Could 
> we separate various non-functional changes (moving code around, etc.) into a 
> separate change to keep the diff for this one minimal?


I've done that as far as I can tell. Please let me know if I've missed anything.




Comment at: clang/include/clang/Tooling/Refactoring/Transformer.h:80
+// \endcode
+struct TextChange {
+  // The (bound) id of the node whose source will be replaced.  This id should

ilya-biryukov wrote:
> `MatchChange` or something similar might be a better name.
> This actually tries to change the matched AST node to a textual replacement.
I chose this to contrast with an AST change.  The idea being that we're 
specifying a replacement relative to source code locations (informed by the 
ast). If we later, say, integrate with your library I could imagine specifying 
changes to AST nodes.  But, maybe I'm overthinking... If we're going to drop 
"text", what about "source?" be clearer than "text"? E.g, `SourceChange` or (my 
preference) `SourceEdit`?



Comment at: clang/include/clang/Tooling/Refactoring/Transformer.h:87
+  TextGenerator Replacement;
+  TextGenerator Explanation;
+};

ilya-biryukov wrote:
> I would've expected explanation to be the trait of the rewrite rule, since 
> all changes have to be applied.
> What's the reasoning behind having it at the level of separate changes? How 
> would this explanation be used? For debugging purposes or displaying that to 
> the user?
I think that for most cases, one explanation sufficies for the whole 
transformation. However, there are some tidies that emit multiple diagnoses 
(for example if changing before a declaration and a definition).   Would it 
help if I clarify in the comments?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60408



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

[PATCH] D60408: [LibTooling] Extend Transformer to support multiple simultaneous changes.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 194886.
ymandel added a comment.

More code movement (putting things back).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60408

Files:
  clang/include/clang/Tooling/Refactoring/Transformer.h
  clang/lib/Tooling/Refactoring/Transformer.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -13,36 +13,12 @@
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
-namespace clang {
-namespace tooling {
-namespace {
-using ast_matchers::anyOf;
-using ast_matchers::argumentCountIs;
-using ast_matchers::callee;
-using ast_matchers::callExpr;
-using ast_matchers::cxxMemberCallExpr;
-using ast_matchers::cxxMethodDecl;
-using ast_matchers::cxxRecordDecl;
-using ast_matchers::declRefExpr;
-using ast_matchers::expr;
-using ast_matchers::functionDecl;
-using ast_matchers::hasAnyName;
-using ast_matchers::hasArgument;
-using ast_matchers::hasDeclaration;
-using ast_matchers::hasElse;
-using ast_matchers::hasName;
-using ast_matchers::hasType;
-using ast_matchers::ifStmt;
-using ast_matchers::member;
-using ast_matchers::memberExpr;
-using ast_matchers::namedDecl;
-using ast_matchers::on;
-using ast_matchers::pointsTo;
-using ast_matchers::to;
-using ast_matchers::unless;
-
-using llvm::StringRef;
 
+using namespace clang;
+using namespace tooling;
+using namespace ast_matchers;
+
+namespace {
 constexpr char KHeaderContents[] = R"cc(
   struct string {
 string(const char*);
@@ -59,6 +35,9 @@
 PCFProto& GetProto();
   };
   }  // namespace proto
+  class Logger {};
+  void operator<<(Logger& l, string msg);
+  Logger& log(int level);
 )cc";
 
 static ast_matchers::internal::Matcher
@@ -141,18 +120,15 @@
 static RewriteRule ruleStrlenSize() {
   StringRef StringExpr = "strexpr";
   auto StringType = namedDecl(hasAnyName("::basic_string", "::string"));
-  return buildRule(
- callExpr(
- callee(functionDecl(hasName("strlen"))),
- hasArgument(0, cxxMemberCallExpr(
-on(expr(hasType(isOrPointsTo(StringType)))
-   .bind(StringExpr)),
-callee(cxxMethodDecl(hasName("c_str")))
-  // Specify the intended type explicitly, because the matcher "type" of
-  // `callExpr()` is `Stmt`, not `Expr`.
-  .as()
-  .replaceWith("REPLACED")
-  .because("Use size() method directly on string.");
+  return makeRule(
+  callExpr(callee(functionDecl(hasName("strlen"))),
+   hasArgument(0, cxxMemberCallExpr(
+  on(expr(hasType(isOrPointsTo(StringType)))
+ .bind(StringExpr)),
+  callee(cxxMethodDecl(hasName("c_str")),
+  changeRoot()
+  .to("REPLACED")
+  .because("Use size() method directly on string."));
 }
 
 TEST_F(TransformerTest, StrlenSize) {
@@ -181,15 +157,13 @@
 // Tests replacing an expression.
 TEST_F(TransformerTest, Flag) {
   StringRef Flag = "flag";
-  RewriteRule Rule =
-  buildRule(
-  cxxMemberCallExpr(on(expr(hasType(cxxRecordDecl(hasName(
-"proto::ProtoCommandLineFlag"
-   .bind(Flag)),
-unless(callee(cxxMethodDecl(hasName("GetProto"))
-  .change(Flag)
-  .replaceWith("EXPR")
-  .because("Use GetProto() to access proto fields.");
+  RewriteRule Rule = makeRule(
+  cxxMemberCallExpr(on(expr(hasType(cxxRecordDecl(
+hasName("proto::ProtoCommandLineFlag"
+   .bind(Flag)),
+unless(callee(cxxMethodDecl(hasName("GetProto"),
+  changeTextOf(Flag).to("EXPR").because(
+  "Use GetProto() to access proto fields."));
 
   std::string Input = R"cc(
 proto::ProtoCommandLineFlag flag;
@@ -207,9 +181,9 @@
 
 TEST_F(TransformerTest, NodePartNameNamedDecl) {
   StringRef Fun = "fun";
-  RewriteRule Rule = buildRule(functionDecl(hasName("bad")).bind(Fun))
- .change(Fun, NodePart::Name)
- .replaceWith("good");
+  RewriteRule Rule = makeRule(
+  functionDecl(hasName("bad")).bind(Fun),
+  changeTextOf(Fun, NodePart::Name).to("good"));
 
   std::string Input = R"cc(
 int bad(int x);
@@ -240,9 +214,8 @@
   )cc";
 
   StringRef Ref = "ref";
-  testRule(buildRule(declRefExpr(to(functionDecl(hasName("bad".bind(Ref))
-   .change(Ref, NodePart::Name)
-   .replaceWith("good"),
+  testRule(makeRule(declRefExpr(to(functionDecl(hasName("bad".bind(Ref),
+   

[PATCH] D60408: [LibTooling] Extend Transformer to support multiple simultaneous changes.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 194883.
ymandel marked 2 inline comments as done.
ymandel added a comment.

Restore code ordering for unrelated code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60408

Files:
  clang/include/clang/Tooling/Refactoring/Transformer.h
  clang/lib/Tooling/Refactoring/Transformer.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -13,36 +13,12 @@
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
-namespace clang {
-namespace tooling {
-namespace {
-using ast_matchers::anyOf;
-using ast_matchers::argumentCountIs;
-using ast_matchers::callee;
-using ast_matchers::callExpr;
-using ast_matchers::cxxMemberCallExpr;
-using ast_matchers::cxxMethodDecl;
-using ast_matchers::cxxRecordDecl;
-using ast_matchers::declRefExpr;
-using ast_matchers::expr;
-using ast_matchers::functionDecl;
-using ast_matchers::hasAnyName;
-using ast_matchers::hasArgument;
-using ast_matchers::hasDeclaration;
-using ast_matchers::hasElse;
-using ast_matchers::hasName;
-using ast_matchers::hasType;
-using ast_matchers::ifStmt;
-using ast_matchers::member;
-using ast_matchers::memberExpr;
-using ast_matchers::namedDecl;
-using ast_matchers::on;
-using ast_matchers::pointsTo;
-using ast_matchers::to;
-using ast_matchers::unless;
-
-using llvm::StringRef;
 
+using namespace clang;
+using namespace tooling;
+using namespace ast_matchers;
+
+namespace {
 constexpr char KHeaderContents[] = R"cc(
   struct string {
 string(const char*);
@@ -59,6 +35,9 @@
 PCFProto& GetProto();
   };
   }  // namespace proto
+  class Logger {};
+  void operator<<(Logger& l, string msg);
+  Logger& log(int level);
 )cc";
 
 static ast_matchers::internal::Matcher
@@ -141,18 +120,15 @@
 static RewriteRule ruleStrlenSize() {
   StringRef StringExpr = "strexpr";
   auto StringType = namedDecl(hasAnyName("::basic_string", "::string"));
-  return buildRule(
- callExpr(
- callee(functionDecl(hasName("strlen"))),
- hasArgument(0, cxxMemberCallExpr(
-on(expr(hasType(isOrPointsTo(StringType)))
-   .bind(StringExpr)),
-callee(cxxMethodDecl(hasName("c_str")))
-  // Specify the intended type explicitly, because the matcher "type" of
-  // `callExpr()` is `Stmt`, not `Expr`.
-  .as()
-  .replaceWith("REPLACED")
-  .because("Use size() method directly on string.");
+  return makeRule(
+  callExpr(callee(functionDecl(hasName("strlen"))),
+   hasArgument(0, cxxMemberCallExpr(
+  on(expr(hasType(isOrPointsTo(StringType)))
+ .bind(StringExpr)),
+  callee(cxxMethodDecl(hasName("c_str")),
+  changeRoot()
+  .to("REPLACED")
+  .because("Use size() method directly on string."));
 }
 
 TEST_F(TransformerTest, StrlenSize) {
@@ -181,15 +157,13 @@
 // Tests replacing an expression.
 TEST_F(TransformerTest, Flag) {
   StringRef Flag = "flag";
-  RewriteRule Rule =
-  buildRule(
-  cxxMemberCallExpr(on(expr(hasType(cxxRecordDecl(hasName(
-"proto::ProtoCommandLineFlag"
-   .bind(Flag)),
-unless(callee(cxxMethodDecl(hasName("GetProto"))
-  .change(Flag)
-  .replaceWith("EXPR")
-  .because("Use GetProto() to access proto fields.");
+  RewriteRule Rule = makeRule(
+  cxxMemberCallExpr(on(expr(hasType(cxxRecordDecl(
+hasName("proto::ProtoCommandLineFlag"
+   .bind(Flag)),
+unless(callee(cxxMethodDecl(hasName("GetProto"),
+  changeTextOf(Flag).to("EXPR").because(
+  "Use GetProto() to access proto fields."));
 
   std::string Input = R"cc(
 proto::ProtoCommandLineFlag flag;
@@ -207,9 +181,9 @@
 
 TEST_F(TransformerTest, NodePartNameNamedDecl) {
   StringRef Fun = "fun";
-  RewriteRule Rule = buildRule(functionDecl(hasName("bad")).bind(Fun))
- .change(Fun, NodePart::Name)
- .replaceWith("good");
+  RewriteRule Rule = makeRule(
+  functionDecl(hasName("bad")).bind(Fun),
+  changeTextOf(Fun, NodePart::Name).to("good"));
 
   std::string Input = R"cc(
 int bad(int x);
@@ -240,9 +214,8 @@
   )cc";
 
   StringRef Ref = "ref";
-  testRule(buildRule(declRefExpr(to(functionDecl(hasName("bad".bind(Ref))
-   .change(Ref, NodePart::Name)
-   .replaceWith("good"),
+  

[PATCH] D60455: [SYCL] Add support for SYCL device attributes

[Mariya Podchishchaeva via Phabricator via cfe-commits]

Fznamznon updated this revision to Diff 194878.
Fznamznon added a comment.

Applied comments from @aaron.ballman and @keryell

- Introduce a C++11 and C2x style spelling in the clang namespace I didn't find 
path to add two namespaces to attribute (like [[clang::sycl::device]] so 
[[clang::sycl_device]] spelling is added.
- Since both attributes have spellings and possible can be used as some 
"standard" outlining in Clang/LLVM I added documetation.
- Added more test cases.
- As @bader mentioned sycl_device can be used to mark functions, which are 
called from the different translation units so I added simple handling of this 
attribute in Sema.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60455

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/SemaSYCL/device-attributes-on-non-sycl.cpp
  clang/test/SemaSYCL/device-attrubutes.cpp

Index: clang/test/SemaSYCL/device-attrubutes.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/device-attrubutes.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -fsyntax-only -fsycl-is-device -verify %s
+
+[[clang::sycl_device]] int gv = 0;
+__attribute((sycl_device)) int gv1 = 0;
+[[clang::sycl_kernel]] int gv2 = 0; // expected-warning {{'sycl_kernel' attribute only applies to functions}}
+__attribute((sycl_kernel)) int gv3 = 0; // expected-warning {{'sycl_kernel' attribute only applies to functions}}
+
+__attribute((sycl_kernel)) void foo();
+__attribute((sycl_device)) void foo1();
+[[clang::sycl_kernel]] void foo2();
+[[clang::sycl_device]] void foo3();
+
+__attribute((sycl_kernel(1))) void foo(); // expected-error {{'sycl_kernel' attribute takes no arguments}}
+__attribute((sycl_device(1))) void foo1(); // expected-error {{'sycl_device' attribute takes no arguments}}
+[[clang::sycl_kernel(1)]] void foo2(); // expected-error {{'sycl_kernel' attribute takes no arguments}}
+[[clang::sycl_device(1)]] void foo3(); // expected-error {{'sycl_device' attribute takes no arguments}}
Index: clang/test/SemaSYCL/device-attributes-on-non-sycl.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/device-attributes-on-non-sycl.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -fsyntax-only -fsycl-is-device -verify %s
+// Now pretend that we're compiling a C++ file. There should be warnings.
+// RUN: %clang_cc1 -DEXPECT_WARNINGS -fsyntax-only -verify -x c++ %s
+
+#if defined(EXPECT_WARNINGS)
+// expected-warning@+8 {{'sycl_kernel' attribute ignored}}
+// expected-warning@+8 {{'sycl_device' attribute ignored}}
+// expected-warning@+8 {{'sycl_kernel' attribute ignored}}
+// expected-warning@+8 {{'sycl_device' attribute ignored}}
+#else
+// expected-no-diagnostics
+#endif
+
+__attribute((sycl_kernel)) void foo();
+__attribute((sycl_device)) void foo1();
+[[clang::sycl_kernel]] void foo2();
+[[clang::sycl_device]] void foo3();
+
Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -124,6 +124,8 @@
 // CHECK-NEXT: ReturnTypestate (SubjectMatchRule_function, SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: ReturnsNonNull (SubjectMatchRule_objc_method, SubjectMatchRule_function)
 // CHECK-NEXT: ReturnsTwice (SubjectMatchRule_function)
+// CHECK-NEXT: SYCLDevice (SubjectMatchRule_function, SubjectMatchRule_variable)
+// CHECK-NEXT: SYCLKernel (SubjectMatchRule_function)
 // CHECK-NEXT: ScopedLockable (SubjectMatchRule_record)
 // CHECK-NEXT: Section (SubjectMatchRule_function, SubjectMatchRule_variable_is_global, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property)
 // CHECK-NEXT: SetTypestate (SubjectMatchRule_function_is_member)
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -6755,6 +6755,12 @@
   case ParsedAttr::AT_Flatten:
 handleSimpleAttribute(S, D, AL);
 break;
+  case ParsedAttr::AT_SYCLDevice:
+handleSimpleAttribute(S, D, AL);
+break;
+  case ParsedAttr::AT_SYCLKernel:
+handleSimpleAttribute(S, D, AL);
+break;
   case ParsedAttr::AT_Format:
 handleFormatAttr(S, D, AL);
 break;
Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -253,6 +253,48 @@
   }];
 }
 
+def SYCLDeviceDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+The sycl_device attribute specifies function which is supposed to be 

[PATCH] D60570: [Sema] Add more tests for the behavior of argument-dependent name lookup

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno marked an inline comment as done.
riccibruno added inline comments.



Comment at: 
test/CXX/basic/basic.lookup/basic.lookup.argdep/p2-associated-namespaces-classes.cpp:304
+static_assert(f(g3) == 4, "");// FIXME: Also well-formed from the 
union rule.
+  // expected-error@-1 {{use of 
undeclared}}
+  }

Quuxplusone wrote:
> I see how `g3` matches the example in CWG997
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#997
> However, I don't see how CWG997's resolution actually affected this example 
> in the slightest. The wording inserted for CWG997 was, "Additionally, if the 
> aforementioned set of overloaded functions is named with a template-id, its 
> associated classes and namespaces are those of its type template-arguments 
> and its template template-arguments." That makes e.g.
> 
> f(g3)
> 
> consider `N::f`, because `N::S` is a "type template-argument" of the 
> template-id `g3` which names the set of overloaded functions.  But it 
> doesn't do anything at all to `f(g3)` because `g3` is not a template-id and 
> doesn't have any template-arguments.
> 
> This piece of ADL is implemented only by GCC (not EDG, Clang, or MSVC), and 
> personally I would very much like to keep it that way. We know there's no 
> real-world code that expects or relies on CWG997 — because such code would 
> never work in practice except on GCC. Let's keep it that way!  As soon as you 
> implement a crazy arcane rule, such that code _could_ portably rely on it, 
> code _will start_ relying on it... and then we'll never be able to simplify 
> the language.
> Case in point: the piece of ADL described in this blog post --
> https://quuxplusone.github.io/blog/2019/04/09/adl-insanity-round-2/
> As soon as the above-described arcane ADL rule was implemented in GCC and 
> Clang, Boost.Hana started relying on it; and now the rule is "locked in" to 
> the paper standard because there's real-world code relying on it.
> Personally I'd like to _keep_ real-world code from relying on CWG997, until 
> someone figures out what CWG was thinking when they added it.
I think that the relevant part of CWG 997 is the removal of the restriction on 
non-dependent parameter types. Sure, `g3` is not a `template-id`, but it refers 
to an overload set which contains the second `g3`, and one of the parameter of 
this second `g3` is `N::Q`.

I don't think this is a surprising rule. It matches the general intuition that 
for function types ADL is done based on the function parameter types and return 
type. Not having this rule introduces a difference between function templates 
and functions in overload sets. Consider https://godbolt.org/z/UXHqm2 :
```
namespace N {
struct S1 {};
template  struct S2 {};

void f(void (*g)());
}

void g1();  // #1
void g1(N::S1); // #2

void g2();  // #3
template  void g2(N::S2);// #4

void test() {
f(g1); // ok, g1 is #1
f(g2); // should be ok, g2 is #3
}
```


Repository:
  rC Clang

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

https://reviews.llvm.org/D60570



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

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clangd/TUScheduler.cpp:338
+  Barrier(Barrier), Done(false) {
+  FileInputs.CompileCommand = CDB.getFallbackCommand(FileName);
+}

ioeric wrote:
> ilya-biryukov wrote:
> > The command is filled with a fallback by `ClangdServer`, right? Why do we 
> > need to repeat this here?
> `ASTWorker::FileInputs` is not set until ASTWorker runs update and gets 
> compile command. Before that, `FileInputs` contains empty compile command 
> that can be used by `runWithPreamble`/`runWithAST` (afaict). Initializing it 
> to fallback command seems to be a better alternative.
That makes sense. Could we remove the `getFallbackCommand` call from the 
`ClangdServer::addDocument`?
Let's make the `TUScheduler` fully responsible for the compile command.



Comment at: clangd/TUScheduler.cpp:359
+if (auto Cmd = CDB.getCompileCommand(FileName))
+  Inputs.CompileCommand = *Cmd;
 // Will be used to check if we can avoid rebuilding the AST.

ioeric wrote:
> ilya-biryukov wrote:
> > Maybe update the heuristic field in the current compile command if its 
> > empty to indicate we're using an older command?
> > That might happen if a previous call to `getCompileCommand` succeeded (so 
> > the stored command does not have a heuristic set).
> If `CDB.getCompileCommand` failed, we would use `Inputs.CompileCommand` which 
> should be the fallback command set in ClangdServer. It might be a good idea 
> to use the old command, but it doesn't seem to be in the scope of this patch. 
> Added a `FIXME`.
Oh, I mixed `Inputs` and `FileInputs` in my head.
It feels reasonable to completely move the handling of compile command to 
`TUScheduler`, see the other comment at the constructor of `ASTWorker`.



Comment at: clangd/TUScheduler.cpp:552
+const tooling::CompileCommand ::getCurrentCompileCommand() const {
+  return FileInputs.CompileCommand;
+}

ioeric wrote:
> ilya-biryukov wrote:
> > This is racy, `FileInputs` is only accessed from a worker thread now.
> > I'm afraid we'll need a separate variable with a lock around it (could 
> > reuse one lock for preamble and compile command, probably)
> It looks like we could also guard `FileInputs`? Adding another variable seems 
> to make the state more complicated. 
`FileInputs` are currently accessed without locks in a bunch of places and it'd 
be nice to keep it that way (the alternative is more complicated code).
Doing the same thing we do for preamble looks like the best alternative here.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607



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

[PATCH] D59221: [asan] Add gcc 8's driver option -fsanitize=pointer-compare and -fsanitize=pointer-substract.

[pierre gousseau via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL358285: [asan] Add gcc 8s driver option 
-fsanitize=pointer-compare and… (authored by pgousseau, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D59221?vs=192447=194873#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D59221

Files:
  cfe/trunk/include/clang/Basic/Sanitizers.def
  cfe/trunk/include/clang/Driver/SanitizerArgs.h
  cfe/trunk/lib/Driver/SanitizerArgs.cpp
  cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp
  cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
  cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp
  cfe/trunk/lib/Driver/ToolChains/Fuchsia.cpp
  cfe/trunk/lib/Driver/ToolChains/Linux.cpp
  cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
  cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
  cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp
  cfe/trunk/lib/Driver/ToolChains/PS4CPU.cpp
  cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
  cfe/trunk/test/Driver/fsanitize.c

Index: cfe/trunk/lib/Driver/SanitizerArgs.cpp
===
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp
@@ -775,8 +775,27 @@
 Args.hasFlag(options::OPT_fsanitize_address_use_odr_indicator,
  options::OPT_fno_sanitize_address_use_odr_indicator,
  AsanUseOdrIndicator);
+
+if (AllAddedKinds & SanitizerKind::PointerCompare & ~AllRemove) {
+  AsanInvalidPointerCmp = true;
+}
+
+if (AllAddedKinds & SanitizerKind::PointerSubtract & ~AllRemove) {
+  AsanInvalidPointerSub = true;
+}
+
   } else {
 AsanUseAfterScope = false;
+// -fsanitize=pointer-compare/pointer-subtract requires -fsanitize=address.
+SanitizerMask DetectInvalidPointerPairs =
+SanitizerKind::PointerCompare | SanitizerKind::PointerSubtract;
+if (AllAddedKinds & DetectInvalidPointerPairs & ~AllRemove) {
+  TC.getDriver().Diag(clang::diag::err_drv_argument_only_allowed_with)
+  << lastArgumentForMask(D, Args,
+ SanitizerKind::PointerCompare |
+ SanitizerKind::PointerSubtract)
+  << "-fsanitize=address";
+}
   }
 
   if (AllAddedKinds & SanitizerKind::HWAddress) {
@@ -963,6 +982,16 @@
   if (AsanUseOdrIndicator)
 CmdArgs.push_back("-fsanitize-address-use-odr-indicator");
 
+  if (AsanInvalidPointerCmp) {
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back("-asan-detect-invalid-pointer-cmp");
+  }
+
+  if (AsanInvalidPointerSub) {
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back("-asan-detect-invalid-pointer-sub");
+  }
+
   if (!HwasanAbi.empty()) {
 CmdArgs.push_back("-default-function-attr");
 CmdArgs.push_back(Args.MakeArgString("hwasan-abi=" + HwasanAbi));
Index: cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp
+++ cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp
@@ -410,6 +410,8 @@
   const bool IsMIPS64 = getTriple().isMIPS64();
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::PointerCompare;
+  Res |= SanitizerKind::PointerSubtract;
   Res |= SanitizerKind::Vptr;
   if (IsX86_64 || IsMIPS64) {
 Res |= SanitizerKind::Leak;
Index: cfe/trunk/lib/Driver/ToolChains/Linux.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Linux.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Linux.cpp
@@ -1003,6 +1003,8 @@
  getTriple().getArch() == llvm::Triple::thumbeb;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::PointerCompare;
+  Res |= SanitizerKind::PointerSubtract;
   Res |= SanitizerKind::Fuzzer;
   Res |= SanitizerKind::FuzzerNoLink;
   Res |= SanitizerKind::KernelAddress;
Index: cfe/trunk/lib/Driver/ToolChains/Fuchsia.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Fuchsia.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Fuchsia.cpp
@@ -283,6 +283,8 @@
 SanitizerMask Fuchsia::getSupportedSanitizers() const {
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   Res |= SanitizerKind::Address;
+  Res |= SanitizerKind::PointerCompare;
+  Res |= SanitizerKind::PointerSubtract;
   Res |= SanitizerKind::Fuzzer;
   Res |= SanitizerKind::FuzzerNoLink;
   Res |= SanitizerKind::SafeStack;
Index: cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
+++ cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
@@ -459,6 +459,8 @@
 SanitizerMask toolchains::MinGW::getSupportedSanitizers() const {
   

[PATCH] D59221: [asan] Add gcc 8's driver option -fsanitize=pointer-compare and -fsanitize=pointer-substract.

[pierre gousseau via Phabricator via cfe-commits]

pgousseau marked an inline comment as done.
pgousseau added inline comments.



Comment at: test/Driver/fsanitize.c:837
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=pointer-compare 
-fno-sanitize=pointer-compare %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-NO-POINTER-CMP
+// CHECK-POINTER-ALL: 
"-cc1{{.*}}-fsanitize={{.*}}pointer-compare,pointer-subtract{{.*}}" {{.*}} 
"-mllvm" "-asan-detect-invalid-pointer-cmp" "-mllvm" 
"-asan-detect-invalid-pointer-sub"
+// CHECK-POINTER-CMP-NEEDS-ADDRESS: error: invalid argument 
'-fsanitize=pointer-compare' only allowed with '-fsanitize=address'

thakis wrote:
> Should some of these be {{[^"}*}} instead of {{.*}} so that the match isn't 
> accidentally across different flags?
Yes I should add one for the first check. Will add it thanks!


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

https://reviews.llvm.org/D59221



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

r358285 - [asan] Add gcc 8's driver option -fsanitize=pointer-compare and -fsanitize=pointer-substract.

[Pierre Gousseau via cfe-commits]

Author: pgousseau
Date: Fri Apr 12 07:14:58 2019
New Revision: 358285

URL: http://llvm.org/viewvc/llvm-project?rev=358285=rev
Log:
[asan] Add gcc 8's driver option -fsanitize=pointer-compare and 
-fsanitize=pointer-substract.

Disabled by default as this is still an experimental feature.

Reviewed By: thakis

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

Modified:
cfe/trunk/include/clang/Basic/Sanitizers.def
cfe/trunk/include/clang/Driver/SanitizerArgs.h
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp
cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
cfe/trunk/lib/Driver/ToolChains/FreeBSD.cpp
cfe/trunk/lib/Driver/ToolChains/Fuchsia.cpp
cfe/trunk/lib/Driver/ToolChains/Linux.cpp
cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
cfe/trunk/lib/Driver/ToolChains/NetBSD.cpp
cfe/trunk/lib/Driver/ToolChains/PS4CPU.cpp
cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
cfe/trunk/test/Driver/fsanitize.c

Modified: cfe/trunk/include/clang/Basic/Sanitizers.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Sanitizers.def?rev=358285=358284=358285=diff
==
--- cfe/trunk/include/clang/Basic/Sanitizers.def (original)
+++ cfe/trunk/include/clang/Basic/Sanitizers.def Fri Apr 12 07:14:58 2019
@@ -40,6 +40,12 @@
 // AddressSanitizer
 SANITIZER("address", Address)
 
+// Requires AddressSanitizer
+SANITIZER("pointer-compare", PointerCompare)
+
+// Requires AddressSanitizer
+SANITIZER("pointer-subtract", PointerSubtract)
+
 // Kernel AddressSanitizer (KASan)
 SANITIZER("kernel-address", KernelAddress)
 

Modified: cfe/trunk/include/clang/Driver/SanitizerArgs.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/SanitizerArgs.h?rev=358285=358284=358285=diff
==
--- cfe/trunk/include/clang/Driver/SanitizerArgs.h (original)
+++ cfe/trunk/include/clang/Driver/SanitizerArgs.h Fri Apr 12 07:14:58 2019
@@ -38,6 +38,8 @@ class SanitizerArgs {
   bool AsanPoisonCustomArrayCookie = false;
   bool AsanGlobalsDeadStripping = false;
   bool AsanUseOdrIndicator = false;
+  bool AsanInvalidPointerCmp = false;
+  bool AsanInvalidPointerSub = false;
   std::string HwasanAbi;
   bool LinkCXXRuntimes = false;
   bool NeedPIE = false;

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=358285=358284=358285=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Fri Apr 12 07:14:58 2019
@@ -775,8 +775,27 @@ SanitizerArgs::SanitizerArgs(const ToolC
 Args.hasFlag(options::OPT_fsanitize_address_use_odr_indicator,
  options::OPT_fno_sanitize_address_use_odr_indicator,
  AsanUseOdrIndicator);
+
+if (AllAddedKinds & SanitizerKind::PointerCompare & ~AllRemove) {
+  AsanInvalidPointerCmp = true;
+}
+
+if (AllAddedKinds & SanitizerKind::PointerSubtract & ~AllRemove) {
+  AsanInvalidPointerSub = true;
+}
+
   } else {
 AsanUseAfterScope = false;
+// -fsanitize=pointer-compare/pointer-subtract requires -fsanitize=address.
+SanitizerMask DetectInvalidPointerPairs =
+SanitizerKind::PointerCompare | SanitizerKind::PointerSubtract;
+if (AllAddedKinds & DetectInvalidPointerPairs & ~AllRemove) {
+  TC.getDriver().Diag(clang::diag::err_drv_argument_only_allowed_with)
+  << lastArgumentForMask(D, Args,
+ SanitizerKind::PointerCompare |
+ SanitizerKind::PointerSubtract)
+  << "-fsanitize=address";
+}
   }
 
   if (AllAddedKinds & SanitizerKind::HWAddress) {
@@ -963,6 +982,16 @@ void SanitizerArgs::addArgs(const ToolCh
   if (AsanUseOdrIndicator)
 CmdArgs.push_back("-fsanitize-address-use-odr-indicator");
 
+  if (AsanInvalidPointerCmp) {
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back("-asan-detect-invalid-pointer-cmp");
+  }
+
+  if (AsanInvalidPointerSub) {
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back("-asan-detect-invalid-pointer-sub");
+  }
+
   if (!HwasanAbi.empty()) {
 CmdArgs.push_back("-default-function-attr");
 CmdArgs.push_back(Args.MakeArgString("hwasan-abi=" + HwasanAbi));

Modified: cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp?rev=358285=358284=358285=diff
==
--- cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/CrossWindows.cpp Fri Apr 12 07:14:58 2019
@@ -277,6 +277,8 @@ AddCXXStdlibLibArgs(const 

[PATCH] D60123: [AST] Forbid copy/move of statements/types.

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC358283: [AST] Forbid copy/move of statements/types (authored 
by brunoricci, committed by ).

Repository:
  rC Clang

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

https://reviews.llvm.org/D60123

Files:
  include/clang/AST/Stmt.h
  include/clang/AST/Type.h


Index: include/clang/AST/Type.h
===
--- include/clang/AST/Type.h
+++ include/clang/AST/Type.h
@@ -1813,7 +1813,9 @@
   friend class ASTWriter;
 
   Type(const Type &) = delete;
+  Type(Type &&) = delete;
   Type =(const Type &) = delete;
+  Type =(Type &&) = delete;
 
   TypeClass getTypeClass() const { return static_cast(TypeBits.TC); 
}
 
Index: include/clang/AST/Stmt.h
===
--- include/clang/AST/Stmt.h
+++ include/clang/AST/Stmt.h
@@ -1042,6 +1042,11 @@
 return static_cast(StmtBits.sClass);
   }
 
+  Stmt(const Stmt &) = delete;
+  Stmt(Stmt &&) = delete;
+  Stmt =(const Stmt &) = delete;
+  Stmt =(Stmt &&) = delete;
+
   const char *getStmtClassName() const;
 
   bool isOMPStructuredBlock() const { return StmtBits.IsOMPStructuredBlock; }


Index: include/clang/AST/Type.h
===
--- include/clang/AST/Type.h
+++ include/clang/AST/Type.h
@@ -1813,7 +1813,9 @@
   friend class ASTWriter;
 
   Type(const Type &) = delete;
+  Type(Type &&) = delete;
   Type =(const Type &) = delete;
+  Type =(Type &&) = delete;
 
   TypeClass getTypeClass() const { return static_cast(TypeBits.TC); }
 
Index: include/clang/AST/Stmt.h
===
--- include/clang/AST/Stmt.h
+++ include/clang/AST/Stmt.h
@@ -1042,6 +1042,11 @@
 return static_cast(StmtBits.sClass);
   }
 
+  Stmt(const Stmt &) = delete;
+  Stmt(Stmt &&) = delete;
+  Stmt =(const Stmt &) = delete;
+  Stmt =(Stmt &&) = delete;
+
   const char *getStmtClassName() const;
 
   bool isOMPStructuredBlock() const { return StmtBits.IsOMPStructuredBlock; }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r358283 - [AST] Forbid copy/move of statements/types

[Bruno Ricci via cfe-commits]

Author: brunoricci
Date: Fri Apr 12 06:26:55 2019
New Revision: 358283

URL: http://llvm.org/viewvc/llvm-project?rev=358283=rev
Log:
[AST] Forbid copy/move of statements/types

Statements, expressions and types are not supposed to be copied/moved,
and trying to do so is only going to result in tears. Someone tripped
on this a few days ago on the mailing list. NFC.

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

Reviewed By: aaron.ballman


Modified:
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/include/clang/AST/Type.h

Modified: cfe/trunk/include/clang/AST/Stmt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Stmt.h?rev=358283=358282=358283=diff
==
--- cfe/trunk/include/clang/AST/Stmt.h (original)
+++ cfe/trunk/include/clang/AST/Stmt.h Fri Apr 12 06:26:55 2019
@@ -1042,6 +1042,11 @@ public:
 return static_cast(StmtBits.sClass);
   }
 
+  Stmt(const Stmt &) = delete;
+  Stmt(Stmt &&) = delete;
+  Stmt =(const Stmt &) = delete;
+  Stmt =(Stmt &&) = delete;
+
   const char *getStmtClassName() const;
 
   bool isOMPStructuredBlock() const { return StmtBits.IsOMPStructuredBlock; }

Modified: cfe/trunk/include/clang/AST/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=358283=358282=358283=diff
==
--- cfe/trunk/include/clang/AST/Type.h (original)
+++ cfe/trunk/include/clang/AST/Type.h Fri Apr 12 06:26:55 2019
@@ -1813,7 +1813,9 @@ public:
   friend class ASTWriter;
 
   Type(const Type &) = delete;
+  Type(Type &&) = delete;
   Type =(const Type &) = delete;
+  Type =(Type &&) = delete;
 
   TypeClass getTypeClass() const { return static_cast(TypeBits.TC); 
}
 


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

[PATCH] D60029: Add const children() accessors to all AST nodes.

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added a comment.

Sorry for the delay. Thanks a lot for the patch!

Some of these casts are rather questionable. However this has nothing to do 
with your patch since you are just adding the const-qualified version of 
`children()`. Therefore I believe this patch looks good. Do you want me to 
commit it for you ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60029



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

[PATCH] D60568: [OpenMP] Add support for registering requires directives with the runtime

[Alexandre Eichenberger via Phabricator via cfe-commits]

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

see note above; apologies if it is already done and hiding somewhere I did not 
see




Comment at: lib/CodeGen/CGOpenMPRuntime.h:641
+  /// directive is present.
+  bool HasRequiresUnifiedSharedMemory = false;
+

Don't you need a bool for each characteristics? Your intention is to have one 
bit vector for each characteristics that matter to the compiler?

Also, it is my belief that you need to record 2 states: 
unmaterialized (meaning I have not processed any target yet, so I should record 
any requires as they arrive)
finalized (I am processing a target, so the state is now fixed)

you need this in case you have an input like this:

declare target
int x
end declare target

requires unified memory

which is illegal


Repository:
  rC Clang

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

https://reviews.llvm.org/D60568



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

[PATCH] D60560: [clangd] Enable clang-tidy by default.

[Haojian Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL358282: [clangd] Enable clang-tidy by default. (authored by 
hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D60560?vs=194659=194858#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D60560

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


Index: clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
@@ -228,7 +228,7 @@
 static llvm::cl::opt EnableClangTidy(
 "clang-tidy",
 llvm::cl::desc("Enable clang-tidy diagnostics."),
-llvm::cl::init(false));
+llvm::cl::init(true));
 
 static llvm::cl::opt SuggestMissingIncludes(
 "suggest-missing-includes",


Index: clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
@@ -228,7 +228,7 @@
 static llvm::cl::opt EnableClangTidy(
 "clang-tidy",
 llvm::cl::desc("Enable clang-tidy diagnostics."),
-llvm::cl::init(false));
+llvm::cl::init(true));
 
 static llvm::cl::opt SuggestMissingIncludes(
 "suggest-missing-includes",
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r358282 - [clangd] Enable clang-tidy by default.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Fri Apr 12 06:07:48 2019
New Revision: 358282

URL: http://llvm.org/viewvc/llvm-project?rev=358282=rev
Log:
[clangd] Enable clang-tidy by default.

Summary:
We have turned on the flag internally for a while, and we don't receive 
complains.
Should be good to turn it on now.

If the projects doesn't have .clang-tidy files, no clang-tidy check will
be run.

Reviewers: sammccall

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

Tags: #clang

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

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

Modified: clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp?rev=358282=358281=358282=diff
==
--- clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp (original)
+++ clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp Fri Apr 12 06:07:48 2019
@@ -228,7 +228,7 @@ static llvm::cl::opt ClangT
 static llvm::cl::opt EnableClangTidy(
 "clang-tidy",
 llvm::cl::desc("Enable clang-tidy diagnostics."),
-llvm::cl::init(false));
+llvm::cl::init(true));
 
 static llvm::cl::opt SuggestMissingIncludes(
 "suggest-missing-includes",


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

[PATCH] D60605: [clangd] Revamp textDocument/onTypeFormatting.

[Sam McCall via Phabricator via cfe-commits]

sammccall updated this revision to Diff 194855.
sammccall added a comment.

Unit tests.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60605

Files:
  clangd/CMakeLists.txt
  clangd/ClangdLSPServer.cpp
  clangd/ClangdServer.cpp
  clangd/ClangdServer.h
  clangd/Format.cpp
  clangd/Format.h
  unittests/clangd/CMakeLists.txt
  unittests/clangd/FormatTests.cpp

Index: unittests/clangd/FormatTests.cpp
===
--- /dev/null
+++ unittests/clangd/FormatTests.cpp
@@ -0,0 +1,155 @@
+//===-- FormatTests.cpp - Automatic code formatting tests -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Format.h"
+#include "Annotations.h"
+#include "SourceCode.h"
+#include "TestFS.h"
+#include "clang/Format/Format.h"
+#include "clang/Tooling/Core/Replacement.h"
+#include "llvm/Support/Error.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace clangd {
+namespace {
+
+std::string afterTyped(llvm::StringRef CodeWithCursor,
+   llvm::StringRef Typed) {
+  Annotations Code(CodeWithCursor);
+  auto Cursor = llvm::cantFail(positionToOffset(Code.code(), Code.point()));
+  auto Changes =
+  formatIncremental(Code.code(), Cursor, Typed,
+format::getGoogleStyle(format::FormatStyle::LK_Cpp));
+  std::string NewCode =
+  cantFail(tooling::applyAllReplacements(Code.code(), Changes));
+  NewCode.insert(Changes.getShiftedCodePosition(Cursor), "^");
+  return NewCode;
+}
+
+// We can't pass raw strings directly to EXPECT_EQ because of gcc bugs.
+void expectAfterNewline(const char *Before, const char *After) {
+  EXPECT_EQ(After, afterTyped(Before, "\n")) << Before;
+}
+
+TEST(FormatIncremental, SplitComment) {
+  expectAfterNewline(R"cpp(
+// this comment was
+^split
+)cpp",
+   R"cpp(
+// this comment was
+// ^split
+)cpp");
+
+  expectAfterNewline(R"cpp(
+// trailing whitespace is not a split
+^   
+)cpp",
+   R"cpp(
+// trailing whitespace is not a split
+^
+)cpp");
+
+
+  expectAfterNewline(R"cpp(
+// extra   
+^ whitespace
+)cpp",
+   R"cpp(
+// extra
+// ^whitespace
+)cpp");
+
+  expectAfterNewline(R"cpp(
+/// triple
+^slash
+)cpp",
+   R"cpp(
+/// triple
+/// ^slash
+)cpp");
+
+  expectAfterNewline(R"cpp(
+int x;  // aligned
+^comment
+)cpp",
+   R"cpp(
+int x;  // aligned
+// ^comment
+)cpp");
+}
+
+TEST(FormatIncremental, Indentation) {
+  expectAfterNewline(R"cpp(
+void foo() {
+  if (bar)
+^
+)cpp",
+   R"cpp(
+void foo() {
+  if (bar)
+^
+)cpp");
+
+  expectAfterNewline(R"cpp(
+void foo() {
+  bar(baz(
+^
+)cpp",
+   R"cpp(
+void foo() {
+  bar(baz(
+  ^
+)cpp");
+
+  expectAfterNewline(R"cpp(
+class X {
+protected:
+^
+)cpp",
+   R"cpp(
+class X {
+ protected:
+  ^
+)cpp");
+}
+
+TEST(FormatIncremental, FormatPreviousLine) {
+  expectAfterNewline(R"cpp(
+void foo() {
+   untouched( );
+int x=2;
+^
+)cpp",
+ R"cpp(
+void foo() {
+   untouched( );
+   int x = 2;
+   ^
+)cpp");
+
+  expectAfterNewline(R"cpp(
+int x=untouched( );
+auto L = []{return;return;};
+^
+)cpp",
+   R"cpp(
+int x=untouched( );
+auto L = [] {
+  return;
+  return;
+};
+^
+)cpp");
+}
+
+} // namespace
+} // namespace clangd
+} // namespace clang
Index: unittests/clangd/CMakeLists.txt
===
--- unittests/clangd/CMakeLists.txt
+++ unittests/clangd/CMakeLists.txt
@@ -27,6 +27,7 @@
   FileDistanceTests.cpp
   FileIndexTests.cpp
   FindSymbolsTests.cpp
+  FormatTests.cpp
   FSTests.cpp
   FunctionTests.cpp
   FuzzyMatchTests.cpp
Index: clangd/Format.h
===
--- /dev/null
+++ clangd/Format.h
@@ -0,0 +1,45 @@
+//===--- Format.h - automatic code formatting ---*- C++-*--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// Clangd uses clang-format for formatting operations.
+// This file adapts it to support new scenarios like format-on-type.
+//
+//===--===//
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_FORMAT_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_FORMAT_H
+
+#include "Protocol.h"
+#include "clang/Format/Format.h"
+#include "llvm/ADT/StringRef.h"
+
+namespace clang {
+namespace clangd {
+
+/// Applies limited formatting around new \p InsertedText.
+/// The \p Code already 

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Eric Liu via Phabricator via cfe-commits]

ioeric added inline comments.



Comment at: clangd/TUScheduler.cpp:338
+  Barrier(Barrier), Done(false) {
+  FileInputs.CompileCommand = CDB.getFallbackCommand(FileName);
+}

ilya-biryukov wrote:
> The command is filled with a fallback by `ClangdServer`, right? Why do we 
> need to repeat this here?
`ASTWorker::FileInputs` is not set until ASTWorker runs update and gets compile 
command. Before that, `FileInputs` contains empty compile command that can be 
used by `runWithPreamble`/`runWithAST` (afaict). Initializing it to fallback 
command seems to be a better alternative.



Comment at: clangd/TUScheduler.cpp:359
+if (auto Cmd = CDB.getCompileCommand(FileName))
+  Inputs.CompileCommand = *Cmd;
 // Will be used to check if we can avoid rebuilding the AST.

ilya-biryukov wrote:
> Maybe update the heuristic field in the current compile command if its empty 
> to indicate we're using an older command?
> That might happen if a previous call to `getCompileCommand` succeeded (so the 
> stored command does not have a heuristic set).
If `CDB.getCompileCommand` failed, we would use `Inputs.CompileCommand` which 
should be the fallback command set in ClangdServer. It might be a good idea to 
use the old command, but it doesn't seem to be in the scope of this patch. 
Added a `FIXME`.



Comment at: clangd/TUScheduler.cpp:552
+const tooling::CompileCommand ::getCurrentCompileCommand() const {
+  return FileInputs.CompileCommand;
+}

ilya-biryukov wrote:
> This is racy, `FileInputs` is only accessed from a worker thread now.
> I'm afraid we'll need a separate variable with a lock around it (could reuse 
> one lock for preamble and compile command, probably)
It looks like we could also guard `FileInputs`? Adding another variable seems 
to make the state more complicated. 



Comment at: clangd/TUScheduler.cpp:835
 
 void TUScheduler::update(PathRef File, ParseInputs Inputs,
  WantDiagnostics WantDiags) {

ilya-biryukov wrote:
> We should add a comment that compile command in inputs is ignored.
> IMO even better is to accept an `FS` and `Contents` instead of `ParseInputs`.
Added commen. Unfortunately, `ParseInputs` contains other things like `Index` 
and `Opts`, so we couldn't replace it with FS and Contents.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607



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

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Eric Liu via Phabricator via cfe-commits]

ioeric updated this revision to Diff 194850.
ioeric marked 7 inline comments as done.
ioeric added a comment.

- address review comments


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607

Files:
  clangd/ClangdServer.cpp
  clangd/ClangdServer.h
  clangd/Compiler.h
  clangd/GlobalCompilationDatabase.cpp
  clangd/TUScheduler.cpp
  clangd/TUScheduler.h
  unittests/clangd/ClangdTests.cpp
  unittests/clangd/CodeCompleteTests.cpp
  unittests/clangd/TUSchedulerTests.cpp

Index: unittests/clangd/TUSchedulerTests.cpp
===
--- unittests/clangd/TUSchedulerTests.cpp
+++ unittests/clangd/TUSchedulerTests.cpp
@@ -21,8 +21,6 @@
 namespace clangd {
 namespace {
 
-using ::testing::_;
-using ::testing::AllOf;
 using ::testing::AnyOf;
 using ::testing::Each;
 using ::testing::ElementsAre;
@@ -103,7 +101,7 @@
 TUSchedulerTests::DiagsCallbackKey;
 
 TEST_F(TUSchedulerTests, MissingFiles) {
-  TUScheduler S(getDefaultAsyncThreadsCount(),
+  TUScheduler S(CDB, getDefaultAsyncThreadsCount(),
 /*StorePreamblesInMemory=*/true, /*ASTCallbacks=*/nullptr,
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -154,7 +152,7 @@
 // thread until we've scheduled them all.
 Notification Ready;
 TUScheduler S(
-getDefaultAsyncThreadsCount(),
+CDB, getDefaultAsyncThreadsCount(),
 /*StorePreamblesInMemory=*/true, captureDiags(),
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -184,7 +182,7 @@
 TEST_F(TUSchedulerTests, Debounce) {
   std::atomic CallbackCount(0);
   {
-TUScheduler S(getDefaultAsyncThreadsCount(),
+TUScheduler S(CDB, getDefaultAsyncThreadsCount(),
   /*StorePreamblesInMemory=*/true, captureDiags(),
   /*UpdateDebounce=*/std::chrono::seconds(1),
   ASTRetentionPolicy());
@@ -220,7 +218,7 @@
   {
 Notification InconsistentReadDone; // Must live longest.
 TUScheduler S(
-getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
+CDB, getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
 /*ASTCallbacks=*/nullptr,
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -277,7 +275,7 @@
   {
 Notification Proceed; // Ensure we schedule everything.
 TUScheduler S(
-getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
+CDB, getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
 /*ASTCallbacks=*/captureDiags(),
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -346,7 +344,7 @@
 
   // Run TUScheduler and collect some stats.
   {
-TUScheduler S(getDefaultAsyncThreadsCount(),
+TUScheduler S(CDB, getDefaultAsyncThreadsCount(),
   /*StorePreamblesInMemory=*/true, captureDiags(),
   /*UpdateDebounce=*/std::chrono::milliseconds(50),
   ASTRetentionPolicy());
@@ -437,10 +435,11 @@
   std::atomic BuiltASTCounter(0);
   ASTRetentionPolicy Policy;
   Policy.MaxRetainedASTs = 2;
-  TUScheduler S(
-  /*AsyncThreadsCount=*/1, /*StorePreambleInMemory=*/true,
-  /*ASTCallbacks=*/nullptr,
-  /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(), Policy);
+  TUScheduler S(CDB,
+/*AsyncThreadsCount=*/1, /*StorePreambleInMemory=*/true,
+/*ASTCallbacks=*/nullptr,
+/*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
+Policy);
 
   llvm::StringLiteral SourceContents = R"cpp(
 int* a;
@@ -487,11 +486,11 @@
 }
 
 TEST_F(TUSchedulerTests, EmptyPreamble) {
-  TUScheduler S(
-  /*AsyncThreadsCount=*/4, /*StorePreambleInMemory=*/true,
-  /*ASTCallbacks=*/nullptr,
-  /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
-  ASTRetentionPolicy());
+  TUScheduler S(CDB,
+/*AsyncThreadsCount=*/4, /*StorePreambleInMemory=*/true,
+/*ASTCallbacks=*/nullptr,
+/*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
+ASTRetentionPolicy());
 
   auto Foo = testPath("foo.cpp");
   auto Header = testPath("foo.h");
@@ -532,11 +531,11 @@
 TEST_F(TUSchedulerTests, RunWaitsForPreamble) {
   // Testing strategy: we update the file and schedule a few preamble reads at
   // the same time. All reads should get the same non-null preamble.
-  TUScheduler S(
-  /*AsyncThreadsCount=*/4, /*StorePreambleInMemory=*/true,
-  /*ASTCallbacks=*/nullptr,
-  /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
-  ASTRetentionPolicy());
+  TUScheduler S(CDB,
+/*AsyncThreadsCount=*/4, 

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Eric Liu via Phabricator via cfe-commits]

ioeric updated this revision to Diff 194851.
ioeric added a comment.

- Add missing comment to TUScheduler.h


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607

Files:
  clangd/ClangdServer.cpp
  clangd/ClangdServer.h
  clangd/Compiler.h
  clangd/GlobalCompilationDatabase.cpp
  clangd/TUScheduler.cpp
  clangd/TUScheduler.h
  unittests/clangd/ClangdTests.cpp
  unittests/clangd/CodeCompleteTests.cpp
  unittests/clangd/TUSchedulerTests.cpp

Index: unittests/clangd/TUSchedulerTests.cpp
===
--- unittests/clangd/TUSchedulerTests.cpp
+++ unittests/clangd/TUSchedulerTests.cpp
@@ -21,8 +21,6 @@
 namespace clangd {
 namespace {
 
-using ::testing::_;
-using ::testing::AllOf;
 using ::testing::AnyOf;
 using ::testing::Each;
 using ::testing::ElementsAre;
@@ -103,7 +101,7 @@
 TUSchedulerTests::DiagsCallbackKey;
 
 TEST_F(TUSchedulerTests, MissingFiles) {
-  TUScheduler S(getDefaultAsyncThreadsCount(),
+  TUScheduler S(CDB, getDefaultAsyncThreadsCount(),
 /*StorePreamblesInMemory=*/true, /*ASTCallbacks=*/nullptr,
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -154,7 +152,7 @@
 // thread until we've scheduled them all.
 Notification Ready;
 TUScheduler S(
-getDefaultAsyncThreadsCount(),
+CDB, getDefaultAsyncThreadsCount(),
 /*StorePreamblesInMemory=*/true, captureDiags(),
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -184,7 +182,7 @@
 TEST_F(TUSchedulerTests, Debounce) {
   std::atomic CallbackCount(0);
   {
-TUScheduler S(getDefaultAsyncThreadsCount(),
+TUScheduler S(CDB, getDefaultAsyncThreadsCount(),
   /*StorePreamblesInMemory=*/true, captureDiags(),
   /*UpdateDebounce=*/std::chrono::seconds(1),
   ASTRetentionPolicy());
@@ -220,7 +218,7 @@
   {
 Notification InconsistentReadDone; // Must live longest.
 TUScheduler S(
-getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
+CDB, getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
 /*ASTCallbacks=*/nullptr,
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -277,7 +275,7 @@
   {
 Notification Proceed; // Ensure we schedule everything.
 TUScheduler S(
-getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
+CDB, getDefaultAsyncThreadsCount(), /*StorePreamblesInMemory=*/true,
 /*ASTCallbacks=*/captureDiags(),
 /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
 ASTRetentionPolicy());
@@ -346,7 +344,7 @@
 
   // Run TUScheduler and collect some stats.
   {
-TUScheduler S(getDefaultAsyncThreadsCount(),
+TUScheduler S(CDB, getDefaultAsyncThreadsCount(),
   /*StorePreamblesInMemory=*/true, captureDiags(),
   /*UpdateDebounce=*/std::chrono::milliseconds(50),
   ASTRetentionPolicy());
@@ -437,10 +435,11 @@
   std::atomic BuiltASTCounter(0);
   ASTRetentionPolicy Policy;
   Policy.MaxRetainedASTs = 2;
-  TUScheduler S(
-  /*AsyncThreadsCount=*/1, /*StorePreambleInMemory=*/true,
-  /*ASTCallbacks=*/nullptr,
-  /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(), Policy);
+  TUScheduler S(CDB,
+/*AsyncThreadsCount=*/1, /*StorePreambleInMemory=*/true,
+/*ASTCallbacks=*/nullptr,
+/*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
+Policy);
 
   llvm::StringLiteral SourceContents = R"cpp(
 int* a;
@@ -487,11 +486,11 @@
 }
 
 TEST_F(TUSchedulerTests, EmptyPreamble) {
-  TUScheduler S(
-  /*AsyncThreadsCount=*/4, /*StorePreambleInMemory=*/true,
-  /*ASTCallbacks=*/nullptr,
-  /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
-  ASTRetentionPolicy());
+  TUScheduler S(CDB,
+/*AsyncThreadsCount=*/4, /*StorePreambleInMemory=*/true,
+/*ASTCallbacks=*/nullptr,
+/*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
+ASTRetentionPolicy());
 
   auto Foo = testPath("foo.cpp");
   auto Header = testPath("foo.h");
@@ -532,11 +531,11 @@
 TEST_F(TUSchedulerTests, RunWaitsForPreamble) {
   // Testing strategy: we update the file and schedule a few preamble reads at
   // the same time. All reads should get the same non-null preamble.
-  TUScheduler S(
-  /*AsyncThreadsCount=*/4, /*StorePreambleInMemory=*/true,
-  /*ASTCallbacks=*/nullptr,
-  /*UpdateDebounce=*/std::chrono::steady_clock::duration::zero(),
-  ASTRetentionPolicy());
+  TUScheduler S(CDB,
+/*AsyncThreadsCount=*/4, /*StorePreambleInMemory=*/true,
+

[PATCH] D53072: [clang-format] Create a new tool for IDEs based on clang-format

[Ivan Donchevskii via Phabricator via cfe-commits]

yvvan updated this revision to Diff 194844.
yvvan retitled this revision from "[clang-format] Introduce the flag which 
allows not to shrink lines" to "[clang-format] Create a new tool for IDEs based 
on clang-format".
yvvan edited the summary of this revision.
yvvan added a reviewer: arphaman.
yvvan added a comment.
Herald added subscribers: dexonsmith, mgorny.

New approach - title and summary are updated.


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

https://reviews.llvm.org/D53072

Files:
  include/clang/Format/Format.h
  lib/Format/ContinuationIndenter.cpp
  lib/Format/Format.cpp
  lib/Format/FormatInternal.h
  lib/Format/TokenAnalyzer.cpp
  lib/Format/TokenAnalyzer.h
  lib/Format/UnwrappedLineFormatter.cpp
  lib/Format/UnwrappedLineFormatter.h
  lib/Format/UnwrappedLineParser.cpp
  lib/Format/UnwrappedLineParser.h
  tools/CMakeLists.txt
  tools/clang-format-ide/CMakeLists.txt
  tools/clang-format-ide/ClangFormatIDE.cpp
  tools/clang-format/ClangFormat.cpp
  tools/clang-format/ClangFormat.h
  unittests/Format/FormatTest.cpp

Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -35,15 +35,16 @@
 SC_DoNotCheck
   };
 
-  std::string format(llvm::StringRef Code,
- const FormatStyle  = getLLVMStyle(),
- StatusCheck CheckComplete = SC_ExpectComplete) {
+  std::string format(
+  llvm::StringRef Code, const FormatStyle  = getLLVMStyle(),
+  StatusCheck CheckComplete = SC_ExpectComplete,
+  ExtraFormattingOptions FormattingOptions = ExtraFormattingOptions::None) {
 LLVM_DEBUG(llvm::errs() << "---\n");
 LLVM_DEBUG(llvm::errs() << Code << "\n\n");
 std::vector Ranges(1, tooling::Range(0, Code.size()));
 FormattingAttemptStatus Status;
 tooling::Replacements Replaces =
-reformat(Style, Code, Ranges, "", );
+reformat(Style, FormattingOptions, Code, Ranges, "", );
 if (CheckComplete != SC_DoNotCheck) {
   bool ExpectedCompleteFormat = CheckComplete == SC_ExpectComplete;
   EXPECT_EQ(ExpectedCompleteFormat, Status.FormatComplete)
@@ -395,6 +396,25 @@
Style));
 }
 
+TEST_F(FormatTest, KeepsLineBreaks) {
+  FormatStyle Style = getLLVMStyle();
+  EXPECT_EQ("if (a\n"
+"&& b) {\n"
+"}",
+format("if (a\n"
+   "&& b) {\n"
+   "}",
+   Style, SC_ExpectComplete,
+   ExtraFormattingOptions::KeepLineBreaksForNonEmptyLines));
+
+  EXPECT_EQ("[]() {\n"
+"  foo(); }",
+format("[]() {\n"
+   "foo(); }",
+   Style, SC_ExpectComplete,
+   ExtraFormattingOptions::KeepLineBreaksForNonEmptyLines));
+}
+
 TEST_F(FormatTest, RecognizesBinaryOperatorKeywords) {
   verifyFormat("x = (a) and (b);");
   verifyFormat("x = (a) or (b);");
Index: tools/clang-format-ide/ClangFormatIDE.cpp
===
--- tools/clang-format-ide/ClangFormatIDE.cpp
+++ tools/clang-format-ide/ClangFormatIDE.cpp
@@ -0,0 +1,102 @@
+//===-- clang-format/ClangFormat.cpp - Clang format tool --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+/// \file
+/// This file implements a clang-format tool that automatically formats
+/// (fragments of) C++ code.
+///
+//===--===//
+
+#include "../clang-format/ClangFormat.h"
+
+static cl::opt
+KeepLineBreaks("keep-line-breaks",
+   cl::desc("If set, keeps all existing line breaks"),
+   cl::cat(ClangFormatCategory));
+
+static void PrintVersion(raw_ostream ) {
+  OS << clang::getClangToolFullVersion("clang-format-ide") << '\n';
+}
+
+int main(int argc, const char **argv) {
+  llvm::InitLLVM X(argc, argv);
+
+  cl::HideUnrelatedOptions(ClangFormatCategory);
+
+  cl::SetVersionPrinter(PrintVersion);
+  cl::ParseCommandLineOptions(
+  argc, argv,
+  "A tool to format C/C++/Java/JavaScript/Objective-C/Protobuf/C# code.\n\n"
+  "If no arguments are specified, it formats the code from standard input\n"
+  "and writes the result to the standard output.\n"
+  "If s are given, it reformats the files. If -i is specified\n"
+  "together with s, the files are edited in-place. Otherwise, the\n"
+  "result is written to the standard output.\n");
+
+  if (Help) {
+cl::PrintHelpMessage();
+return 0;
+  }
+
+  if (DumpConfig) {
+StringRef FileName;
+std::unique_ptr Code;
+if (FileNames.empty()) {
+  // We can't read the code 

[PATCH] D58675: [clang] Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` compatible JSON profiling output dumps

[Anton Afanasyev via Phabricator via cfe-commits]

anton-afanasyev added a comment.

Use native llvm JSON library update: https://reviews.llvm.org/D60609


Repository:
  rL LLVM

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

https://reviews.llvm.org/D58675



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

Re: r357340 - Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` compatible JSON profiling output dumps.

[Nico Weber via cfe-commits]

I haven't tried -ftime-report here. I tried it in the past and found it
difficult to interpret, as the blog post you link to correctly says :) I
thought -ftime-trace was supposed to be more usable, so I figured I'd try
that instead. And for frontend stuff, it does look much better!

Ideas on how to improve the backend situation:
- Let FPPassManager::runOnFunction() call

if (ProfileTime)
llvm::timeTraceProfilerBegin("RunPass", FP->getPassName());

  for each pass so that it's visible which path the time goes into

- Have a thing _somewhere_ (in clang? in chrome's about:tracing? a
standalone tool?) that makes it possible to look at a flame graph view of
the trace. A flame graph is a trace that's sorted by call stack, not by
time, so that all the same stacks are next to each other, which makes it
easy to see things like "30% of time is spent in function X" – together
with the first suggestion it'd make the slowest path visible.

I haven't actually tried doing this, so I'm not sure it'd help, but I could
imagine it would :)

On Fri, Apr 12, 2019 at 2:41 AM Anton Afanasyev 
wrote:

> Hi Nico,
> yes, you are right, current implementation is mostly focused on frontend.
> Yes, I can impove BE time output after getting feedback like yours one. Do
> you need detailed info about BE passes times? Btw, did you try
> -ftime-report option? It could give you detailed info on BE passes
> bottlenecks, though its implementation is a little bit messy for now (as
> Aras noted here:
> http://aras-p.info/blog/2019/01/12/Investigating-compile-times-and-Clang-ftime-report/
> ).
>   Thanks,
>Anton
>
> пт, 12 апр. 2019 г. в 00:22, Nico Weber :
>
>> I tried using this to see why X86ISelLowering.cpp takes so long to build
>> on my system. The output json produced by this flag is at
>> http://s000.tinyupload.com/?file_id=00019982161870973700
>>
>> It looks like this produces lots of useful information for frontend time,
>> but in this case most time is spent in the backend, where this doesn't
>> produce very useful output. Are there any plans to improve output for
>> backend time?
>>
>> On Sat, Mar 30, 2019 at 9:38 AM Anton Afanasyev via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: anton-afanasyev
>>> Date: Sat Mar 30 01:42:48 2019
>>> New Revision: 357340
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=357340=rev
>>> Log:
>>> Adds `-ftime-trace` option to clang that produces Chrome
>>> `chrome://tracing` compatible JSON profiling output dumps.
>>>
>>> This change adds hierarchical "time trace" profiling blocks that can be
>>> visualized in Chrome, in a "flame chart" style. Each profiling block can
>>> have a "detail" string that for example indicates the file being processed,
>>> template name being instantiated, function being optimized etc.
>>>
>>> This is taken from GitHub PR:
>>> https://github.com/aras-p/llvm-project-20170507/pull/2
>>>
>>> Patch by Aras Pranckevičius.
>>>
>>> Differential Revision: https://reviews.llvm.org/D58675
>>>
>>> Modified:
>>> cfe/trunk/include/clang/Basic/CodeGenOptions.def
>>> cfe/trunk/include/clang/Driver/Options.td
>>> cfe/trunk/include/clang/Frontend/FrontendOptions.h
>>> cfe/trunk/lib/CodeGen/BackendUtil.cpp
>>> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>>> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>>> cfe/trunk/lib/Frontend/CompilerInstance.cpp
>>> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>>> cfe/trunk/lib/Parse/ParseAST.cpp
>>> cfe/trunk/lib/Parse/ParseDeclCXX.cpp
>>> cfe/trunk/lib/Parse/ParseTemplate.cpp
>>> cfe/trunk/lib/Sema/Sema.cpp
>>> cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
>>> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
>>> cfe/trunk/lib/Serialization/GlobalModuleIndex.cpp
>>> cfe/trunk/tools/driver/cc1_main.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Basic/CodeGenOptions.def
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/CodeGenOptions.def?rev=357340=357339=357340=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Basic/CodeGenOptions.def (original)
>>> +++ cfe/trunk/include/clang/Basic/CodeGenOptions.def Sat Mar 30 01:42:48
>>> 2019
>>> @@ -224,6 +224,7 @@ CODEGENOPT(FineGrainedBitfieldAccesses,
>>>  CODEGENOPT(StrictEnums   , 1, 0) ///< Optimize based on strict enum
>>> definition.
>>>  CODEGENOPT(StrictVTablePointers, 1, 0) ///< Optimize based on the
>>> strict vtable pointers
>>>  CODEGENOPT(TimePasses, 1, 0) ///< Set when -ftime-report is
>>> enabled.
>>> +CODEGENOPT(TimeTrace , 1, 0) ///< Set when -ftime-trace is
>>> enabled.
>>>  CODEGENOPT(UnrollLoops   , 1, 0) ///< Control whether loops are
>>> unrolled.
>>>  CODEGENOPT(RerollLoops   , 1, 0) ///< Control whether loops are
>>> rerolled.
>>>  CODEGENOPT(NoUseJumpTables   , 1, 0) ///< Set when -fno-jump-tables is
>>> enabled.
>>>
>>> Modified: 

[PATCH] D60607: [clangd] Wait for compile command in ASTWorker instead of ClangdServer

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

This is long overdue




Comment at: clangd/TUScheduler.cpp:338
+  Barrier(Barrier), Done(false) {
+  FileInputs.CompileCommand = CDB.getFallbackCommand(FileName);
+}

The command is filled with a fallback by `ClangdServer`, right? Why do we need 
to repeat this here?



Comment at: clangd/TUScheduler.cpp:358
+// current implementation.
+if (auto Cmd = CDB.getCompileCommand(FileName))
+  Inputs.CompileCommand = *Cmd;

Could you document that we initially start with a fallback, so update here?



Comment at: clangd/TUScheduler.cpp:359
+if (auto Cmd = CDB.getCompileCommand(FileName))
+  Inputs.CompileCommand = *Cmd;
 // Will be used to check if we can avoid rebuilding the AST.

Maybe update the heuristic field in the current compile command if its empty to 
indicate we're using an older command?
That might happen if a previous call to `getCompileCommand` succeeded (so the 
stored command does not have a heuristic set).



Comment at: clangd/TUScheduler.cpp:552
+const tooling::CompileCommand ::getCurrentCompileCommand() const {
+  return FileInputs.CompileCommand;
+}

This is racy, `FileInputs` is only accessed from a worker thread now.
I'm afraid we'll need a separate variable with a lock around it (could reuse 
one lock for preamble and compile command, probably)



Comment at: clangd/TUScheduler.cpp:835
 
 void TUScheduler::update(PathRef File, ParseInputs Inputs,
  WantDiagnostics WantDiags) {

We should add a comment that compile command in inputs is ignored.
IMO even better is to accept an `FS` and `Contents` instead of `ParseInputs`.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60607



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

[PATCH] D60539: Add -std=c++14 language standard option to tests that require C++14 default

[Sam McCall via Phabricator via cfe-commits]

sammccall requested changes to this revision.
sammccall added a comment.
This revision now requires changes to proceed.
Herald added a subscriber: jsji.

I don't think this is a suitable fix :-(

There are lots of places where we construct command-lines in tests, it may be 
true today that this is the only one that fails with `gnucxx11`, but there are 
other possible values for `CLANG_DEFAULT_STD_CXX` and also code changes over 
time. So if we want to be robust to this we need a general approach to this 
that can be used in `SymbolCollectorTest`, `TestTU`, and others.

Adding `-std=c++14` doesn't work in general as it has side-effects: `clang 
-std=c++14 foo.c` is a warning, `clang -std=c++14 -x c-header foo.h` is an 
error. It would be nice if clang had a flag to specify the default c++ language 
version without also forcing the file to be parsed as C++, but AFAIK it does 
not.

> In our case, we set the default to be gnucxx11. However, doing so will cause 
> the test cases in this patch to fail as they rely on the C++14 default.

Do you need to build clangd? We explicitly don't aim to support building 
everywhere clang can be built, maybe we should just disable in this case?


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

https://reviews.llvm.org/D60539



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

[PATCH] D60257: [Lookup] Invisible decls should not be ambiguous when renaming.

[Eric Liu via Phabricator via cfe-commits]

ioeric updated this revision to Diff 194841.
ioeric marked 2 inline comments as done.
ioeric added a comment.

- Add test comment.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60257

Files:
  include/clang/Tooling/Core/Lookup.h
  lib/Tooling/Core/Lookup.cpp
  lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
  unittests/Tooling/LookupTest.cpp

Index: unittests/Tooling/LookupTest.cpp
===
--- unittests/Tooling/LookupTest.cpp
+++ unittests/Tooling/LookupTest.cpp
@@ -44,8 +44,8 @@
 const auto *Callee = cast(Expr->getCallee()->IgnoreImplicit());
 const ValueDecl *FD = Callee->getDecl();
 return tooling::replaceNestedName(
-Callee->getQualifier(), Visitor.DeclStack.back()->getDeclContext(), FD,
-ReplacementString);
+Callee->getQualifier(), Callee->getLocation(),
+Visitor.DeclStack.back()->getDeclContext(), FD, ReplacementString);
   };
 
   Visitor.OnCall = [&](CallExpr *Expr) {
@@ -181,12 +181,12 @@
 TEST(LookupTest, replaceNestedClassName) {
   GetDeclsVisitor Visitor;
 
-  auto replaceRecordTypeLoc = [&](RecordTypeLoc Loc,
+  auto replaceRecordTypeLoc = [&](RecordTypeLoc TLoc,
   StringRef ReplacementString) {
-const auto *FD = cast(Loc.getDecl());
+const auto *FD = cast(TLoc.getDecl());
 return tooling::replaceNestedName(
-nullptr, Visitor.DeclStack.back()->getDeclContext(), FD,
-ReplacementString);
+nullptr, TLoc.getBeginLoc(), Visitor.DeclStack.back()->getDeclContext(),
+FD, ReplacementString);
   };
 
   Visitor.OnRecordTypeLoc = [&](RecordTypeLoc Type) {
@@ -211,6 +211,40 @@
   };
   Visitor.runOver("namespace a { namespace b { class Foo {}; } }\n"
   "namespace c { using a::b::Foo; Foo f();; }\n");
+
+  // Rename TypeLoc `x::y::Old` to new name `x::Foo` at [0] and check that the
+  // type is replaced with "Foo" instead of "x::Foo". Although there is a symbol
+  // `x::y::Foo` in c.cc [1], it should not make "Foo" at [0] ambiguous because
+  // it's not visible at [0].
+  Visitor.OnRecordTypeLoc = [&](RecordTypeLoc Type) {
+if (Type.getDecl()->getQualifiedNameAsString() == "x::y::Old")
+  EXPECT_EQ("Foo", replaceRecordTypeLoc(Type, "::x::Foo"));
+  };
+  Visitor.runOver(R"(
+// a.h
+namespace x {
+ namespace y {
+  class Old {};
+  class Other {};
+ }
+}
+
+// b.h
+namespace x {
+ namespace y {
+  // This is to be renamed to x::Foo
+  // The expected replacement is "Foo".
+  Old f;  // [0].
+ }
+}
+
+// c.cc
+namespace x {
+namespace y {
+ using Foo = ::x::y::Other; // [1]
+}
+}
+)");
 }
 
 } // end anonymous namespace
Index: lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
===
--- lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
+++ lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
@@ -542,8 +542,8 @@
 if (!llvm::isa(
 RenameInfo.Context->getDeclContext())) {
   ReplacedName = tooling::replaceNestedName(
-  RenameInfo.Specifier, RenameInfo.Context->getDeclContext(),
-  RenameInfo.FromDecl,
+  RenameInfo.Specifier, RenameInfo.Begin,
+  RenameInfo.Context->getDeclContext(), RenameInfo.FromDecl,
   NewName.startswith("::") ? NewName.str()
: ("::" + NewName).str());
 } else {
Index: lib/Tooling/Core/Lookup.cpp
===
--- lib/Tooling/Core/Lookup.cpp
+++ lib/Tooling/Core/Lookup.cpp
@@ -14,6 +14,7 @@
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclarationName.h"
+#include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/SmallVector.h"
 using namespace clang;
 using namespace clang::tooling;
@@ -123,7 +124,8 @@
 // FIXME: consider using namespaces.
 static std::string disambiguateSpellingInScope(StringRef Spelling,
StringRef QName,
-   const DeclContext ) {
+   const DeclContext ,
+   SourceLocation UseLoc) {
   assert(QName.startswith("::"));
   assert(QName.endswith(Spelling));
   if (Spelling.startswith("::"))
@@ -138,9 +140,10 @@
   getAllNamedNamespaces();
   auto  = UseContext.getParentASTContext();
   StringRef TrimmedQName = QName.substr(2);
+  const auto  = UseContext.getParentASTContext().getSourceManager();
+  UseLoc = SM.getSpellingLoc(UseLoc);
 
-  auto IsAmbiguousSpelling = [, , ](
- const llvm::StringRef CurSpelling) {
+  auto IsAmbiguousSpelling = [&](const llvm::StringRef CurSpelling) {
 if (CurSpelling.startswith("::"))
 

[PATCH] D60570: [Sema] Add more tests for the behavior of argument-dependent name lookup

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added inline comments.



Comment at: 
test/CXX/basic/basic.lookup/basic.lookup.argdep/p2-associated-namespaces-classes.cpp:304
+static_assert(f(g3) == 4, "");// FIXME: Also well-formed from the 
union rule.
+  // expected-error@-1 {{use of 
undeclared}}
+  }

I see how `g3` matches the example in CWG997
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#997
However, I don't see how CWG997's resolution actually affected this example in 
the slightest. The wording inserted for CWG997 was, "Additionally, if the 
aforementioned set of overloaded functions is named with a template-id, its 
associated classes and namespaces are those of its type template-arguments and 
its template template-arguments." That makes e.g.

f(g3)

consider `N::f`, because `N::S` is a "type template-argument" of the 
template-id `g3` which names the set of overloaded functions.  But it 
doesn't do anything at all to `f(g3)` because `g3` is not a template-id and 
doesn't have any template-arguments.

This piece of ADL is implemented only by GCC (not EDG, Clang, or MSVC), and 
personally I would very much like to keep it that way. We know there's no 
real-world code that expects or relies on CWG997 — because such code would 
never work in practice except on GCC. Let's keep it that way!  As soon as you 
implement a crazy arcane rule, such that code _could_ portably rely on it, code 
_will start_ relying on it... and then we'll never be able to simplify the 
language.
Case in point: the piece of ADL described in this blog post --
https://quuxplusone.github.io/blog/2019/04/09/adl-insanity-round-2/
As soon as the above-described arcane ADL rule was implemented in GCC and 
Clang, Boost.Hana started relying on it; and now the rule is "locked in" to the 
paper standard because there's real-world code relying on it.
Personally I'd like to _keep_ real-world code from relying on CWG997, until 
someone figures out what CWG was thinking when they added it.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60570



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

[PATCH] D60257: [Lookup] Invisible decls should not be ambiguous when renaming.

[Eric Liu via Phabricator via cfe-commits]

ioeric added inline comments.



Comment at: unittests/Tooling/LookupTest.cpp:215
+
+  // Potentially ambiguous symbols that are not visible at reference location
+  // are not considered ambiguous.

hokein wrote:
> The test seems hard to understand what it actually does, could you explain 
> it? which symbol is ambiguous here? What's the behavior of the test before vs 
> after the fix?
added comment. PTAL


Repository:
  rC Clang

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

https://reviews.llvm.org/D60257



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

[PATCH] D60316: [clangd] Include insertion: require header guards, drop other heuristics, treat .def like .inc.

[Eric Liu via Phabricator via cfe-commits]

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

in case you missed this patch :)


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D60316



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