date:20190627

[PATCH] D58164: Block+lambda: allow reference capture

2019-06-27 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

I'm not sure we've ever written down what the semantics of the block capture 
are actually supposed to be in this situation.  I guess capturing a reference 
is the right thing to do?  Is that what we generally do if this is a POD type?


Repository:
  rC Clang

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

https://reviews.llvm.org/D58164



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

[PATCH] D61809: [BPF] Preserve debuginfo array/union/struct type/access index

2019-06-27 Thread Yonghong Song via Phabricator via cfe-commits

yonghong-song marked 2 inline comments as done.
yonghong-song added a comment.

@rsmith I have proposed one clang intrinsic and three IR intrinsics for CO-RE. 
Could you take a look and share your opinions as well? Thanks!




Comment at: docs/LanguageExtensions.rst:1958
+array subscript access and structure/union member access are preserved with
+IR intrinsics ``preserve_array_access_index``, ``preserve_union_access_index``
+and ``preserve_struct_access_index``, instead of IR GetElementPtr instructions.

efriedma wrote:
> "preserved with the IR intrinsics" isn't really useful; this is the user's 
> manual, not a developer guide to LLVM internals. Probably better to say what 
> it enables from the user's perspective: the CO-RE feature for BPF targets.
Will reword to be more towards users in the next revision.



Comment at: docs/LanguageExtensions.rst:1960
+and ``preserve_struct_access_index``, instead of IR GetElementPtr instructions.
+``__builtin_preserve_access_index`` takes effect only when debuginfo (typically
+with ``-g``) is available since debuginfo is used as IR intrinsic metadata

efriedma wrote:
> I would rather not have __builtin_preserve_access_index fail to do anything 
> when debug info is disabled. If it's hard to fix, making it a hard error is 
> probably okay.
The IR intrinsics needs to have debuginfo as the metadata so that the 
user-level access info can be reconstructed. If no debug info, just IR 
intrinsics without debuginfo is less useful. So let me make a hard error.

We can relax it later if IR intrinsics without deebuginfo metadata becomes 
workable/useful.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61809



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

[PATCH] D63789: [ODRHash] Fix null pointer dereference for ObjC selectors with empty slots.

2019-06-27 Thread Richard Trieu via Phabricator via cfe-commits

rtrieu accepted this revision.
rtrieu 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/D63789/new/

https://reviews.llvm.org/D63789



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

[PATCH] D63789: [ODRHash] Fix null pointer dereference for ObjC selectors with empty slots.

2019-06-27 Thread Volodymyr Sapsai via Phabricator via cfe-commits

vsapsai updated this revision to Diff 206992.
vsapsai added a comment.
Herald added a project: clang.

- Address review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63789

Files:
  clang/lib/AST/ODRHash.cpp
  clang/test/Modules/odr_hash.mm


Index: clang/test/Modules/odr_hash.mm
===
--- clang/test/Modules/odr_hash.mm
+++ clang/test/Modules/odr_hash.mm
@@ -57,6 +57,14 @@
 @interface Interface3 
 @end
 
+@interface EmptySelectorSlot
+- (void)method:(int)arg;
+- (void)method:(int)arg :(int)empty;
+
+- (void)multiple:(int)arg1 args:(int)arg2 :(int)arg3;
+- (void)multiple:(int)arg1 :(int)arg2 args:(int)arg3;
+@end
+
 #endif
 
 #if defined(FIRST)
@@ -289,6 +297,29 @@
 }  // namespace ObjCTypeParam
 }  // namespace Types
 
+namespace CallMethods {
+#if defined(FIRST)
+void invalid1(EmptySelectorSlot *obj) {
+  [obj method:0];
+}
+void invalid2(EmptySelectorSlot *obj) {
+  [obj multiple:0 args:0 :0];
+}
+#elif defined(SECOND)
+void invalid1(EmptySelectorSlot *obj) {
+  [obj method:0 :0];
+}
+void invalid2(EmptySelectorSlot *obj) {
+  [obj multiple:0 :0 args:0];
+}
+#endif
+// expected-error@second.h:* {{'CallMethods::invalid1' has different 
definitions in different modules; definition in module 'SecondModule' first 
difference is function body}}
+// expected-note@first.h:* {{but in 'FirstModule' found a different body}}
+
+// expected-error@second.h:* {{'CallMethods::invalid2' has different 
definitions in different modules; definition in module 'SecondModule' first 
difference is function body}}
+// expected-note@first.h:* {{but in 'FirstModule' found a different body}}
+}  // namespace CallMethods
+
 // Keep macros contained to one file.
 #ifdef FIRST
 #undef FIRST
Index: clang/lib/AST/ODRHash.cpp
===
--- clang/lib/AST/ODRHash.cpp
+++ clang/lib/AST/ODRHash.cpp
@@ -71,8 +71,13 @@
 AddBoolean(S.isKeywordSelector());
 AddBoolean(S.isUnarySelector());
 unsigned NumArgs = S.getNumArgs();
+ID.AddInteger(NumArgs);
 for (unsigned i = 0; i < NumArgs; ++i) {
-  AddIdentifierInfo(S.getIdentifierInfoForSlot(i));
+  const IdentifierInfo *II = S.getIdentifierInfoForSlot(i);
+  AddBoolean(II);
+  if (II) {
+AddIdentifierInfo(II);
+  }
 }
 break;
   }


Index: clang/test/Modules/odr_hash.mm
===
--- clang/test/Modules/odr_hash.mm
+++ clang/test/Modules/odr_hash.mm
@@ -57,6 +57,14 @@
 @interface Interface3 
 @end
 
+@interface EmptySelectorSlot
+- (void)method:(int)arg;
+- (void)method:(int)arg :(int)empty;
+
+- (void)multiple:(int)arg1 args:(int)arg2 :(int)arg3;
+- (void)multiple:(int)arg1 :(int)arg2 args:(int)arg3;
+@end
+
 #endif
 
 #if defined(FIRST)
@@ -289,6 +297,29 @@
 }  // namespace ObjCTypeParam
 }  // namespace Types
 
+namespace CallMethods {
+#if defined(FIRST)
+void invalid1(EmptySelectorSlot *obj) {
+  [obj method:0];
+}
+void invalid2(EmptySelectorSlot *obj) {
+  [obj multiple:0 args:0 :0];
+}
+#elif defined(SECOND)
+void invalid1(EmptySelectorSlot *obj) {
+  [obj method:0 :0];
+}
+void invalid2(EmptySelectorSlot *obj) {
+  [obj multiple:0 :0 args:0];
+}
+#endif
+// expected-error@second.h:* {{'CallMethods::invalid1' has different definitions in different modules; definition in module 'SecondModule' first difference is function body}}
+// expected-note@first.h:* {{but in 'FirstModule' found a different body}}
+
+// expected-error@second.h:* {{'CallMethods::invalid2' has different definitions in different modules; definition in module 'SecondModule' first difference is function body}}
+// expected-note@first.h:* {{but in 'FirstModule' found a different body}}
+}  // namespace CallMethods
+
 // Keep macros contained to one file.
 #ifdef FIRST
 #undef FIRST
Index: clang/lib/AST/ODRHash.cpp
===
--- clang/lib/AST/ODRHash.cpp
+++ clang/lib/AST/ODRHash.cpp
@@ -71,8 +71,13 @@
 AddBoolean(S.isKeywordSelector());
 AddBoolean(S.isUnarySelector());
 unsigned NumArgs = S.getNumArgs();
+ID.AddInteger(NumArgs);
 for (unsigned i = 0; i < NumArgs; ++i) {
-  AddIdentifierInfo(S.getIdentifierInfoForSlot(i));
+  const IdentifierInfo *II = S.getIdentifierInfoForSlot(i);
+  AddBoolean(II);
+  if (II) {
+AddIdentifierInfo(II);
+  }
 }
 break;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63822: [Driver] Fix style issues of --print-supported-cpus

2019-06-27 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay updated this revision to Diff 206993.
MaskRay added a comment.

Restore a comment


Repository:
  rC Clang

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

https://reviews.llvm.org/D63822

Files:
  include/clang/Driver/Options.td
  lib/Driver/Driver.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/print-supported-cpus.c
  tools/driver/cc1_main.cpp

Index: tools/driver/cc1_main.cpp
===
--- tools/driver/cc1_main.cpp
+++ tools/driver/cc1_main.cpp
@@ -169,8 +169,8 @@
 static void ensureSufficientStack() {}
 #endif
 
-/// print supported cpus of the given target
-int PrintSupportedCPUs(std::string TargetStr) {
+/// Print supported cpus of the given target.
+static int PrintSupportedCPUs(std::string TargetStr) {
   std::string Error;
   const llvm::Target *TheTarget =
   llvm::TargetRegistry::lookupTarget(TargetStr, Error);
@@ -219,10 +219,9 @@
   if (Clang->getFrontendOpts().TimeTrace)
 llvm::timeTraceProfilerInitialize();
 
-  // --print-supported-cpus takes priority over the actual compilation
-  if (Clang->getFrontendOpts().PrintSupportedCPUs) {
+  // --print-supported-cpus takes priority over the actual compilation.
+  if (Clang->getFrontendOpts().PrintSupportedCPUs)
 return PrintSupportedCPUs(Clang->getTargetOpts().Triple);
-  }
 
   // Infer the builtin include path if unspecified.
   if (Clang->getHeaderSearchOpts().UseBuiltinIncludes &&
Index: test/Driver/print-supported-cpus.c
===
--- test/Driver/print-supported-cpus.c
+++ test/Driver/print-supported-cpus.c
@@ -1,35 +1,27 @@
-// Test that the --print-supported-cpus flag works
-// Also test its aliases: -mcpu=? and -mtune=?
+// Test that --print-supported-cpus lists supported CPU models.
 
 // REQUIRES: x86-registered-target
 // REQUIRES: arm-registered-target
 
-// RUN: %clang --target=x86_64-unknown-linux-gnu \
-// RUN:   --print-supported-cpus 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-X86
+// RUN: %clang --target=x86_64-unknown-linux-gnu --print-supported-cpus 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
+// Test -mcpu=? and -mtune=? alises.
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mcpu=? 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mtune=? -fuse-ld=dummy 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
+// CHECK-NOT: warning: argument unused during compilation
 // CHECK-X86: Target: x86_64-unknown-linux-gnu
 // CHECK-X86: corei7
 // CHECK-X86: Use -mcpu or -mtune to specify the target's processor.
 
-// RUN: %clang --target=x86_64-unknown-linux-gnu \
-// RUN:   -mcpu=? 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-X86-MCPU
-// CHECK-X86-MCPU: Target: x86_64-unknown-linux-gnu
-// CHECK-X86-MCPU: corei7
-// CHECK-X86-MCPU: Use -mcpu or -mtune to specify the target's processor.
+// RUN: %clang --target=arm-unknown-linux-android --print-supported-cpus 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-ARM
 
-// RUN: %clang --target=arm-unknown-linux-android \
-// RUN:   --print-supported-cpus 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-ARM
 // CHECK-ARM: Target: arm-unknown-linux-android
 // CHECK-ARM: cortex-a73
 // CHECK-ARM: cortex-a75
 // CHECK-ARM: Use -mcpu or -mtune to specify the target's processor.
-
-// RUN: %clang --target=arm-unknown-linux-android \
-// RUN:   -mtune=? 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-ARM-MTUNE
-// CHECK-ARM-MTUNE: Target: arm-unknown-linux-android
-// CHECK-ARM-MTUNE: cortex-a73
-// CHECK-ARM-MTUNE: cortex-a75
-// CHECK-ARM-MTUNE: Use -mcpu or -mtune to specify the target's processor.
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1767,7 +1767,7 @@
   Opts.ShowHelp = Args.hasArg(OPT_help);
   Opts.ShowStats = Args.hasArg(OPT_print_stats);
   Opts.ShowTimers = Args.hasArg(OPT_ftime_report);
-  Opts.PrintSupportedCPUs = Args.hasArg(OPT__print_supported_cpus);
+  Opts.PrintSupportedCPUs = Args.hasArg(OPT_print_supported_cpus);
   Opts.TimeTrace = Args.hasArg(OPT_ftime_trace);
   Opts.ShowVersion = Args.hasArg(OPT_version);
   Opts.ASTMergeFiles = Args.getAllArgValues(OPT_ast_merge);
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -280,6 +280,7 @@
 
 // -{fsyntax-only,-analyze,emit-ast} only run up to the compiler.
   } else if ((PhaseArg = DAL.getLastArg(options::OPT_fsyntax_only)) ||
+ (PhaseArg = DAL.getLastArg(options::OPT_print_supported_cpus)) ||
  (PhaseArg = DAL.getLastArg(options::OPT_module_file_info)) ||
  (PhaseArg = DAL.getLastArg(options::OPT_verify_pch)) ||
  (PhaseArg =

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

2019-06-27 Thread Justin Hibbits via Phabricator via cfe-commits

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



Comment at: lib/Basic/Targets/PPC.cpp:318
+  Features["spe"] = llvm::StringSwitch(CPU)
+.Case("e500", true)
+.Case("8548", true)

vit9696 wrote:
> nemanjai wrote:
> > The `e500v2` that you added doesn't support SPE?
> I rechecked the docs, and there is no e500v2 option for -mcpu in GCC:
> https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options.
> 
> GCC defines 8540 (currently missing) and 8548, which I suppose we should 
> support with default switches for SPE. As for other options, there also is 
> -me500, which enables SPE, and -me500mc, which does not. I believe the need 
> of these options is discussible.
> 
> The author of the patch may have his own thoughts behind, but I am not sure 
> if e500, e500v1, or e500v2 should be used as mcpu switches at all. I am not 
> against it if it makes things more convenient though.
I decided it's better to match gcc in this regard, and support only 8548 (8540 
is e500v1, which this SPE codegen does not support).


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



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

[PATCH] D63822: [Driver] Fix style issues of --print-supported-cpus

2019-06-27 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay updated this revision to Diff 206989.
MaskRay retitled this revision from "[Driver] Delete --print-supported-cpus in 
favor of -mcpu=? or -mtune=?" to "[Driver] Fix style issues of 
--print-supported-cpus".
MaskRay added a comment.

Repurpose


Repository:
  rC Clang

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

https://reviews.llvm.org/D63822

Files:
  include/clang/Driver/Options.td
  lib/Driver/Driver.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/print-supported-cpus.c
  tools/driver/cc1_main.cpp

Index: tools/driver/cc1_main.cpp
===
--- tools/driver/cc1_main.cpp
+++ tools/driver/cc1_main.cpp
@@ -169,8 +169,8 @@
 static void ensureSufficientStack() {}
 #endif
 
-/// print supported cpus of the given target
-int PrintSupportedCPUs(std::string TargetStr) {
+/// Print supported cpus of the given target.
+static int PrintSupportedCPUs(std::string TargetStr) {
   std::string Error;
   const llvm::Target *TheTarget =
   llvm::TargetRegistry::lookupTarget(TargetStr, Error);
@@ -219,10 +219,9 @@
   if (Clang->getFrontendOpts().TimeTrace)
 llvm::timeTraceProfilerInitialize();
 
-  // --print-supported-cpus takes priority over the actual compilation
-  if (Clang->getFrontendOpts().PrintSupportedCPUs) {
+  // -mcpu=? takes priority over the actual compilation.
+  if (Clang->getFrontendOpts().PrintSupportedCPUs)
 return PrintSupportedCPUs(Clang->getTargetOpts().Triple);
-  }
 
   // Infer the builtin include path if unspecified.
   if (Clang->getHeaderSearchOpts().UseBuiltinIncludes &&
Index: test/Driver/print-supported-cpus.c
===
--- test/Driver/print-supported-cpus.c
+++ test/Driver/print-supported-cpus.c
@@ -1,35 +1,27 @@
-// Test that the --print-supported-cpus flag works
-// Also test its aliases: -mcpu=? and -mtune=?
+// Test that --print-supported-cpus lists supported CPU models.
 
 // REQUIRES: x86-registered-target
 // REQUIRES: arm-registered-target
 
-// RUN: %clang --target=x86_64-unknown-linux-gnu \
-// RUN:   --print-supported-cpus 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-X86
+// RUN: %clang --target=x86_64-unknown-linux-gnu --print-supported-cpus 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
+// Test -mcpu=? and -mtune=? alises.
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mcpu=? 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mtune=? -fuse-ld=dummy 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
+// CHECK-NOT: warning: argument unused during compilation
 // CHECK-X86: Target: x86_64-unknown-linux-gnu
 // CHECK-X86: corei7
 // CHECK-X86: Use -mcpu or -mtune to specify the target's processor.
 
-// RUN: %clang --target=x86_64-unknown-linux-gnu \
-// RUN:   -mcpu=? 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-X86-MCPU
-// CHECK-X86-MCPU: Target: x86_64-unknown-linux-gnu
-// CHECK-X86-MCPU: corei7
-// CHECK-X86-MCPU: Use -mcpu or -mtune to specify the target's processor.
+// RUN: %clang --target=arm-unknown-linux-android --print-supported-cpus 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-ARM
 
-// RUN: %clang --target=arm-unknown-linux-android \
-// RUN:   --print-supported-cpus 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-ARM
 // CHECK-ARM: Target: arm-unknown-linux-android
 // CHECK-ARM: cortex-a73
 // CHECK-ARM: cortex-a75
 // CHECK-ARM: Use -mcpu or -mtune to specify the target's processor.
-
-// RUN: %clang --target=arm-unknown-linux-android \
-// RUN:   -mtune=? 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-ARM-MTUNE
-// CHECK-ARM-MTUNE: Target: arm-unknown-linux-android
-// CHECK-ARM-MTUNE: cortex-a73
-// CHECK-ARM-MTUNE: cortex-a75
-// CHECK-ARM-MTUNE: Use -mcpu or -mtune to specify the target's processor.
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1767,7 +1767,7 @@
   Opts.ShowHelp = Args.hasArg(OPT_help);
   Opts.ShowStats = Args.hasArg(OPT_print_stats);
   Opts.ShowTimers = Args.hasArg(OPT_ftime_report);
-  Opts.PrintSupportedCPUs = Args.hasArg(OPT__print_supported_cpus);
+  Opts.PrintSupportedCPUs = Args.hasArg(OPT_print_supported_cpus);
   Opts.TimeTrace = Args.hasArg(OPT_ftime_trace);
   Opts.ShowVersion = Args.hasArg(OPT_version);
   Opts.ASTMergeFiles = Args.getAllArgValues(OPT_ast_merge);
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -280,6 +280,7 @@
 
 // -{fsyntax-only,-analyze,emit-ast} only run up to the compiler.
   } else if ((PhaseArg = DAL.getLastArg(options::OPT_fsyntax_only)) ||
+ (PhaseArg = DAL.getLastArg(options::OPT_print_supported_cpus)) ||
  (PhaseArg =

[PATCH] D61809: [BPF] Preserve debuginfo array/union/struct type/access index

2019-06-27 Thread Eli Friedman via Phabricator via cfe-commits

efriedma added a comment.

The new approach to tracking expressions inside of 
__builtin_preserve_access_index seems okay.

Please let @rsmith comment since he looked at this before.




Comment at: docs/LanguageExtensions.rst:1958
+array subscript access and structure/union member access are preserved with
+IR intrinsics ``preserve_array_access_index``, ``preserve_union_access_index``
+and ``preserve_struct_access_index``, instead of IR GetElementPtr instructions.

"preserved with the IR intrinsics" isn't really useful; this is the user's 
manual, not a developer guide to LLVM internals. Probably better to say what it 
enables from the user's perspective: the CO-RE feature for BPF targets.



Comment at: docs/LanguageExtensions.rst:1960
+and ``preserve_struct_access_index``, instead of IR GetElementPtr instructions.
+``__builtin_preserve_access_index`` takes effect only when debuginfo (typically
+with ``-g``) is available since debuginfo is used as IR intrinsic metadata

I would rather not have __builtin_preserve_access_index fail to do anything 
when debug info is disabled. If it's hard to fix, making it a hard error is 
probably okay.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61809



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

[PATCH] D63915: [analyzer][WIP] ReturnValueChecker: Model the guaranteed boolean return value of function calls

2019-06-27 Thread Csaba Dabis via Phabricator via cfe-commits

Charusso planned changes to this revision.
Charusso marked 2 inline comments as done.
Charusso added a comment.

Heavily WIP, see inline.




Comment at: clang/test/Analysis/return-value-guaranteed.cpp:37
+bool parseFile() {
+  clang_analyzer_eval(error() == true); // FIXME: xpected-warning{{TRUE}}
+

It is blind.



Comment at: clang/test/Analysis/return-value-guaranteed.cpp:82
+  if (error())
+(void)(1 / !error());
+}

It makes no reports.


Repository:
  rC Clang

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

https://reviews.llvm.org/D63915



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

[PATCH] D63915: [analyzer][WIP] ReturnValueChecker: Model the guaranteed boolean return value of function calls

2019-06-27 Thread Csaba Dabis via Phabricator via cfe-commits

Charusso created this revision.
Charusso added reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, 
Szelethus.
Charusso added a project: clang.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, 
a.sidorin, rnkovacs, szepet, mgorny.

Options:

- `apiModeling.ReturnValue:Calls`

  (string) A semicolon separated list of tuples.
  Where each tuple consists of a call name,
  its truth value, and an optional class name
  of that method separated by colons: "call
  name : truth value : optional class name";"...".
  It ensures the boolean return value of each
  function call. (default: "")



- `apiModeling.ReturnValue:Projects`

  (string) A semicolon separated list of predefined
  projects. It adds to the "Calls" additional
  hard coded call-lists of the given projects.
  Possible value: "llvm". (default: "llvm")


Repository:
  rC Clang

https://reviews.llvm.org/D63915

Files:
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
  clang/lib/StaticAnalyzer/Checkers/ReturnValueChecker.cpp
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/return-value-guaranteed.cpp

Index: clang/test/Analysis/return-value-guaranteed.cpp
===
--- /dev/null
+++ clang/test/Analysis/return-value-guaranteed.cpp
@@ -0,0 +1,83 @@
+// RUN: %clang_analyze_cc1 \
+// RUN:  -analyzer-checker=core \
+// RUN:  -analyzer-checker=apiModeling.ReturnValue \
+// RUN:  -analyzer-config apiModeling.ReturnValue:Calls=" error : true " \
+// RUN:  -analyzer-checker=debug.ExprInspection \
+// RUN:  -verify %s
+// RUN: %clang_analyze_cc1 \
+// RUN:  -analyzer-checker=core \
+// RUN:  -analyzer-checker=apiModeling.ReturnValue \
+// RUN:  -analyzer-config apiModeling.ReturnValue:Calls="error:true;error:false:ErrorHandler" \
+// RUN:  -analyzer-checker=debug.ExprInspection \
+// RUN:  -verify %s
+
+// FIXME: expected-no-diagnostics
+
+void clang_analyzer_eval(bool);
+void clang_analyzer_warnIfReached();
+
+
+struct Foo { int Field; };
+bool error();
+bool problem();
+void doSomething();
+
+// We predefine the return value of 'error()' to 'true' and we cannot take the
+// false-branches where error would occur.
+namespace test_calls {
+bool parseFoo(Foo ) {
+  if (problem())
+return error();
+
+  F.Field = 0;
+  return false;
+}
+
+bool parseFile() {
+  clang_analyzer_eval(error() == true); // FIXME: xpected-warning{{TRUE}}
+
+  Foo F;
+  if (parseFoo(F))
+return true;
+
+  if (F.Field == 0) {
+// no-warning: "The left operand of '==' is a garbage value" was here.
+doSomething();
+  }
+
+  return false;
+}
+} // namespace test_calls
+
+namespace test_classes {
+struct ErrorHandler {
+  static bool error();
+};
+
+bool parseFoo(Foo ) {
+  if (problem())
+return error();
+
+  F.Field = 0;
+  return ErrorHandler::error();
+}
+
+bool parseFile() {
+  Foo F;
+  if (parseFoo(F))
+return true;
+
+  if (F.Field == 0) {
+// no-warning: "The left operand of '==' is a garbage value" was here.
+doSomething();
+  }
+
+  return false;
+}
+} // namespace test_classes
+
+void test_note() {
+  clang_analyzer_eval(error() == true); // FIXME: xpected-warning{{TRUE}}
+  if (error())
+(void)(1 / !error());
+}
Index: clang/test/Analysis/analyzer-config.c
===
--- clang/test/Analysis/analyzer-config.c
+++ clang/test/Analysis/analyzer-config.c
@@ -9,6 +9,8 @@
 // CHECK-NEXT: alpha.clone.CloneChecker:ReportNormalClones = true
 // CHECK-NEXT: alpha.security.MmapWriteExec:MmapProtExec = 0x04
 // CHECK-NEXT: alpha.security.MmapWriteExec:MmapProtRead = 0x01
+// CHECK-NEXT: apiModeling.ReturnValue:Calls = ""
+// CHECK-NEXT: apiModeling.ReturnValue:Projects = "llvm"
 // CHECK-NEXT: avoid-suppressing-null-argument-paths = false
 // CHECK-NEXT: c++-allocator-inlining = true
 // CHECK-NEXT: c++-container-inlining = false
@@ -88,4 +90,4 @@
 // CHECK-NEXT: unroll-loops = false
 // CHECK-NEXT: widen-loops = false
 // CHECK-NEXT: [stats]
-// CHECK-NEXT: num-entries = 85
+// CHECK-NEXT: num-entries = 87
Index: clang/lib/StaticAnalyzer/Checkers/ReturnValueChecker.cpp
===
--- /dev/null
+++ clang/lib/StaticAnalyzer/Checkers/ReturnValueChecker.cpp
@@ -0,0 +1,156 @@
+//===- ReturnValueChecker - Applies guaranteed return values *- 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
+//
+//===--===//
+//
+// This defines ReturnValueChecker, which checks for calls with guaranteed
+// boolean return value. It ensures the return value of each function call.
+//
+//===--===//
+

[PATCH] D63718: [ADT] Implement llvm::bsearch() with std::partition_point()

2019-06-27 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63718



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

[PATCH] D63845: [WIP] Create a clang attribute that lets users specify LLVM attributes

2019-06-27 Thread Johannes Doerfert via Phabricator via cfe-commits

jdoerfert added a comment.

In D63845#1560605 , @aaron.ballman 
wrote:

> In D63845#1559995 , @lebedev.ri 
> wrote:
>
> > What's the target use-case here? What can't be solved with normal 
> > attributes?
>

With "normal" you mean something like `__attribute__((noescape))`? We don't 
have them for all attributes, I doubt we want to but I might be wrong.

>> I wonder if this should go to cfe+llvm -dev lists first, it's kinda 
>> intrusive.

This is not a review to get this in. Before anything happens an RFC will be 
issued and discussed. We'll use this to experiment and other people can do so 
as well.

>> I also wonder if all these should cause a clang diagnostic, at least under 
>> `-Wall`.

What do you mean?

>> How is versioning expected to be handled? New attribute vs old clang, and 
>> vice versa.

Unknown attributes are not necessarily a problem, they should compile fine 
ignoring the attribute, or am I wrong?

> Also, we already have the `annotate` attribute for passing information 
> through to LLVM. Why do we need four different ways to do this?

I didn't know that one, e.g., it is not in 
https://clang.llvm.org/docs/AttributeReference.html. I glanced it in clang and 
it did not seem to do the same thing, thus allowing to generate LLVM-IR 
attributes at the different positions. If it is, we should use it instead.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63845

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

[PATCH] D52847: [clang-doc] Handle anonymous namespaces

2019-06-27 Thread Julie Hockett via Phabricator via cfe-commits

juliehockett updated this revision to Diff 206979.

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

https://reviews.llvm.org/D52847

Files:
  clang-tools-extra/clang-doc/Representation.cpp
  clang-tools-extra/clang-doc/Representation.h
  clang-tools-extra/clang-doc/Serialize.cpp
  clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
  clang-tools-extra/unittests/clang-doc/SerializeTest.cpp

Index: clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
+++ clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
@@ -131,6 +131,7 @@
 
   NamespaceInfo *A = InfoAsNamespace(Infos[0].get());
   NamespaceInfo ExpectedA(EmptySID);
+  ExpectedA.Name = "@nonymous_namespace";
   CheckNamespaceInfo(, A);
 }
 
Index: clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
===
--- clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
+++ clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
@@ -132,9 +132,6 @@
   if (CreateDirectory(Path))
 return llvm::make_error("Unable to create directory.\n",
llvm::inconvertibleErrorCode());
-
-  if (Name.empty())
-Name = "GlobalNamespace";
   llvm::sys::path::append(Path, Name + Ext);
   return Path;
 }
@@ -222,8 +219,8 @@
 
 doc::Info *I = Reduced.get().get();
 
-auto InfoPath =
-getInfoOutputFile(OutDirectory, I->Namespace, I->Name, "." + Format);
+auto InfoPath = getInfoOutputFile(OutDirectory, I->Namespace,
+  I->extractName(), "." + Format);
 if (!InfoPath) {
   llvm::errs() << toString(InfoPath.takeError()) << "\n";
   continue;
Index: clang-tools-extra/clang-doc/Serialize.cpp
===
--- clang-tools-extra/clang-doc/Serialize.cpp
+++ clang-tools-extra/clang-doc/Serialize.cpp
@@ -270,13 +270,19 @@
 template 
 static void
 populateParentNamespaces(llvm::SmallVector ,
- const T *D) {
+ const T *D, bool ) {
   const auto *DC = dyn_cast(D);
   while ((DC = DC->getParent())) {
-if (const auto *N = dyn_cast(DC))
-  Namespaces.emplace_back(getUSRForDecl(N), N->getNameAsString(),
+if (const auto *N = dyn_cast(DC)) {
+  std::string Namespace;
+  if (N->isAnonymousNamespace()) {
+Namespace = "@nonymous_namespace";
+IsAnonymousNamespace = true;
+  } else
+Namespace = N->getNameAsString();
+  Namespaces.emplace_back(getUSRForDecl(N), Namespace,
   InfoType::IT_namespace);
-else if (const auto *N = dyn_cast(DC))
+} else if (const auto *N = dyn_cast(DC))
   Namespaces.emplace_back(getUSRForDecl(N), N->getNameAsString(),
   InfoType::IT_record);
 else if (const auto *N = dyn_cast(DC))
@@ -289,10 +295,11 @@
 }
 
 template 
-static void populateInfo(Info , const T *D, const FullComment *C) {
+static void populateInfo(Info , const T *D, const FullComment *C,
+ bool ) {
   I.USR = getUSRForDecl(D);
   I.Name = D->getNameAsString();
-  populateParentNamespaces(I.Namespace, D);
+  populateParentNamespaces(I.Namespace, D, IsInAnonymousNamespace);
   if (C) {
 I.Description.emplace_back();
 parseFullComment(C, I.Description.back());
@@ -301,8 +308,9 @@
 
 template 
 static void populateSymbolInfo(SymbolInfo , const T *D, const FullComment *C,
-   int LineNumber, StringRef Filename) {
-  populateInfo(I, D, C);
+   int LineNumber, StringRef Filename,
+   bool ) {
+  populateInfo(I, D, C, IsInAnonymousNamespace);
   if (D->isThisDeclarationADefinition())
 I.DefLoc.emplace(LineNumber, Filename);
   else
@@ -311,8 +319,9 @@
 
 static void populateFunctionInfo(FunctionInfo , const FunctionDecl *D,
  const FullComment *FC, int LineNumber,
- StringRef Filename) {
-  populateSymbolInfo(I, D, FC, LineNumber, Filename);
+ StringRef Filename,
+ bool ) {
+  populateSymbolInfo(I, D, FC, LineNumber, Filename, IsInAnonymousNamespace);
   if (const auto *T = getDeclForType(D->getReturnType())) {
 if (dyn_cast(T))
   I.ReturnType =
@@ -329,21 +338,28 @@
 std::unique_ptr emitInfo(const NamespaceDecl *D, const FullComment *FC,
int LineNumber, llvm::StringRef File,
bool PublicOnly) {
-  if (PublicOnly && ((D->isAnonymousNamespace()) ||
+  auto I = llvm::make_unique();
+  bool IsInAnonymousNamespace = false;
+  populateInfo(*I, D, FC, IsInAnonymousNamespace);
+  if (PublicOnly && ((IsInAnonymousNamespace || D->isAnonymousNamespace()) ||

[PATCH] D63911: [clang-doc] Serialize child namespaces and records

2019-06-27 Thread Julie Hockett via Phabricator via cfe-commits

juliehockett added inline comments.



Comment at: clang-tools-extra/clang-doc/Serialize.cpp:341
+  Parent->USR = ParentUSR;
+  Parent->ChildNamespaces.emplace_back(I->USR, I->Name, 
InfoType::IT_namespace);
+  return {std::unique_ptr{std::move(I)},

You're probably going to want the path in this too, here and below



Comment at: clang-tools-extra/clang-doc/Serialize.cpp:398
   I->ChildFunctions.emplace_back(std::move(Func));
-  return std::unique_ptr{std::move(I)};
+  return {std::unique_ptr{std::move(I)}, nullptr};
 }

Maybe return the parent in the second position, and then comment about how the 
info itself is wrapped in its parent scope? That would make more sense 
logically, and they all end up in the same place. Same for methods/enums.



Comment at: clang-tools-extra/clang-doc/Serialize.h:30
 
-std::unique_ptr emitInfo(const NamespaceDecl *D, const FullComment *FC,
-   int LineNumber, StringRef File, bool 
PublicOnly);
-std::unique_ptr emitInfo(const RecordDecl *D, const FullComment *FC,
-   int LineNumber, StringRef File, bool 
PublicOnly);
-std::unique_ptr emitInfo(const EnumDecl *D, const FullComment *FC,
-   int LineNumber, StringRef File, bool 
PublicOnly);
-std::unique_ptr emitInfo(const FunctionDecl *D, const FullComment *FC,
-   int LineNumber, StringRef File, bool 
PublicOnly);
-std::unique_ptr emitInfo(const CXXMethodDecl *D, const FullComment *FC,
-   int LineNumber, StringRef File, bool 
PublicOnly);
+std::pair, std::unique_ptr>
+emitInfo(const NamespaceDecl *D, const FullComment *FC, int LineNumber,

Comment here what each of these represents, e.g. the first info contains the 
relevant information about the declaration, the second records the parent.



Comment at: clang-tools-extra/unittests/clang-doc/SerializeTest.cpp:41-44
+if (I.first)
+  EmittedInfos.emplace_back(std::move(I.first));
+if (I.second)
+  EmittedInfos.emplace_back(std::move(I.second));

Extract this logic into a mapDecl function, since it's repeated so much



Comment at: clang-tools-extra/unittests/clang-doc/SerializeTest.cpp:362
+  NamespaceInfo *ParentA = InfoAsNamespace(Infos[1].get());
+  NamespaceInfo ExpectedParentA(EmptySID);
+  ExpectedParentA.ChildRecords.emplace_back(Infos[0]->USR, "A",

Just use the EmptySID -- the checking function ignores the USRs since they can 
be system-dependent. Here and below.


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

https://reviews.llvm.org/D63911



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

[PATCH] D62556: [analyzer] NFC: CallDescription: Implement describing C library functions.

2019-06-27 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ updated this revision to Diff 206978.
NoQ marked 4 inline comments as done.
NoQ added a comment.

Fxd.


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

https://reviews.llvm.org/D62556

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
  clang/lib/StaticAnalyzer/Core/CallEvent.cpp
  clang/unittests/StaticAnalyzer/CallDescriptionTest.cpp

Index: clang/unittests/StaticAnalyzer/CallDescriptionTest.cpp
===
--- clang/unittests/StaticAnalyzer/CallDescriptionTest.cpp
+++ clang/unittests/StaticAnalyzer/CallDescriptionTest.cpp
@@ -102,6 +102,16 @@
   {{"foo"}, true},
   }), "void foo(); struct bar { void foo(); }; void test() { foo(); }"));
 
+  EXPECT_TRUE(tooling::runToolOnCode(
+  new CallDescriptionAction({
+  {{"memset", 3}, false},
+  {{CDF_MaybeBuiltin, "memset", 3}, true}
+  }),
+  "void foo() {"
+  "  int x;"
+  "  __builtin___memset_chk(, 0, sizeof(x),"
+  " __builtin_object_size(, 0));"
+  "}"));
 }
 
 } // namespace
Index: clang/lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- clang/lib/StaticAnalyzer/Core/CallEvent.cpp
+++ clang/lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -356,20 +356,33 @@
   // FIXME: Add ObjC Message support.
   if (getKind() == CE_ObjCMessage)
 return false;
+
+  const IdentifierInfo *II = getCalleeIdentifier();
+  if (!II)
+return false;
+  const FunctionDecl *FD = dyn_cast_or_null(getDecl());
+  if (!FD)
+return false;
+
+  if (CD.Flags & CDF_MaybeBuiltin) {
+return CheckerContext::isCLibraryFunction(FD, CD.getFunctionName()) &&
+   (CD.RequiredArgs == CallDescription::NoArgRequirement ||
+CD.RequiredArgs <= getNumArgs());
+  }
+
   if (!CD.IsLookupDone) {
 CD.IsLookupDone = true;
 CD.II = ()->getStateManager().getContext().Idents.get(
 CD.getFunctionName());
   }
-  const IdentifierInfo *II = getCalleeIdentifier();
-  if (!II || II != CD.II)
+
+  if (II != CD.II)
 return false;
 
-  const Decl *D = getDecl();
   // If CallDescription provides prefix names, use them to improve matching
   // accuracy.
-  if (CD.QualifiedName.size() > 1 && D) {
-const DeclContext *Ctx = D->getDeclContext();
+  if (CD.QualifiedName.size() > 1 && FD) {
+const DeclContext *Ctx = FD->getDeclContext();
 // See if we'll be able to match them all.
 size_t NumUnmatched = CD.QualifiedName.size() - 1;
 for (; Ctx && isa(Ctx); Ctx = Ctx->getParent()) {
Index: clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
===
--- clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
+++ clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
@@ -1044,6 +1044,14 @@
   }
 };
 
+enum CallDescriptionFlags : int {
+  /// Describes a C standard function that is sometimes implemented as a macro
+  /// that expands to a compiler builtin with some __builtin prefix.
+  /// The builtin may as well have a few extra arguments on top of the requested
+  /// number of arguments.
+  CDF_MaybeBuiltin = 1 << 0,
+};
+
 /// This class represents a description of a function call using the number of
 /// arguments and the name of the function.
 class CallDescription {
@@ -1055,11 +1063,14 @@
   // e.g. "{a, b}" represent the qualified names, like "a::b".
   std::vector QualifiedName;
   unsigned RequiredArgs;
+  int Flags;
 
 public:
   const static unsigned NoArgRequirement = std::numeric_limits::max();
 
   /// Constructs a CallDescription object.
+  /// @param Flags A bitwise-or of CallDescriptionFlags that tweak
+  /// the matching behavior of the CallDescription object.
   ///
   /// @param QualifiedName The list of the name qualifiers of the function that
   /// will be matched. The user is allowed to skip any of the qualifiers.
@@ -1069,9 +1080,15 @@
   /// @param RequiredArgs The number of arguments that is expected to match a
   /// call. Omit this parameter to match every occurrence of call with a given
   /// name regardless the number of arguments.
+  CallDescription(int Flags, ArrayRef QualifiedName,
+  unsigned RequiredArgs = NoArgRequirement)
+  : QualifiedName(QualifiedName), RequiredArgs(RequiredArgs),
+Flags(Flags) {}
+
+  /// Construct a CallDescription with default flags.
   CallDescription(ArrayRef QualifiedName,
   unsigned RequiredArgs = NoArgRequirement)
-  : QualifiedName(QualifiedName), RequiredArgs(RequiredArgs) {}
+  : CallDescription(0, QualifiedName, RequiredArgs) {}
 
   /// Get the name of the function that this object matches.
   StringRef getFunctionName() const { return QualifiedName.back(); }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D62556: [analyzer] NFC: CallDescription: Implement describing C library functions.

2019-06-27 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added inline comments.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h:1064
   // e.g. "{a, b}" represent the qualified names, like "a::b".
   std::vector QualifiedName;
   unsigned RequiredArgs;

a_sidorin wrote:
> Not for this review, but why do we have a vector of `const char *`, not 
> StringRefs?
The constructor accepts `ArrayRef` rather than 
`ArrayRef` because `{ "foo", "bar" }` is not a valid initializer for 
`ArrayRef`. The field is the same for simplicity, as converting 
`ArrayRef` to a `vector` is annoying and not really 
useful. See also D51390.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h:1066
   unsigned RequiredArgs;
+  int Flags;
 

a_sidorin wrote:
> Is it a good idea to make Flags a bitfield structure?
This would prevent us from passing the flags into the constructor as `CDF_Foo | 
CDF_Bar` etc.- we'll have to specify every field on every line. I wanted to 
make the initializers as concise as possible to avoid line breaks in code like 
D62557.



Comment at: clang/lib/StaticAnalyzer/Core/CallEvent.cpp:379
+
   if (!II || II != CD.II)
 return false;

a_sidorin wrote:
> `!II` is never false due to the newly-introduced early return.
Right!


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

https://reviews.llvm.org/D62556



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

[PATCH] D63912: [ObjC] Add a warning for implicit conversions of a constant non-boolean value to BOOL

2019-06-27 Thread Erik Pilkington via Phabricator via cfe-commits

erik.pilkington created this revision.
erik.pilkington added reviewers: rjmccall, steven_wu.
Herald added subscribers: dexonsmith, jkorous.
Herald added a project: clang.
erik.pilkington added a reviewer: arphaman.

On macOS, BOOL is a typedef for signed char, but it should never hold a value 
that isn't 1 or 0. Any code that expects a different value in their BOOL should 
be fixed. See also D63856 .

rdar://problem/51954400 ObjC: Add diagnostics to catch incorrect usage of BOOL


Repository:
  rC Clang

https://reviews.llvm.org/D63912

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/objc-bool-constant-conversion-fixit.m
  clang/test/Sema/objc-bool-constant-conversion.m

Index: clang/test/Sema/objc-bool-constant-conversion.m
===
--- /dev/null
+++ clang/test/Sema/objc-bool-constant-conversion.m
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 %s -verify -fsyntax-only
+
+typedef signed char BOOL;
+#define YES __objc_yes
+#define NO __objc_no
+
+BOOL B;
+
+int main() {
+  B = 0;
+  B = 1;
+  B = YES;
+  B = NO;
+
+  B = -1; // expected-warning{{implicit conversion from -1 to BOOL; the only well defined values for BOOL are YES and NO}}
+  B = 0 - 1; // expected-warning{{implicit conversion from -1 to BOOL; the only well defined values for BOOL are YES and NO}}
+  B = YES + YES; // expected-warning {{implicit conversion from 2 to BOOL; the only well defined values for BOOL are YES and NO}}
+  B = YES | YES;
+
+  B = B ? 2 : 2; // expected-warning 2 {{implicit conversion from 2 to BOOL; the only well defined values for BOOL are YES and NO}}
+
+  BOOL Init = -1; // expected-warning{{implicit conversion from -1 to BOOL; the only well defined values for BOOL are YES and NO}}
+  BOOL Init2 = B ? 2 : 2; // expected-warning 2 {{implicit conversion from 2 to BOOL; the only well defined values for BOOL are YES and NO}}
+
+  void takesbool(BOOL);
+  takesbool(43); // expected-warning {{implicit conversion from 43 to BOOL; the only well defined values for BOOL are YES and NO}}
+
+  BOOL OutOfRange = 400; // expected-warning{{implicit conversion from 400 to BOOL; the only well defined values for BOOL are YES and NO}}
+}
+
+@interface BoolProp
+@property BOOL b;
+@end
+
+void f(BoolProp *bp) {
+  bp.b = 43; // expected-warning {{implicit conversion from 43 to BOOL; the only well defined values for BOOL are YES and NO}}
+  [bp setB:43]; // expected-warning {{implicit conversion from 43 to BOOL; the only well defined values for BOOL are YES and NO}}
+}
Index: clang/test/Sema/objc-bool-constant-conversion-fixit.m
===
--- /dev/null
+++ clang/test/Sema/objc-bool-constant-conversion-fixit.m
@@ -0,0 +1,40 @@
+// RUN: %clang_cc1 -Werror=constant-conversion %s -fixit-recompile -fixit-to-temporary -E -o - | FileCheck %s
+
+typedef signed char BOOL;
+
+BOOL b;
+
+int main() {
+  BOOL b = 2;
+  // CHECK: BOOL b = 2 ? YES : NO;
+
+  b = b ? 2 : 1;
+  // CHECK: b = b ? 2 ? YES : NO : 1;
+
+  b = b ? 1 : 2;
+  // CHECK: b = b ? 1 : 2 ? YES : NO;
+
+  b = b ? 2 : 2;
+  // CHECK: b = b ? 2 ? YES : NO : 2 ? YES : NO;
+
+  b = 1 + 1;
+  // CHECK: b = (1 + 1) ? YES : NO;
+
+  b = 1 | 2;
+  // CHECK: b = (1 | 2) ? YES : NO;
+
+  b = 1 << 1;
+  // CHECK: b = (1 << 1) ? YES : NO;
+}
+
+@interface BoolProp
+@property BOOL b;
+@end
+
+void f(BoolProp *bp) {
+  bp.b = 43;
+  // CHECK: bp.b = 43 ? YES : NO;
+
+  [bp setB:43];
+  // CHECK: [bp setB:43 ? YES : NO];
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -6,6 +6,11 @@
   return true;
 }
 
+static bool isObjCSignedCharBool(Sema , QualType Ty) {
+  return Ty->isSpecificBuiltinType(BuiltinType::SChar) &&
+ S.getLangOpts().ObjC && S.NSAPIObj->isObjCBOOLType(Ty);
+}
+
 static void
 CheckImplicitConversion(Sema , Expr *E, QualType T, SourceLocation CC,
 bool *ICContext = nullptr) {
@@ -11159,6 +11164,29 @@
 }
   }
 
+  // If the we're converting a constant to an ObjC BOOL on a platform where BOOL
+  // is a typedef for signed char (macOS), then that constant value has to be 1
+  // or 0.
+  if (isObjCSignedCharBool(S, T) && Source->isIntegralType(S.Context)) {
+Expr::EvalResult Result;
+if (E->EvaluateAsInt(Result, S.getASTContext(),
+ Expr::SE_AllowSideEffects) &&
+Result.Val.getInt() != 1 && Result.Val.getInt() != 0) {
+  auto Builder = S.Diag(CC, diag::warn_impcast_constant_int_to_objc_bool)
+ << Result.Val.getInt().toString(10);
+  Expr *Ignored = E->IgnoreImplicit();
+  bool NeedsParens = isa(Ignored) ||
+ isa(Ignored) ||
+ isa(Ignored);
+  SourceLocation EndLoc =

[PATCH] D63911: [clang-doc] Serialize child namespaces and records

2019-06-27 Thread Diego Astiazarán via Phabricator via cfe-commits

DiegoAstiazaran created this revision.
DiegoAstiazaran added reviewers: juliehockett, jakehehrlich, lebedev.ri.
DiegoAstiazaran added a project: clang-tools-extra.

Serialization of child namespaces and records is now handled.
Namespaces can have child records and child namespaces.
Records can only have child records.


https://reviews.llvm.org/D63911

Files:
  clang-tools-extra/clang-doc/Mapper.cpp
  clang-tools-extra/clang-doc/Serialize.cpp
  clang-tools-extra/clang-doc/Serialize.h
  clang-tools-extra/unittests/clang-doc/SerializeTest.cpp

Index: clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
+++ clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
@@ -38,8 +38,10 @@
   bool VisitNamespaceDecl(const NamespaceDecl *D) {
 auto I = serialize::emitInfo(D, getComment(D), /*Line=*/0,
  /*File=*/"test.cpp", Public);
-if (I)
-  EmittedInfos.emplace_back(std::move(I));
+if (I.first)
+  EmittedInfos.emplace_back(std::move(I.first));
+if (I.second)
+  EmittedInfos.emplace_back(std::move(I.second));
 return true;
   }
 
@@ -49,32 +51,40 @@
   return true;
 auto I = serialize::emitInfo(D, getComment(D), /*Line=*/0,
  /*File=*/"test.cpp", Public);
-if (I)
-  EmittedInfos.emplace_back(std::move(I));
+if (I.first)
+  EmittedInfos.emplace_back(std::move(I.first));
+if (I.second)
+  EmittedInfos.emplace_back(std::move(I.second));
 return true;
   }
 
   bool VisitCXXMethodDecl(const CXXMethodDecl *D) {
 auto I = serialize::emitInfo(D, getComment(D), /*Line=*/0,
  /*File=*/"test.cpp", Public);
-if (I)
-  EmittedInfos.emplace_back(std::move(I));
+if (I.first)
+  EmittedInfos.emplace_back(std::move(I.first));
+if (I.second)
+  EmittedInfos.emplace_back(std::move(I.second));
 return true;
   }
 
   bool VisitRecordDecl(const RecordDecl *D) {
 auto I = serialize::emitInfo(D, getComment(D), /*Line=*/0,
  /*File=*/"test.cpp", Public);
-if (I)
-  EmittedInfos.emplace_back(std::move(I));
+if (I.first)
+  EmittedInfos.emplace_back(std::move(I.first));
+if (I.second)
+  EmittedInfos.emplace_back(std::move(I.second));
 return true;
   }
 
   bool VisitEnumDecl(const EnumDecl *D) {
 auto I = serialize::emitInfo(D, getComment(D), /*Line=*/0,
  /*File=*/"test.cpp", Public);
-if (I)
-  EmittedInfos.emplace_back(std::move(I));
+if (I.first)
+  EmittedInfos.emplace_back(std::move(I.first));
+if (I.second)
+  EmittedInfos.emplace_back(std::move(I.second));
 return true;
   }
 };
@@ -101,19 +111,19 @@
 // Test serialization of namespace declarations.
 TEST(SerializeTest, emitNamespaceInfo) {
   EmittedInfoList Infos;
-  ExtractInfosFromCode("namespace A { namespace B { void f() {} } }", 3,
+  ExtractInfosFromCode("namespace A { namespace B { void f() {} } }", 5,
/*Public=*/false, Infos);
 
   NamespaceInfo *A = InfoAsNamespace(Infos[0].get());
   NamespaceInfo ExpectedA(EmptySID, "A");
   CheckNamespaceInfo(, A);
 
-  NamespaceInfo *B = InfoAsNamespace(Infos[1].get());
+  NamespaceInfo *B = InfoAsNamespace(Infos[2].get());
   NamespaceInfo ExpectedB(EmptySID, "B");
   ExpectedB.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
   CheckNamespaceInfo(, B);
 
-  NamespaceInfo *BWithFunction = InfoAsNamespace(Infos[2].get());
+  NamespaceInfo *BWithFunction = InfoAsNamespace(Infos[4].get());
   NamespaceInfo ExpectedBWithFunction(EmptySID);
   FunctionInfo F;
   F.Name = "f";
@@ -127,7 +137,7 @@
 
 TEST(SerializeTest, emitAnonymousNamespaceInfo) {
   EmittedInfoList Infos;
-  ExtractInfosFromCode("namespace { }", 1, /*Public=*/false, Infos);
+  ExtractInfosFromCode("namespace { }", 2, /*Public=*/false, Infos);
 
   NamespaceInfo *A = InfoAsNamespace(Infos[0].get());
   NamespaceInfo ExpectedA(EmptySID);
@@ -142,7 +152,8 @@
   E() {}
 protected:
   void ProtectedMethod();
-};)raw", 3, /*Public=*/false, Infos);
+};)raw",
+   4, /*Public=*/false, Infos);
 
   RecordInfo *E = InfoAsRecord(Infos[0].get());
   RecordInfo ExpectedE(EmptySID, "E");
@@ -150,7 +161,7 @@
   ExpectedE.DefLoc = Location(0, llvm::SmallString<16>{"test.cpp"});
   CheckRecordInfo(, E);
 
-  RecordInfo *RecordWithEConstructor = InfoAsRecord(Infos[1].get());
+  RecordInfo *RecordWithEConstructor = InfoAsRecord(Infos[2].get());
   RecordInfo ExpectedRecordWithEConstructor(EmptySID);
   FunctionInfo EConstructor;
   EConstructor.Name = "E";
@@ -164,7 +175,7 @@
   std::move(EConstructor));
   CheckRecordInfo(, RecordWithEConstructor);
 
-  RecordInfo *RecordWithMethod = InfoAsRecord(Infos[2].get());
+  RecordInfo *RecordWithMethod = InfoAsRecord(Infos[3].get());

[PATCH] D63908: hwasan: Improve precision of checks using short granule tags.

2019-06-27 Thread Peter Collingbourne via Phabricator via cfe-commits

pcc created this revision.
pcc added a reviewer: eugenis.
Herald added subscribers: Sanitizers, cfe-commits, jfb, hiraditya, javed.absar, 
kubamracek.
Herald added projects: clang, Sanitizers, LLVM.

A short granule is a granule of size between 1 and `TG-1` bytes. The size
of a short granule is stored at the location in shadow memory where the
granule's tag is normally stored, while the granule's actual tag is stored
in the last byte of the granule. This means that in order to verify that a
pointer tag matches a memory tag, HWASAN must check for two possibilities:

- the pointer tag is equal to the memory tag in shadow memory, or
- the shadow memory tag is actually a short granule size, the value being 
loaded is in bounds of the granule and the pointer tag is equal to the last 
byte of the granule.

Pointer tags between 1 to `TG-1` are possible and are as likely as any other
tag. This means that these tags in memory have two interpretations: the full
tag interpretation (where the pointer tag is between 1 and `TG-1` and the
last byte of the granule is ordinary data) and the short tag interpretation
(where the pointer tag is stored in the granule).

When HWASAN detects an error near a memory tag between 1 and `TG-1`, it
will show both the memory tag and the last byte of the granule. Currently,
it is up to the user to disambiguate the two possibilities.

Because this functionality obsoletes the right aligned heap feature of
the HWASAN memory allocator (and because we can no longer easily test
it), the feature is removed.

Also update the documentation to cover both short granule tags and
outlined checks.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63908

Files:
  clang/docs/HardwareAssistedAddressSanitizerDesign.rst
  compiler-rt/lib/hwasan/hwasan_allocator.cpp
  compiler-rt/lib/hwasan/hwasan_checks.h
  compiler-rt/lib/hwasan/hwasan_flags.inc
  compiler-rt/lib/hwasan/hwasan_report.cpp
  compiler-rt/lib/hwasan/hwasan_report.h
  compiler-rt/test/hwasan/TestCases/heap-buffer-overflow.c
  compiler-rt/test/hwasan/TestCases/random-align-right.c
  compiler-rt/test/hwasan/TestCases/stack-oob.c
  compiler-rt/test/hwasan/TestCases/tail-magic.c
  llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
  llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
  llvm/test/CodeGen/AArch64/hwasan-check-memaccess.ll
  llvm/test/Instrumentation/HWAddressSanitizer/alloca-with-calls.ll
  llvm/test/Instrumentation/HWAddressSanitizer/alloca.ll
  llvm/test/Instrumentation/HWAddressSanitizer/basic.ll
  llvm/test/Instrumentation/HWAddressSanitizer/kernel-alloca.ll

Index: llvm/test/Instrumentation/HWAddressSanitizer/kernel-alloca.ll
===
--- llvm/test/Instrumentation/HWAddressSanitizer/kernel-alloca.ll
+++ llvm/test/Instrumentation/HWAddressSanitizer/kernel-alloca.ll
@@ -14,9 +14,10 @@
 ; CHECK: %[[B:[^ ]*]] = lshr i64 %[[A]], 20
 ; CHECK: %[[BASE_TAG:[^ ]*]] = xor i64 %[[A]], %[[B]]
 
-; CHECK: %[[X:[^ ]*]] = alloca i32, align 16
+; CHECK: %[[X:[^ ]*]] = alloca { i32, [12 x i8] }, align 16
+; CHECK: %[[X_GEP:[^ ]*]] = getelementptr { i32, [12 x i8] }, { i32, [12 x i8] }* %[[X]], i32 0, i32 0
 ; CHECK: %[[X_TAG:[^ ]*]] = xor i64 %[[BASE_TAG]], 0
-; CHECK: %[[X1:[^ ]*]] = ptrtoint i32* %[[X]] to i64
+; CHECK: %[[X1:[^ ]*]] = ptrtoint i32* %[[X_GEP]] to i64
 ; CHECK: %[[C:[^ ]*]] = shl i64 %[[X_TAG]], 56
 ; CHECK: %[[D:[^ ]*]] = or i64 %[[C]], 72057594037927935
 ; CHECK: %[[E:[^ ]*]] = and i64 %[[X1]], %[[D]]
Index: llvm/test/Instrumentation/HWAddressSanitizer/basic.ll
===
--- llvm/test/Instrumentation/HWAddressSanitizer/basic.ll
+++ llvm/test/Instrumentation/HWAddressSanitizer/basic.ll
@@ -28,11 +28,35 @@
 ; RECOVER-ZERO-BASED-SHADOW: %[[E:[^ ]*]] = inttoptr i64 %[[D]] to i8*
 ; RECOVER: %[[MEMTAG:[^ ]*]] = load i8, i8* %[[E]]
 ; RECOVER: %[[F:[^ ]*]] = icmp ne i8 %[[PTRTAG]], %[[MEMTAG]]
-; RECOVER: br i1 %[[F]], label {{.*}}, label {{.*}}, !prof {{.*}}
+; RECOVER: br i1 %[[F]], label %[[MISMATCH:[0-9]*]], label %[[CONT:[0-9]*]], !prof {{.*}}
+
+; RECOVER: [[MISMATCH]]:
+; RECOVER: %[[NOTSHORT:[^ ]*]] = icmp ugt i8 %[[MEMTAG]], 15
+; RECOVER: br i1 %[[NOTSHORT]], label %[[FAIL:[0-9]*]], label %[[SHORT:[0-9]*]], !prof {{.*}}
 
+; RECOVER: [[FAIL]]:
 ; RECOVER: call void asm sideeffect "brk #2336", "{x0}"(i64 %[[A]])
 ; RECOVER: br label
 
+; RECOVER: [[SHORT]]:
+; RECOVER: %[[LOWBITS:[^ ]*]] = and i64 %[[A]], 15
+; RECOVER: %[[LOWBITS_I8:[^ ]*]] = trunc i64 %[[LOWBITS]] to i8
+; RECOVER: %[[LAST:[^ ]*]] = add i8 %[[LOWBITS_I8]], 0
+; RECOVER: %[[OOB:[^ ]*]] = icmp uge i8 %[[LAST]], %[[MEMTAG]]
+; RECOVER: br i1 %[[OOB]], label %[[FAIL]], label %[[INBOUNDS:[0-9]*]], !prof {{.*}}
+
+; RECOVER: [[INBOUNDS]]:
+; RECOVER: %[[EOG_ADDR:[^ ]*]] = or i64 %[[C]], 15
+; RECOVER: %[[EOG_PTR:[^ ]*]] = inttoptr i64 %[[EOG_ADDR]] to i8*
+; RECOVER: %[[EOGTAG:[^ ]*]] = load i8, i8* %[[EOG_PTR]]
+; RECOVER:

[PATCH] D63907: [clang-scan-deps] Implementation of dependency scanner over minimized sources

2019-06-27 Thread Alex Lorenz via Phabricator via cfe-commits

arphaman created this revision.
arphaman added reviewers: Bigcheese, aganea.
Herald added subscribers: tschuett, dexonsmith, jkorous, mgorny.
Herald added a project: clang.

This patch implements the fast dependency scanning mode in `clang-scan-deps`: 
the preprocessing is done on files that are minimized using the dependency 
directives source minimizer.

A shared file system cache is used to ensure that the file system requests and 
source minimization is performed only once. The cache assumes that the 
underlying filesystem won't change during the course of the scan (or if it 
will, it will not affect the output), and it can't be evicted. This means that 
the service and workers can be used for a single run of a dependency scanner, 
and can't be reused across multiple, incremental runs. This is something that 
we'll most likely support in the future though. Note that the driver still 
utilizes the underlying real filesystem.

This patch is also still missing the fast skipped PP block skipping 
optimization that I mentioned at EuroLLVM talk.


Repository:
  rC Clang

https://reviews.llvm.org/D63907

Files:
  clang/include/clang/Basic/FileManager.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningFilesystem.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningService.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/lib/Tooling/DependencyScanning/CMakeLists.txt
  clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  
clang/test/ClangScanDeps/Inputs/frameworks/Framework.framework/Headers/Framework.h
  
clang/test/ClangScanDeps/Inputs/frameworks/Framework.framework/PrivateHeaders/PrivateHeader.h
  clang/test/ClangScanDeps/Inputs/header_stat_before_open_cdb.json
  clang/test/ClangScanDeps/Inputs/vfsoverlay.yaml
  clang/test/ClangScanDeps/Inputs/vfsoverlay_cdb.json
  clang/test/ClangScanDeps/header_stat_before_open.m
  clang/test/ClangScanDeps/regular_cdb.cpp
  clang/test/ClangScanDeps/vfsoverlay.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -8,6 +8,7 @@
 
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Tooling/CommonOptionsParser.h"
+#include "clang/Tooling/DependencyScanning/DependencyScanningService.h"
 #include "clang/Tooling/DependencyScanning/DependencyScanningWorker.h"
 #include "clang/Tooling/JSONCompilationDatabase.h"
 #include "llvm/Support/InitLLVM.h"
@@ -45,9 +46,10 @@
   ///
   /// \param Compilations The reference to the compilation database that's
   /// used by the clang tool.
-  DependencyScanningTool(const tooling::CompilationDatabase ,
+  DependencyScanningTool(DependencyScanningService ,
+ const tooling::CompilationDatabase ,
  SharedStream , SharedStream )
-  : Compilations(Compilations), OS(OS), Errs(Errs) {}
+  : Worker(Service), Compilations(Compilations), OS(OS), Errs(Errs) {}
 
   /// Computes the dependencies for the given file and prints them out.
   ///
@@ -80,6 +82,20 @@
 
 llvm::cl::OptionCategory DependencyScannerCategory("Tool options");
 
+static llvm::cl::opt ScanMode(
+"mode",
+llvm::cl::desc("The preprocessing mode used to compute the dependencies"),
+llvm::cl::values(
+clEnumValN(ScanningMode::MinimizedSourcePreprocessing,
+   "preprocess-minimized-sources",
+   "The set of dependencies is computed by preprocessing the "
+   "source files that were minimized to only include the "
+   "contents that might affect the dependencies"),
+clEnumValN(ScanningMode::CanonicalPreprocessing, "preprocess",
+   "The set of dependencies is computed by preprocessing the "
+   "unmodified source files")),
+llvm::cl::init(ScanningMode::MinimizedSourcePreprocessing));
+
 llvm::cl::opt
 NumThreads("j", llvm::cl::Optional,
llvm::cl::desc("Number of worker threads to use (default: use "
@@ -135,12 +151,14 @@
   SharedStream Errs(llvm::errs());
   // Print out the dependency results to STDOUT by default.
   SharedStream DependencyOS(llvm::outs());
+
+  DependencyScanningService Service(ScanMode);
   unsigned NumWorkers =
   NumThreads == 0 ? llvm::hardware_concurrency() : NumThreads;
   std::vector> WorkerTools;
   for (unsigned I = 0; I < NumWorkers; ++I)
 WorkerTools.push_back(llvm::make_unique(
-*AdjustingCompilations, DependencyOS, Errs));
+Service, *AdjustingCompilations, DependencyOS, Errs));
 
   std::vector WorkerThreads;
   std::atomic HadErrors(false);
Index:

[PATCH] D63048: Update VERSION to remove the hardcoded 4.2.1 version

2019-06-27 Thread Reid Kleckner via Phabricator via cfe-commits

rnk added a comment.

I'd be in favor of removing them.


Repository:
  rC Clang

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

https://reviews.llvm.org/D63048



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

[PATCH] D63533: [analyzer] Fix clang-tidy crash on GCCAsmStmt

2019-06-27 Thread Nathan Huckleberry via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL364605: [analyzer] Fix clang-tidy crash on GCCAsmStmt 
(authored by Nathan-Huckleberry, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63533?vs=206954=206956#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63533

Files:
  cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
  cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp


Index: cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
+++ cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify 
%s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() && "Encountered GCCAsmStmt 
without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 


Index: cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
+++ cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify %s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() && "Encountered GCCAsmStmt without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r364605 - [analyzer] Fix clang-tidy crash on GCCAsmStmt

2019-06-27 Thread Nathan Huckleberry via cfe-commits

Author: nathan-huckleberry
Date: Thu Jun 27 15:46:40 2019
New Revision: 364605

URL: http://llvm.org/viewvc/llvm-project?rev=364605=rev
Log:
[analyzer] Fix clang-tidy crash on GCCAsmStmt

Summary:
Added entry in switch statement to recognize GCCAsmStmt
as a possible block terminator.

Handling to build CFG using GCCAsmStmt was already implemented.

Reviewers: nickdesaulniers, george.karpenkov, NoQ

Reviewed By: nickdesaulniers, NoQ

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

Tags: #clang

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

Added:
cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
Modified:
cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp?rev=364605=364604=364605=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/CoreEngine.cpp Thu Jun 27 15:46:40 2019
@@ -396,6 +396,11 @@ void CoreEngine::HandleBlockExit(const C
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() && "Encountered GCCAsmStmt 
without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 

Added: cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp?rev=364605=auto
==
--- cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp (added)
+++ cfe/trunk/test/Analysis/egraph-asm-goto-no-crash.cpp Thu Jun 27 15:46:40 
2019
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify 
%s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}


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

[PATCH] D63533: [analyzer] Fix clang-tidy crash on GCCAsmStmt

2019-06-27 Thread Nathan Huckleberry via Phabricator via cfe-commits

Nathan-Huckleberry updated this revision to Diff 206954.
Nathan-Huckleberry added a comment.

- Minor style change on assert


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63533

Files:
  clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
  clang/test/Analysis/egraph-asm-goto-no-crash.cpp


Index: clang/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- /dev/null
+++ clang/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify 
%s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() && "Encountered GCCAsmStmt 
without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 


Index: clang/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- /dev/null
+++ clang/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify %s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() && "Encountered GCCAsmStmt without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libclc] r364604 - Creating release candidate rc3 from release_801 branch

2019-06-27 Thread Tom Stellard via cfe-commits

Author: tstellar
Date: Thu Jun 27 15:33:04 2019
New Revision: 364604

URL: http://llvm.org/viewvc/llvm-project?rev=364604=rev
Log:
Creating release candidate rc3 from release_801 branch

Added:
libclc/tags/RELEASE_801/rc3/
  - copied from r364603, libclc/branches/release_80/

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

[libunwind] r364604 - Creating release candidate rc3 from release_801 branch

2019-06-27 Thread Tom Stellard via cfe-commits

Author: tstellar
Date: Thu Jun 27 15:33:04 2019
New Revision: 364604

URL: http://llvm.org/viewvc/llvm-project?rev=364604=rev
Log:
Creating release candidate rc3 from release_801 branch

Added:
libunwind/tags/RELEASE_801/rc3/
  - copied from r364603, libunwind/branches/release_80/

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

[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

2019-06-27 Thread Richard Smith - zygoloid via Phabricator via cfe-commits

rsmith accepted this revision.
rsmith added inline comments.
This revision is now accepted and ready to land.



Comment at: lib/Sema/SemaExprCXX.cpp:7762-7764
+  llvm::SmallDenseMap NewTransformCache;
+  auto SavedTransformCache = TransformCache;
+  TransformCache = NewTransformCache;

dgoldman wrote:
> Should I do the same `std::move` and `clear` here as well?
Yes, please.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62648



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

[PATCH] D62441: [analyzer] NFC: Introduce a convenient CallDescriptionMap class.

2019-06-27 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ updated this revision to Diff 206951.
NoQ added a comment.

Indeed. Subtle!


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

https://reviews.llvm.org/D62441

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
  clang/unittests/StaticAnalyzer/CMakeLists.txt
  clang/unittests/StaticAnalyzer/CallDescriptionTest.cpp
  clang/unittests/StaticAnalyzer/Reusables.h

Index: clang/unittests/StaticAnalyzer/Reusables.h
===
--- clang/unittests/StaticAnalyzer/Reusables.h
+++ clang/unittests/StaticAnalyzer/Reusables.h
@@ -17,16 +17,24 @@
 namespace clang {
 namespace ento {
 
+// Find a node in the current AST that matches a matcher.
+template 
+const T *findNode(const Decl *Where, MatcherT What) {
+  using namespace ast_matchers;
+  auto Matches = match(decl(hasDescendant(What.bind("root"))),
+   *Where, Where->getASTContext());
+  assert(Matches.size() <= 1 && "Ambiguous match!");
+  assert(Matches.size() >= 1 && "Match not found!");
+  const T *Node = selectFirst("root", Matches);
+  assert(Node && "Type mismatch!");
+  return Node;
+}
+
 // Find a declaration in the current AST by name.
 template 
 const T *findDeclByName(const Decl *Where, StringRef Name) {
   using namespace ast_matchers;
-  auto Matcher = decl(hasDescendant(namedDecl(hasName(Name)).bind("d")));
-  auto Matches = match(Matcher, *Where, Where->getASTContext());
-  assert(Matches.size() == 1 && "Ambiguous name!");
-  const T *Node = selectFirst("d", Matches);
-  assert(Node && "Name not found!");
-  return Node;
+  return findNode(Where, namedDecl(hasName(Name)));
 }
 
 // A re-usable consumer that constructs ExprEngine out of CompilerInvocation.
Index: clang/unittests/StaticAnalyzer/CallDescriptionTest.cpp
===
--- /dev/null
+++ clang/unittests/StaticAnalyzer/CallDescriptionTest.cpp
@@ -0,0 +1,109 @@
+//===- unittests/StaticAnalyzer/CallDescriptionTest.cpp ---===//
+//
+// 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 "Reusables.h"
+
+#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
+#include "clang/Tooling/Tooling.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace ento {
+namespace {
+
+// Test that we can put a value into an int-type variable and load it
+// back from that variable. Test what happens if default bindings are used.
+class CallDescriptionConsumer : public ExprEngineConsumer {
+  const CallDescriptionMap 
+  void performTest(const Decl *D) {
+using namespace ast_matchers;
+
+if (!D->hasBody())
+  return;
+
+const CallExpr *CE = findNode(D, callExpr());
+const StackFrameContext *SFC =
+Eng.getAnalysisDeclContextManager().getStackFrame(D);
+ProgramStateRef State = Eng.getInitialState(SFC);
+CallEventRef<> Call =
+Eng.getStateManager().getCallEventManager().getCall(CE, State, SFC);
+
+const bool *LookupResult = CDM.lookup(*Call);
+// Check that we've found the function in the map
+// with the correct description.
+assert(LookupResult && *LookupResult);
+  }
+
+public:
+  CallDescriptionConsumer(CompilerInstance ,
+  const CallDescriptionMap )
+  : ExprEngineConsumer(C), CDM(CDM) {}
+
+  bool HandleTopLevelDecl(DeclGroupRef DG) override {
+for (const auto *D : DG)
+  performTest(D);
+return true;
+  }
+};
+
+class CallDescriptionAction : public ASTFrontendAction {
+  const CallDescriptionMap 
+
+public:
+  CallDescriptionAction(const CallDescriptionMap ) : CDM(CDM) {}
+
+  std::unique_ptr CreateASTConsumer(CompilerInstance ,
+ StringRef File) override {
+return llvm::make_unique(Compiler, CDM);
+  }
+};
+
+TEST(CallEvent, CallDescription) {
+  // Test simple name matching.
+  EXPECT_TRUE(tooling::runToolOnCode(
+  new CallDescriptionAction({
+  {{"bar"}, false},
+  {{"foo"}, true},
+  }), "void foo(); void bar() { foo(); }"));
+
+  // Test arguments check.
+  EXPECT_TRUE(tooling::runToolOnCode(
+  new CallDescriptionAction({
+  {{"foo", 1}, true},
+  {{"foo", 2}, false},
+  }), "void foo(int); void foo(int, int); void bar() { foo(1); }"));
+
+  // Test qualified names.
+  EXPECT_TRUE(tooling::runToolOnCode(
+  new CallDescriptionAction({
+  {{{"std", "basic_string", "c_str"}}, true},
+  }),
+  "namespace std { inline namespace __1 {"
+  "  template class basic_string {"
+  "  public:"
+  "T *c_str();"
+  "  };"
+  "}}"
+  "void foo() {"
+  "  using namespace std;"
+  "  basic_string s;"
+  "  s.c_str();"
+

[PATCH] D63623: [clang-tidy] new check: bugprone-posix-return

2019-06-27 Thread Jian Cai via Phabricator via cfe-commits

jcai19 updated this revision to Diff 206947.
jcai19 added a comment.

Update test names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63623

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/PosixReturnCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/PosixReturnCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-posix-return.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp

Index: clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp
@@ -0,0 +1,127 @@
+// RUN: %check_clang_tidy %s bugprone-posix-return %t
+
+#define NULL nullptr
+#define ZERO 0
+#define NEGATIVE_ONE -1
+
+typedef long off_t;
+typedef decltype(sizeof(int)) size_t;
+typedef int pid_t;
+typedef struct __posix_spawn_file_actions* posix_spawn_file_actions_t;
+typedef struct __posix_spawnattr* posix_spawnattr_t;
+
+extern "C" int posix_fadvise(int fd, off_t offset, off_t len, int advice);
+extern "C" int posix_fallocate(int fd, off_t offset, off_t len);
+extern "C" int posix_madvise(void *addr, size_t len, int advice);
+extern "C" int posix_memalign(void **memptr, size_t alignment, size_t size);
+extern "C" int posix_openpt(int flags);
+extern "C" int posix_spawn(pid_t *pid, const char *path,
+const posix_spawn_file_actions_t *file_actions,
+const posix_spawnattr_t *attrp,
+char *const argv[], char *const envp[]);
+extern "C" int posix_spawnp(pid_t *pid, const char *file,
+ const posix_spawn_file_actions_t *file_actions,
+ const posix_spawnattr_t *attrp,
+ char *const argv[], char *const envp[]);
+
+void warningLessThanZero() {
+  if (posix_fadvise(0, 0, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+  // CHECK-FIXES: posix_fadvise(0, 0, 0, 0) > 0
+  if (posix_fallocate(0, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:32: warning:
+  // CHECK-FIXES: posix_fallocate(0, 0, 0) > 0
+  if (posix_madvise(NULL, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  // CHECK-FIXES: posix_madvise(NULL, 0, 0) > 0
+  if (posix_memalign(NULL, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning:
+  // CHECK-FIXES: posix_memalign(NULL, 0, 0) > 0
+  if (posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:59: warning:
+  // CHECK-FIXES: posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) > 0
+  if (posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:60: warning:
+  // CHECK-FIXES: posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) > 0
+}
+
+void warningAlwaysTrue() {
+  if (posix_fadvise(0, 0, 0, 0) >= 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+}
+
+void warningEqualsNegative() {
+  if (posix_fadvise(0, 0, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+  if (posix_fadvise(0, 0, 0, 0) != -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) <= -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) < -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fallocate(0, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:32: warning:
+  if (posix_madvise(NULL, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_memalign(NULL, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning:
+  if (posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:59: warning:
+  if (posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:60: warning:
+}
+
+void WarningWithMacro() {
+  if (posix_fadvise(0, 0, 0, 0) < ZERO) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  // CHECK-FIXES: posix_fadvise(0, 0, 0, 0) > ZERO
+  if (posix_fadvise(0, 0, 0, 0) >= ZERO) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) == NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) != NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) <= NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) < NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+}
+
+void noWarning() {
+  if (posix_openpt(0) < 0) {}
+  if (posix_openpt(0) <= 0) {}
+  if (posix_openpt(0) == -1) {}
+  if (posix_openpt(0) != -1) {}
+  if (posix_openpt(0) <= -1) {}
+  if (posix_openpt(0) < -1) {}
+  if

[PATCH] D63623: [clang-tidy] new check: bugprone-posix-return

2019-06-27 Thread Jian Cai via Phabricator via cfe-commits

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



Comment at: clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp:96
+  if (posix_fadvise(0, 0, 0, 0) < 0) {}
+  if (posix_fadvise(0, 0, 0, 0) >= 0) {} else {}
+  if (posix_fadvise(0, 0, 0, 0) == -1) {}

gribozavr wrote:
> jcai19 wrote:
> > gribozavr wrote:
> > > Shouldn't there be a warning in the else branch?
> > This check only matches calls to the POSIX functions in the global scope, 
> > not member functions or functions defined within namespaces. Although in 
> > the global scope,  this particular case will still pass as there won't be a 
> > ``<`` binary operator for the else branch so no matching will happen.
> Sorry, yes, that's what I meant -- if we warn on `< 0`, then we should warn 
> on the else branch of `>=`. I just commented on the wrong test -- sorry about 
> that.
Thanks for the clarification. Actually >= 0 is always true since the call 
return 0 on success and a positive value on error, so the else branch will 
never be reached. I have update my check and the warning message to reflect 
this. Good catch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63623



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

[PATCH] D63623: [clang-tidy] new check: bugprone-posix-return

2019-06-27 Thread Jian Cai via Phabricator via cfe-commits

jcai19 updated this revision to Diff 206946.
jcai19 added a comment.

Update the check to catch redundant code and update the warning message to be 
more speicific.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63623

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/PosixReturnCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/PosixReturnCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-posix-return.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp

Index: clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/bugprone-posix-return.cpp
@@ -0,0 +1,124 @@
+// RUN: %check_clang_tidy %s bugprone-posix-return %t
+
+#define NULL nullptr
+#define ZERO 0
+#define NEGATIVE_ONE -1
+
+typedef long off_t;
+typedef decltype(sizeof(int)) size_t;
+typedef int pid_t;
+typedef struct __posix_spawn_file_actions* posix_spawn_file_actions_t;
+typedef struct __posix_spawnattr* posix_spawnattr_t;
+
+extern "C" int posix_fadvise(int fd, off_t offset, off_t len, int advice);
+extern "C" int posix_fallocate(int fd, off_t offset, off_t len);
+extern "C" int posix_madvise(void *addr, size_t len, int advice);
+extern "C" int posix_memalign(void **memptr, size_t alignment, size_t size);
+extern "C" int posix_openpt(int flags);
+extern "C" int posix_spawn(pid_t *pid, const char *path,
+const posix_spawn_file_actions_t *file_actions,
+const posix_spawnattr_t *attrp,
+char *const argv[], char *const envp[]);
+extern "C" int posix_spawnp(pid_t *pid, const char *file,
+ const posix_spawn_file_actions_t *file_actions,
+ const posix_spawnattr_t *attrp,
+ char *const argv[], char *const envp[]);
+
+void warningLEZero() {
+  if (posix_fadvise(0, 0, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+  // CHECK-FIXES: posix_fadvise(0, 0, 0, 0) > 0
+  if (posix_fadvise(0, 0, 0, 0) >= 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+  if (posix_fallocate(0, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:32: warning:
+  // CHECK-FIXES: posix_fallocate(0, 0, 0) > 0
+  if (posix_madvise(NULL, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  // CHECK-FIXES: posix_madvise(NULL, 0, 0) > 0
+  if (posix_memalign(NULL, 0, 0) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning:
+  // CHECK-FIXES: posix_memalign(NULL, 0, 0) > 0
+  if (posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:59: warning:
+  // CHECK-FIXES: posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) > 0
+  if (posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) < 0) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:60: warning:
+  // CHECK-FIXES: posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) > 0
+}
+
+void warningEqualsNegative() {
+  if (posix_fadvise(0, 0, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: posix_fadvise
+  if (posix_fadvise(0, 0, 0, 0) != -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) <= -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) < -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fallocate(0, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:32: warning:
+  if (posix_madvise(NULL, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_memalign(NULL, 0, 0) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning:
+  if (posix_spawn(NULL, NULL, NULL, NULL, {NULL}, {NULL}) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:59: warning:
+  if (posix_spawnp(NULL, NULL, NULL, NULL, {NULL}, {NULL}) == -1) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:60: warning:
+}
+
+void WarningWithMacro() {
+  if (posix_fadvise(0, 0, 0, 0) < ZERO) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  // CHECK-FIXES: posix_fadvise(0, 0, 0, 0) > ZERO
+  if (posix_fadvise(0, 0, 0, 0) >= ZERO) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) == NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) != NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) <= NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+  if (posix_fadvise(0, 0, 0, 0) < NEGATIVE_ONE) {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning:
+}
+
+void noWarning() {
+  if (posix_openpt(0) < 0) {}
+  if (posix_openpt(0) <= 0) {}
+  if (posix_openpt(0) == -1) {}
+  if (posix_openpt(0) != -1) {}
+  if (posix_openpt(0) <= -1) {}
+  if

[PATCH] D63857: [clang-doc] Structured HTML generator

2019-06-27 Thread Jake Ehrlich via Phabricator via cfe-commits

jakehehrlich added a comment.

Overall looks better. One of my comments causes a sweeping change to occur so 
I'll respond back after thats done.




Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:91
+struct HTMLFile {
+  llvm::SmallString<16> DoctypeDecl{""};
+  std::vector> Children; // List of child nodes

Does this ever change? If not this should be a global constexpr constant char* 
inside of an anon-namespace.

e.g.

namespace {
  constexpr const char* kDoctypeDecl = "...";
}



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:170
+OS << " " << A.getKey() << "=\"" << A.getValue() << "\"";
+  OS << (SelfClosing ? "/>" : ">");
+  if (!InlineChildren)

You can exit here if its self closing right?



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:187
 
-std::string genTag(const Twine , const Twine ) {
-  return "<" + Tag.str() + ">" + Text.str() + "";
+static void genHTML(const EnumInfo , TagNode *N);
+static void genHTML(const FunctionInfo , TagNode *N);

You should return TagNodes, not assign to them by ref. Preferably via retruning 
a unique pointer. It doesn't make sense to have the consumer do the constructor 
I would imagine. For instance what tag is the right tag type? The consumer 
shouldn't decide, the producer should. 



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:190
+
+static void genEnumsBlock(const std::vector , TagNode *N) {
+  if (Enums.empty())

Same comment here these function should look like (at a very high an imprecise 
level, obviously some functions will be more complicated.)

```
std::unique_ptr genFoo(info) {
  auto out = llvm::make_unique<...>(...);
  for (const auto  : info.bars)
out->Children.emplace_back(genBar(B));
  return out;
}
```

This goes for all of these functions


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

https://reviews.llvm.org/D63857



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

[PATCH] D63533: [analyzer] Fix clang-tidy crash on GCCAsmStmt

2019-06-27 Thread Nick Desaulniers via Phabricator via cfe-commits

nickdesaulniers added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:401
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() == true && "Encountered 
GCCAsmStmt without labels");
+// TODO: Handle jumping to labels

prefer: `assert(shouldBeTrue() && "asdfasdf")` to `assert(shouldBeTrue() == 
true && "asfas")`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63533



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

r364595 - Pattern match struct types in test case.

2019-06-27 Thread Akira Hatanaka via cfe-commits

Author: ahatanak
Date: Thu Jun 27 14:16:19 2019
New Revision: 364595

URL: http://llvm.org/viewvc/llvm-project?rev=364595=rev
Log:
Pattern match struct types in test case.

This simplifies the test cases in a patch I'm planning to send later.

Modified:
cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m

Modified: cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m?rev=364595=364594=364595=diff
==
--- cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m (original)
+++ cfe/trunk/test/CodeGenObjC/strong-in-c-struct.m Thu Jun 27 14:16:19 2019
@@ -90,10 +90,16 @@ StrongOuter2 getStrongOuter2(void);
 void calleeStrongSmall(StrongSmall);
 void func(Strong *);
 
+// CHECK: %[[STRUCT_STRONGOUTER:.*]] = type { %[[STRUCT_STRONG:.*]], i8*, 
double }
+// CHECK: %[[STRUCT_STRONG]] = type { %[[STRUCT_TRIVIAL:.*]], i8* }
+// CHECK: %[[STRUCT_TRIVIAL]] = type { [4 x i32] }
+// CHECK: %[[STRUCT_BLOCK_BYREF_T:.*]] = type { i8*, 
%[[STRUCT_BLOCK_BYREF_T]]*, i32, i32, i8*, i8*, i8*, %[[STRUCT_STRONGOUTER]] }
+// CHECK: %[[STRUCT_STRONGSMALL:.*]] = type { i32, i8* }
+// CHECK: %[[STRUCT_STRONGBLOCK:.*]] = type { void ()* }
 // CHECK: %[[STRUCT_BITFIELD1:.*]] = type { i8, i8, i8*, i32, i8*, [3 x i32], 
i8*, double, i8, i8 }
 
 // CHECK: define void @test_constructor_destructor_StrongOuter()
-// CHECK: %[[T:.*]] = alloca %[[STRUCT_STRONGOUTER:.*]], align 8
+// CHECK: %[[T:.*]] = alloca %[[STRUCT_STRONGOUTER]], align 8
 // CHECK: %[[V0:.*]] = bitcast %[[STRUCT_STRONGOUTER]]* %[[T]] to i8**
 // CHECK: call void @__default_constructor_8_S_s16_s24(i8** %[[V0]])
 // CHECK: %[[V1:.*]] = bitcast %[[STRUCT_STRONGOUTER]]* %[[T]] to i8**
@@ -148,7 +154,7 @@ void test_constructor_destructor_StrongO
   StrongOuter t;
 }
 
-// CHECK: define void 
@test_copy_constructor_StrongOuter(%[[STRUCT_STRONGOUTER:.*]]* %[[S:.*]])
+// CHECK: define void 
@test_copy_constructor_StrongOuter(%[[STRUCT_STRONGOUTER]]* %[[S:.*]])
 // CHECK: %[[S_ADDR:.*]] = alloca %[[STRUCT_STRONGOUTER]]*, align 8
 // CHECK: %[[T:.*]] = alloca %[[STRUCT_STRONGOUTER]], align 8
 // CHECK: store %[[STRUCT_STRONGOUTER]]* %[[S]], %[[STRUCT_STRONGOUTER]]** 
%[[S_ADDR]], align 8
@@ -235,7 +241,7 @@ void test_copy_assignment_StrongOuter(St
 }
 
 // CHECK: define void @test_move_constructor_StrongOuter()
-// CHECK: %[[T1:.*]] = getelementptr inbounds %[[STRUCT_BLOCK_BYREF_T:.*]], 
%[[STRUCT_BLOCK_BYREF_T]]* %{{.*}}, i32 0, i32 7
+// CHECK: %[[T1:.*]] = getelementptr inbounds %[[STRUCT_BLOCK_BYREF_T]], 
%[[STRUCT_BLOCK_BYREF_T]]* %{{.*}}, i32 0, i32 7
 // CHECK: %[[V1:.*]] = bitcast %[[STRUCT_STRONGOUTER]]* %[[T1]] to i8**
 // CHECK: call void @__default_constructor_8_S_s16_s24(i8** %[[V1]])
 // CHECK: %[[T2:.*]] = getelementptr inbounds %[[STRUCT_BLOCK_BYREF_T]], 
%[[STRUCT_BLOCK_BYREF_T]]* %{{.*}}, i32 0, i32 7
@@ -411,10 +417,10 @@ void test_move_assignment_StrongOuter2(S
 }
 
 // CHECK: define void @test_parameter_StrongSmall([2 x i64] %[[A_COERCE:.*]])
-// CHECK: %[[A:.*]] = alloca %[[STRUCT_STRONG:.*]], align 8
-// CHECK: %[[V0:.*]] = bitcast %[[STRUCT_STRONG]]* %[[A]] to [2 x i64]*
+// CHECK: %[[A:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
+// CHECK: %[[V0:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[A]] to [2 x i64]*
 // CHECK: store [2 x i64] %[[A_COERCE]], [2 x i64]* %[[V0]], align 8
-// CHECK: %[[V1:.*]] = bitcast %[[STRUCT_STRONG]]* %[[A]] to i8**
+// CHECK: %[[V1:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[A]] to i8**
 // CHECK: call void @__destructor_8_s8(i8** %[[V1]])
 // CHECK: ret void
 
@@ -422,7 +428,7 @@ void test_parameter_StrongSmall(StrongSm
 }
 
 // CHECK: define void @test_argument_StrongSmall([2 x i64] %[[A_COERCE:.*]])
-// CHECK: %[[A:.*]] = alloca %[[STRUCT_STRONGSMALL:.*]], align 8
+// CHECK: %[[A:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
 // CHECK: %[[TEMP_LVALUE:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
 // CHECK: %[[V0:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[A]] to [2 x i64]*
 // CHECK: store [2 x i64] %[[A_COERCE]], [2 x i64]* %[[V0]], align 8
@@ -441,7 +447,7 @@ void test_argument_StrongSmall(StrongSma
 }
 
 // CHECK: define [2 x i64] @test_return_StrongSmall([2 x i64] %[[A_COERCE:.*]])
-// CHECK: %[[RETVAL:.*]] = alloca %[[STRUCT_STRONGSMALL:.*]], align 8
+// CHECK: %[[RETVAL:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
 // CHECK: %[[A:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
 // CHECK: %[[V0:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[A]] to [2 x i64]*
 // CHECK: store [2 x i64] %[[A_COERCE]], [2 x i64]* %[[V0]], align 8
@@ -459,7 +465,7 @@ StrongSmall test_return_StrongSmall(Stro
 }
 
 // CHECK: define void @test_destructor_ignored_result()
-// CHECK: %[[COERCE:.*]] = alloca %[[STRUCT_STRONGSMALL:.*]], align 8
+// CHECK: %[[COERCE:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
 // CHECK: %[[CALL:.*]] = call [2 x i64] @getStrongSmall()
 // CHECK: %[[V0:.*]] = bitcast

[PATCH] D63533: [analyzer] Fix clang-tidy crash on GCCAsmStmt

2019-06-27 Thread Artem Dergachev via Phabricator via cfe-commits

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

Looks great now, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63533



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

[PATCH] D63894: [CXX] Exercise all paths through these tests

2019-06-27 Thread Paul Robinson via Phabricator via cfe-commits

probinson created this revision.
probinson added a reviewer: rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

These 3 tests have dialect-based conditionals, but weren't running Clang with 
enough different dialects to actually enable those conditional sections.


Repository:
  rC Clang

https://reviews.llvm.org/D63894

Files:
  clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
  clang/test/SemaCXX/class.cpp
  clang/test/SemaCXX/linkage2.cpp


Index: clang/test/SemaCXX/linkage2.cpp
===
--- clang/test/SemaCXX/linkage2.cpp
+++ clang/test/SemaCXX/linkage2.cpp
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -std=gnu++11 %s
-// RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions 
-Wno-local-type-template-args %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions 
-Wno-local-type-template-args %s -std=gnu++98
 // RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions 
-Wno-local-type-template-args -fmodules %s
 
 namespace test1 {
Index: clang/test/SemaCXX/class.cpp
===
--- clang/test/SemaCXX/class.cpp
+++ clang/test/SemaCXX/class.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -Wc++11-compat %s 
+// RUN: %clang_cc1 -fsyntax-only -verify -Wc++11-compat %s -std=c++98
 class C {
 public:
   auto int errx; // expected-error {{storage class specified for a member 
declaration}}
Index: clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
===
--- clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
+++ clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++98 %s
 // RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
 
 // C++03 [namespace.udecl]p4:


Index: clang/test/SemaCXX/linkage2.cpp
===
--- clang/test/SemaCXX/linkage2.cpp
+++ clang/test/SemaCXX/linkage2.cpp
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -std=gnu++11 %s
-// RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions -Wno-local-type-template-args %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions -Wno-local-type-template-args %s -std=gnu++98
 // RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions -Wno-local-type-template-args -fmodules %s
 
 namespace test1 {
Index: clang/test/SemaCXX/class.cpp
===
--- clang/test/SemaCXX/class.cpp
+++ clang/test/SemaCXX/class.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify -Wc++11-compat %s 
+// RUN: %clang_cc1 -fsyntax-only -verify -Wc++11-compat %s -std=c++98
 class C {
 public:
   auto int errx; // expected-error {{storage class specified for a member declaration}}
Index: clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
===
--- clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
+++ clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p4.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++98 %s
 // RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
 
 // C++03 [namespace.udecl]p4:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63857: [clang-doc] Structured HTML generator

2019-06-27 Thread Diego Astiazarán via Phabricator via cfe-commits

DiegoAstiazaran updated this revision to Diff 206920.
DiegoAstiazaran marked 7 inline comments as done.
DiegoAstiazaran added a comment.

Fix TagType enum name and members.
Add anonymous namespace.
Separate the implementation from the definition for some functions.
Use emplace_back instead of push_back for instantiation of vector members.


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

https://reviews.llvm.org/D63857

Files:
  clang-tools-extra/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/clang-doc/MDGenerator.cpp
  clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp

Index: clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
@@ -40,16 +40,31 @@
   llvm::raw_string_ostream Actual(Buffer);
   auto Err = G->generateDocForInfo(, Actual);
   assert(!Err);
-  std::string Expected = R"raw(namespace Namespace
-Namespaces
-ChildNamespace
-Records
-ChildStruct
-Functions
-OneFunction
- OneFunction()
-Enums
-enum OneEnum
+  std::string Expected = R"raw(
+
+namespace Namespace
+
+  namespace Namespace
+  Namespaces
+  
+ChildNamespace
+  
+  Records
+  
+ChildStruct
+  
+  Functions
+  
+OneFunction
+
+   OneFunction()
+
+  
+  Enums
+  
+enum OneEnum
+  
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -80,18 +95,37 @@
   llvm::raw_string_ostream Actual(Buffer);
   auto Err = G->generateDocForInfo(, Actual);
   assert(!Err);
-  std::string Expected = R"raw(class r
-Defined at line 10 of test.cpp
-Inherits from F, G
-Members
-private int X
-Records
-ChildStruct
-Functions
-OneFunction
- OneFunction()
-Enums
-enum OneEnum
+  std::string Expected = R"raw(
+
+class r
+
+  class r
+  
+Defined at line 10 of test.cpp
+  
+  
+Inherits from F, G
+  
+  Members
+  
+private int X
+  
+  Records
+  
+ChildStruct
+  
+  Functions
+  
+OneFunction
+
+   OneFunction()
+
+  
+  Enums
+  
+enum OneEnum
+  
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -116,9 +150,18 @@
   llvm::raw_string_ostream Actual(Buffer);
   auto Err = G->generateDocForInfo(, Actual);
   assert(!Err);
-  std::string Expected = R"raw(f
-void f(int P)
-Defined at line 10 of test.cpp
+  std::string Expected = R"raw(
+
+
+
+  f
+  
+void f(int P)
+  
+  
+Defined at line 10 of test.cpp
+  
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -141,11 +184,18 @@
   llvm::raw_string_ostream Actual(Buffer);
   auto Err = G->generateDocForInfo(, Actual);
   assert(!Err);
-  std::string Expected = R"raw(enum class e
-
-X
-
-Defined at line 10 of test.cpp
+  std::string Expected = R"raw(
+
+
+
+  enum class e
+  
+X
+  
+  
+Defined at line 10 of test.cpp
+  
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -194,12 +244,29 @@
   llvm::raw_string_ostream Actual(Buffer);
   auto Err = G->generateDocForInfo(, Actual);
   assert(!Err);
-  std::string Expected = R"raw(f
-void f(int I, int J)
-Defined at line 10 of test.cpp
-
- Brief description.
- Extended description that continues onto the next line.
+  std::string Expected = R"raw(
+
+
+
+  f
+  
+void f(int I, int J)
+  
+  
+Defined at line 10 of test.cpp
+  
+  
+
+  
+ Brief description.
+  
+  
+ Extended description that
+ continues onto the next line.
+  
+
+  
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
Index: clang-tools-extra/clang-doc/MDGenerator.cpp
===
--- clang-tools-extra/clang-doc/MDGenerator.cpp
+++ clang-tools-extra/clang-doc/MDGenerator.cpp
@@ -20,11 +20,11 @@
 
 // Markdown generation
 
-std::string genItalic(const Twine ) { return "*" + Text.str() + "*"; }
+static std::string genItalic(const Twine ) { return "*" + Text.str() + "*"; }
 
-std::string genEmphasis(const Twine ) { return "**" + Text.str() + "**"; }
+static std::string genEmphasis(const Twine ) { return "**" + Text.str() + "**"; }
 
-std::string genLink(const Twine , const Twine ) {
+static std::string genLink(const Twine , const Twine ) {
   return "[" + Text.str() + "](" + Link.str() + ")";
 }
 
@@ -92,7 +92,7 @@
   }
 }
 
-void genMarkdown(const EnumInfo , llvm::raw_ostream ) {
+static void genMarkdown(const EnumInfo , llvm::raw_ostream ) {
   if (I.Scoped)
 writeLine("| enum class " + I.Name + " |", OS);
   else
@@ -112,7 +112,7 @@
 writeDescription(C, OS);
 }
 
-void genMarkdown(const FunctionInfo , llvm::raw_ostream ) {
+static void genMarkdown(const FunctionInfo , llvm::raw_ostream ) {
   std::string Buffer;
   llvm::raw_string_ostream Stream(Buffer);
   bool First = true;
@@ -139,7 +139,7 @@
 writeDescription(C, OS);
 }
 
-void genMarkdown(const NamespaceInfo , llvm::raw_ostream ) {
+static void genMarkdown(const NamespaceInfo , llvm::raw_ostream ) {
   if (I.Name ==

[PATCH] D63533: [analyzer] Fix clang-tidy crash on GCCAsmStmt

2019-06-27 Thread Nathan Huckleberry via Phabricator via cfe-commits

Nathan-Huckleberry updated this revision to Diff 206919.
Nathan-Huckleberry added a comment.

- Add assertion message and simplify test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63533

Files:
  clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
  clang/test/Analysis/egraph-asm-goto-no-crash.cpp


Index: clang/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- /dev/null
+++ clang/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify 
%s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() == true && "Encountered 
GCCAsmStmt without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 


Index: clang/test/Analysis/egraph-asm-goto-no-crash.cpp
===
--- /dev/null
+++ clang/test/Analysis/egraph-asm-goto-no-crash.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection -verify %s
+
+// expected-no-diagnostics
+
+void clang_analyzer_warnIfReached();
+
+void testAsmGoto() {
+  asm goto("xor %0, %0\n je %l[label1]\n jl %l[label2]"
+   : /* no outputs */
+   : /* inputs */
+   : /* clobbers */
+   : label1, label2 /* any labels used */);
+
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+
+  label1:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+
+  label2:
+  // FIXME: Should be reachable.
+  clang_analyzer_warnIfReached();
+  return;
+}
Index: clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -396,6 +396,11 @@
   case Stmt::WhileStmtClass:
 HandleBranch(cast(Term)->getCond(), Term, B, Pred);
 return;
+
+  case Stmt::GCCAsmStmtClass:
+assert(cast(Term)->isAsmGoto() == true && "Encountered GCCAsmStmt without labels");
+// TODO: Handle jumping to labels
+return;
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63893: [clang-tidy] Extend TransformerClangTidyCheck to support adding includes.

2019-06-27 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits

ymandel created this revision.
ymandel added reviewers: ilya-biryukov, gribozavr.
Herald added a subscriber: xazax.hun.
Herald added a project: clang.
ymandel added a parent revision: D63892: [LibTooling] Extend `RewriteRule` with 
support for adding includes..

This revision implements support for the `AddedIncludes` field in
RewriteRule cases; that is, it supports specifying the addition of include
directives in files modified by the clang tidy check.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63893

Files:
  clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
  clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.h
  clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
@@ -19,6 +19,7 @@
 namespace utils {
 namespace {
 using tooling::change;
+using tooling::IncludeFormat;
 using tooling::RewriteRule;
 using tooling::text;
 using tooling::stencil::cat;
@@ -121,6 +122,54 @@
   Input, nullptr, "input.cc", None, Options));
 }
 
+RewriteRule replaceCall(IncludeFormat Format) {
+  using namespace ::clang::ast_matchers;
+  RewriteRule Rule = makeRule(callExpr(callee(functionDecl(hasName("f",
+  change(text("other()")), text("no message"));
+  addInclude(Rule, "clang/OtherLib.h", Format);
+  return Rule;
+}
+
+template 
+class IncludeCheck : public TransformerClangTidyCheck {
+public:
+  IncludeCheck(StringRef Name, ClangTidyContext *Context)
+  : TransformerClangTidyCheck(replaceCall(Format), Name, Context) {}
+};
+
+TEST(TransformerClangTidyCheckTest, AddIncludeQuoted) {
+
+  std::string Input = R"cc(
+int f(int x);
+int h(int x) { return f(x); }
+  )cc";
+  std::string Expected = R"cc(#include "clang/OtherLib.h"
+
+
+int f(int x);
+int h(int x) { return other(); }
+  )cc";
+
+  EXPECT_EQ(Expected,
+test::runCheckOnCode>(Input));
+}
+
+TEST(TransformerClangTidyCheckTest, AddIncludeAngled) {
+  std::string Input = R"cc(
+int f(int x);
+int h(int x) { return f(x); }
+  )cc";
+  std::string Expected = R"cc(#include 
+
+
+int f(int x);
+int h(int x) { return other(); }
+  )cc";
+
+  EXPECT_EQ(Expected,
+test::runCheckOnCode>(Input));
+}
+
 } // namespace
 } // namespace utils
 } // namespace tidy
Index: clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.h
===
--- clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.h
+++ clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.h
@@ -10,7 +10,9 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_TRANSFORMER_CLANG_TIDY_CHECK_H
 
 #include "../ClangTidy.h"
+#include "../utils/IncludeInserter.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Frontend/CompilerInstance.h"
 #include "clang/Tooling/Refactoring/Transformer.h"
 #include 
 #include 
@@ -52,11 +54,14 @@
   TransformerClangTidyCheck(tooling::RewriteRule R, StringRef Name,
 ClangTidyContext *Context);
 
+  void registerPPCallbacks(const SourceManager , Preprocessor *PP,
+   Preprocessor *ModuleExpanderPP) override;
   void registerMatchers(ast_matchers::MatchFinder *Finder) final;
   void check(const ast_matchers::MatchFinder::MatchResult ) final;
 
 private:
   Optional Rule;
+  std::unique_ptr Inserter;
 };
 
 } // namespace utils
Index: clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
===
--- clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
+++ clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
@@ -44,6 +44,15 @@
  " explicitly provide an empty explanation if none is desired");
 }
 
+void TransformerClangTidyCheck::registerPPCallbacks(
+const SourceManager , Preprocessor *PP, Preprocessor *ModuleExpanderPP) {
+  if (Rule) {
+Inserter = llvm::make_unique(
+SM, getLangOpts(), utils::IncludeSorter::IS_LLVM);
+PP->addPPCallbacks(Inserter->CreatePPCallbacks());
+  }
+}
+
 void TransformerClangTidyCheck::registerMatchers(
 ast_matchers::MatchFinder *Finder) {
   if (Rule)
@@ -87,6 +96,15 @@
   for (const auto  : *Transformations) {
 Diag << FixItHint::CreateReplacement(T.Range, T.Replacement);
   }
+
+  for (const auto  : Case.AddedIncludes) {
+auto  = I.first;
+if (Optional Fix = Inserter->CreateIncludeInsertion(
+Result.SourceManager->getMainFileID(), Header,
+/*IsAngled=*/I.second == tooling::IncludeFormat::Angled)) {
+  Diag << *Fix;
+}
+  }
 }
 
 } // namespace utils

[PATCH] D63892: [LibTooling] Extend `RewriteRule` with support for adding includes.

2019-06-27 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits

ymandel created this revision.
ymandel added reviewers: ilya-biryukov, gribozavr.
Herald added a project: clang.

This revision allows users to specify the insertion of an included directive (at
the top of the file being rewritten) as part of a rewrite rule.  These
directives are bundled with `RewriteRule` cases, so that different cases can
potentially result in different include actions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63892

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
@@ -198,6 +198,42 @@
   testRule(std::move(Rule), Input, Expected);
 }
 
+TEST_F(TransformerTest, AddIncludeQuoted) {
+  RewriteRule Rule = makeRule(callExpr(callee(functionDecl(hasName("f",
+  change(text("other()")));
+  addInclude(Rule, "clang/OtherLib.h");
+
+  std::string Input = R"cc(
+int f(int x);
+int h(int x) { return f(x); }
+  )cc";
+  std::string Expected = R"cc(#include "clang/OtherLib.h"
+
+int f(int x);
+int h(int x) { return other(); }
+  )cc";
+
+  testRule(Rule, Input, Expected);
+}
+
+TEST_F(TransformerTest, AddIncludeAngled) {
+  RewriteRule Rule = makeRule(callExpr(callee(functionDecl(hasName("f",
+  change(text("other()")));
+  addInclude(Rule, "clang/OtherLib.h", IncludeFormat::Angled);
+
+  std::string Input = R"cc(
+int f(int x);
+int h(int x) { return f(x); }
+  )cc";
+  std::string Expected = R"cc(#include 
+
+int f(int x);
+int h(int x) { return other(); }
+  )cc";
+
+  testRule(Rule, Input, Expected);
+}
+
 TEST_F(TransformerTest, NodePartNameNamedDecl) {
   StringRef Fun = "fun";
   RewriteRule Rule = makeRule(functionDecl(hasName("bad")).bind(Fun),
Index: clang/lib/Tooling/Refactoring/Transformer.cpp
===
--- clang/lib/Tooling/Refactoring/Transformer.cpp
+++ clang/lib/Tooling/Refactoring/Transformer.cpp
@@ -98,8 +98,14 @@
 
 RewriteRule tooling::makeRule(DynTypedMatcher M, SmallVector Edits,
   TextGenerator Explanation) {
-  return RewriteRule{{RewriteRule::Case{std::move(M), std::move(Edits),
-std::move(Explanation)}}};
+  return RewriteRule{{RewriteRule::Case{
+  std::move(M), std::move(Edits), std::move(Explanation), {;
+}
+
+void tooling::addInclude(RewriteRule , StringRef Header,
+ IncludeFormat Format) {
+  for (auto  : Rule.Cases)
+Case.AddedIncludes.emplace_back(Header.str(), Format);
 }
 
 // Determines whether A is a base type of B in the class hierarchy, including
@@ -217,8 +223,8 @@
   Root->second.getSourceRange().getBegin());
   assert(RootLoc.isValid() && "Invalid location for Root node of match.");
 
-  auto Transformations = tooling::detail::translateEdits(
-  Result, tooling::detail::findSelectedCase(Result, Rule).Edits);
+  RewriteRule::Case Case = tooling::detail::findSelectedCase(Result, Rule);
+  auto Transformations = tooling::detail::translateEdits(Result, Case.Edits);
   if (!Transformations) {
 Consumer(Transformations.takeError());
 return;
@@ -241,5 +247,17 @@
 }
   }
 
+  for (const auto  : Case.AddedIncludes) {
+auto  = I.first;
+switch (I.second) {
+  case IncludeFormat::Quoted:
+AC.addHeader(Header);
+break;
+  case IncludeFormat::Angled:
+AC.addHeader((llvm::Twine("<") + Header + ">").str());
+break;
+}
+  }
+
   Consumer(std::move(AC));
 }
Index: clang/include/clang/Tooling/Refactoring/Transformer.h
===
--- clang/include/clang/Tooling/Refactoring/Transformer.h
+++ clang/include/clang/Tooling/Refactoring/Transformer.h
@@ -86,6 +86,12 @@
   TextGenerator Note;
 };
 
+/// Format of the path in an include directive -- angle brackets or quotes.
+enum class IncludeFormat {
+  Quoted,
+  Angled,
+};
+
 /// Description of a source-code transformation.
 //
 // A *rewrite rule* describes a transformation of source code. A simple rule
@@ -114,6 +120,10 @@
 ast_matchers::internal::DynTypedMatcher Matcher;
 SmallVector Edits;
 TextGenerator Explanation;
+// Include paths that to add to the file affected by this case.  These are
+// bundled with the `Case`, rather than the `RewriteRule`, because each case
+// might have different associated changes to the includes.
+std::vector> AddedIncludes;
   };
   // We expect RewriteRules will most commonly include only one case.
   SmallVector Cases;
@@ -137,6 +147,16 @@
   return makeRule(std::move(M), std::move(Edits), std::move(Explanation));
 }
 
+/// For every case

[PATCH] D62293: [modules] Add PP callbacks for entering and leaving a submodule.

2019-06-27 Thread Vassil Vassilev via Phabricator via cfe-commits

v.g.vassilev updated this revision to Diff 206887.
v.g.vassilev marked an inline comment as done.
v.g.vassilev added a comment.

Add comments, add missing callbacks. Thanks Richard!


Repository:
  rC Clang

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

https://reviews.llvm.org/D62293

Files:
  include/clang/Lex/PPCallbacks.h
  lib/Lex/PPLexerChange.cpp


Index: lib/Lex/PPLexerChange.cpp
===
--- lib/Lex/PPLexerChange.cpp
+++ lib/Lex/PPLexerChange.cpp
@@ -647,6 +647,8 @@
 BuildingSubmoduleStack.push_back(
 BuildingSubmoduleInfo(M, ImportLoc, ForPragma, CurSubmoduleState,
   PendingModuleMacroNames.size()));
+if (Callbacks)
+  Callbacks->EnteredSubmodule(M, ImportLoc, ForPragma);
 return;
   }
 
@@ -691,6 +693,9 @@
   BuildingSubmoduleInfo(M, ImportLoc, ForPragma, CurSubmoduleState,
 PendingModuleMacroNames.size()));
 
+  if (Callbacks)
+Callbacks->EnteredSubmodule(M, ImportLoc, ForPragma);
+
   // Switch to this submodule as the current submodule.
   CurSubmoduleState = 
 
@@ -731,6 +736,10 @@
 // are tracking macro visibility, don't build any, and preserve the list
 // of pending names for the surrounding submodule.
 BuildingSubmoduleStack.pop_back();
+
+if (Callbacks)
+  Callbacks->LeftSubmodule(LeavingMod, ImportLoc, ForPragma);
+
 makeModuleVisible(LeavingMod, ImportLoc);
 return LeavingMod;
   }
@@ -815,6 +824,9 @@
 
   BuildingSubmoduleStack.pop_back();
 
+  if (Callbacks)
+Callbacks->LeftSubmodule(LeavingMod, ImportLoc, ForPragma);
+
   // A nested #include makes the included submodule visible.
   makeModuleVisible(LeavingMod, ImportLoc);
   return LeavingMod;
Index: include/clang/Lex/PPCallbacks.h
===
--- include/clang/Lex/PPCallbacks.h
+++ include/clang/Lex/PPCallbacks.h
@@ -132,6 +132,28 @@
   SrcMgr::CharacteristicKind FileType) {
   }
 
+  /// Callback invoked whenever a submodule was entered.
+  ///
+  /// \param M The submodule we have entered.
+  ///
+  /// \param ImportLoc The location of import directive token.
+  ///
+  /// \param ForPragma If entering from pragma directive.
+  ///
+  virtual void EnteredSubmodule(Module *M, SourceLocation ImportLoc,
+bool ForPragma) { }
+
+  /// Callback invoked whenever a submodule was left.
+  ///
+  /// \param M The submodule we have left.
+  ///
+  /// \param ImportLoc The location of import directive token.
+  ///
+  /// \param ForPragma If entering from pragma directive.
+  ///
+  virtual void LeftSubmodule(Module *M, SourceLocation ImportLoc,
+ bool ForPragma) { }
+
   /// Callback invoked whenever there was an explicit module-import
   /// syntax.
   ///
@@ -395,6 +417,18 @@
Imported, FileType);
   }
 
+  void EnteredSubmodule(Module *M, SourceLocation ImportLoc,
+bool ForPragma) override {
+First->EnteredSubmodule(M, ImportLoc, ForPragma);
+Second->EnteredSubmodule(M, ImportLoc, ForPragma);
+  }
+
+  void LeftSubmodule(Module *M, SourceLocation ImportLoc,
+ bool ForPragma) override {
+First->LeftSubmodule(M, ImportLoc, ForPragma);
+Second->LeftSubmodule(M, ImportLoc, ForPragma);
+  }
+
   void moduleImport(SourceLocation ImportLoc, ModuleIdPath Path,
 const Module *Imported) override {
 First->moduleImport(ImportLoc, Path, Imported);


Index: lib/Lex/PPLexerChange.cpp
===
--- lib/Lex/PPLexerChange.cpp
+++ lib/Lex/PPLexerChange.cpp
@@ -647,6 +647,8 @@
 BuildingSubmoduleStack.push_back(
 BuildingSubmoduleInfo(M, ImportLoc, ForPragma, CurSubmoduleState,
   PendingModuleMacroNames.size()));
+if (Callbacks)
+  Callbacks->EnteredSubmodule(M, ImportLoc, ForPragma);
 return;
   }
 
@@ -691,6 +693,9 @@
   BuildingSubmoduleInfo(M, ImportLoc, ForPragma, CurSubmoduleState,
 PendingModuleMacroNames.size()));
 
+  if (Callbacks)
+Callbacks->EnteredSubmodule(M, ImportLoc, ForPragma);
+
   // Switch to this submodule as the current submodule.
   CurSubmoduleState = 
 
@@ -731,6 +736,10 @@
 // are tracking macro visibility, don't build any, and preserve the list
 // of pending names for the surrounding submodule.
 BuildingSubmoduleStack.pop_back();
+
+if (Callbacks)
+  Callbacks->LeftSubmodule(LeavingMod, ImportLoc, ForPragma);
+
 makeModuleVisible(LeavingMod, ImportLoc);
 return LeavingMod;
   }
@@ -815,6 +824,9 @@
 
   BuildingSubmoduleStack.pop_back();
 
+  if (Callbacks)
+Callbacks->LeftSubmodule(LeavingMod, ImportLoc, ForPragma);
+
   // A nested #include makes the included submodule visible.

[PATCH] D63889: Check possible warnings on global initializers for reachability

2019-06-27 Thread Nathan Huckleberry via Phabricator via cfe-commits

Nathan-Huckleberry created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Create CFG for initializers and perform analysis based warnings on global 
variables


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63889

Files:
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/Sema/AnalysisBasedWarnings.h
  clang/lib/Analysis/AnalysisDeclContext.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/warn-unreachable-warning-var-decl.cpp

Index: clang/test/Sema/warn-unreachable-warning-var-decl.cpp
===
--- /dev/null
+++ clang/test/Sema/warn-unreachable-warning-var-decl.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -verify %s
+int e = 1 ? 0 : 1/0;
+int g = 1 ? 1/0 : 0;// expected-warning{{division by zero is undefined}}
+
+#define SHIFT(n)(((n) == 32) ? 0 : ((1<<(n))-1))
+
+int x = SHIFT(32);
+int y = SHIFT(0);
+
+// FIXME: Expressions in lambdas aren't ignored
+int z = [](){
+  return 1 ? 0 : 1/0; // expected-warning{{division by zero is undefined}}
+}();
+
+int f(void)
+{
+int x = 1 ? 0 : 1/0;
+return x;
+}
+
+template
+struct X0 {
+static T value;
+};
+
+template
+struct X1 {
+static T value;
+};
+
+template
+T X0::value = 3.14; // expected-warning{{implicit conversion from 'double' to 'int' changes value from 3.14 to 3}}
+
+template
+T X1::value = 1 ? 0 : 1/0;
+
+template struct X0; // expected-note{{in instantiation of static data member 'X0::value' requested here}}
+
+constexpr signed char c1 = 100 * 2; // ok expected-warning{{changes value}}
+constexpr signed char c2 = '\x64' * '\2'; // also ok  expected-warning{{changes value}}
+constexpr int shr_32 = 0 >> 32; // expected-error {{constant expression}} expected-note {{shift count 32 >= width of type}}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -4881,6 +4881,8 @@
"default argument expression has capturing blocks?");
   }
 
+  AnalysisWarnings.IssueWarningsForRegisteredVarDecl(Param);
+
   // We already type-checked the argument, so we know it works.
   // Just mark all of the declarations in this potentially-evaluated expression
   // as being "referenced".
@@ -16662,7 +16664,7 @@
   case ExpressionEvaluationContext::PotentiallyEvaluatedIfUsed:
 if (!Stmts.empty() && getCurFunctionOrMethodDecl()) {
   FunctionScopes.back()->PossiblyUnreachableDiags.
-push_back(sema::PossiblyUnreachableDiag(PD, Loc, Stmts));
+push_back(clang::sema::PossiblyUnreachableDiag(PD, Loc, Stmts));
   return true;
 }
 
@@ -16671,17 +16673,36 @@
 // but nonetheless is always required to be a constant expression, so we
 // can skip diagnosing.
 // FIXME: Using the mangling context here is a hack.
+//
+// Mangling context seems to only be defined on constexpr vardecl that
+// displayed errors
+// This skips warnings that were already emitted as notes on errors.
 if (auto *VD = dyn_cast_or_null(
 ExprEvalContexts.back().ManglingContextDecl)) {
   if (VD->isConstexpr() ||
   (VD->isStaticDataMember() && VD->isFirstDecl() && !VD->isInline()))
 break;
+}
+
+// For any other kind of variable, we should build a CFG for its
+// initializer and check whether the context in question is reachable.
+if(auto *VD = dyn_cast_or_null(
+CurContext->getLastDecl())) {
+  if(VD->getDefinition()) {
+VD = VD->getDefinition();
+  }
   // FIXME: For any other kind of variable, we should build a CFG for its
   // initializer and check whether the context in question is reachable.
+  // Some cases aren't picked up by path analysis currently
+  if(!Stmts.empty() && VD->isFileVarDecl()) {
+AnalysisWarnings.RegisterVarDeclWarning(VD, clang::sema::PossiblyUnreachableDiag(PD, Loc, Stmts));
+return true;
+  }
 }
 
 Diag(Loc, PD);
 return true;
+
   }
 
   return false;
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -288,6 +288,9 @@
 UnparsedDefaultArgInstantiations.erase(InstPos);
   }
 
+  // Check for delayed warnings
+  AnalysisWarnings.IssueWarningsForRegisteredVarDecl(Param);
+
   return false;
 }
 
@@ -333,7 +336,21 @@
 return;
   }
 
+  // Temporarily change the context and add param to it
+  // Allows DiagRuntimeBehavior to register this param with
+  // any possibly warnings
+  // Param gets added back to context when function is added
+  // to context
+  // FIXME: Params should probably be diagnosed after being
+  // actually added to context. Either params get added to
+  // context before the function

[PATCH] D63538: [analyzer][CFG] Return the correct terminator condition

2019-06-27 Thread Gábor Horváth via Phabricator via cfe-commits

xazax.hun added a comment.

This change will be really useful for the lifetime analysis as well! Thanks!

I have one concern though. The analyzer is using linerarized (or threaded) CFGs 
with every subexpression being a separate entry in the basic blocks. Will your 
change give sensible answers for non-linearized CFGs? If not, this should be 
documented. Do we have users of this API with non-linearized CFGs?


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

https://reviews.llvm.org/D63538



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

r364575 - [OPENMP]Generate correctly implicit flags for mapped data.

2019-06-27 Thread Alexey Bataev via cfe-commits

Author: abataev
Date: Thu Jun 27 11:53:07 2019
New Revision: 364575

URL: http://llvm.org/viewvc/llvm-project?rev=364575=rev
Log:
[OPENMP]Generate correctly implicit flags for mapped data.

Implicit flag must not be emitted for explicitly specified firstprivate
variables, but for implicitly captured sizes of the VLAs.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/test/OpenMP/nvptx_lambda_capturing.cpp
cfe/trunk/test/OpenMP/target_codegen.cpp
cfe/trunk/test/OpenMP/target_firstprivate_codegen.cpp
cfe/trunk/test/OpenMP/target_map_codegen.cpp
cfe/trunk/test/OpenMP/target_parallel_codegen.cpp
cfe/trunk/test/OpenMP/target_parallel_for_codegen.cpp
cfe/trunk/test/OpenMP/target_parallel_for_simd_codegen.cpp
cfe/trunk/test/OpenMP/target_simd_codegen.cpp
cfe/trunk/test/OpenMP/target_teams_codegen.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_codegen.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_simd_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=364575=364574=364575=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Thu Jun 27 11:53:07 2019
@@ -7155,7 +7155,9 @@ private:
   CodeGenFunction 
 
   /// Set of all first private variables in the current directive.
-  llvm::SmallPtrSet FirstPrivateDecls;
+  /// bool data is set to true if the variable is implicitly marked as
+  /// firstprivate, false otherwise.
+  llvm::DenseMap, bool> FirstPrivateDecls;
 
   /// Map between device pointer declarations and their expression components.
   /// The key value for declarations in 'this' is null.
@@ -7836,8 +7838,8 @@ public:
 // Extract firstprivate clause information.
 for (const auto *C : Dir.getClausesOfKind())
   for (const auto *D : C->varlists())
-FirstPrivateDecls.insert(
-
cast(cast(D)->getDecl())->getCanonicalDecl());
+FirstPrivateDecls.try_emplace(
+cast(cast(D)->getDecl()), C->isImplicit());
 // Extract device pointer clause information.
 for (const auto *C : Dir.getClausesOfKind())
   for (auto L : C->component_lists())
@@ -8354,6 +8356,7 @@ public:
   MapValuesArrayTy ,
   MapValuesArrayTy ,
   MapFlagsArrayTy ) const {
+bool IsImplicit = true;
 // Do the default mapping.
 if (CI.capturesThis()) {
   CurBasePointers.push_back(CV);
@@ -8379,6 +8382,10 @@ public:
 CurMapTypes.push_back(OMP_MAP_NONE);
 CurSizes.push_back(llvm::Constant::getNullValue(CGF.Int64Ty));
   }
+  const VarDecl *VD = CI.getCapturedVar();
+  auto I = FirstPrivateDecls.find(VD);
+  if (I != FirstPrivateDecls.end())
+IsImplicit = I->getSecond();
 } else {
   assert(CI.capturesVariable() && "Expected captured reference.");
   const auto *PtrTy = cast(RI.getType().getTypePtr());
@@ -8390,7 +8397,8 @@ public:
   // type, the default is 'tofrom'.
   CurMapTypes.push_back(getMapModifiersForPrivateClauses(CI));
   const VarDecl *VD = CI.getCapturedVar();
-  if (FirstPrivateDecls.count(VD) &&
+  auto I = FirstPrivateDecls.find(VD);
+  if (I != FirstPrivateDecls.end() &&
   VD->getType().isConstant(CGF.getContext())) {
 llvm::Constant *Addr =
 CGF.CGM.getOpenMPRuntime().registerTargetFirstprivateCopy(CGF, VD);
@@ -8404,7 +8412,7 @@ public:
 CurPointers.push_back(Addr);
   } else {
 CurBasePointers.push_back(CV);
-if (FirstPrivateDecls.count(VD) && ElementType->isAnyPointerType()) {
+if (I != FirstPrivateDecls.end() && ElementType->isAnyPointerType()) {
   Address PtrAddr = CGF.EmitLoadOfReference(CGF.MakeAddrLValue(
   CV, ElementType, CGF.getContext().getDeclAlign(VD),
   AlignmentSource::Decl));
@@ -8413,12 +8421,15 @@ public:
   CurPointers.push_back(CV);
 }
   }
+  if (I != FirstPrivateDecls.end())
+IsImplicit = I->getSecond();
 }
 // Every default map produces a single argument which is a target 
parameter.
 CurMapTypes.back() |= OMP_MAP_TARGET_PARAM;
 
 // Add flag stating this is an implicit map.
-CurMapTypes.back() |= OMP_MAP_IMPLICIT;
+if (IsImplicit)
+  CurMapTypes.back() |= OMP_MAP_IMPLICIT;
   }
 };
 } // anonymous namespace
@@ -8884,7 +8895,8 @@ void CGOpenMPRuntime::emitTargetCall(Cod
 CGF.getTypeSize(RI->getType()), CGF.Int64Ty, /*isSigned=*/true));
 // Copy to the device as an argument. No need to retrieve it.
 CurMapTypes.push_back(MappableExprsHandler::OMP_MAP_LITERAL |
-  MappableExprsHandler::OMP_MAP_TARGET_PARAM);
+

[PATCH] D62829: [clang-tidy] Check for dynamically initialized statics in headers.

2019-06-27 Thread Charles Zhang via Phabricator via cfe-commits

czhang added a comment.

ping


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

https://reviews.llvm.org/D62829



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

2019-06-27 Thread Lingda Li via Phabricator via cfe-commits

lildmh updated this revision to Diff 206895.
lildmh added a comment.

Change the type of size from `size_t` to `int64_t`, and rebase


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

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0

[PATCH] D63856: [ObjC] Add a -Wtautological-compare warning for BOOL

2019-06-27 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

In D63856#1561132 , @erik.pilkington 
wrote:

> In D63856#1561112 , @rjmccall wrote:
>
> > In D63856#1560213 , 
> > @erik.pilkington wrote:
> >
> > > In D63856#1560180 , @rjmccall 
> > > wrote:
> > >
> > > > This only applies to relational operators, right?  I'm a little 
> > > > uncomfortable with calling this "tautological" since it's not like it's 
> > > > *undefined behavior* to have `(BOOL) 2`, it's just *unwise*.  But as 
> > > > long as we aren't warning about reasonable idioms that are intended to 
> > > > handle unfortunate situations — like other code that might have left a 
> > > > non-`{0,1}` value in the `BOOL` — I think this is fine.
> > >
> > >
> > > I think the party line is that it is undefined behaviour (in some sense), 
> > > since UBSan will happily crash if you try to load a non-boolean value 
> > > from a BOOL.
> >
> >
> > What?  Since when?
>
>
> https://reviews.llvm.org/D27607


Interesting; I'm not sure I find that convincing.  Probably the least 
convincing part is where it links to its own behavioral documentation as 
justification for doing what it does.  But okay, I guess we do this.

>>> It is a bit unfortunate that "defensive" code will start warning here 
>>> though :/. Maybe we can try to detect and permit something like `B < NO || 
>>> B > YES`, or emit a note with some canonical way of checking for 
>>> non-boolean BOOLs. Even if we end up having to disable it default, I think 
>>> its still a good diagnostic to have. A warning on stores to BOOL would 
>>> probably be a lot higher value, though.
>> 
>> I'm not sure this is a problem because I'm not sure there's any reason to 
>> write defensive code besides `B != NO` or `B == NO`.  It's potentially 
>> problematic if someone writes `B == YES`, though.
> 
> I was thinking about something like the following, which probably isn't worth 
> warning on. Another way of handling it would be only emitting the diagnostic 
> if `!InRange`. Not exactly sure how common that pattern actually is though.
> 
>   void myAPI(BOOL DoAThing) {
> if (DoAThing > YES || DoAThing < NO) DoAThing = YES;
> // ...
>   }

I don't think it's a problem to warn about this; this is just a silly way of 
writing `if (DoAThing != NO) { DoAThing = YES; }`.


Repository:
  rC Clang

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

https://reviews.llvm.org/D63856



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

[PATCH] D62961: [AST] Add new Type queries for sizeless types

2019-06-27 Thread Richard Sandiford via Phabricator via cfe-commits

rsandifo-arm updated this revision to Diff 206894.
rsandifo-arm added a comment.

- Update for new version of D62960 


Repository:
  rC Clang

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

https://reviews.llvm.org/D62961

Files:
  include/clang/AST/CanonicalType.h
  include/clang/AST/Type.h
  lib/AST/Type.cpp
  unittests/AST/CMakeLists.txt
  unittests/AST/SizelessTypesTest.cpp

Index: unittests/AST/SizelessTypesTest.cpp
===
--- /dev/null
+++ unittests/AST/SizelessTypesTest.cpp
@@ -0,0 +1,105 @@
+//===- unittests/AST/SizelessTypesTest.cpp --- Sizeless type 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
+//
+//===--===//
+//
+// This file contains tests for clang::Type queries related to sizeless types.
+//
+//===--===//
+
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Type.h"
+#include "clang/Tooling/Tooling.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+struct SizelessTypeTester : public ::testing::Test {
+  // Declare an incomplete structure type.
+  std::unique_ptr AST = tooling::buildASTFromCode("struct foo;");
+  ASTContext  = AST->getASTContext();
+  TranslationUnitDecl  = *Ctx.getTranslationUnitDecl();
+  TypeDecl *Foo = cast(TU.lookup(("foo")).front());
+  const Type *FooTy = Foo->getTypeForDecl();
+};
+
+TEST_F(SizelessTypeTester, TestSizeless) {
+  ASSERT_TRUE(Ctx.SveInt8Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveInt16Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveInt32Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveInt64Ty->isSizelessType());
+
+  ASSERT_TRUE(Ctx.SveUint8Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveUint16Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveUint32Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveUint64Ty->isSizelessType());
+
+  ASSERT_TRUE(Ctx.SveFloat16Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveFloat32Ty->isSizelessType());
+  ASSERT_TRUE(Ctx.SveFloat64Ty->isSizelessType());
+
+  ASSERT_TRUE(Ctx.SveBoolTy->isSizelessType());
+
+  ASSERT_FALSE(Ctx.VoidTy->isSizelessType());
+  ASSERT_FALSE(Ctx.PseudoObjectTy->isSizelessType());
+  ASSERT_FALSE(FooTy->isSizelessType());
+
+  ASSERT_FALSE(Ctx.getPointerType(Ctx.SveBoolTy)->isSizelessType());
+  ASSERT_FALSE(Ctx.getLValueReferenceType(Ctx.SveBoolTy)->isSizelessType());
+  ASSERT_FALSE(Ctx.getRValueReferenceType(Ctx.SveBoolTy)->isSizelessType());
+}
+
+TEST_F(SizelessTypeTester, TestIndefinite) {
+  ASSERT_FALSE(Ctx.SveInt8Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveInt16Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveInt32Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveInt64Ty->isIndefiniteType());
+
+  ASSERT_FALSE(Ctx.SveUint8Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveUint16Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveUint32Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveUint64Ty->isIndefiniteType());
+
+  ASSERT_FALSE(Ctx.SveFloat16Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveFloat32Ty->isIndefiniteType());
+  ASSERT_FALSE(Ctx.SveFloat64Ty->isIndefiniteType());
+
+  ASSERT_FALSE(Ctx.SveBoolTy->isIndefiniteType());
+
+  ASSERT_TRUE(Ctx.VoidTy->isIndefiniteType());
+  ASSERT_FALSE(Ctx.PseudoObjectTy->isIndefiniteType());
+  ASSERT_TRUE(FooTy->isIndefiniteType());
+
+  ASSERT_FALSE(Ctx.getPointerType(Ctx.SveBoolTy)->isIndefiniteType());
+  ASSERT_FALSE(Ctx.getLValueReferenceType(Ctx.SveBoolTy)->isIndefiniteType());
+  ASSERT_FALSE(Ctx.getRValueReferenceType(Ctx.SveBoolTy)->isIndefiniteType());
+}
+
+TEST_F(SizelessTypeTester, TestIncomplete) {
+  ASSERT_TRUE(Ctx.SveInt8Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveInt16Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveInt32Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveInt64Ty->isIncompleteType());
+
+  ASSERT_TRUE(Ctx.SveUint8Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveUint16Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveUint32Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveUint64Ty->isIncompleteType());
+
+  ASSERT_TRUE(Ctx.SveFloat16Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveFloat32Ty->isIncompleteType());
+  ASSERT_TRUE(Ctx.SveFloat64Ty->isIncompleteType());
+
+  ASSERT_TRUE(Ctx.SveBoolTy->isIncompleteType());
+
+  ASSERT_TRUE(Ctx.VoidTy->isIncompleteType());
+  ASSERT_FALSE(Ctx.PseudoObjectTy->isIncompleteType());
+  ASSERT_TRUE(FooTy->isIncompleteType());
+
+  ASSERT_FALSE(Ctx.getPointerType(Ctx.SveBoolTy)->isIncompleteType());
+  ASSERT_FALSE(Ctx.getLValueReferenceType(Ctx.SveBoolTy)->isIncompleteType());
+  ASSERT_FALSE(Ctx.getRValueReferenceType(Ctx.SveBoolTy)->isIncompleteType());
+}
Index: unittests/AST/CMakeLists.txt
===
---

[PATCH] D62960: SVE opaque type for C intrinsics demo

2019-06-27 Thread Richard Sandiford via Phabricator via cfe-commits

rsandifo-arm marked 7 inline comments as done.
rsandifo-arm added a comment.

Thanks for the reviews!




Comment at: include/clang/Basic/AArch64SVEACLETypes.def:10
+//
+//  This file defines the database about various builtin singleton types.
+//

rovka wrote:
> You can be more specific :)
Yeah, there were a few cut-&-pastos here, sorry.  Hopefully fixed in the 
updated version.



Comment at: include/clang/Basic/AArch64SVEACLETypes.def:29
+#define SVE_VECTOR_TYPE(Name, Id, SingletonId, ElKind, ElBits, IsSigned, IsFP)\
+  BUILTIN_TYPE(Name, Id, SingletonId)
+#endif

rovka wrote:
> Maybe use SVE_TYPE instead of BUILTIN_TYPE, to avoid any confusion?  You 
> can't re-use a defition of BUILTIN_TYPE between this header and 
> BuiltinTypes.def anyway, since they both undefine it at the end.
Yeah, that's definitely better, especially given the different number of 
arguments.  Done in the updated version.



Comment at: lib/AST/ASTContext.cpp:6645
+  case BuiltinType::Id:
+#include "clang/Basic/AArch64SVEACLETypes.def"
 #define BUILTIN_TYPE(KIND, ID)

rovka wrote:
> Here and in most other places: no need for 2 defines, you can just #define 
> BUILTIN_TYPE (or if you choose to rename it to SVE_TYPE) since it's the same 
> code for both vectors and predicates.
Thanks, that shaved quite a lot of lines off the patch :-)



Comment at: lib/AST/ItaniumMangle.cpp:2680
+break;
+#include "clang/Basic/AArch64SVEACLETypes.def"
   }

rovka wrote:
> erik.pilkington wrote:
> > rsandifo-arm wrote:
> > > erik.pilkington wrote:
> > > > jfb wrote:
> > > > > @rjmccall you probably should review this part.
> > > > Sorry for the drive by comment, but: All of these mangling should 
> > > > really be using the "vendor extension" production IMO:
> > > > 
> > > > ` ::= u `
> > > > 
> > > > As is, these manglings intrude on the users's namespace, (i.e. if they 
> > > > had a type named `objc_selector` or something), and confuse demanglers 
> > > > which incorrectly assume these are substitutable (vendor extension 
> > > > builtin types are substitutable too though, but that should be handled 
> > > > here).
> > > It isn't obvious from the patch, but the SVE names that we're mangling 
> > > are predefined names like __SVInt8_t. rather than user-facing names like 
> > > svint8_t  The predefined names and their mangling are defined by the 
> > > platform ABI (https://developer.arm.com/docs/100986/), so it wouldn't 
> > > be valid for another part of the implementation to use those names for 
> > > something else.
> > > 
> > > I realise you were making a general point here though, sorry.
> > > 
> > The mangling in the document you linked does use the vendor extension 
> > production here though, i.e. the example is `void f(int8x8_t)`, which 
> > mangles to _Z1f**u10__Int8x8_t**. It is true that this shouldn't ever 
> > collide with another mangling in practice, but my point is there isn't any 
> > need to smuggle it into the mangling by pretending it's a user defined 
> > type, when the itanium grammar and related tools have a special way for 
> > vendors to add builtin types.
> I agree with Erik here, the example in the PCS document seems to suggest 
> using u. I think either the patch needs to be updated or the document needs 
> to be more clear about what the mangling is supposed to look like.
Thanks for highlighting this problem, and sorry for not noticing myself when 
pointing you at the doc.

Unfortunately, the specification and implementation already difer for the 
Advanced SIMD types, with both clang and GCC omitting the 'u' despite the spec 
saying it should be present.  So we're considering changing the spec to match 
what's now the de facto ABI.

For SVE we do still have the opportunity to use 'u'.  I've left it as-is for 
now though, until we've reached a decision about whether to follow existing 
practice for Advanced SIMD or whether to do what the spec says.



Comment at: lib/AST/MicrosoftMangle.cpp:2110
+llvm_unreachable("mangling an sve type not yet supported");
+#include "clang/Basic/AArch64SVEACLETypes.def"
   }

rovka wrote:
> Should we have llvm_unreachable or report a proper error? I like the 
> unreachable if we're checking elsewhere that SVE isn't supported on Windows, 
> but I notice we report errors for some of the other types.
Fixed to report the error, since this wouldn't be trapped earlier.



Comment at: lib/CodeGen/CGDebugInfo.cpp:709
+  case BuiltinType::Id: \
+return nullptr;
+#include "clang/Basic/AArch64SVEACLETypes.def"

rovka wrote:
> I don't really know this code, but I can't help but notice that nullptr is 
> only ever used for the void type. Is it safe to also use it for the SVE 
> types, or can we do something else instead?
Fixed to report an error here too and return a "safe" value until the TODO

[PATCH] D63856: [ObjC] Add a -Wtautological-compare warning for BOOL

2019-06-27 Thread Erik Pilkington via Phabricator via cfe-commits

erik.pilkington added a comment.

In D63856#1561112 , @rjmccall wrote:

> In D63856#1560213 , @erik.pilkington 
> wrote:
>
> > In D63856#1560180 , @rjmccall 
> > wrote:
> >
> > > This only applies to relational operators, right?  I'm a little 
> > > uncomfortable with calling this "tautological" since it's not like it's 
> > > *undefined behavior* to have `(BOOL) 2`, it's just *unwise*.  But as long 
> > > as we aren't warning about reasonable idioms that are intended to handle 
> > > unfortunate situations — like other code that might have left a 
> > > non-`{0,1}` value in the `BOOL` — I think this is fine.
> >
> >
> > I think the party line is that it is undefined behaviour (in some sense), 
> > since UBSan will happily crash if you try to load a non-boolean value from 
> > a BOOL.
>
>
> What?  Since when?


https://reviews.llvm.org/D27607

> 
> 
>> It is a bit unfortunate that "defensive" code will start warning here though 
>> :/. Maybe we can try to detect and permit something like `B < NO || B > 
>> YES`, or emit a note with some canonical way of checking for non-boolean 
>> BOOLs. Even if we end up having to disable it default, I think its still a 
>> good diagnostic to have. A warning on stores to BOOL would probably be a lot 
>> higher value, though.
> 
> I'm not sure this is a problem because I'm not sure there's any reason to 
> write defensive code besides `B != NO` or `B == NO`.  It's potentially 
> problematic if someone writes `B == YES`, though.

I was thinking about something like the following, which probably isn't worth 
warning on. Another way of handling it would be only emitting the diagnostic if 
`!InRange`. Not exactly sure how common that pattern actually is though.

  void myAPI(BOOL DoAThing) {
if (DoAThing > YES || DoAThing < NO) DoAThing = YES;
// ...
  }


Repository:
  rC Clang

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

https://reviews.llvm.org/D63856



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

[PATCH] D62977: [clang-tidy]: Google: new check 'google-upgrade-googletest-case'

2019-06-27 Thread Alex Strelnikov via Phabricator via cfe-commits

astrelni marked 4 inline comments as done.
astrelni added a comment.

In D62977#1560879 , @lebedev.ri wrote:

> Looks reasonable. I did not review the check itself though.
>  Are `test/clang-tidy/google-upgrade-googletest-case-nosuite.cpp` and 
> `test/clang-tidy/google-upgrade-googletest-case.cpp ` identical other than 
> the included header and expected output?
>  I'd recommend to condense it into a single file, and just have two `RUN` 
> lines each one checking different message prefixes


The nosuite test was a strict subset. I've combined them with a few lines that 
needed to be turned via preprocessor branches. Thank you, I actually wasn't 
aware that these tests can have multiple `RUN` lines.




Comment at: clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.h:34
+private:
+  std::unordered_set MatchedTemplateLocations;
+};

lebedev.ri wrote:
> Have you tried `llvm::DenseSet` instead?
> This //may// not matter *here*, but `std::unordered_set` usually results in 
> horrible perf.
Thanks, I wasn't aware of what is available.



Comment at: 
clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case-nosuite.cpp:9
+void DummyFixTarget() {}
+// CHECK-FIXES: void DummyFixTarget() {}
+

lebedev.ri wrote:
> Hm?
I added a comment to better explain this in the combined test. 
check_clang_tidy.py asserts that there is at least one message, fix or note 
comment present in the file. If there isn't one, the script returns without 
even running the test. I couldn't see an option to pass that would turn of this 
check, please let me know if you are aware of one.


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

https://reviews.llvm.org/D62977



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

[PATCH] D62960: SVE opaque type for C intrinsics demo

2019-06-27 Thread Richard Sandiford via Phabricator via cfe-commits

rsandifo-arm updated this revision to Diff 206891.
rsandifo-arm added a comment.

- Fix comments in AArch64SVEACLETypes.def
- Rename BUILTIN_TYPE to SVE_TYPE and use it where possible
- Report errors for TODOs instead of using llvm_unreachable
- Add a test for the errors
- Formatting fixes


Repository:
  rC Clang

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

https://reviews.llvm.org/D62960

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/Type.h
  include/clang/Basic/AArch64SVEACLETypes.def
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/ExprConstant.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/AST/NSAPI.cpp
  lib/AST/PrintfFormatString.cpp
  lib/AST/Type.cpp
  lib/AST/TypeLoc.cpp
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CodeGenTypes.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/Index/USRGeneration.cpp
  lib/Sema/Sema.cpp
  lib/Sema/SemaExpr.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  test/CodeGen/aarch64-sve.c
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -1527,6 +1527,9 @@
   case BuiltinType::OCLClkEvent:
   case BuiltinType::OCLQueue:
   case BuiltinType::OCLReserveID:
+  // SVE Types
+#define SVE_TYPE(Name, Id, SingletonId) case BuiltinType::Id:
+#include "clang/Basic/AArch64SVEACLETypes.def"
 #define BUILTIN_TYPE(Id, SingletonId)
 #define SIGNED_TYPE(Id, SingletonId) case BuiltinType::Id:
 #define UNSIGNED_TYPE(Id, SingletonId) case BuiltinType::Id:
Index: test/CodeGen/aarch64-sve.c
===
--- /dev/null
+++ test/CodeGen/aarch64-sve.c
@@ -0,0 +1,9 @@
+// RUN: not %clang_cc1 -triple arm64-none-linux-gnu -target-feature +sve \
+// RUN:  -emit-llvm -o - %s -debug-info-kind=limited 2>&1 | FileCheck %s
+
+// Placeholder test for SVE types
+
+// CHECK: cannot yet generate code for SVE type '__SVInt8_t'
+// CHECK: cannot yet generate debug info for SVE type '__SVInt8_t'
+
+__SVInt8_t *ptr;
Index: lib/Serialization/ASTReader.cpp
===
--- lib/Serialization/ASTReader.cpp
+++ lib/Serialization/ASTReader.cpp
@@ -7037,6 +7037,12 @@
 case PREDEF_TYPE_OMP_ARRAY_SECTION:
   T = Context.OMPArraySectionTy;
   break;
+// SVE Types
+#define SVE_TYPE(Name, Id, SingletonId) \
+case PREDEF_TYPE_##Id##_ID: \
+  T = Context.SingletonId; \
+  break;
+#include "clang/Basic/AArch64SVEACLETypes.def"
 }
 
 assert(!T.isNull() && "Unknown predefined type");
Index: lib/Serialization/ASTCommon.cpp
===
--- lib/Serialization/ASTCommon.cpp
+++ lib/Serialization/ASTCommon.cpp
@@ -232,6 +232,12 @@
   case BuiltinType::OCLReserveID:
 ID = PREDEF_TYPE_RESERVE_ID_ID;
 break;
+  // SVE Types
+#define SVE_TYPE(Name, Id, SingletonId) \
+  case BuiltinType::Id: \
+ID = PREDEF_TYPE_##Id##_ID; \
+break;
+#include "clang/Basic/AArch64SVEACLETypes.def"
   case BuiltinType::BuiltinFn:
 ID = PREDEF_TYPE_BUILTIN_FN;
 break;
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -5243,6 +5243,9 @@
 #define EXT_OPAQUE_TYPE(ExtType, Id, Ext) \
   case BuiltinType::Id:
 #include "clang/Basic/OpenCLExtensionTypes.def"
+  // SVE Types
+#define SVE_TYPE(Name, Id, SingletonId) case BuiltinType::Id:
+#include "clang/Basic/AArch64SVEACLETypes.def"
 #define PLACEHOLDER_TYPE(ID, SINGLETON_ID)
 #define BUILTIN_TYPE(ID, SINGLETON_ID) case BuiltinType::ID:
 #include "clang/AST/BuiltinTypes.def"
@@ -17049,6 +17052,9 @@
 #define EXT_OPAQUE_TYPE(ExtType, Id, Ext) \
   case BuiltinType::Id:
 #include "clang/Basic/OpenCLExtensionTypes.def"
+  // SVE Types
+#define SVE_TYPE(Name, Id, SingletonId) case BuiltinType::Id:
+#include "clang/Basic/AArch64SVEACLETypes.def"
 #define BUILTIN_TYPE(Id, SingletonId) case BuiltinType::Id:
 #define PLACEHOLDER_TYPE(Id, SingletonId)
 #include "clang/AST/BuiltinTypes.def"
Index: lib/Sema/Sema.cpp
===
--- lib/Sema/Sema.cpp
+++ lib/Sema/Sema.cpp
@@ -336,7 +336,13 @@
 addImplicitTypedef(#ExtType, Context.Id##Ty); \
 setOpenCLExtensionForType(Context.Id##Ty, #Ext);
 #include "clang/Basic/OpenCLExtensionTypes.def"
-};
+  }
+
+  // SVE Types
+  // TODO: Check target?
+#define SVE_TYPE(Name, Id, SingletonId) \
+  addImplicitTypedef(Name, Context.SingletonId);
+#include "clang/Basic/AArch64SVEACLETypes.def"
 
   if (Context.getTargetInfo().hasBuiltinMSVaList()) {
 DeclarationName MSVaList = ("__builtin_ms_va_list");
Index: lib/Index/USRGeneration.cpp
===
---

[PATCH] D62977: [clang-tidy]: Google: new check 'google-upgrade-googletest-case'

2019-06-27 Thread Alex Strelnikov via Phabricator via cfe-commits

astrelni updated this revision to Diff 206889.

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

https://reviews.llvm.org/D62977

Files:
  clang-tools-extra/clang-tidy/google/CMakeLists.txt
  clang-tools-extra/clang-tidy/google/GoogleTidyModule.cpp
  clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.cpp
  clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/google-upgrade-googletest-case.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/Inputs/gtest/gtest-typed-test.h
  clang-tools-extra/test/clang-tidy/Inputs/gtest/gtest.h
  
clang-tools-extra/test/clang-tidy/Inputs/gtest/nosuite/gtest/gtest-typed-test.h
  clang-tools-extra/test/clang-tidy/Inputs/gtest/nosuite/gtest/gtest.h
  clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
  llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn

Index: llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
===
--- llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
+++ llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
@@ -28,6 +28,7 @@
 "OverloadedUnaryAndCheck.cpp",
 "TodoCommentCheck.cpp",
 "UnnamedNamespaceInHeaderCheck.cpp",
+"UpgradeGoogletestCaseCheck.cpp",
 "UsingNamespaceDirectiveCheck.cpp",
   ]
 }
Index: clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
@@ -0,0 +1,1016 @@
+// RUN: %check_clang_tidy %s google-upgrade-googletest-case %t -- -- -I%S/Inputs
+// RUN: %check_clang_tidy -check-suffix=NOSUITE %s google-upgrade-googletest-case %t -- -- -DNOSUITE -I%S/Inputs/gtest/nosuite
+
+#include "gtest/gtest.h"
+
+// When including a version of googletest without the replacement names, this
+// check should not produce any diagnostics. The following dummy fix is present
+// because `check_clang_tidy.py` requires at least one warning, fix or note. 
+void Dummy() {}
+// CHECK-FIXES-NOSUITE: void Dummy() {}
+
+// 
+// Macros
+
+TYPED_TEST_CASE(FooTest, FooTypes);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case' are deprecated; use equivalent APIs named with 'suite'
+// CHECK-FIXES: TYPED_TEST_SUITE(FooTest, FooTypes);
+TYPED_TEST_CASE_P(FooTest);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: TYPED_TEST_SUITE_P(FooTest);
+REGISTER_TYPED_TEST_CASE_P(FooTest, FooTestName);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: REGISTER_TYPED_TEST_SUITE_P(FooTest, FooTestName);
+INSTANTIATE_TYPED_TEST_CASE_P(FooPrefix, FooTest, FooTypes);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: INSTANTIATE_TYPED_TEST_SUITE_P(FooPrefix, FooTest, FooTypes);
+
+#ifdef TYPED_TEST_CASE
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef TYPED_TEST_CASE
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define TYPED_TEST_CASE(CaseName, Types, ...)
+#endif
+
+#ifdef TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define TYPED_TEST_CASE_P(SuiteName)
+#endif
+
+#ifdef REGISTER_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef REGISTER_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define REGISTER_TYPED_TEST_CASE_P(SuiteName, ...)
+#endif
+
+#ifdef INSTANTIATE_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef INSTANTIATE_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define INSTANTIATE_TYPED_TEST_CASE_P(Prefix, SuiteName, Types, ...)
+#endif
+
+TYPED_TEST_CASE(FooTest, FooTypes);
+TYPED_TEST_CASE_P(FooTest);
+REGISTER_TYPED_TEST_CASE_P(FooTest, FooTestName);
+INSTANTIATE_TYPED_TEST_CASE_P(FooPrefix, FooTest, FooTypes);
+
+// 
+// testing::Test
+
+class FooTest : public testing::Test {
+public:
+  static void SetUpTestCase();
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+  // CHECK-FIXES: static void SetUpTestSuite();
+  static void TearDownTestCase();
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+  // CHECK-FIXES: static void TearDownTestSuite();
+};
+
+void

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

2019-06-27 Thread Lingda Li via Phabricator via cfe-commits

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



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Currently 
> > > > > > > > > > > > > > > > > > > > > > > > > > > `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > > > > > > generated by the 
> > > > > > > > > > > > > > > > > > > > > > > > > > > compiler. But can we 
> > > > > > > > > > > > > > > > > > > > > > > > > > > instead pass this data as 
> > > > > > > > > > > > > > > > > > > > > > > > > > > an extra parameter to 
> > > > > > > > > > > > > > > > > > > > > > > > > > > this `omp_mapper` 
> > > > > > > > > > > > > > > > > > > > > > > > > > > function.
> > > > > > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme 
> > > > > > > > > > > > > > > > > > > > > > > > > > will be very difficult and 
> > > > > > > > > > > > > > > > > > > > > > > > > > inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > > > > > > > components as an argument 
> > > > > > > > > > > > > > > > > > > > > > > > > > of `omp_mapper` function, 
> > > > > > > > > > > > > > > > > > > > > > > > > > it means that the runtime 
> > > > > > > > > > > > > > > > > > > > > > > > > > needs to generate all 
> > > > > > > > > > > > > > > > > > > > > > > > > > components related to a map 
> > > > > > > > > > > > > > > > > > > > > > > > > > clause. I don't think the 
> > > > > > > > > > > > > > > > > > > > > > > > > > runtime is able to do that 
> > > > > > > > > > > > > > > > > > > > > > > > > > efficiently. On the other 
> > > > > > > > > > > > > > > > > > > > > > > > > > hand, in the current 
> > > > > > > > > > > > > > > > > > > > > > > > > > scheme, these components 
> > > > > > > > > > > > > > > > > > > > > > > > > > are naturally generated by 
> > > > > > > > > > > > > > > > > > > > > > > > > > the compiler, and the 
> > > > > > > > > > > > > > > > > > > > > > > > > > runtime only needs to know 
> > > > > > > > > > > > > > > > > > > > > > > > > > the base pointer, pointer, 
> > > > > > > > > > > > > > > > > > > > > > > > > > type, size. etc.
> > > > > > > > > > > > > > > > > > > > > > > > > With the current scheme, we 
> > > > > > > > > > > > > > > > > > > > > > > > > may end with the code 
> > > > > > > > > > > > > > > > > > > > > > > > > blowout. We need to generate 
> > > > > > > > > > > > > > > > > > > > > > > > > very similar code for 
> > > > > > > > > > > > > > > > > > > > > > > > > different types and 
> > > > > > > > > > > > > > > > > > > > > > > > > variables. The worst thing 
> > > > > > > > > > > > > > > > > > > > > > > > > here is that we will be 
> > > > > > > > > > > > > > > > > > > > > > > > > unable to optimize this huge 
> > > > > > > > > > > > > > > > > > > > > > > > > amount of code because the 
> > > > > > > > > > > > > > > > > > > > > > > > > codegen relies on the runtime 
> > > > > > > > > > > > > > > > > > > > > > > > > functions and the code cannot 
> > > > > > > > > > > > > > > > > > > > > > > > > be inlined. That's why I 
> > > > > > > > > > > > > > > > > > > > > > > > > would like to move as much as 
> > > > > > > > > > > > > > > > > > > > > > > > > possible code to the runtime 
> > > > > > > > > > > > > > > > > > > > > > > > > rather than to emit it in the 
> > > > > > > > > > > > > > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > > > > > > > > > > > > > I understand your concerns. I 
> > > > > > > > > > > > > > > > > > > > > > > > think this is the best we can 
> > > > > > > > > > > > > > > > > > > > > > > > do right now.
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > The most worrisome case will be 
> >

[PATCH] D63856: [ObjC] Add a -Wtautological-compare warning for BOOL

2019-06-27 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

In D63856#1560213 , @erik.pilkington 
wrote:

> In D63856#1560180 , @rjmccall wrote:
>
> > This only applies to relational operators, right?  I'm a little 
> > uncomfortable with calling this "tautological" since it's not like it's 
> > *undefined behavior* to have `(BOOL) 2`, it's just *unwise*.  But as long 
> > as we aren't warning about reasonable idioms that are intended to handle 
> > unfortunate situations — like other code that might have left a non-`{0,1}` 
> > value in the `BOOL` — I think this is fine.
>
>
> I think the party line is that it is undefined behaviour (in some sense), 
> since UBSan will happily crash if you try to load a non-boolean value from a 
> BOOL.


What?  Since when?

> It is a bit unfortunate that "defensive" code will start warning here though 
> :/. Maybe we can try to detect and permit something like `B < NO || B > YES`, 
> or emit a note with some canonical way of checking for non-boolean BOOLs. 
> Even if we end up having to disable it default, I think its still a good 
> diagnostic to have. A warning on stores to BOOL would probably be a lot 
> higher value, though.

I'm not sure this is a problem because I'm not sure there's any reason to write 
defensive code besides `B != NO` or `B == NO`.  It's potentially problematic if 
someone writes `B == YES`, though.


Repository:
  rC Clang

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

https://reviews.llvm.org/D63856



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

2019-06-27 Thread Alexey Bataev via Phabricator via cfe-commits

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > lildmh wrote:
> > > > > > > > > ABataev wrote:
> > > > > > > > > > lildmh wrote:
> > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > Currently 
> > > > > > > > > > > > > > > > > > > > > > > > > > `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > > > > > generated by the compiler. 
> > > > > > > > > > > > > > > > > > > > > > > > > > But can we instead pass 
> > > > > > > > > > > > > > > > > > > > > > > > > > this data as an extra 
> > > > > > > > > > > > > > > > > > > > > > > > > > parameter to this 
> > > > > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will 
> > > > > > > > > > > > > > > > > > > > > > > > > be very difficult and 
> > > > > > > > > > > > > > > > > > > > > > > > > inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > > > > > > components as an argument of 
> > > > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function, it 
> > > > > > > > > > > > > > > > > > > > > > > > > means that the runtime needs 
> > > > > > > > > > > > > > > > > > > > > > > > > to generate all components 
> > > > > > > > > > > > > > > > > > > > > > > > > related to a map clause. I 
> > > > > > > > > > > > > > > > > > > > > > > > > don't think the runtime is 
> > > > > > > > > > > > > > > > > > > > > > > > > able to do that efficiently. 
> > > > > > > > > > > > > > > > > > > > > > > > > On the other hand, in the 
> > > > > > > > > > > > > > > > > > > > > > > > > current scheme, these 
> > > > > > > > > > > > > > > > > > > > > > > > > components are naturally 
> > > > > > > > > > > > > > > > > > > > > > > > > generated by the compiler, 
> > > > > > > > > > > > > > > > > > > > > > > > > and the runtime only needs to 
> > > > > > > > > > > > > > > > > > > > > > > > > know the base pointer, 
> > > > > > > > > > > > > > > > > > > > > > > > > pointer, type, size. etc.
> > > > > > > > > > > > > > > > > > > > > > > > With the current scheme, we may 
> > > > > > > > > > > > > > > > > > > > > > > > end with the code blowout. We 
> > > > > > > > > > > > > > > > > > > > > > > > need to generate very similar 
> > > > > > > > > > > > > > > > > > > > > > > > code for different types and 
> > > > > > > > > > > > > > > > > > > > > > > > variables. The worst thing here 
> > > > > > > > > > > > > > > > > > > > > > > > is that we will be unable to 
> > > > > > > > > > > > > > > > > > > > > > > > optimize this huge amount of 
> > > > > > > > > > > > > > > > > > > > > > > > code because the codegen relies 
> > > > > > > > > > > > > > > > > > > > > > > > on the runtime functions and 
> > > > > > > > > > > > > > > > > > > > > > > > the code cannot be inlined. 
> > > > > > > > > > > > > > > > > > > > > > > > That's why I would like to move 
> > > > > > > > > > > > > > > > > > > > > > > > as much as possible code to the 
> > > > > > > > > > > > > > > > > > > > > > > > runtime rather than to emit it 
> > > > > > > > > > > > > > > > > > > > > > > > in the compiler. 
> > > > > > > > > > > > > > > > > > > > > > > I understand your concerns. I 
> > > > > > > > > > > > > > > > > > > > > > > think this is the best we can do 
> > > > > > > > > > > > > > > > > > > > > > > right now.
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > The most worrisome case will be 
> > > > > > > > > > > > > > > > > > > > > > > when we have nested mappers 
> > > > > > > > > > > > > > > > > > > > > > > within each other. In this case, 
> > > > > > > > > > > > > > > > > > > > > > > a mapper function will call 
> > > > > > > > > > > > > > > > > > > > > > > another mapper function. We can 
> > > > > > > > > > > > > > > > > > > > > > > inline the inner mapper functions 
> > > > > > > > >

[PATCH] D63773: [clangd] dummy variable extraction on a function scope

2019-06-27 Thread Shaurya Gupta via Phabricator via cfe-commits

SureYeaah marked 14 inline comments as done.
SureYeaah added inline comments.



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:173
+  // give up if extraction will take a variable out of scope
+  if (!extractionAllowed(ParStmt, N, M))
+break;

sammccall wrote:
> here you're traversing the whole Expr to find the referenced decls at each 
> iteration of this loop.
> Can you analyse the expr just once, and reuse the list of decls?
I thought it'll only be analyzed once but actually it's at max twice in the 
case where the selected expression is a part of a DeclStmt in the  of a 
ForStmt.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63773



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

2019-06-27 Thread Lingda Li via Phabricator via cfe-commits

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



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` 
> > > > > > > > > > > > > > > > > > > > > > > > > is generated by the compiler. 
> > > > > > > > > > > > > > > > > > > > > > > > > But can we instead pass this 
> > > > > > > > > > > > > > > > > > > > > > > > > data as an extra parameter to 
> > > > > > > > > > > > > > > > > > > > > > > > > this `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will 
> > > > > > > > > > > > > > > > > > > > > > > > be very difficult and 
> > > > > > > > > > > > > > > > > > > > > > > > inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > > > > > components as an argument of 
> > > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function, it means 
> > > > > > > > > > > > > > > > > > > > > > > > that the runtime needs to 
> > > > > > > > > > > > > > > > > > > > > > > > generate all components related 
> > > > > > > > > > > > > > > > > > > > > > > > to a map clause. I don't think 
> > > > > > > > > > > > > > > > > > > > > > > > the runtime is able to do that 
> > > > > > > > > > > > > > > > > > > > > > > > efficiently. On the other hand, 
> > > > > > > > > > > > > > > > > > > > > > > > in the current scheme, these 
> > > > > > > > > > > > > > > > > > > > > > > > components are naturally 
> > > > > > > > > > > > > > > > > > > > > > > > generated by the compiler, and 
> > > > > > > > > > > > > > > > > > > > > > > > the runtime only needs to know 
> > > > > > > > > > > > > > > > > > > > > > > > the base pointer, pointer, 
> > > > > > > > > > > > > > > > > > > > > > > > type, size. etc.
> > > > > > > > > > > > > > > > > > > > > > > With the current scheme, we may 
> > > > > > > > > > > > > > > > > > > > > > > end with the code blowout. We 
> > > > > > > > > > > > > > > > > > > > > > > need to generate very similar 
> > > > > > > > > > > > > > > > > > > > > > > code for different types and 
> > > > > > > > > > > > > > > > > > > > > > > variables. The worst thing here 
> > > > > > > > > > > > > > > > > > > > > > > is that we will be unable to 
> > > > > > > > > > > > > > > > > > > > > > > optimize this huge amount of code 
> > > > > > > > > > > > > > > > > > > > > > > because the codegen relies on the 
> > > > > > > > > > > > > > > > > > > > > > > runtime functions and the code 
> > > > > > > > > > > > > > > > > > > > > > > cannot be inlined. That's why I 
> > > > > > > > > > > > > > > > > > > > > > > would like to move as much as 
> > > > > > > > > > > > > > > > > > > > > > > possible code to the runtime 
> > > > > > > > > > > > > > > > > > > > > > > rather than to emit it in the 
> > > > > > > > > > > > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > > > > > > > > > > > I understand your concerns. I think 
> > > > > > > > > > > > > > > > > > > > > > this is the best we can do right 
> > > > > > > > > > > > > > > > > > > > > > now.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > The most worrisome case will be 
> > > > > > > > > > > > > > > > > > > > > > when we have nested mappers within 
> > > > > > > > > > > > > > > > > > > > > > each other. In this case, a mapper 
> > > > > > > > > > > > > > > > > > > > > > function will call another mapper 
> > > > > > > > > > > > > > > > > > > > > > function. We can inline the inner 
> > > > > > > > > > > > > > > > > > > > > > mapper functions in this scenario, 
> > > > > > > > > > > > > > > > > > > > > > so that these mapper function can 
> > > > > > > > > > > > > > > > > > > > > > be properly optimized. As a result, 
> > > > > > > > > > > > > > > > > > > > > > I think the performance should be 
> > > > > > > > > > > > > > > >

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

2019-06-27 Thread Alexey Bataev via Phabricator via cfe-commits

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > lildmh wrote:
> > > > > > > > > ABataev wrote:
> > > > > > > > > > lildmh wrote:
> > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > > > generated by the compiler. But 
> > > > > > > > > > > > > > > > > > > > > > > > can we instead pass this data 
> > > > > > > > > > > > > > > > > > > > > > > > as an extra parameter to this 
> > > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be 
> > > > > > > > > > > > > > > > > > > > > > > very difficult and inefficient. 
> > > > > > > > > > > > > > > > > > > > > > > If we pass components as an 
> > > > > > > > > > > > > > > > > > > > > > > argument of `omp_mapper` 
> > > > > > > > > > > > > > > > > > > > > > > function, it means that the 
> > > > > > > > > > > > > > > > > > > > > > > runtime needs to generate all 
> > > > > > > > > > > > > > > > > > > > > > > components related to a map 
> > > > > > > > > > > > > > > > > > > > > > > clause. I don't think the runtime 
> > > > > > > > > > > > > > > > > > > > > > > is able to do that efficiently. 
> > > > > > > > > > > > > > > > > > > > > > > On the other hand, in the current 
> > > > > > > > > > > > > > > > > > > > > > > scheme, these components are 
> > > > > > > > > > > > > > > > > > > > > > > naturally generated by the 
> > > > > > > > > > > > > > > > > > > > > > > compiler, and the runtime only 
> > > > > > > > > > > > > > > > > > > > > > > needs to know the base pointer, 
> > > > > > > > > > > > > > > > > > > > > > > pointer, type, size. etc.
> > > > > > > > > > > > > > > > > > > > > > With the current scheme, we may end 
> > > > > > > > > > > > > > > > > > > > > > with the code blowout. We need to 
> > > > > > > > > > > > > > > > > > > > > > generate very similar code for 
> > > > > > > > > > > > > > > > > > > > > > different types and variables. The 
> > > > > > > > > > > > > > > > > > > > > > worst thing here is that we will be 
> > > > > > > > > > > > > > > > > > > > > > unable to optimize this huge amount 
> > > > > > > > > > > > > > > > > > > > > > of code because the codegen relies 
> > > > > > > > > > > > > > > > > > > > > > on the runtime functions and the 
> > > > > > > > > > > > > > > > > > > > > > code cannot be inlined. That's why 
> > > > > > > > > > > > > > > > > > > > > > I would like to move as much as 
> > > > > > > > > > > > > > > > > > > > > > possible code to the runtime rather 
> > > > > > > > > > > > > > > > > > > > > > than to emit it in the compiler. 
> > > > > > > > > > > > > > > > > > > > > I understand your concerns. I think 
> > > > > > > > > > > > > > > > > > > > > this is the best we can do right now.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > The most worrisome case will be when 
> > > > > > > > > > > > > > > > > > > > > we have nested mappers within each 
> > > > > > > > > > > > > > > > > > > > > other. In this case, a mapper 
> > > > > > > > > > > > > > > > > > > > > function will call another mapper 
> > > > > > > > > > > > > > > > > > > > > function. We can inline the inner 
> > > > > > > > > > > > > > > > > > > > > mapper functions in this scenario, so 
> > > > > > > > > > > > > > > > > > > > > that these mapper function can be 
> > > > > > > > > > > > > > > > > > > > > properly optimized. As a result, I 
> > > > > > > > > > > > > > > > > > > > > think the performance should be fine.
> > > > > > > > > > > > > > > > > > > > Instead, we can use indirect function 
> > > > > > > > > > > > > > > > > > > > calls passed in the array to the 
> > > > > > > > > > > > > > > > > > > > runtime. Do you think it is going to be 
> > > > > > > > > > > > > > > > > > > > slower? In your current scheme, we 
> > > > > > > > > > > > > > > > > > > > generate many runtime calls instead. 
> > > > > > > > >

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

2019-06-27 Thread Lingda Li via Phabricator via cfe-commits

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



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > > generated by the compiler. But 
> > > > > > > > > > > > > > > > > > > > > > > can we instead pass this data as 
> > > > > > > > > > > > > > > > > > > > > > > an extra parameter to this 
> > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be 
> > > > > > > > > > > > > > > > > > > > > > very difficult and inefficient. If 
> > > > > > > > > > > > > > > > > > > > > > we pass components as an argument 
> > > > > > > > > > > > > > > > > > > > > > of `omp_mapper` function, it means 
> > > > > > > > > > > > > > > > > > > > > > that the runtime needs to generate 
> > > > > > > > > > > > > > > > > > > > > > all components related to a map 
> > > > > > > > > > > > > > > > > > > > > > clause. I don't think the runtime 
> > > > > > > > > > > > > > > > > > > > > > is able to do that efficiently. On 
> > > > > > > > > > > > > > > > > > > > > > the other hand, in the current 
> > > > > > > > > > > > > > > > > > > > > > scheme, these components are 
> > > > > > > > > > > > > > > > > > > > > > naturally generated by the 
> > > > > > > > > > > > > > > > > > > > > > compiler, and the runtime only 
> > > > > > > > > > > > > > > > > > > > > > needs to know the base pointer, 
> > > > > > > > > > > > > > > > > > > > > > pointer, type, size. etc.
> > > > > > > > > > > > > > > > > > > > > With the current scheme, we may end 
> > > > > > > > > > > > > > > > > > > > > with the code blowout. We need to 
> > > > > > > > > > > > > > > > > > > > > generate very similar code for 
> > > > > > > > > > > > > > > > > > > > > different types and variables. The 
> > > > > > > > > > > > > > > > > > > > > worst thing here is that we will be 
> > > > > > > > > > > > > > > > > > > > > unable to optimize this huge amount 
> > > > > > > > > > > > > > > > > > > > > of code because the codegen relies on 
> > > > > > > > > > > > > > > > > > > > > the runtime functions and the code 
> > > > > > > > > > > > > > > > > > > > > cannot be inlined. That's why I would 
> > > > > > > > > > > > > > > > > > > > > like to move as much as possible code 
> > > > > > > > > > > > > > > > > > > > > to the runtime rather than to emit it 
> > > > > > > > > > > > > > > > > > > > > in the compiler. 
> > > > > > > > > > > > > > > > > > > > I understand your concerns. I think 
> > > > > > > > > > > > > > > > > > > > this is the best we can do right now.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > The most worrisome case will be when we 
> > > > > > > > > > > > > > > > > > > > have nested mappers within each other. 
> > > > > > > > > > > > > > > > > > > > In this case, a mapper function will 
> > > > > > > > > > > > > > > > > > > > call another mapper function. We can 
> > > > > > > > > > > > > > > > > > > > inline the inner mapper functions in 
> > > > > > > > > > > > > > > > > > > > this scenario, so that these mapper 
> > > > > > > > > > > > > > > > > > > > function can be properly optimized. As 
> > > > > > > > > > > > > > > > > > > > a result, I think the performance 
> > > > > > > > > > > > > > > > > > > > should be fine.
> > > > > > > > > > > > > > > > > > > Instead, we can use indirect function 
> > > > > > > > > > > > > > > > > > > calls passed in the array to the runtime. 
> > > > > > > > > > > > > > > > > > > Do you think it is going to be slower? In 
> > > > > > > > > > > > > > > > > > > your current scheme, we generate many 
> > > > > > > > > > > > > > > > > > > runtime calls instead. Could you try to 
> > > > > > > > > > > > > > > > > > > estimate the number of calls in cases if 
> > > > > > > > > > > > > > > > > > > we'll call the mappers through the 
> > > > >

[PATCH] D61809: [BPF] Preserve debuginfo array/union/struct type/access index

2019-06-27 Thread Yonghong Song via Phabricator via cfe-commits

yonghong-song added a comment.

@eli.friedman Hi, Just ping. I have removed getParents() for ASTContext and 
added description of the new intrinsic in language doc. Could you take a look? 
Thanks!


Repository:
  rC Clang

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

https://reviews.llvm.org/D61809



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

2019-06-27 Thread Alexey Bataev via Phabricator via cfe-commits

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > lildmh wrote:
> > > > > > > > > ABataev wrote:
> > > > > > > > > > lildmh wrote:
> > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > generated by the compiler. But can 
> > > > > > > > > > > > > > > > > > > > > > we instead pass this data as an 
> > > > > > > > > > > > > > > > > > > > > > extra parameter to this 
> > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be very 
> > > > > > > > > > > > > > > > > > > > > difficult and inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > > components as an argument of 
> > > > > > > > > > > > > > > > > > > > > `omp_mapper` function, it means that 
> > > > > > > > > > > > > > > > > > > > > the runtime needs to generate all 
> > > > > > > > > > > > > > > > > > > > > components related to a map clause. I 
> > > > > > > > > > > > > > > > > > > > > don't think the runtime is able to do 
> > > > > > > > > > > > > > > > > > > > > that efficiently. On the other hand, 
> > > > > > > > > > > > > > > > > > > > > in the current scheme, these 
> > > > > > > > > > > > > > > > > > > > > components are naturally generated by 
> > > > > > > > > > > > > > > > > > > > > the compiler, and the runtime only 
> > > > > > > > > > > > > > > > > > > > > needs to know the base pointer, 
> > > > > > > > > > > > > > > > > > > > > pointer, type, size. etc.
> > > > > > > > > > > > > > > > > > > > With the current scheme, we may end 
> > > > > > > > > > > > > > > > > > > > with the code blowout. We need to 
> > > > > > > > > > > > > > > > > > > > generate very similar code for 
> > > > > > > > > > > > > > > > > > > > different types and variables. The 
> > > > > > > > > > > > > > > > > > > > worst thing here is that we will be 
> > > > > > > > > > > > > > > > > > > > unable to optimize this huge amount of 
> > > > > > > > > > > > > > > > > > > > code because the codegen relies on the 
> > > > > > > > > > > > > > > > > > > > runtime functions and the code cannot 
> > > > > > > > > > > > > > > > > > > > be inlined. That's why I would like to 
> > > > > > > > > > > > > > > > > > > > move as much as possible code to the 
> > > > > > > > > > > > > > > > > > > > runtime rather than to emit it in the 
> > > > > > > > > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > > > > > > > > I understand your concerns. I think this 
> > > > > > > > > > > > > > > > > > > is the best we can do right now.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > The most worrisome case will be when we 
> > > > > > > > > > > > > > > > > > > have nested mappers within each other. In 
> > > > > > > > > > > > > > > > > > > this case, a mapper function will call 
> > > > > > > > > > > > > > > > > > > another mapper function. We can inline 
> > > > > > > > > > > > > > > > > > > the inner mapper functions in this 
> > > > > > > > > > > > > > > > > > > scenario, so that these mapper function 
> > > > > > > > > > > > > > > > > > > can be properly optimized. As a result, I 
> > > > > > > > > > > > > > > > > > > think the performance should be fine.
> > > > > > > > > > > > > > > > > > Instead, we can use indirect function calls 
> > > > > > > > > > > > > > > > > > passed in the array to the runtime. Do you 
> > > > > > > > > > > > > > > > > > think it is going to be slower? In your 
> > > > > > > > > > > > > > > > > > current scheme, we generate many runtime 
> > > > > > > > > > > > > > > > > > calls instead. Could you try to estimate 
> > > > > > > > > > > > > > > > > > the number of calls in cases if we'll call 
> > > > > > > > > > > > > > > > > > the mappers through the indirect function 
> > > > > > > > > > > > > > > > > > calls and in your cuurent scheme, where we 
> > > > > > > > > > > > > > > > > > need to call the runtime functions many 
> > > > > > > > > > > > > > > > > > times in each particular mapper?
> > > > > > > > > > > > > > > > > Hi Alexey,
>

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

2019-06-27 Thread Lingda Li via Phabricator via cfe-commits

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



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > generated by the compiler. But can we 
> > > > > > > > > > > > > > > > > > > > > instead pass this data as an extra 
> > > > > > > > > > > > > > > > > > > > > parameter to this `omp_mapper` 
> > > > > > > > > > > > > > > > > > > > > function.
> > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be very 
> > > > > > > > > > > > > > > > > > > > difficult and inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > components as an argument of 
> > > > > > > > > > > > > > > > > > > > `omp_mapper` function, it means that 
> > > > > > > > > > > > > > > > > > > > the runtime needs to generate all 
> > > > > > > > > > > > > > > > > > > > components related to a map clause. I 
> > > > > > > > > > > > > > > > > > > > don't think the runtime is able to do 
> > > > > > > > > > > > > > > > > > > > that efficiently. On the other hand, in 
> > > > > > > > > > > > > > > > > > > > the current scheme, these components 
> > > > > > > > > > > > > > > > > > > > are naturally generated by the 
> > > > > > > > > > > > > > > > > > > > compiler, and the runtime only needs to 
> > > > > > > > > > > > > > > > > > > > know the base pointer, pointer, type, 
> > > > > > > > > > > > > > > > > > > > size. etc.
> > > > > > > > > > > > > > > > > > > With the current scheme, we may end with 
> > > > > > > > > > > > > > > > > > > the code blowout. We need to generate 
> > > > > > > > > > > > > > > > > > > very similar code for different types and 
> > > > > > > > > > > > > > > > > > > variables. The worst thing here is that 
> > > > > > > > > > > > > > > > > > > we will be unable to optimize this huge 
> > > > > > > > > > > > > > > > > > > amount of code because the codegen relies 
> > > > > > > > > > > > > > > > > > > on the runtime functions and the code 
> > > > > > > > > > > > > > > > > > > cannot be inlined. That's why I would 
> > > > > > > > > > > > > > > > > > > like to move as much as possible code to 
> > > > > > > > > > > > > > > > > > > the runtime rather than to emit it in the 
> > > > > > > > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > > > > > > > I understand your concerns. I think this is 
> > > > > > > > > > > > > > > > > > the best we can do right now.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > The most worrisome case will be when we 
> > > > > > > > > > > > > > > > > > have nested mappers within each other. In 
> > > > > > > > > > > > > > > > > > this case, a mapper function will call 
> > > > > > > > > > > > > > > > > > another mapper function. We can inline the 
> > > > > > > > > > > > > > > > > > inner mapper functions in this scenario, so 
> > > > > > > > > > > > > > > > > > that these mapper function can be properly 
> > > > > > > > > > > > > > > > > > optimized. As a result, I think the 
> > > > > > > > > > > > > > > > > > performance should be fine.
> > > > > > > > > > > > > > > > > Instead, we can use indirect function calls 
> > > > > > > > > > > > > > > > > passed in the array to the runtime. Do you 
> > > > > > > > > > > > > > > > > think it is going to be slower? In your 
> > > > > > > > > > > > > > > > > current scheme, we generate many runtime 
> > > > > > > > > > > > > > > > > calls instead. Could you try to estimate the 
> > > > > > > > > > > > > > > > > number of calls in cases if we'll call the 
> > > > > > > > > > > > > > > > > mappers through the indirect function calls 
> > > > > > > > > > > > > > > > > and in your cuurent scheme, where we need to 
> > > > > > > > > > > > > > > > > call the runtime functions many times in each 
> > > > > > > > > > > > > > > > > particular mapper?
> > > > > > > > > > > > > > > > Hi Alexey,
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Sorry I don't understand your idea. What 
> > > > > > > > > > > > > > > > indirect function

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

2019-06-27 Thread Alexey Bataev via Phabricator via cfe-commits

ABataev added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > lildmh wrote:
> > > > > > > > > ABataev wrote:
> > > > > > > > > > lildmh wrote:
> > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > generated by the compiler. But can we 
> > > > > > > > > > > > > > > > > > > > instead pass this data as an extra 
> > > > > > > > > > > > > > > > > > > > parameter to this `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be very 
> > > > > > > > > > > > > > > > > > > difficult and inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > components as an argument of `omp_mapper` 
> > > > > > > > > > > > > > > > > > > function, it means that the runtime needs 
> > > > > > > > > > > > > > > > > > > to generate all components related to a 
> > > > > > > > > > > > > > > > > > > map clause. I don't think the runtime is 
> > > > > > > > > > > > > > > > > > > able to do that efficiently. On the other 
> > > > > > > > > > > > > > > > > > > hand, in the current scheme, these 
> > > > > > > > > > > > > > > > > > > components are naturally generated by the 
> > > > > > > > > > > > > > > > > > > compiler, and the runtime only needs to 
> > > > > > > > > > > > > > > > > > > know the base pointer, pointer, type, 
> > > > > > > > > > > > > > > > > > > size. etc.
> > > > > > > > > > > > > > > > > > With the current scheme, we may end with 
> > > > > > > > > > > > > > > > > > the code blowout. We need to generate very 
> > > > > > > > > > > > > > > > > > similar code for different types and 
> > > > > > > > > > > > > > > > > > variables. The worst thing here is that we 
> > > > > > > > > > > > > > > > > > will be unable to optimize this huge amount 
> > > > > > > > > > > > > > > > > > of code because the codegen relies on the 
> > > > > > > > > > > > > > > > > > runtime functions and the code cannot be 
> > > > > > > > > > > > > > > > > > inlined. That's why I would like to move as 
> > > > > > > > > > > > > > > > > > much as possible code to the runtime rather 
> > > > > > > > > > > > > > > > > > than to emit it in the compiler. 
> > > > > > > > > > > > > > > > > I understand your concerns. I think this is 
> > > > > > > > > > > > > > > > > the best we can do right now.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > The most worrisome case will be when we have 
> > > > > > > > > > > > > > > > > nested mappers within each other. In this 
> > > > > > > > > > > > > > > > > case, a mapper function will call another 
> > > > > > > > > > > > > > > > > mapper function. We can inline the inner 
> > > > > > > > > > > > > > > > > mapper functions in this scenario, so that 
> > > > > > > > > > > > > > > > > these mapper function can be properly 
> > > > > > > > > > > > > > > > > optimized. As a result, I think the 
> > > > > > > > > > > > > > > > > performance should be fine.
> > > > > > > > > > > > > > > > Instead, we can use indirect function calls 
> > > > > > > > > > > > > > > > passed in the array to the runtime. Do you 
> > > > > > > > > > > > > > > > think it is going to be slower? In your current 
> > > > > > > > > > > > > > > > scheme, we generate many runtime calls instead. 
> > > > > > > > > > > > > > > > Could you try to estimate the number of calls 
> > > > > > > > > > > > > > > > in cases if we'll call the mappers through the 
> > > > > > > > > > > > > > > > indirect function calls and in your cuurent 
> > > > > > > > > > > > > > > > scheme, where we need to call the runtime 
> > > > > > > > > > > > > > > > functions many times in each particular mapper?
> > > > > > > > > > > > > > > Hi Alexey,
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Sorry I don't understand your idea. What indirect 
> > > > > > > > > > > > > > > function calls do you propose to be passed to the 
> > > > > > > > > > > > > > > runtime? What are these functions supposed to do?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > The number of function calls will be exactly 
> > > > > > > > > > > > > > > equal to the number of components mapped, no 
> > > > > > > > > > > > > > > matter whether there

[PATCH] D63756: [AMDGPU] Increased the number of implicit argument bytes for both OpenCL and HIP (CLANG).

2019-06-27 Thread Christudasan Devadasan via Phabricator via cfe-commits

cdevadas added a comment.

I have created the review for adding the metadata in the backend. 
https://reviews.llvm.org/D63886 
Marking the current review depended on D63886 .


Repository:
  rC Clang

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

https://reviews.llvm.org/D63756



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

2019-06-27 Thread Lingda Li via Phabricator via cfe-commits

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



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > Currently `currentComponent` is generated 
> > > > > > > > > > > > > > > > > > > by the compiler. But can we instead pass 
> > > > > > > > > > > > > > > > > > > this data as an extra parameter to this 
> > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > Emm, I think this scheme will be very 
> > > > > > > > > > > > > > > > > > difficult and inefficient. If we pass 
> > > > > > > > > > > > > > > > > > components as an argument of `omp_mapper` 
> > > > > > > > > > > > > > > > > > function, it means that the runtime needs 
> > > > > > > > > > > > > > > > > > to generate all components related to a map 
> > > > > > > > > > > > > > > > > > clause. I don't think the runtime is able 
> > > > > > > > > > > > > > > > > > to do that efficiently. On the other hand, 
> > > > > > > > > > > > > > > > > > in the current scheme, these components are 
> > > > > > > > > > > > > > > > > > naturally generated by the compiler, and 
> > > > > > > > > > > > > > > > > > the runtime only needs to know the base 
> > > > > > > > > > > > > > > > > > pointer, pointer, type, size. etc.
> > > > > > > > > > > > > > > > > With the current scheme, we may end with the 
> > > > > > > > > > > > > > > > > code blowout. We need to generate very 
> > > > > > > > > > > > > > > > > similar code for different types and 
> > > > > > > > > > > > > > > > > variables. The worst thing here is that we 
> > > > > > > > > > > > > > > > > will be unable to optimize this huge amount 
> > > > > > > > > > > > > > > > > of code because the codegen relies on the 
> > > > > > > > > > > > > > > > > runtime functions and the code cannot be 
> > > > > > > > > > > > > > > > > inlined. That's why I would like to move as 
> > > > > > > > > > > > > > > > > much as possible code to the runtime rather 
> > > > > > > > > > > > > > > > > than to emit it in the compiler. 
> > > > > > > > > > > > > > > > I understand your concerns. I think this is the 
> > > > > > > > > > > > > > > > best we can do right now.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > The most worrisome case will be when we have 
> > > > > > > > > > > > > > > > nested mappers within each other. In this case, 
> > > > > > > > > > > > > > > > a mapper function will call another mapper 
> > > > > > > > > > > > > > > > function. We can inline the inner mapper 
> > > > > > > > > > > > > > > > functions in this scenario, so that these 
> > > > > > > > > > > > > > > > mapper function can be properly optimized. As a 
> > > > > > > > > > > > > > > > result, I think the performance should be fine.
> > > > > > > > > > > > > > > Instead, we can use indirect function calls 
> > > > > > > > > > > > > > > passed in the array to the runtime. Do you think 
> > > > > > > > > > > > > > > it is going to be slower? In your current scheme, 
> > > > > > > > > > > > > > > we generate many runtime calls instead. Could you 
> > > > > > > > > > > > > > > try to estimate the number of calls in cases if 
> > > > > > > > > > > > > > > we'll call the mappers through the indirect 
> > > > > > > > > > > > > > > function calls and in your cuurent scheme, where 
> > > > > > > > > > > > > > > we need to call the runtime functions many times 
> > > > > > > > > > > > > > > in each particular mapper?
> > > > > > > > > > > > > > Hi Alexey,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Sorry I don't understand your idea. What indirect 
> > > > > > > > > > > > > > function calls do you propose to be passed to the 
> > > > > > > > > > > > > > runtime? What are these functions supposed to do?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The number of function calls will be exactly equal 
> > > > > > > > > > > > > > to the number of components mapped, no matter 
> > > > > > > > > > > > > > whether there are nested mappers or not. The number 
> > > > > > > > > > > > > > of components depend on the program. E.g., if we 
> > > > > > > > > > > > > > map a large array section, then there will be

[PATCH] D63518: BitStream reader: propagate errors

2019-06-27 Thread JF Bastien via Phabricator via cfe-commits

jfb marked 2 inline comments as done.
jfb added a subscriber: hans.
jfb added inline comments.



Comment at: llvm/trunk/lib/Bitcode/Reader/BitcodeReader.cpp:205
+  return MaybeBitCode.takeError();
+switch (unsigned BitCode = MaybeBitCode.get()) {
 default: // Default behavior: reject

abrachet wrote:
> This and an identical switch on line 5367 cause an unused variable warning 
> from this commit. I don't know if the build bots report on this, or the 
> proper way to tell you about this but hopefully you will see it :)
Thanks, looks like @Hans fixed it in r364505. Odd that it wasn't warning 
locally for me.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63518



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

[PATCH] D63878: [CTU] Add missing statistics

2019-06-27 Thread Gábor Horváth via Phabricator via cfe-commits

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63878



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

[PATCH] D63638: [clang][NewPM] Add new pass manager RUN lines to avx512f-builtins.c

2019-06-27 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added a comment.

In D63638#1560846 , @spatel wrote:

> I skimmed D63174  but haven't applied either 
> of these patches to test locally, so I may not have the full picture.
>
> IMO, we do not want clang regression tests running 
> -instcombine/-instsimplify. That can cause clang tests to break when an 
> underlying LLVM change is made. Forcing LLVM devs to depend on clang and fix 
> the resulting breakage is backwards and unexpected extra work. This has 
> happened to me several times.
>
> As a compromise to the -O0 IR explosion, we do have precedent for running the 
> optimizer's -mem2reg pass since that doesn't change frequently at this point.
>
> And I haven't tried this, but we do have utils/update_cc_test_checks.py - 
> this is supposed to take the manual labor out of generating assertions in the 
> same way that we do in the optimizer and codegen regression tests with 
> utils/update_test_checks.py and utils/update_llc_test_checks.py. Can you 
> start with that and remove the irrelevant CHECK lines, so only the 
> common/important lines remain? Or just use independent FileCheck 
> '--check-prefixes'?


I definitely agree running -instcombine would be bad since it can replace 
squences with other sequences. -instsimplify is a little less scary because our 
intrinsic tests shouldn't really have a lot of things that are trivially 
reducible. Though that may not be as true as I want it to be. The main issue we 
seemed to need -instsimplify for with the new pass manager is to merge 
redundant bitcasts. The inliner in the old pass manager seemed to do that 
itself, but the new pass manager's always inliner doesn't.


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

https://reviews.llvm.org/D63638



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

[PATCH] D60455: [SYCL] Implement SYCL device code outlining

2019-06-27 Thread Mariya Podchishchaeva via Phabricator via cfe-commits

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

Minor fix


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/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Parse/ParseAST.cpp
  clang/lib/Sema/CMakeLists.txt
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaSYCL.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CodeGenSYCL/device-functions.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/SemaSYCL/device-attributes-on-non-sycl.cpp
  clang/test/SemaSYCL/device-attributes.cpp
  clang/test/SemaSYCL/device-code-outlining.cpp

Index: clang/test/SemaSYCL/device-code-outlining.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/device-code-outlining.cpp
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 -std=c++11 -fsycl-is-device -ast-dump %s | FileCheck %s
+
+template 
+T bar(T arg);
+// CHECK: FunctionTemplateDecl {{.*}} bar
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+void foo() {
+  int a = 1 + 1 + bar(1);
+}
+// CHECK: FunctionDecl {{.*}} foo
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+template 
+T bar(T arg) {
+  return arg;
+}
+
+template 
+__attribute__((sycl_kernel)) void kernel_single_task(Func kernelFunc) {
+  kernelFunc();
+}
+// CHECK: FunctionTemplateDecl {{.*}} kernel_single_task
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+void host_foo() {
+  int b = 0;
+}
+// CHECK: FunctionDecl {{.*}} host_foo
+// CHECK-NOT: SYCLDeviceAttr
+// CHECK: FunctionDecl {{.*}} main
+
+int main() {
+  kernel_single_task([]() { foo(); });
+  host_foo();
+  return 0;
+}
Index: clang/test/SemaSYCL/device-attributes.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/device-attributes.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fsycl-is-device -verify %s
+
+[[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(1))) void foo(); // expected-error {{'sycl_kernel' attribute takes no arguments}}
+[[clang::sycl_kernel(1)]] void foo2(); // expected-error {{'sycl_kernel' attribute takes no arguments}}
+
+// Only template functions
+__attribute__((sycl_kernel)) void foo(); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+[[clang::sycl_kernel]] void foo1(); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// At least two template parameters
+template 
+__attribute__((sycl_kernel)) void foo(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Both first two template parameters must be a typenames
+template 
+__attribute__((sycl_kernel)) void foo(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Must return void
+template 
+__attribute__((sycl_kernel)) int foo(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] int foo1(T P); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Must take at least one argument
+template 
+__attribute__((sycl_kernel)) void foo(); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(); // expected-warning {{'sycl_kernel' attribute only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// No diagnosticts
+template 
+__attribute__((sycl_kernel)) void foo(T P);
+template 
+[[clang::sycl_kernel]] void foo1(T P);

[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

2019-06-27 Thread David Goldman via Phabricator via cfe-commits

dgoldman added inline comments.



Comment at: lib/Sema/SemaExprCXX.cpp:7762-7764
+  llvm::SmallDenseMap NewTransformCache;
+  auto SavedTransformCache = TransformCache;
+  TransformCache = NewTransformCache;

Should I do the same `std::move` and `clear` here as well?


Repository:
  rC Clang

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

https://reviews.llvm.org/D62648



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

[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

2019-06-27 Thread David Goldman via Phabricator via cfe-commits

dgoldman updated this revision to Diff 206870.
dgoldman marked 9 inline comments as done.
dgoldman added a comment.

- Minor fixes


Repository:
  rC Clang

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

https://reviews.llvm.org/D62648

Files:
  lib/Sema/SemaExprCXX.cpp
  test/Sema/typo-correction-recursive.cpp

Index: test/Sema/typo-correction-recursive.cpp
===
--- /dev/null
+++ test/Sema/typo-correction-recursive.cpp
@@ -0,0 +1,120 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Check the following typo correction behavior:
+// - multiple typos in a single member call chain are all diagnosed
+// - no typos are diagnosed for multiple typos in an expression when not all
+//   typos can be corrected
+
+class DeepClass
+{
+public:
+  void trigger() const;  // expected-note {{'trigger' declared here}}
+};
+
+class Y
+{
+public:
+  const DeepClass& getX() const { return m_deepInstance; }  // expected-note {{'getX' declared here}}
+private:
+  DeepClass m_deepInstance;
+  int m_n;
+};
+
+class Z
+{
+public:
+  const Y& getY0() const { return m_y0; }  // expected-note {{'getY0' declared here}}
+  const Y& getActiveY() const { return m_y0; }
+
+private:
+  Y m_y0;
+  Y m_y1;
+};
+
+Z z_obj;
+
+void testMultipleCorrections()
+{
+  z_obj.getY2().  // expected-error {{no member named 'getY2' in 'Z'; did you mean 'getY0'}}
+  getM(). // expected-error {{no member named 'getM' in 'Y'; did you mean 'getX'}}
+  triggee();  // expected-error {{no member named 'triggee' in 'DeepClass'; did you mean 'trigger'}}
+}
+
+void testNoCorrections()
+{
+  z_obj.getY2().  // expected-error {{no member named 'getY2' in 'Z'}}
+  getM().
+  thisDoesntSeemToMakeSense();
+}
+
+struct C {};
+struct D { int value; };
+struct A {
+  C get_me_a_C();
+};
+struct B {
+  D get_me_a_D();  // expected-note {{'get_me_a_D' declared here}}
+};
+class Scope {
+public:
+  A make_an_A();
+  B make_a_B();  // expected-note {{'make_a_B' declared here}}
+};
+
+Scope scope_obj;
+
+int testDiscardedCorrections() {
+  return scope_obj.make_an_E().  // expected-error {{no member named 'make_an_E' in 'Scope'; did you mean 'make_a_B'}}
+  get_me_a_Z().value;// expected-error {{no member named 'get_me_a_Z' in 'B'; did you mean 'get_me_a_D'}}
+}
+
+class AmbiguousHelper {
+public:
+  int helpMe();
+  int helpBe();
+};
+class Ambiguous {
+public:
+  int calculateA();
+  int calculateB();
+
+  AmbiguousHelper getHelp1();
+  AmbiguousHelper getHelp2();
+};
+
+Ambiguous ambiguous_obj;
+
+int testDirectAmbiguousCorrection() {
+  return ambiguous_obj.calculateZ();  // expected-error {{no member named 'calculateZ' in 'Ambiguous'}}
+}
+
+int testRecursiveAmbiguousCorrection() {
+  return ambiguous_obj.getHelp3().// expected-error {{no member named 'getHelp3' in 'Ambiguous'}}
+  helpCe();
+}
+
+
+class DeepAmbiguityHelper {
+public:
+  DeepAmbiguityHelper& help1();
+  DeepAmbiguityHelper& help2();
+
+  DeepAmbiguityHelper& methodA();
+  DeepAmbiguityHelper& somethingMethodB();
+  DeepAmbiguityHelper& functionC();
+  DeepAmbiguityHelper& deepMethodD();
+  DeepAmbiguityHelper& asDeepAsItGets();
+};
+
+DeepAmbiguityHelper deep_obj;
+
+int testDeepAmbiguity() {
+  deep_obj.
+  methodB(). // expected-error {{no member named 'methodB' in 'DeepAmbiguityHelper'}}
+  somethingMethodC().
+  functionD().
+  deepMethodD().
+  help3().
+  asDeepASItGet().
+  functionE();
+}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -7610,15 +7610,22 @@
   llvm::SmallDenseMap OverloadResolution;
 
   /// Emit diagnostics for all of the TypoExprs encountered.
+  ///
   /// If the TypoExprs were successfully corrected, then the diagnostics should
   /// suggest the corrections. Otherwise the diagnostics will not suggest
   /// anything (having been passed an empty TypoCorrection).
-  void EmitAllDiagnostics() {
+  ///
+  /// If we've failed to correct due to ambiguous corrections, we need to
+  /// be sure to pass empty corrections and replacements. Otherwise it's
+  /// possible that the Consumer has a TypoCorrection that failed to ambiguity
+  /// and we don't want to report those diagnostics.
+  void EmitAllDiagnostics(bool IsAmbiguous) {
 for (TypoExpr *TE : TypoExprs) {
   auto  = SemaRef.getTypoExprState(TE);
   if (State.DiagHandler) {
-TypoCorrection TC = State.Consumer->getCurrentCorrection();
-ExprResult Replacement = TransformCache[TE];
+TypoCorrection TC = IsAmbiguous
+? TypoCorrection() : State.Consumer->getCurrentCorrection();
+ExprResult Replacement = IsAmbiguous ? ExprError() : TransformCache[TE];
 
 // Extract the NamedDecl from the transformed TypoExpr and add it to the
 // TypoCorrection, replacing the existing decls. This ensures the right

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

2019-06-27 Thread Johan Vikström via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL364551: [clangd] Emit semantic highlighting tokens when the 
main AST is built. (authored by jvikstrom, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63821?vs=206854=206867#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63821

Files:
  clang-tools-extra/trunk/clangd/ClangdServer.cpp
  clang-tools-extra/trunk/clangd/ClangdServer.h
  clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/trunk/clangd/ClangdServer.h
===
--- clang-tools-extra/trunk/clangd/ClangdServer.h
+++ clang-tools-extra/trunk/clangd/ClangdServer.h
@@ -18,6 +18,7 @@
 #include "Function.h"
 #include "GlobalCompilationDatabase.h"
 #include "Protocol.h"
+#include "SemanticHighlighting.h"
 #include "TUScheduler.h"
 #include "XRefs.h"
 #include "index/Background.h"
@@ -49,6 +50,11 @@
   std::vector Diagnostics) = 0;
   /// Called whenever the file status is updated.
   virtual void onFileUpdated(PathRef File, const TUStatus ){};
+
+  /// Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) {}
 };
 
 /// When set, used by ClangdServer to get clang-tidy options for each particular
@@ -131,6 +137,9 @@
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
+
+/// Enable semantic highlighting features.
+bool SemanticHighlighting = false;
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -304,7 +313,7 @@
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
-
+  
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;
Index: clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
@@ -7,7 +7,9 @@
 //===--===//
 
 #include "Annotations.h"
+#include "ClangdServer.h"
 #include "SemanticHighlighting.h"
+#include "TestFS.h"
 #include "TestTU.h"
 #include "gmock/gmock.h"
 
@@ -64,6 +66,30 @@
   }
 }
 
+TEST(ClangdSemanticHighlightingTest, GeneratesHighlightsWhenFileChange) {
+  class HighlightingsCounterDiagConsumer : public DiagnosticsConsumer {
+  public:
+std::atomic Count = {0};
+
+void onDiagnosticsReady(PathRef, std::vector) override {}
+void onHighlightingsReady(
+PathRef File, std::vector Highlightings) override {
+  ++Count;
+}
+  };
+
+  auto FooCpp = testPath("foo.cpp");
+  MockFSProvider FS;
+  FS.Files[FooCpp] = "";
+
+  MockCompilationDatabase MCD;
+  HighlightingsCounterDiagConsumer DiagConsumer;
+  ClangdServer Server(MCD, FS, DiagConsumer, ClangdServer::optsForTest());
+  Server.addDocument(FooCpp, "int a;");
+  ASSERT_TRUE(Server.blockUntilIdleForTest()) << "Waiting for server";
+  ASSERT_EQ(DiagConsumer.Count, 1);
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/trunk/clangd/ClangdServer.cpp
===
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp
@@ -48,8 +48,10 @@
 
 // Update the FileIndex with new ASTs and plumb the diagnostics responses.
 struct UpdateIndexCallbacks : public ParsingCallbacks {
-  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer )
-  : FIndex(FIndex), DiagConsumer(DiagConsumer) {}
+  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer ,
+   bool SemanticHighlighting)
+  : FIndex(FIndex), DiagConsumer(DiagConsumer),
+SemanticHighlighting(SemanticHighlighting) {}
 
   void onPreambleAST(PathRef Path, ASTContext ,
  std::shared_ptr PP,
@@ -61,6 +63,8 @@
   void onMainAST(PathRef Path, ParsedAST ) override {
 if (FIndex)
   FIndex->updateMain(Path, AST);
+if (SemanticHighlighting)
+  DiagConsumer.onHighlightingsReady(Path, getSemanticHighlightings(AST));
   }
 
   void onDiagnostics(PathRef File, std::vector Diags) override {
@@ -74,6 +78,7 @@
 private:
   FileIndex *FIndex;
   DiagnosticsConsumer 
+  bool SemanticHighlighting;
 };
 } // namespace
 
@@ -82,6 +87,7 @@
   Opts.UpdateDebounce =

[clang-tools-extra] r364551 - [clangd] Emit semantic highlighting tokens when the main AST is built.

2019-06-27 Thread Johan Vikstrom via cfe-commits

Author: jvikstrom
Date: Thu Jun 27 08:13:03 2019
New Revision: 364551

URL: http://llvm.org/viewvc/llvm-project?rev=364551=rev
Log:
[clangd] Emit semantic highlighting tokens when the main AST is built.

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

Modified:
clang-tools-extra/trunk/clangd/ClangdServer.cpp
clang-tools-extra/trunk/clangd/ClangdServer.h
clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=364551=364550=364551=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Thu Jun 27 08:13:03 2019
@@ -48,8 +48,10 @@ namespace {
 
 // Update the FileIndex with new ASTs and plumb the diagnostics responses.
 struct UpdateIndexCallbacks : public ParsingCallbacks {
-  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer )
-  : FIndex(FIndex), DiagConsumer(DiagConsumer) {}
+  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer ,
+   bool SemanticHighlighting)
+  : FIndex(FIndex), DiagConsumer(DiagConsumer),
+SemanticHighlighting(SemanticHighlighting) {}
 
   void onPreambleAST(PathRef Path, ASTContext ,
  std::shared_ptr PP,
@@ -61,6 +63,8 @@ struct UpdateIndexCallbacks : public Par
   void onMainAST(PathRef Path, ParsedAST ) override {
 if (FIndex)
   FIndex->updateMain(Path, AST);
+if (SemanticHighlighting)
+  DiagConsumer.onHighlightingsReady(Path, getSemanticHighlightings(AST));
   }
 
   void onDiagnostics(PathRef File, std::vector Diags) override {
@@ -74,6 +78,7 @@ struct UpdateIndexCallbacks : public Par
 private:
   FileIndex *FIndex;
   DiagnosticsConsumer 
+  bool SemanticHighlighting;
 };
 } // namespace
 
@@ -82,6 +87,7 @@ ClangdServer::Options ClangdServer::opts
   Opts.UpdateDebounce = std::chrono::steady_clock::duration::zero(); // Faster!
   Opts.StorePreamblesInMemory = true;
   Opts.AsyncThreadsCount = 4; // Consistent!
+  Opts.SemanticHighlighting = true;
   return Opts;
 }
 
@@ -102,10 +108,11 @@ ClangdServer::ClangdServer(const GlobalC
   // is parsed.
   // FIXME(ioeric): this can be slow and we may be able to index on less
   // critical paths.
-  WorkScheduler(CDB, Opts.AsyncThreadsCount, Opts.StorePreamblesInMemory,
-llvm::make_unique(DynamicIdx.get(),
-DiagConsumer),
-Opts.UpdateDebounce, Opts.RetentionPolicy) {
+  WorkScheduler(
+  CDB, Opts.AsyncThreadsCount, Opts.StorePreamblesInMemory,
+  llvm::make_unique(
+  DynamicIdx.get(), DiagConsumer, Opts.SemanticHighlighting),
+  Opts.UpdateDebounce, Opts.RetentionPolicy) {
   // Adds an index to the stack, at higher priority than existing indexes.
   auto AddIndex = [&](SymbolIndex *Idx) {
 if (this->Index != nullptr) {

Modified: clang-tools-extra/trunk/clangd/ClangdServer.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.h?rev=364551=364550=364551=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.h (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.h Thu Jun 27 08:13:03 2019
@@ -18,6 +18,7 @@
 #include "Function.h"
 #include "GlobalCompilationDatabase.h"
 #include "Protocol.h"
+#include "SemanticHighlighting.h"
 #include "TUScheduler.h"
 #include "XRefs.h"
 #include "index/Background.h"
@@ -49,6 +50,11 @@ public:
   std::vector Diagnostics) = 0;
   /// Called whenever the file status is updated.
   virtual void onFileUpdated(PathRef File, const TUStatus ){};
+
+  /// Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) {}
 };
 
 /// When set, used by ClangdServer to get clang-tidy options for each 
particular
@@ -131,6 +137,9 @@ public:
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
+
+/// Enable semantic highlighting features.
+bool SemanticHighlighting = false;
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -304,7 +313,7 @@ private:
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
-
+  
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;

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

[PATCH] D63638: [clang][NewPM] Add new pass manager RUN lines to avx512f-builtins.c

2019-06-27 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri added a comment.

In D63638#1560846 , @spatel wrote:

> I skimmed D63174  but haven't applied either 
> of these patches to test locally, so I may not have the full picture.
>
> IMO, we do not want clang regression tests running 
> -instcombine/-instsimplify. That can cause clang tests to break when an 
> underlying LLVM change is made. Forcing LLVM devs to depend on clang and fix 
> the resulting breakage is backwards and unexpected extra work.


+1

> This has happened to me several times.



> As a compromise to the -O0 IR explosion, we do have precedent for running the 
> optimizer's -mem2reg pass since that doesn't change frequently at this point.
> 
> And I haven't tried this, but we do have utils/update_cc_test_checks.py - 
> this is supposed to take the manual labor out of generating assertions in the 
> same way that we do in the optimizer and codegen regression tests with 
> utils/update_test_checks.py and utils/update_llc_test_checks.py. Can you 
> start with that and remove the irrelevant CHECK lines, so only the 
> common/important lines remain? Or just use independent FileCheck 
> '--check-prefixes'?

That script has bitrot and is unusable last time i checked; everyone preferred 
to manually write broken checklines here :)


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

https://reviews.llvm.org/D63638



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

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

2019-06-27 Thread Haojian Wu via Phabricator via cfe-commits

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

Let's rephrase the commit message, I think this patch is just to "emit the 
semantic highlighting tokens when the main AST is built".




Comment at: clang-tools-extra/clangd/unittests/ClangdTests.cpp:844
 
+TEST(ClangdSemanticHighlightingTest, GeneratesHighlightsWhenFileChange) {
+  class HighlightingsCounterDiagConsumer : public DiagnosticsConsumer {

maybe move this test to SemanticHighlightingTests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821



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

[PATCH] D62977: [clang-tidy]: Google: new check 'google-upgrade-googletest-case'

2019-06-27 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri resigned from this revision.
lebedev.ri added a comment.

Looks reasonable. I did not review the check itself though.
Are `test/clang-tidy/google-upgrade-googletest-case-nosuite.cpp` and 
`test/clang-tidy/google-upgrade-googletest-case.cpp ` identical other than the 
included header and expected output?
I'd recommend to condense it into a single file, and just have two `RUN` lines 
each one checking different message prefixes




Comment at: clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.h:34
+private:
+  std::unordered_set MatchedTemplateLocations;
+};

Have you tried `llvm::DenseSet` instead?
This //may// not matter *here*, but `std::unordered_set` usually results in 
horrible perf.



Comment at: 
clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case-nosuite.cpp:9
+void DummyFixTarget() {}
+// CHECK-FIXES: void DummyFixTarget() {}
+

Hm?


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

https://reviews.llvm.org/D62977



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

[PATCH] D60455: [SYCL] Implement SYCL device code outlining

2019-06-27 Thread Mariya Podchishchaeva via Phabricator via cfe-commits

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

Added warning diagnostic for `sycl_kernel` attribute.

Now if the `sycl_kernel` attribute applied to a function which doesn't meet 
requirements for OpenCL kernel generation, attribute will be ignored and 
diagnostic will be emitted.


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/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Parse/ParseAST.cpp
  clang/lib/Sema/CMakeLists.txt
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaSYCL.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CodeGenSYCL/device-functions.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/SemaSYCL/device-attributes-on-non-sycl.cpp
  clang/test/SemaSYCL/device-attributes.cpp
  clang/test/SemaSYCL/device-code-outlining.cpp

Index: clang/test/SemaSYCL/device-code-outlining.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/device-code-outlining.cpp
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 -std=c++11 -fsycl-is-device -ast-dump %s | FileCheck %s
+
+template 
+T bar(T arg);
+// CHECK: FunctionTemplateDecl {{.*}} bar
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+void foo() {
+  int a = 1 + 1 + bar(1);
+}
+// CHECK: FunctionDecl {{.*}} foo
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+template 
+T bar(T arg) {
+  return arg;
+}
+
+template 
+__attribute__((sycl_kernel)) void kernel_single_task(Func kernelFunc) {
+  kernelFunc();
+}
+// CHECK: FunctionTemplateDecl {{.*}} kernel_single_task
+// CHECK: SYCLDeviceAttr {{.*}} Implicit
+
+void host_foo() {
+  int b = 0;
+}
+// CHECK: FunctionDecl {{.*}} host_foo
+// CHECK-NOT: SYCLDeviceAttr
+// CHECK: FunctionDecl {{.*}} main
+
+int main() {
+  kernel_single_task([]() { foo(); });
+  host_foo();
+  return 0;
+}
Index: clang/test/SemaSYCL/device-attributes.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/device-attributes.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fsycl-is-device -verify %s
+
+[[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(1))) void foo(); // expected-error {{'sycl_kernel' attribute takes no arguments}}
+[[clang::sycl_kernel(1)]] void foo2(); // expected-error {{'sycl_kernel' attribute takes no arguments}}
+
+// Only template functions
+__attribute__((sycl_kernel)) void foo(); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+[[clang::sycl_kernel]] void foo1(); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// At least two template parameters
+template 
+__attribute__((sycl_kernel)) void foo(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Both first two template parameters must be a typenames
+template 
+__attribute__((sycl_kernel)) void foo(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Must return void
+template 
+__attribute__((sycl_kernel)) int foo(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] int foo1(T P); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+// Must take at least one argument
+template 
+__attribute__((sycl_kernel)) void foo(); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+template 
+[[clang::sycl_kernel]] void foo1(); // expected-warning {{'sycl_kernel' only applies to template funtions with special prototype, please refer 'sycl_kernel' attribute documentation}}
+
+//

[PATCH] D63638: [clang][NewPM] Add new pass manager RUN lines to avx512f-builtins.c

2019-06-27 Thread Sanjay Patel via Phabricator via cfe-commits

spatel added a comment.

I skimmed D63174  but haven't applied either 
of these patches to test locally, so I may not have the full picture.

IMO, we do not want clang regression tests running -instcombine/-instsimplify. 
That can cause clang tests to break when an underlying LLVM change is made. 
Forcing LLVM devs to depend on clang and fix the resulting breakage is 
backwards and unexpected extra work. This has happened to me several times.

As a compromise to the -O0 IR explosion, we do have precedent for running the 
optimizer's -mem2reg pass since that doesn't change frequently at this point.

And I haven't tried this, but we do have utils/update_cc_test_checks.py - this 
is supposed to take the manual labor out of generating assertions in the same 
way that we do in the optimizer and codegen regression tests with 
utils/update_test_checks.py and utils/update_llc_test_checks.py. Can you start 
with that and remove the irrelevant CHECK lines, so only the common/important 
lines remain? Or just use independent FileCheck '--check-prefixes'?


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

https://reviews.llvm.org/D63638



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

[PATCH] D63773: [clangd] dummy variable extraction on a function scope

2019-06-27 Thread Sam McCall via Phabricator via cfe-commits

sammccall added a comment.

Please forgive the mix of high-level and low-level comments here.
Happy to discuss further of course!




Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:55
+// checks whether any variable in a given expr is declared in the DeclStmt
+static bool isDeclaredIn(const DeclStmt *Decl, const Expr *Exp,
+ const SourceManager ) {

nit: why take a DeclStmt instead of just the Decl here?



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:55
+// checks whether any variable in a given expr is declared in the DeclStmt
+static bool isDeclaredIn(const DeclStmt *Decl, const Expr *Exp,
+ const SourceManager ) {

sammccall wrote:
> nit: why take a DeclStmt instead of just the Decl here?
This function name is confusing - it's unclear which of DeclStmt vs Exp is 
declared in which, and that it's subexpressions of Exp that are being checked

maybe `bool referencesLocalDecls`? and rename Decl -> Scope, as it provides the 
meaning of "local"



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:56
+static bool isDeclaredIn(const DeclStmt *Decl, const Expr *Exp,
+ const SourceManager ) {
+

nit: SourceManager is almost universally `SM` (or something more verbose)



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:62
+  public:
+std::vector DeclRefExprs;
+bool VisitDeclRefExpr(DeclRefExpr *DeclRef) { // NOLINT

nit: seems a little clearer to collect the referenced decls rather than the 
referencing exprs.
(It will also generalize better if we want to do things like notice referenced 
local classes, which we don't yet)



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:73
+// Beginning location of the ValueDecl of the DeclRef
+auto ValueDeclLoc = DeclRef->getDecl()->getBeginLoc();
+// return true if this ValueDecl location is within the DeclStmt

nit: "ValueDecl" is not usually a very interesting class conceptually, I'd just 
call this DeclLoc



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:73
+// Beginning location of the ValueDecl of the DeclRef
+auto ValueDeclLoc = DeclRef->getDecl()->getBeginLoc();
+// return true if this ValueDecl location is within the DeclStmt

sammccall wrote:
> nit: "ValueDecl" is not usually a very interesting class conceptually, I'd 
> just call this DeclLoc
throughout you're using `auto` a bit too heavily - usually doesn't aid 
readability when the type is a single word like `SourceLocation` here and isn't 
named in the expression



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:130
+// TODO: Add more unit tests after SelectionTree ancestor bug is fixed
+static bool extractionAllowed(const Stmt *ParStmt, const SelectionTree::Node 
*N,
+  const SourceManager ) {

Another general style point: LLVM does use short variable names (like `N`) 
sometimes when the type unambiguously describes the role of the variable and 
the scope is small.

That's not the case here: a `SelectionTree::Node` could be almost anything so 
I'd suggest TargetExpr or so.

Conversely I think `Parent` or `NewParent` would be clearer than `ParStmt` 
which repeats more info from the type.



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:132
+  const SourceManager ) {
+  if (isa(ParStmt) &&
+  !checkForStmt(dyn_cast(ParStmt), N->ASTNode.get(), M))

I might be missing something, but as I understand:
 - you're proposing moving the expr N out of the scope ParStmt
 - you're testing whether any subexpression of N references anything declared 
in certain substmts of ParStmt
 - because of "certain substmts" you're only supporting this for some types of 
ParStmt

why can't we just check for anything declared inside ParStmt, and make this 
fully general (applied for all stmts)?



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:157
+// we also check if doing the extraction will take a variable out of scope
+static const clang::Stmt *getStmt(const SelectionTree::Node *N,
+  const SourceManager ) {

this needs a much more descriptive name.
maybe `getInsertionPoint()`?



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:159
+  const SourceManager ) {
+  auto CurN = N;
+  while (CurN->Parent) {

auto* (or `const auto*`) - we typically spell out the pointer-ness



Comment at:

[PATCH] D62977: [clang-tidy]: Google: new check 'google-upgrade-googletest-case'

2019-06-27 Thread Alex Strelnikov via Phabricator via cfe-commits

astrelni added a comment.

In D62977#1559649 , @lebedev.ri wrote:

> In D62977#1559637 , @astrelni wrote:
>
> > In D62977#1559628 , @lebedev.ri 
> > wrote:
> >
> > > It //sounds// correct, but i don't see accompanying test changes, so i 
> > > can't be sure.
> >
> >
> > The tests as they are cover the positive case in that they would not show 
> > warning or fixes if we didn't find the replacements.
>
>
> Yep
>
> In D62977#1559637 , @astrelni wrote:
>
> > The only way to test the negative is to make a second test with a second 
> > set of mock googletest headers that declare things in the v1.8 way. Is this 
> > what you would prefer?
>
>
> If that is what it takes to get the test coverage, i suppose so.


What do you think of this?


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

https://reviews.llvm.org/D62977



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

[PATCH] D62977: [clang-tidy]: Google: new check 'google-upgrade-googletest-case'

2019-06-27 Thread Alex Strelnikov via Phabricator via cfe-commits

astrelni updated this revision to Diff 206855.

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

https://reviews.llvm.org/D62977

Files:
  clang-tools-extra/clang-tidy/google/CMakeLists.txt
  clang-tools-extra/clang-tidy/google/GoogleTidyModule.cpp
  clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.cpp
  clang-tools-extra/clang-tidy/google/UpgradeGoogletestCaseCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/google-upgrade-googletest-case.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/Inputs/gtest/gtest-typed-test.h
  clang-tools-extra/test/clang-tidy/Inputs/gtest/gtest.h
  
clang-tools-extra/test/clang-tidy/Inputs/gtest/nosuite/gtest/gtest-typed-test.h
  clang-tools-extra/test/clang-tidy/Inputs/gtest/nosuite/gtest/gtest.h
  clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case-nosuite.cpp
  clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
  llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn

Index: llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
===
--- llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
+++ llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/google/BUILD.gn
@@ -28,6 +28,7 @@
 "OverloadedUnaryAndCheck.cpp",
 "TodoCommentCheck.cpp",
 "UnnamedNamespaceInHeaderCheck.cpp",
+"UpgradeGoogletestCaseCheck.cpp",
 "UsingNamespaceDirectiveCheck.cpp",
   ]
 }
Index: clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/google-upgrade-googletest-case.cpp
@@ -0,0 +1,991 @@
+// RUN: %check_clang_tidy %s google-upgrade-googletest-case %t -- -- -I%S/Inputs
+
+#include "gtest/gtest.h"
+
+// 
+// Macros
+
+TYPED_TEST_CASE(FooTest, FooTypes);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case' are deprecated; use equivalent APIs named with 'suite'
+// CHECK-FIXES: TYPED_TEST_SUITE(FooTest, FooTypes);
+TYPED_TEST_CASE_P(FooTest);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: TYPED_TEST_SUITE_P(FooTest);
+REGISTER_TYPED_TEST_CASE_P(FooTest, FooTestName);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: REGISTER_TYPED_TEST_SUITE_P(FooTest, FooTestName);
+INSTANTIATE_TYPED_TEST_CASE_P(FooPrefix, FooTest, FooTypes);
+// CHECK-MESSAGES: [[@LINE-1]]:1: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: INSTANTIATE_TYPED_TEST_SUITE_P(FooPrefix, FooTest, FooTypes);
+
+#ifdef TYPED_TEST_CASE
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef TYPED_TEST_CASE
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define TYPED_TEST_CASE TYPED_TEST_SUITE
+#endif
+
+#ifdef TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define TYPED_TEST_CASE_P TYPED_TEST_SUITE_P
+#endif
+
+#ifdef REGISTER_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef REGISTER_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define REGISTER_TYPED_TEST_CASE_P REGISTER_TYPED_TEST_SUITE_P
+#endif
+
+#ifdef INSTANTIATE_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:2: warning: Google Test APIs named with 'case'
+#undef INSTANTIATE_TYPED_TEST_CASE_P
+// CHECK-MESSAGES: [[@LINE-1]]:8: warning: Google Test APIs named with 'case'
+#define INSTANTIATE_TYPED_TEST_CASE_P INSTANTIATE_TYPED_TEST_SUITE_P
+#endif
+
+TYPED_TEST_CASE(FooTest, FooTypes);
+TYPED_TEST_CASE_P(FooTest);
+REGISTER_TYPED_TEST_CASE_P(FooTest, FooTestName);
+INSTANTIATE_TYPED_TEST_CASE_P(FooPrefix, FooTest, FooTypes);
+
+// 
+// testing::Test
+
+class FooTest : public testing::Test {
+public:
+  static void SetUpTestCase();
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+  // CHECK-FIXES: static void SetUpTestSuite();
+  static void TearDownTestCase();
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+  // CHECK-FIXES: static void TearDownTestSuite();
+};
+
+void FooTest::SetUpTestCase() {}
+// CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: void FooTest::SetUpTestSuite() {}
+
+void FooTest::TearDownTestCase() {}
+// CHECK-MESSAGES: [[@LINE-1]]:15: warning: Google Test APIs named with 'case'
+// CHECK-FIXES: void FooTest::TearDownTestSuite() {}
+
+template  class

[PATCH] D63878: [CTU] Add missing statistics

2019-06-27 Thread Gabor Marton via Phabricator via cfe-commits

martong created this revision.
martong added a reviewer: xazax.hun.
Herald added subscribers: cfe-commits, gamesh411, Szelethus, dkrupp, rnkovacs.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63878

Files:
  clang/lib/CrossTU/CrossTranslationUnit.cpp


Index: clang/lib/CrossTU/CrossTranslationUnit.cpp
===
--- clang/lib/CrossTU/CrossTranslationUnit.cpp
+++ clang/lib/CrossTU/CrossTranslationUnit.cpp
@@ -40,6 +40,10 @@
 STATISTIC(NumGetCTUSuccess,
   "The # of getCTUDefinition successfully returned the "
   "requested function's body");
+STATISTIC(NumUnsupportedNodeFound, "The # of imports when the ASTImporter "
+   "encountered an unsupported AST Node");
+STATISTIC(NumNameConflicts, "The # of imports when the ASTImporter "
+"encountered an ODR error");
 STATISTIC(NumTripleMismatch, "The # of triple mismatches");
 STATISTIC(NumLangMismatch, "The # of language mismatches");
 STATISTIC(NumLangDialectMismatch, "The # of language dialect mismatches");
@@ -404,10 +408,10 @@
 [&](const ImportError ) {
   switch (IE.Error) {
   case ImportError::NameConflict:
-// FIXME: Add statistic.
+++NumNameConflicts;
  break;
   case ImportError::UnsupportedConstruct:
-// FIXME: Add statistic.
+++NumUnsupportedNodeFound;
 break;
   case ImportError::Unknown:
 llvm_unreachable("Unknown import error happened.");


Index: clang/lib/CrossTU/CrossTranslationUnit.cpp
===
--- clang/lib/CrossTU/CrossTranslationUnit.cpp
+++ clang/lib/CrossTU/CrossTranslationUnit.cpp
@@ -40,6 +40,10 @@
 STATISTIC(NumGetCTUSuccess,
   "The # of getCTUDefinition successfully returned the "
   "requested function's body");
+STATISTIC(NumUnsupportedNodeFound, "The # of imports when the ASTImporter "
+   "encountered an unsupported AST Node");
+STATISTIC(NumNameConflicts, "The # of imports when the ASTImporter "
+"encountered an ODR error");
 STATISTIC(NumTripleMismatch, "The # of triple mismatches");
 STATISTIC(NumLangMismatch, "The # of language mismatches");
 STATISTIC(NumLangDialectMismatch, "The # of language dialect mismatches");
@@ -404,10 +408,10 @@
 [&](const ImportError ) {
   switch (IE.Error) {
   case ImportError::NameConflict:
-// FIXME: Add statistic.
+++NumNameConflicts;
  break;
   case ImportError::UnsupportedConstruct:
-// FIXME: Add statistic.
+++NumUnsupportedNodeFound;
 break;
   case ImportError::Unknown:
 llvm_unreachable("Unknown import error happened.");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

2019-06-27 Thread Johan Vikström via Phabricator via cfe-commits

jvikstrom updated this revision to Diff 206854.
jvikstrom marked 2 inline comments as done.
jvikstrom added a comment.

Made test safe again


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/unittests/ClangdTests.cpp

Index: clang-tools-extra/clangd/unittests/ClangdTests.cpp
===
--- clang-tools-extra/clangd/unittests/ClangdTests.cpp
+++ clang-tools-extra/clangd/unittests/ClangdTests.cpp
@@ -841,6 +841,30 @@
   EXPECT_FALSE(PathResult.hasValue());
 }
 
+TEST(ClangdSemanticHighlightingTest, GeneratesHighlightsWhenFileChange) {
+  class HighlightingsCounterDiagConsumer : public DiagnosticsConsumer {
+  public:
+std::atomic Count = {0};
+
+void onDiagnosticsReady(PathRef, std::vector) override {}
+void onHighlightingsReady(
+PathRef File, std::vector Highlightings) override {
+  ++Count;
+}
+  };
+
+  auto FooCpp = testPath("foo.cpp");
+  MockFSProvider FS;
+  FS.Files[FooCpp] = "";
+
+  MockCompilationDatabase MCD;
+  HighlightingsCounterDiagConsumer DiagConsumer;
+  ClangdServer Server(MCD, FS, DiagConsumer, ClangdServer::optsForTest());
+  Server.addDocument(FooCpp, "int a;");
+  ASSERT_TRUE(Server.blockUntilIdleForTest()) << "Waiting for server";
+  ASSERT_EQ(DiagConsumer.Count, 1);
+}
+
 TEST_F(ClangdThreadingTest, NoConcurrentDiagnostics) {
   class NoConcurrentAccessDiagConsumer : public DiagnosticsConsumer {
   public:
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -18,6 +18,7 @@
 #include "Function.h"
 #include "GlobalCompilationDatabase.h"
 #include "Protocol.h"
+#include "SemanticHighlighting.h"
 #include "TUScheduler.h"
 #include "XRefs.h"
 #include "index/Background.h"
@@ -49,6 +50,11 @@
   std::vector Diagnostics) = 0;
   /// Called whenever the file status is updated.
   virtual void onFileUpdated(PathRef File, const TUStatus ){};
+
+  /// Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) {}
 };
 
 /// When set, used by ClangdServer to get clang-tidy options for each particular
@@ -131,6 +137,9 @@
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
+
+/// Enable semantic highlighting features.
+bool SemanticHighlighting = false;
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -304,7 +313,7 @@
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
-
+  
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -48,8 +48,10 @@
 
 // Update the FileIndex with new ASTs and plumb the diagnostics responses.
 struct UpdateIndexCallbacks : public ParsingCallbacks {
-  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer )
-  : FIndex(FIndex), DiagConsumer(DiagConsumer) {}
+  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer ,
+   bool SemanticHighlighting)
+  : FIndex(FIndex), DiagConsumer(DiagConsumer),
+SemanticHighlighting(SemanticHighlighting) {}
 
   void onPreambleAST(PathRef Path, ASTContext ,
  std::shared_ptr PP,
@@ -61,6 +63,8 @@
   void onMainAST(PathRef Path, ParsedAST ) override {
 if (FIndex)
   FIndex->updateMain(Path, AST);
+if (SemanticHighlighting)
+  DiagConsumer.onHighlightingsReady(Path, getSemanticHighlightings(AST));
   }
 
   void onDiagnostics(PathRef File, std::vector Diags) override {
@@ -74,6 +78,7 @@
 private:
   FileIndex *FIndex;
   DiagnosticsConsumer 
+  bool SemanticHighlighting;
 };
 } // namespace
 
@@ -82,6 +87,7 @@
   Opts.UpdateDebounce = std::chrono::steady_clock::duration::zero(); // Faster!
   Opts.StorePreamblesInMemory = true;
   Opts.AsyncThreadsCount = 4; // Consistent!
+  Opts.SemanticHighlighting = true;
   return Opts;
 }
 
@@ -102,10 +108,11 @@
   // is parsed.
   // FIXME(ioeric): this can be slow and we may be able to index on less
   // critical paths.
-  WorkScheduler(CDB, Opts.AsyncThreadsCount, Opts.StorePreamblesInMemory,
-llvm::make_unique(DynamicIdx.get(),
-

[PATCH] D63876: [OpenCL] Define CLK_NULL_EVENT without cast

2019-06-27 Thread Sven van Haastregt via Phabricator via cfe-commits

svenvh created this revision.
svenvh added reviewers: Anastasia, yaxunl.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Defining CLK_NULL_EVENT with a `(void*)` cast has the (unintended?)
side-effect that the address space will be fixed (as generic in OpenCL
2.0 mode).  The consequence is that any target specific address space
for the clk_event_t type will not be applied.

It is not clear why the void pointer cast was needed in the first
place, and it seems we can do without it.


Repository:
  rC Clang

https://reviews.llvm.org/D63876

Files:
  lib/Headers/opencl-c-base.h
  test/SemaOpenCL/clk_event_t.cl


Index: test/SemaOpenCL/clk_event_t.cl
===
--- test/SemaOpenCL/clk_event_t.cl
+++ test/SemaOpenCL/clk_event_t.cl
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=c++
 
 // Taken from opencl-c.h
-#define CLK_NULL_EVENT (__builtin_astype(((void*)(__SIZE_MAX__)), clk_event_t))
+#define CLK_NULL_EVENT (__builtin_astype(((__SIZE_MAX__)), clk_event_t))
 
 global clk_event_t ce; // expected-error {{the '__global clk_event_t' type 
cannot be used to declare a program scope variable}}
 
@@ -10,6 +10,7 @@
   event_t e;
   clk_event_t ce1;
   clk_event_t ce2;
+  clk_event_t ce3 = CLK_NULL_EVENT;
 
   if (e == ce1) { // expected-error {{invalid operands to binary expression 
('event_t' and 'clk_event_t')}}
 return 9;
Index: lib/Headers/opencl-c-base.h
===
--- lib/Headers/opencl-c-base.h
+++ lib/Headers/opencl-c-base.h
@@ -413,7 +413,7 @@
 #define CLK_OUT_OF_RESOURCES-5
 
 #define CLK_NULL_QUEUE  0
-#define CLK_NULL_EVENT (__builtin_astype(((void*)(__SIZE_MAX__)), clk_event_t))
+#define CLK_NULL_EVENT (__builtin_astype(((__SIZE_MAX__)), clk_event_t))
 
 // execution model related definitions
 #define CLK_ENQUEUE_FLAGS_NO_WAIT   0x0


Index: test/SemaOpenCL/clk_event_t.cl
===
--- test/SemaOpenCL/clk_event_t.cl
+++ test/SemaOpenCL/clk_event_t.cl
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=c++
 
 // Taken from opencl-c.h
-#define CLK_NULL_EVENT (__builtin_astype(((void*)(__SIZE_MAX__)), clk_event_t))
+#define CLK_NULL_EVENT (__builtin_astype(((__SIZE_MAX__)), clk_event_t))
 
 global clk_event_t ce; // expected-error {{the '__global clk_event_t' type cannot be used to declare a program scope variable}}
 
@@ -10,6 +10,7 @@
   event_t e;
   clk_event_t ce1;
   clk_event_t ce2;
+  clk_event_t ce3 = CLK_NULL_EVENT;
 
   if (e == ce1) { // expected-error {{invalid operands to binary expression ('event_t' and 'clk_event_t')}}
 return 9;
Index: lib/Headers/opencl-c-base.h
===
--- lib/Headers/opencl-c-base.h
+++ lib/Headers/opencl-c-base.h
@@ -413,7 +413,7 @@
 #define CLK_OUT_OF_RESOURCES-5
 
 #define CLK_NULL_QUEUE  0
-#define CLK_NULL_EVENT (__builtin_astype(((void*)(__SIZE_MAX__)), clk_event_t))
+#define CLK_NULL_EVENT (__builtin_astype(((__SIZE_MAX__)), clk_event_t))
 
 // execution model related definitions
 #define CLK_ENQUEUE_FLAGS_NO_WAIT   0x0
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63872: [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

2019-06-27 Thread Haojian Wu via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL364537: [clangd] Fix a case where we fail to detect a 
header-declared symbol in rename. (authored by hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63872?vs=206844=206847#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63872

Files:
  clang-tools-extra/trunk/clangd/refactor/Rename.cpp
  clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp

Index: clang-tools-extra/trunk/clangd/refactor/Rename.cpp
===
--- clang-tools-extra/trunk/clangd/refactor/Rename.cpp
+++ clang-tools-extra/trunk/clangd/refactor/Rename.cpp
@@ -67,15 +67,14 @@
 }
 
 // Query the index to find some other files where the Decl is referenced.
-llvm::Optional getOtherRefFile(const NamedDecl ,
-StringRef MainFile,
+llvm::Optional getOtherRefFile(const Decl , StringRef MainFile,
 const SymbolIndex ) {
   RefsRequest Req;
   // We limit the number of results, this is a correctness/performance
   // tradeoff. We expect the number of symbol references in the current file
   // is smaller than the limit.
   Req.Limit = 100;
-  if (auto ID = getSymbolID())
+  if (auto ID = getSymbolID())
 Req.IDs.insert(*ID);
   llvm::Optional OtherFile;
   Index.refs(Req, [&](const Ref ) {
@@ -97,16 +96,16 @@
 };
 
 // Check the symbol Decl is renameable (per the index) within the file.
-llvm::Optional renamableWithinFile(const NamedDecl ,
+llvm::Optional renamableWithinFile(const Decl ,
StringRef MainFile,
const SymbolIndex *Index) {
-  if (llvm::isa())
+  if (llvm::isa())
 return ReasonToReject::UnsupportedSymbol;
-  auto  = Decl.getASTContext();
+  auto  = RenameDecl.getASTContext();
   const auto  = ASTCtx.getSourceManager();
   bool MainFileIsHeader = ASTCtx.getLangOpts().IsHeaderFile;
   bool DeclaredInMainFile =
-  SM.isWrittenInMainFile(SM.getExpansionLoc(Decl.getLocation()));
+  SM.isWrittenInMainFile(SM.getExpansionLoc(RenameDecl.getLocation()));
 
   // If the symbol is declared in the main file (which is not a header), we
   // rename it.
@@ -115,18 +114,19 @@
 
   // Below are cases where the symbol is declared in the header.
   // If the symbol is function-local, we rename it.
-  if (Decl.getParentFunctionOrMethod())
+  if (RenameDecl.getParentFunctionOrMethod())
 return None;
 
   if (!Index)
 return ReasonToReject::NoIndexProvided;
 
-  bool IsIndexable =
-  SymbolCollector::shouldCollectSymbol(Decl, ASTCtx, {}, false);
+  bool IsIndexable = isa(RenameDecl) &&
+ SymbolCollector::shouldCollectSymbol(
+ cast(RenameDecl), ASTCtx, {}, false);
   // If the symbol is not indexable, we disallow rename.
   if (!IsIndexable)
 return ReasonToReject::NonIndexable;
-  auto OtherFile = getOtherRefFile(Decl, MainFile, *Index);
+  auto OtherFile = getOtherRefFile(RenameDecl, MainFile, *Index);
   // If the symbol is indexable and has no refs from other files in the index,
   // we rename it.
   if (!OtherFile)
@@ -154,7 +154,8 @@
 
   const auto *RenameDecl = Rename->getRenameDecl();
   assert(RenameDecl && "symbol must be found at this point");
-  if (auto Reject = renamableWithinFile(*RenameDecl, File, Index)) {
+  if (auto Reject =
+  renamableWithinFile(*RenameDecl->getCanonicalDecl(), File, Index)) {
 auto Message = [](ReasonToReject Reason) {
   switch (Reason) {
   case NoIndexProvided:
Index: clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp
@@ -78,7 +78,6 @@
   for (const Test  : Tests) {
 Annotations Code(T.Before);
 auto TU = TestTU::withCode(Code.code());
-TU.HeaderCode = "void foo();"; // outside main file, will not be touched.
 auto AST = TU.build();
 auto RenameResult =
 renameWithinFile(AST, testPath(TU.Filename), Code.point(), "abcde");
@@ -92,58 +91,68 @@
 }
 
 TEST(RenameTest, Renameable) {
-  // Test cases where the symbol is declared in header.
   struct Case {
-const char* HeaderCode;
+const char *Code;
 const char* ErrorMessage; // null if no error
+bool IsHeaderFile;
   };
+  const bool HeaderFile = true;
   Case Cases[] = {
   {R"cpp(// allow -- function-local
 void f(int [[Lo^cal]]) {
   [[Local]] = 2;
 }
   )cpp",
-   nullptr},
+   nullptr, HeaderFile},
 
   {R"cpp(// allow -- symbol is indexable and has no refs in index.
 void

[clang-tools-extra] r364537 - [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

2019-06-27 Thread Haojian Wu via cfe-commits

Author: hokein
Date: Thu Jun 27 06:24:10 2019
New Revision: 364537

URL: http://llvm.org/viewvc/llvm-project?rev=364537=rev
Log:
[clangd] Fix a case where we fail to detect a header-declared symbol in rename.

Summary:
Failing case:

```
 #include "foo.h"
 void fo^o() {}
```

getRenameDecl() returns the decl of the symbol under the cursor (which is
in the current main file), instead, we use the canonical decl to determine
whether a symbol is declared in #included header.

Reviewers: sammccall

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

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/refactor/Rename.cpp
clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp

Modified: clang-tools-extra/trunk/clangd/refactor/Rename.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/refactor/Rename.cpp?rev=364537=364536=364537=diff
==
--- clang-tools-extra/trunk/clangd/refactor/Rename.cpp (original)
+++ clang-tools-extra/trunk/clangd/refactor/Rename.cpp Thu Jun 27 06:24:10 2019
@@ -67,15 +67,14 @@ llvm::Optional filePath(con
 }
 
 // Query the index to find some other files where the Decl is referenced.
-llvm::Optional getOtherRefFile(const NamedDecl ,
-StringRef MainFile,
+llvm::Optional getOtherRefFile(const Decl , StringRef MainFile,
 const SymbolIndex ) {
   RefsRequest Req;
   // We limit the number of results, this is a correctness/performance
   // tradeoff. We expect the number of symbol references in the current file
   // is smaller than the limit.
   Req.Limit = 100;
-  if (auto ID = getSymbolID())
+  if (auto ID = getSymbolID())
 Req.IDs.insert(*ID);
   llvm::Optional OtherFile;
   Index.refs(Req, [&](const Ref ) {
@@ -97,16 +96,16 @@ enum ReasonToReject {
 };
 
 // Check the symbol Decl is renameable (per the index) within the file.
-llvm::Optional renamableWithinFile(const NamedDecl ,
+llvm::Optional renamableWithinFile(const Decl ,
StringRef MainFile,
const SymbolIndex *Index) {
-  if (llvm::isa())
+  if (llvm::isa())
 return ReasonToReject::UnsupportedSymbol;
-  auto  = Decl.getASTContext();
+  auto  = RenameDecl.getASTContext();
   const auto  = ASTCtx.getSourceManager();
   bool MainFileIsHeader = ASTCtx.getLangOpts().IsHeaderFile;
   bool DeclaredInMainFile =
-  SM.isWrittenInMainFile(SM.getExpansionLoc(Decl.getLocation()));
+  SM.isWrittenInMainFile(SM.getExpansionLoc(RenameDecl.getLocation()));
 
   // If the symbol is declared in the main file (which is not a header), we
   // rename it.
@@ -115,18 +114,19 @@ llvm::Optional renamable
 
   // Below are cases where the symbol is declared in the header.
   // If the symbol is function-local, we rename it.
-  if (Decl.getParentFunctionOrMethod())
+  if (RenameDecl.getParentFunctionOrMethod())
 return None;
 
   if (!Index)
 return ReasonToReject::NoIndexProvided;
 
-  bool IsIndexable =
-  SymbolCollector::shouldCollectSymbol(Decl, ASTCtx, {}, false);
+  bool IsIndexable = isa(RenameDecl) &&
+ SymbolCollector::shouldCollectSymbol(
+ cast(RenameDecl), ASTCtx, {}, false);
   // If the symbol is not indexable, we disallow rename.
   if (!IsIndexable)
 return ReasonToReject::NonIndexable;
-  auto OtherFile = getOtherRefFile(Decl, MainFile, *Index);
+  auto OtherFile = getOtherRefFile(RenameDecl, MainFile, *Index);
   // If the symbol is indexable and has no refs from other files in the index,
   // we rename it.
   if (!OtherFile)
@@ -154,7 +154,8 @@ renameWithinFile(ParsedAST , llvm::S
 
   const auto *RenameDecl = Rename->getRenameDecl();
   assert(RenameDecl && "symbol must be found at this point");
-  if (auto Reject = renamableWithinFile(*RenameDecl, File, Index)) {
+  if (auto Reject =
+  renamableWithinFile(*RenameDecl->getCanonicalDecl(), File, Index)) {
 auto Message = [](ReasonToReject Reason) {
   switch (Reason) {
   case NoIndexProvided:

Modified: clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp?rev=364537=364536=364537=diff
==
--- clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp (original)
+++ clang-tools-extra/trunk/clangd/unittests/RenameTests.cpp Thu Jun 27 
06:24:10 2019
@@ -78,7 +78,6 @@ TEST(RenameTest, SingleFile) {
   for (const Test  : Tests) {
 Annotations Code(T.Before);
 auto TU = TestTU::withCode(Code.code());
-TU.HeaderCode = "void foo();"; // outside main file, will not be touched.
 auto AST = TU.build();
 auto RenameResult =

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

2019-06-27 Thread Haojian Wu via Phabricator via cfe-commits

hokein added inline comments.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:60
+  void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) override;

jvikstrom wrote:
> hokein wrote:
> > nit: you can remove this override, since we have provided an empty default 
> > implementation.
> I get an `-Winconsistent-missing-override` warnings without the override.
sorry for the confusion, I meant we remove `onHighlightingsReady`, not the 
`override` keyword.



Comment at: clang-tools-extra/clangd/unittests/ClangdTests.cpp:864
+  ClangdServer Server(MCD, FS, DiagConsumer, ClangdServer::optsForTest());
+  Server.addDocument(FooCpp, "int a;");
+  ASSERT_EQ(DiagConsumer.Count, 1);

this is not safe, we need to wait until the server finishes building AST.

add `ASSERT_TRUE(Server.blockUntilIdleForTest()) << "Waiting for server"; `


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821



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

[PATCH] D63872: [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

2019-06-27 Thread Sam McCall via Phabricator via cfe-commits

sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/refactor/Rename.cpp:157
   assert(RenameDecl && "symbol must be found at this point");
+  RenameDecl = cast(RenameDecl->getCanonicalDecl());
   if (auto Reject = renamableWithinFile(*RenameDecl, File, Index)) {

hokein wrote:
> sammccall wrote:
> > This cast isn't safe. I can't remember the exact case, but if you really 
> > need a NamedDecl you need to decide what to do if the canonical one isn't.
> Thanks, it is a little surprising this is not safe (I don't have a corner 
> case in mind either).
> 
> The `shouldCollectSymbol` requires a NamedDecl, I think when the 
> CanonicalDecl is not a NamedDecl, we think this symbol is not indexable.
Sounds good.

See the comment in SymbolCollector about `ObjCPropertyDecl`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63872



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

[PATCH] D63872: [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

2019-06-27 Thread Haojian Wu via Phabricator via cfe-commits

hokein added inline comments.



Comment at: clang-tools-extra/clangd/refactor/Rename.cpp:157
   assert(RenameDecl && "symbol must be found at this point");
+  RenameDecl = cast(RenameDecl->getCanonicalDecl());
   if (auto Reject = renamableWithinFile(*RenameDecl, File, Index)) {

sammccall wrote:
> This cast isn't safe. I can't remember the exact case, but if you really need 
> a NamedDecl you need to decide what to do if the canonical one isn't.
Thanks, it is a little surprising this is not safe (I don't have a corner case 
in mind either).

The `shouldCollectSymbol` requires a NamedDecl, I think when the CanonicalDecl 
is not a NamedDecl, we think this symbol is not indexable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63872



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

[PATCH] D63872: [clangd] Fix a case where we fail to detect a header-declared symbol in rename.

2019-06-27 Thread Haojian Wu via Phabricator via cfe-commits

hokein updated this revision to Diff 206844.
hokein marked 2 inline comments as done.
hokein added a comment.

Address comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63872

Files:
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/unittests/RenameTests.cpp

Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -78,7 +78,6 @@
   for (const Test  : Tests) {
 Annotations Code(T.Before);
 auto TU = TestTU::withCode(Code.code());
-TU.HeaderCode = "void foo();"; // outside main file, will not be touched.
 auto AST = TU.build();
 auto RenameResult =
 renameWithinFile(AST, testPath(TU.Filename), Code.point(), "abcde");
@@ -92,58 +91,68 @@
 }
 
 TEST(RenameTest, Renameable) {
-  // Test cases where the symbol is declared in header.
   struct Case {
-const char* HeaderCode;
+const char *Code;
 const char* ErrorMessage; // null if no error
+bool IsHeaderFile;
   };
+  const bool HeaderFile = true;
   Case Cases[] = {
   {R"cpp(// allow -- function-local
 void f(int [[Lo^cal]]) {
   [[Local]] = 2;
 }
   )cpp",
-   nullptr},
+   nullptr, HeaderFile},
 
   {R"cpp(// allow -- symbol is indexable and has no refs in index.
 void [[On^lyInThisFile]]();
   )cpp",
-   nullptr},
+   nullptr, HeaderFile},
 
   {R"cpp(// disallow -- symbol is indexable and has other refs in index.
 void f() {
   Out^side s;
 }
   )cpp",
-   "used outside main file"},
+   "used outside main file", HeaderFile},
 
   {R"cpp(// disallow -- symbol is not indexable.
 namespace {
 class Unin^dexable {};
 }
   )cpp",
-   "not eligible for indexing"},
+   "not eligible for indexing", HeaderFile},
 
   {R"cpp(// disallow -- namespace symbol isn't supported
 namespace fo^o {}
   )cpp",
-   "not a supported kind"},
+   "not a supported kind", HeaderFile},
+
+  {R"cpp(// foo is declared outside the file.
+void fo^o() {}
+  )cpp", "used outside main file", !HeaderFile/*cc file*/},
   };
-  const char *CommonHeader = "class Outside {};";
-  TestTU OtherFile = TestTU::withCode("Outside s;");
+  const char *CommonHeader = R"cpp(
+class Outside {};
+void foo();
+  )cpp";
+  TestTU OtherFile = TestTU::withCode("Outside s; auto ss = ");
   OtherFile.HeaderCode = CommonHeader;
   OtherFile.Filename = "other.cc";
-  // The index has a "Outside" reference.
+  // The index has a "Outside" reference and a "foo" reference.
   auto OtherFileIndex = OtherFile.index();
 
   for (const auto& Case : Cases) {
-Annotations T(Case.HeaderCode);
-// We open the .h file as the main file.
+Annotations T(Case.Code);
 TestTU TU = TestTU::withCode(T.code());
-TU.Filename = "test.h";
 TU.HeaderCode = CommonHeader;
-// Parsing the .h file as C++ include.
-TU.ExtraArgs.push_back("-xobjective-c++-header");
+if (Case.IsHeaderFile) {
+  // We open the .h file as the main file.
+  TU.Filename = "test.h";
+  // Parsing the .h file as C++ include.
+  TU.ExtraArgs.push_back("-xobjective-c++-header");
+}
 auto AST = TU.build();
 
 auto Results = renameWithinFile(AST, testPath(TU.Filename), T.point(),
Index: clang-tools-extra/clangd/refactor/Rename.cpp
===
--- clang-tools-extra/clangd/refactor/Rename.cpp
+++ clang-tools-extra/clangd/refactor/Rename.cpp
@@ -67,15 +67,14 @@
 }
 
 // Query the index to find some other files where the Decl is referenced.
-llvm::Optional getOtherRefFile(const NamedDecl ,
-StringRef MainFile,
+llvm::Optional getOtherRefFile(const Decl , StringRef MainFile,
 const SymbolIndex ) {
   RefsRequest Req;
   // We limit the number of results, this is a correctness/performance
   // tradeoff. We expect the number of symbol references in the current file
   // is smaller than the limit.
   Req.Limit = 100;
-  if (auto ID = getSymbolID())
+  if (auto ID = getSymbolID())
 Req.IDs.insert(*ID);
   llvm::Optional OtherFile;
   Index.refs(Req, [&](const Ref ) {
@@ -97,16 +96,16 @@
 };
 
 // Check the symbol Decl is renameable (per the index) within the file.
-llvm::Optional renamableWithinFile(const NamedDecl ,
+llvm::Optional renamableWithinFile(const Decl ,
StringRef MainFile,
const SymbolIndex *Index) {
-  if (llvm::isa())
+  if (llvm::isa())
 return ReasonToReject::UnsupportedSymbol;
-  auto  = Decl.getASTContext();
+  auto  =

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

2019-06-27 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 updated this revision to Diff 206842.

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

https://reviews.llvm.org/D63082

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaChecking.cpp
  test/Analysis/misc-ps.c
  test/Sema/integer-overflow.c
  test/Sema/parentheses.c
  test/Sema/parentheses.cpp
  test/Sema/warn-int-in-bool-context.c
  test/Sema/warn-unreachable.c
  test/SemaCXX/constexpr-printing.cpp
  test/SemaCXX/integer-overflow.cpp
  test/SemaCXX/nested-name-spec.cpp
  test/SemaCXX/warn-int-in-bool-context.cpp

Index: test/SemaCXX/warn-int-in-bool-context.cpp
===
--- test/SemaCXX/warn-int-in-bool-context.cpp
+++ test/SemaCXX/warn-int-in-bool-context.cpp
@@ -0,0 +1,170 @@
+// RUN: %clang_cc1 -x c++ -fsyntax-only -verify -Wint-in-bool-context %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -verify %s
+
+#define ONE 1
+#define TWO 2
+
+enum answer {
+  foo,
+  bar,
+  yes,
+  no,
+  unknown,
+};
+
+enum fruit {
+  orange = -3,
+  lemon,
+  banana,
+  apple,
+};
+
+void g(bool b);
+
+template 
+void h() {}
+template 
+void h() {}
+
+bool test(int a, int b, enum answer ans, enum fruit f) {
+  bool r = TWO * 7; // expected-warning {{'*' in boolean context}}
+  r = 3 * 7;// expected-warning {{'*' in boolean context}}
+  r = a * 7;// expected-warning {{'*' in boolean context}}
+  r = a * b;// expected-warning {{'*' in boolean context}}
+  g(3 * 9); // expected-warning {{'*' in boolean context}}
+  h<3 * 9>();
+
+  r = TWO << 7; // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+  r = a << 7;   // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+  r = ONE << b; // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+
+  r = a ? ONE : TWO; // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+  r = a ? (1) : TWO;
+  r = a ? 3 : TWO; // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+  r = a ? -2 : 0;
+  r = a ? 3 : -2;
+  r = a ? 0 : TWO; // expected-warning {{'?:' with integer constants in boolean context}}
+  r = a ? 3 : ONE; // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+  r = a ? ONE : 0;
+  r = a ? 0 : 0;
+  r = a ? ONE : 0;
+  r = a ? ONE : ONE;
+  g(a ? 3 : 9); // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+
+  r = a ? yes   // expected-warning {{enum constant in boolean context}}
+: no;   // expected-warning {{enum constant in boolean context}}
+  r = ans == yes || no; // expected-warning {{enum constant in boolean context}}
+  r = yes || ans == no; // expected-warning {{enum constant in boolean context}}
+  r = ans == yes || ans == no;
+  r = !foo;
+  r = !bar;
+  r = !yes;// expected-warning {{enum constant in boolean context}}
+  g(ans == yes || no); // expected-warning {{enum constant in boolean context}}
+
+  if (8 * 4) // expected-warning {{'*' in boolean context}}
+return a;
+
+  if (a * 4) // expected-warning {{'*' in boolean context}}
+return a;
+
+  if (-TWO * b) // expected-warning {{'*' in boolean context}}
+return a;
+
+  if (TWO << 4) // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+return a;
+
+  if (a << TWO) // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+return a;
+
+  if (ONE << b) // expected-warning {{'<<' in boolean context; did you mean '<'?}}
+return a;
+
+  if (a ? ONE : TWO) // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+return a;
+
+  if (a ? 32 : TWO) // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+return a;
+
+  if (a ? 7 : TWO) // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+return a;
+
+  if (ans == yes || foo)
+return a;
+
+  if (f == apple || orange) // expected-warning {{enum constant in boolean context}}
+return a;
+
+  if (ans == yes || no) // expected-warning {{enum constant in boolean context}}
+return a;
+
+  if (yes || ans == no) // expected-warning {{enum constant in boolean context}}
+return a;
+
+  if (r || a ? 7 : TWO) // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+return a;
+
+  if (b && a ? 7 : TWO) // expected-warning {{'?:' with integer constants in boolean context, the expression will always evaluate to 'true'}}
+return a;
+
+  if ((a ? 7 : TWO) && b == 32) // expected-warning {{'?:' with integer constants in boolean context, the expression will always

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

2019-06-27 Thread Johan Vikström via Phabricator via cfe-commits

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



Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:60
+  void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) override;

hokein wrote:
> nit: you can remove this override, since we have provided an empty default 
> implementation.
I get an `-Winconsistent-missing-override` warnings without the override.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821



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

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

2019-06-27 Thread Johan Vikström via Phabricator via cfe-commits

jvikstrom updated this revision to Diff 206841.
jvikstrom marked an inline comment as done.
jvikstrom added a comment.

Simplified test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/unittests/ClangdTests.cpp

Index: clang-tools-extra/clangd/unittests/ClangdTests.cpp
===
--- clang-tools-extra/clangd/unittests/ClangdTests.cpp
+++ clang-tools-extra/clangd/unittests/ClangdTests.cpp
@@ -13,6 +13,7 @@
 #include "GlobalCompilationDatabase.h"
 #include "Matchers.h"
 #include "SyncAPI.h"
+#include "TUScheduler.h"
 #include "TestFS.h"
 #include "Threading.h"
 #include "URI.h"
@@ -841,6 +842,29 @@
   EXPECT_FALSE(PathResult.hasValue());
 }
 
+TEST(ClangdSemanticHighlightingTest, GeneratesHighlightsWhenFileChange) {
+  class HighlightingsCounterDiagConsumer : public DiagnosticsConsumer {
+  public:
+std::atomic Count = {0};
+
+void onDiagnosticsReady(PathRef, std::vector) override {}
+void onHighlightingsReady(
+PathRef File, std::vector Highlightings) override {
+  ++Count;
+}
+  };
+
+  auto FooCpp = testPath("foo.cpp");
+  MockFSProvider FS;
+  FS.Files[FooCpp] = "";
+
+  MockCompilationDatabase MCD;
+  HighlightingsCounterDiagConsumer DiagConsumer;
+  ClangdServer Server(MCD, FS, DiagConsumer, ClangdServer::optsForTest());
+  Server.addDocument(FooCpp, "int a;");
+  ASSERT_EQ(DiagConsumer.Count, 1);
+}
+
 TEST_F(ClangdThreadingTest, NoConcurrentDiagnostics) {
   class NoConcurrentAccessDiagConsumer : public DiagnosticsConsumer {
   public:
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -18,6 +18,7 @@
 #include "Function.h"
 #include "GlobalCompilationDatabase.h"
 #include "Protocol.h"
+#include "SemanticHighlighting.h"
 #include "TUScheduler.h"
 #include "XRefs.h"
 #include "index/Background.h"
@@ -49,6 +50,11 @@
   std::vector Diagnostics) = 0;
   /// Called whenever the file status is updated.
   virtual void onFileUpdated(PathRef File, const TUStatus ){};
+
+  /// Called by ClangdServer when some \p Highlightings for \p File are ready.
+  virtual void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) {}
 };
 
 /// When set, used by ClangdServer to get clang-tidy options for each particular
@@ -131,6 +137,9 @@
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
+
+/// Enable semantic highlighting features.
+bool SemanticHighlighting = false;
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -304,7 +313,7 @@
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
-
+  
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -48,8 +48,10 @@
 
 // Update the FileIndex with new ASTs and plumb the diagnostics responses.
 struct UpdateIndexCallbacks : public ParsingCallbacks {
-  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer )
-  : FIndex(FIndex), DiagConsumer(DiagConsumer) {}
+  UpdateIndexCallbacks(FileIndex *FIndex, DiagnosticsConsumer ,
+   bool SemanticHighlighting)
+  : FIndex(FIndex), DiagConsumer(DiagConsumer),
+SemanticHighlighting(SemanticHighlighting) {}
 
   void onPreambleAST(PathRef Path, ASTContext ,
  std::shared_ptr PP,
@@ -61,6 +63,8 @@
   void onMainAST(PathRef Path, ParsedAST ) override {
 if (FIndex)
   FIndex->updateMain(Path, AST);
+if (SemanticHighlighting)
+  DiagConsumer.onHighlightingsReady(Path, getSemanticHighlightings(AST));
   }
 
   void onDiagnostics(PathRef File, std::vector Diags) override {
@@ -74,6 +78,7 @@
 private:
   FileIndex *FIndex;
   DiagnosticsConsumer 
+  bool SemanticHighlighting;
 };
 } // namespace
 
@@ -82,6 +87,7 @@
   Opts.UpdateDebounce = std::chrono::steady_clock::duration::zero(); // Faster!
   Opts.StorePreamblesInMemory = true;
   Opts.AsyncThreadsCount = 4; // Consistent!
+  Opts.SemanticHighlighting = true;
   return Opts;
 }
 
@@ -102,10 +108,11 @@
   // is parsed.
   // FIXME(ioeric): this can be slow and

[clang-tools-extra] r364535 - [clang-tidy] Fix NDEBUG build [NFC]

2019-06-27 Thread Mikael Holmen via cfe-commits

Author: uabelho
Date: Thu Jun 27 05:47:57 2019
New Revision: 364535

URL: http://llvm.org/viewvc/llvm-project?rev=364535=rev
Log:
[clang-tidy] Fix NDEBUG build [NFC]

Modified:
clang-tools-extra/trunk/clang-tidy/utils/TransformerClangTidyCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/utils/TransformerClangTidyCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/utils/TransformerClangTidyCheck.cpp?rev=364535=364534=364535=diff
==
--- clang-tools-extra/trunk/clang-tidy/utils/TransformerClangTidyCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/utils/TransformerClangTidyCheck.cpp Thu 
Jun 27 05:47:57 2019
@@ -14,9 +14,11 @@ namespace tidy {
 namespace utils {
 using tooling::RewriteRule;
 
+#ifndef NDEBUG
 static bool hasExplanation(const RewriteRule::Case ) {
   return C.Explanation != nullptr;
 }
+#endif
 
 // This constructor cannot dispatch to the simpler one (below), because, in
 // order to get meaningful results from `getLangOpts` and `Options`, we need 
the


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

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

2019-06-27 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 added a comment.

Alternative “* in boolean context; did you mean to compare it?”


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

https://reviews.llvm.org/D63082



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

[PATCH] D63559: [clangd] Added functionality for getting semantic highlights for variable and function declarations

2019-06-27 Thread Haojian Wu via Phabricator via cfe-commits

hokein closed this revision.
hokein added a comment.

the patch was landed in rL364421 , not sure 
why it was not associated with this review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63559



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

[PATCH] D63821: [clangd] Added C++ API code for semantic highlighting

2019-06-27 Thread Haojian Wu via Phabricator via cfe-commits

hokein added inline comments.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:60
+  void
+  onHighlightingsReady(PathRef File,
+   std::vector Highlightings) override;

nit: you can remove this override, since we have provided an empty default 
implementation.



Comment at: clang-tools-extra/clangd/unittests/ClangdTests.cpp:881
+
+  std::promise StartSecondPromise;
+  std::future StartSecond = StartSecondPromise.get_future();

Looks like the current test could be simplified, I think we want to test that 
when the AST is build/rebuild, we will emit the highlighting tokens. 
Just use `Count` and check the count is to 1?

```
Server.addDocument(FooCpp, "int a;");
ASSERT_TRUE(Server.blockUntilIdleForTest()) << "Waiting for server";
ASSERT_EQ(DiagConsumer.Count, 1);
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63821



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

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

2019-06-27 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 added a comment.

“Perhaps appending something about the resulting value always being true|false 
would help most of these diagnostics be more obvious”

I dont know, this could only diagnose constant multiplications (maybe this is 
already handled by some “always true” check). Anyway, I have no motivation to 
diagnose constant muls, sorry. My goal is to make this warning atleast as good 
as GCC’s implementation.

Okay, we could make it better and append “; did you mean “index * 3 != 0”?


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

https://reviews.llvm.org/D63082



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

[PATCH] D63874: [clangd] No need to setTraversalScope in SemanticHighlighting.

2019-06-27 Thread Haojian Wu via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL364528: [clangd] No need to setTraversalScope in 
SemanticHighlighting. (authored by hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D63874?vs=206834=206835#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D63874

Files:
  clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
  clang-tools-extra/trunk/clangd/SemanticHighlighting.h


Index: clang-tools-extra/trunk/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.h
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.h
@@ -6,8 +6,8 @@
 //
 
//===--===//
 
-#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
-#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
 
 #include "ClangdUnit.h"
 
Index: clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
@@ -1,4 +1,4 @@
-//===--- SemanticHighlighting.cpp - -- ---*- C++ 
-*-===//
+//===--- SemanticHighlighting.cpp - - ---*- C++ 
-*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -70,7 +70,6 @@
 }
 
 std::vector getSemanticHighlightings(ParsedAST ) {
-  AST.getASTContext().setTraversalScope(AST.getLocalTopLevelDecls());
   return HighlightingTokenCollector(AST).collectTokens();
 }
 


Index: clang-tools-extra/trunk/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.h
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.h
@@ -6,8 +6,8 @@
 //
 //===--===//
 
-#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
-#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHT_H
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
 
 #include "ClangdUnit.h"
 
Index: clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
@@ -1,4 +1,4 @@
-//===--- SemanticHighlighting.cpp - -- ---*- C++ -*-===//
+//===--- SemanticHighlighting.cpp - - ---*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -70,7 +70,6 @@
 }
 
 std::vector getSemanticHighlightings(ParsedAST ) {
-  AST.getASTContext().setTraversalScope(AST.getLocalTopLevelDecls());
   return HighlightingTokenCollector(AST).collectTokens();
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

1 2 >

1 - 100 of 123 matches

Mail list logo