Re: [PATCH] D64029: [PGO] Add PGO support at -O0 in the experimental new pass manager

[Rong Xu via cfe-commits]

yes. I already know this issue as this also breaks windows bolt.
The fix should be simple.

-Rong

On Thu, Aug 1, 2019 at 11:52 PM Petr Hosek via Phabricator <
revi...@reviews.llvm.org> wrote:

> phosek added a comment.
>
> Looks like this change broke `Profile/gcc-flag-compatibility.c` test on
> macOS:
>
>    TEST 'Clang :: Profile/gcc-flag-compatibility.c'
> FAILED 
>   Script:
>   --
>   : 'RUN: at line 10';
>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -c -S
> -o - -emit-llvm -fprofile-generate -fno-experimental-new-pass-manager |
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
> -check-prefix=PROFILE-GEN
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>   : 'RUN: at line 11';
>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -c -S
> -o - -emit-llvm -fprofile-generate -fexperimental-new-pass-manager |
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
> -check-prefix=PROFILE-GEN
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>   : 'RUN: at line 16';
>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -c -S
> -o - -emit-llvm -fprofile-generate=/path/to
> -fno-experimental-new-pass-manager |
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
> -check-prefixes=PROFILE-GEN,PROFILE-GEN-EQ
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>   : 'RUN: at line 22';   rm -rf
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir
>   : 'RUN: at line 23';   mkdir -p
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path
>   : 'RUN: at line 24';   llvm-profdata merge
> /b/s/w/ir/k/llvm-project/clang/test/Profile/Inputs/gcc-flag-compatibility.proftext
> -o
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path/default.profdata
>   : 'RUN: at line 25';
>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -o -
> -Xclang -disable-llvm-passes -emit-llvm -S
> -fprofile-use=/b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path
> -fno-experimental-new-pass-manager |
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
> -check-prefix=PROFILE-USE
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>   : 'RUN: at line 26';
>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -o -
> -Xclang -disable-llvm-passes -emit-llvm -S
> -fprofile-use=/b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path
> -fexperimental-new-pass-manager |
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
> -check-prefix=PROFILE-USE
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>   : 'RUN: at line 30';   rm -rf
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir
>   : 'RUN: at line 31';   mkdir -p
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path
>   : 'RUN: at line 32';   llvm-profdata merge
> /b/s/w/ir/k/llvm-project/clang/test/Profile/Inputs/gcc-flag-compatibility.proftext
> -o
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path/file.prof
>   : 'RUN: at line 33';
>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -o -
> -Xclang -disable-llvm-passes -emit-llvm -S
> -fprofile-use=/b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path/file.prof
> -fno-experimental-new-pass-manager |
> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
> -check-prefix=PROFILE-USE
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>   : 'RUN: at line 34';
>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -o -
> -Xclang -disable-llvm-passes -emit-llvm -S
> -fprofile-use=/b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path/file.prof
> -fexperimental-new-pass-ma

r367658 - Revert r367649: Improve raw_ostream so that you can "write" colors using operator<

[Rui Ueyama via cfe-commits]

Author: ruiu
Date: Fri Aug  2 00:22:34 2019
New Revision: 367658

URL: http://llvm.org/viewvc/llvm-project?rev=367658&view=rev
Log:
Revert r367649: Improve raw_ostream so that you can "write" colors using 
operator<<

This reverts commit r367649 in an attempt to unbreak Windows bots.

Modified:
cfe/trunk/include/clang/AST/ASTDumperUtils.h
cfe/trunk/lib/Analysis/CFG.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Frontend/TextDiagnostic.cpp
cfe/trunk/tools/diagtool/TreeView.cpp

Modified: cfe/trunk/include/clang/AST/ASTDumperUtils.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTDumperUtils.h?rev=367658&r1=367657&r2=367658&view=diff
==
--- cfe/trunk/include/clang/AST/ASTDumperUtils.h (original)
+++ cfe/trunk/include/clang/AST/ASTDumperUtils.h Fri Aug  2 00:22:34 2019
@@ -27,7 +27,7 @@ enum ASTDumpOutputFormat {
 // Do not use bold yellow for any text.  It is hard to read on white screens.
 
 struct TerminalColor {
-  llvm::raw_ostream::Color Color;
+  llvm::raw_ostream::Colors Color;
   bool Bold;
 };
 

Modified: cfe/trunk/lib/Analysis/CFG.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/CFG.cpp?rev=367658&r1=367657&r2=367658&view=diff
==
--- cfe/trunk/lib/Analysis/CFG.cpp (original)
+++ cfe/trunk/lib/Analysis/CFG.cpp Fri Aug  2 00:22:34 2019
@@ -5509,7 +5509,7 @@ static void print_block(raw_ostream &OS,
   if (print_edges) {
 // Print the predecessors of this block.
 if (!B.pred_empty()) {
-  const raw_ostream::Color Color = raw_ostream::BLUE;
+  const raw_ostream::Colors Color = raw_ostream::BLUE;
   if (ShowColors)
 OS.changeColor(Color);
   OS << "   Preds " ;
@@ -5546,7 +5546,7 @@ static void print_block(raw_ostream &OS,
 
 // Print the successors of this block.
 if (!B.succ_empty()) {
-  const raw_ostream::Color Color = raw_ostream::MAGENTA;
+  const raw_ostream::Colors Color = raw_ostream::MAGENTA;
   if (ShowColors)
 OS.changeColor(Color);
   OS << "   Succs ";

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=367658&r1=367657&r2=367658&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Fri Aug  2 00:22:34 2019
@@ -1491,10 +1491,6 @@ bool clang::ParseDiagnosticArgs(Diagnost
OPT_fno_diagnostics_show_option, DefaultShowOpt);
 
   llvm::sys::Process::UseANSIEscapeCodes(Args.hasArg(OPT_fansi_escape_codes));
-  if (Opts.ShowColors) {
-llvm::outs().enable_colors();
-llvm::errs().enable_colors();
-  }
 
   // Default behavior is to not to show note include stacks.
   Opts.ShowNoteIncludeStack = false;

Modified: cfe/trunk/lib/Frontend/TextDiagnostic.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/TextDiagnostic.cpp?rev=367658&r1=367657&r2=367658&view=diff
==
--- cfe/trunk/lib/Frontend/TextDiagnostic.cpp (original)
+++ cfe/trunk/lib/Frontend/TextDiagnostic.cpp Fri Aug  2 00:22:34 2019
@@ -23,16 +23,23 @@
 
 using namespace clang;
 
-static const raw_ostream::Color noteColor = raw_ostream::BLACK;
-static const raw_ostream::Color remarkColor = raw_ostream::BLUE;
-static const raw_ostream::Color fixitColor = raw_ostream::GREEN;
-static const raw_ostream::Color caretColor = raw_ostream::GREEN;
-static const raw_ostream::Color warningColor = raw_ostream::MAGENTA;
-static const raw_ostream::Color templateColor = raw_ostream::CYAN;
-static const raw_ostream::Color errorColor = raw_ostream::RED;
-static const raw_ostream::Color fatalColor = raw_ostream::RED;
+static const enum raw_ostream::Colors noteColor =
+  raw_ostream::BLACK;
+static const enum raw_ostream::Colors remarkColor =
+  raw_ostream::BLUE;
+static const enum raw_ostream::Colors fixitColor =
+  raw_ostream::GREEN;
+static const enum raw_ostream::Colors caretColor =
+  raw_ostream::GREEN;
+static const enum raw_ostream::Colors warningColor =
+  raw_ostream::MAGENTA;
+static const enum raw_ostream::Colors templateColor =
+  raw_ostream::CYAN;
+static const enum raw_ostream::Colors errorColor = raw_ostream::RED;
+static const enum raw_ostream::Colors fatalColor = raw_ostream::RED;
 // Used for changing only the bold attribute.
-static const raw_ostream::Color savedColor = raw_ostream::SAVEDCOLOR;
+static const enum raw_ostream::Colors savedColor =
+  raw_ostream::SAVEDCOLOR;
 
 /// Add highlights to differences in template strings.
 static void applyTemplateHighlighting(raw_ostream &OS, StringRef Str,

Modified: cfe/trunk/tools/diagtool/TreeView.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/

r367657 - [PGO] Fix bolt failures from r367628

[Rong Xu via cfe-commits]

Author: xur
Date: Fri Aug  2 00:21:50 2019
New Revision: 367657

URL: http://llvm.org/viewvc/llvm-project?rev=367657&view=rev
Log:
[PGO] Fix bolt failures from r367628

Relaxed the check in a test because the windows bolt generates different
profile variables.

Modified:
cfe/trunk/test/Profile/gcc-flag-compatibility.c

Modified: cfe/trunk/test/Profile/gcc-flag-compatibility.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/gcc-flag-compatibility.c?rev=367657&r1=367656&r2=367657&view=diff
==
--- cfe/trunk/test/Profile/gcc-flag-compatibility.c (original)
+++ cfe/trunk/test/Profile/gcc-flag-compatibility.c Fri Aug  2 00:21:50 2019
@@ -9,8 +9,8 @@
 
 // RUN: %clang %s -c -S -o - -emit-llvm -fprofile-generate 
-fno-experimental-new-pass-manager | FileCheck -check-prefix=PROFILE-GEN %s
 // RUN: %clang %s -c -S -o - -emit-llvm -fprofile-generate 
-fexperimental-new-pass-manager | FileCheck -check-prefix=PROFILE-GEN %s
-// PROFILE-GEN: @__profc_main = private global [2 x i64] zeroinitializer, 
section "__llvm_prf_cnts", align 8
-// PROFILE-GEN: @__profd_main = private global
+// PROFILE-GEN: @__profc_main = {{(private|internal)}} global [2 x i64] 
zeroinitializer, section
+// PROFILE-GEN: @__profd_main =
 
 // Check that -fprofile-generate=/path/to generates /path/to/default.profraw
 // RUN: %clang %s -c -S -o - -emit-llvm -fprofile-generate=/path/to 
-fno-experimental-new-pass-manager | FileCheck 
-check-prefixes=PROFILE-GEN,PROFILE-GEN-EQ %s


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

Re: [PATCH] D64029: [PGO] Add PGO support at -O0 in the experimental new pass manager

[Rong Xu via cfe-commits]

r367657 should fix this.

On Fri, Aug 2, 2019 at 12:20 AM Rong Xu  wrote:

> yes. I already know this issue as this also breaks windows bolt.
> The fix should be simple.
>
> -Rong
>
> On Thu, Aug 1, 2019 at 11:52 PM Petr Hosek via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> phosek added a comment.
>>
>> Looks like this change broke `Profile/gcc-flag-compatibility.c` test on
>> macOS:
>>
>>    TEST 'Clang :: Profile/gcc-flag-compatibility.c'
>> FAILED 
>>   Script:
>>   --
>>   : 'RUN: at line 10';
>>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -c -S
>> -o - -emit-llvm -fprofile-generate -fno-experimental-new-pass-manager |
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
>> -check-prefix=PROFILE-GEN
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>>   : 'RUN: at line 11';
>>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -c -S
>> -o - -emit-llvm -fprofile-generate -fexperimental-new-pass-manager |
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
>> -check-prefix=PROFILE-GEN
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>>   : 'RUN: at line 16';
>>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -c -S
>> -o - -emit-llvm -fprofile-generate=/path/to
>> -fno-experimental-new-pass-manager |
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
>> -check-prefixes=PROFILE-GEN,PROFILE-GEN-EQ
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>>   : 'RUN: at line 22';   rm -rf
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir
>>   : 'RUN: at line 23';   mkdir -p
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path
>>   : 'RUN: at line 24';   llvm-profdata merge
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/Inputs/gcc-flag-compatibility.proftext
>> -o
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path/default.profdata
>>   : 'RUN: at line 25';
>>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -o -
>> -Xclang -disable-llvm-passes -emit-llvm -S
>> -fprofile-use=/b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path
>> -fno-experimental-new-pass-manager |
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
>> -check-prefix=PROFILE-USE
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>>   : 'RUN: at line 26';
>>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -o -
>> -Xclang -disable-llvm-passes -emit-llvm -S
>> -fprofile-use=/b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path
>> -fexperimental-new-pass-manager |
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
>> -check-prefix=PROFILE-USE
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>>   : 'RUN: at line 30';   rm -rf
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir
>>   : 'RUN: at line 31';   mkdir -p
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path
>>   : 'RUN: at line 32';   llvm-profdata merge
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/Inputs/gcc-flag-compatibility.proftext
>> -o
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path/file.prof
>>   : 'RUN: at line 33';
>>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -o -
>> -Xclang -disable-llvm-passes -emit-llvm -S
>> -fprofile-use=/b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/tools/clang/test/Profile/Output/gcc-flag-compatibility.c.tmp.dir/some/path/file.prof
>> -fno-experimental-new-pass-manager |
>> /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/FileCheck
>> -check-prefix=PROFILE-USE
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c
>>   : 'RUN: at line 34';
>>  /b/s/w/ir/k/recipe_cleanup/clangOLc9jG/llvm_build_dir/bin/clang
>> /b/s/w/ir/k/llvm-project/clang/test/Profile/gcc-flag-compatibility.c -o -
>> -Xclang -disable-llvm-passes -emit-llvm -S
>> -fprofile-use=

[PATCH] D65577: [ASTImporter] Import default expression of param before creating the param.

[Balázs Kéri via Phabricator via cfe-commits]

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



Comment at: clang/lib/AST/ASTImporter.cpp:3859
   ToTypeSourceInfo, D->getStorageClass(),
   /*DefaultArg*/ nullptr))
 return ToParm;

shafik wrote:
> This should be `DefaultArg` now?
I am not sure if it is always correct, specially in the 
`hasUninstantiatedDefaultArg` case. (The constructor calls `setDefaultArg` 
only, probably this was the reason to set the default arg afterwards in 
different ways that is not doable with the constructor.)



Comment at: clang/test/Analysis/Inputs/ctu-other.cpp:144
+
+int testDefParmIncompleteImport(int I) {
+  return fDefParm(I);

martong wrote:
> `testImportOfIncompleteDefaultParm` ?
The reason for this name was that the import is incomplete, not the the default 
parameter. (Exactly, before the fix, the import results in a `ParmVarDecl` that 
is for temporary time interval incomplete when the default expression is 
missing.) In this way `testIncompleteImportOfDefaultParm` can be better, or 
`testImportWithIncompleteDefaultParm`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65577



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

[PATCH] D64695: [clang-format] Added new style rule: SortNetBSDIncludes

[Manikishan Ghantasala via Phabricator via cfe-commits]

Manikishan updated this revision to Diff 212978.

Repository:
  rC Clang

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

https://reviews.llvm.org/D64695

Files:
  include/clang/Format/Format.h
  include/clang/Tooling/Inclusions/HeaderIncludes.h
  include/clang/Tooling/Inclusions/IncludeStyle.h
  lib/Format/Format.cpp
  lib/Tooling/Inclusions/HeaderIncludes.cpp
  lib/Tooling/Inclusions/IncludeStyle.cpp
  unittests/Format/SortIncludesTest.cpp

Index: unittests/Format/SortIncludesTest.cpp
===
--- unittests/Format/SortIncludesTest.cpp
+++ unittests/Format/SortIncludesTest.cpp
@@ -70,6 +70,79 @@
  {tooling::Range(25, 1)}));
 }
 
+TEST_F(SortIncludesTest, ParamAndTypesCheck) {
+  FmtStyle = getNetBSDStyle();
+  EXPECT_EQ("#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n",
+  sort("#include \n"
+ "#include \n"
+ "#include \n"
+ "#include \n"
+ "#include \n"
+ "#include \n"));
+  
+}
+
+TEST_F(SortIncludesTest, SortedIncludesUsingSortPriorityAttribute) {
+  FmtStyle = getNetBSDStyle();
+  EXPECT_EQ("#include \n"  
+  "#include \n"  
+  "#include \n"  
+  "#include \n" 
+  "#include \n"
+  "#include \n"
+  "\n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "\n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "\n"
+  "#include \n"
+  "\n"
+  "#include \"pathnames.h\"\n",
+  sort("#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"  
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \"pathnames.h\"\n"
+  "#include \n"
+  "#include \n"
+  "#include \n"
+  "#include \n"));
+  
+  FmtStyle = getLLVMStyle();
+  EXPECT_EQ("#include \"FormatTestUtils.h\"\n"
+"#include \"clang/Format/Format.h\"\n"
+"#include \"llvm/ADT/None.h\"\n"
+"#include \"llvm/Support/Debug.h\"\n"
+"#include \"gtest/gtest.h\"\n",
+sort("#include \"clang/Format/Format.h\"\n"
+"#include \"llvm/ADT/None.h\"\n"
+"#include \"FormatTestUtils.h\"\n"
+"#include \"gtest/gtest.h\"\n"
+"#include \"llvm/Support/Debug.h\"\n"));
+}
+
 TEST_F(SortIncludesTest, NoReplacementsForValidIncludes) {
   // Identical #includes have led to a failure with an unstable sort.
   std::string Code = "#include \n"
Index: lib/Tooling/Inclusions/IncludeStyle.cpp
===
--- lib/Tooling/Inclusions/IncludeStyle.cpp
+++ lib/Tooling/Inclusions/IncludeStyle.cpp
@@ -17,6 +17,7 @@
 IO &IO, IncludeStyle::IncludeCategory &Category) {
   IO.mapOptional("Regex", Category.Regex);
   IO.mapOptional("Priority", Category.Priority);
+  IO.mapOptional("SortPriority", Category.SortPriority);
 }
 
 void ScalarEnumerationTraits::enumeration(
Index: lib/Tooling/Inclusions/HeaderIncludes.cpp
===
--- lib/Tooling/Inclusions/HeaderIncludes.cpp
+++ lib/Tooling/Inclusions/HeaderIncludes.cpp
@@ -199,6 +199,19 @@
   return Ret;
 }
 
+int IncludeCategoryManager::getSortIncludePriority(StringRef IncludeName, bool CheckMainHeader) const {
+  int Ret = INT_MAX;
+  for (unsigned i = 0, e = CategoryRegexs.size(); i != e; ++i)
+if (CategoryRegexs[i].match(IncludeName)) {
+  Ret = Style.IncludeCategories[i].SortPriority;
+  if(Ret == 0)
+Ret = Style.IncludeCategories[i].Priority;
+  break;
+}
+  if (CheckMainHeader && IsMainFile && Ret > 0 && isMainHeader(IncludeName))
+Ret = 0;
+  return Ret;
+}
 bool IncludeCategoryManager::isMainHeader(StringRef IncludeName) const {
   if (!IncludeName.startswith("\""))
 return false;
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -1023,6 +1023,39 @@
   return Style;
 }
 
+FormatStyle getNetBSDStyle() {
+  FormatStyle NetBSDStyle = getLLVMStyle();
+  NetBSDStyle.AlignTrailingComments = true;
+  NetBSDStyle.AlwaysBreakAfterReturnType = FormatStyle::RTBS_AllDefinitions;
+  NetBSDStyle.AlignConsecutiveMacros = true;
+  NetBSDStyle.BreakBeforeBraces = FormatStyle::BS_Mozilla;
+  NetBSDStyle.ColumnLimit = 80;
+  NetBSDStyle.ContinuationIndentWidth = 4;
+  NetBSDStyle.Cpp11BracedListStyle = false;
+  NetBSDStyle.FixNamespaceComments = true;
+  NetBSDStyle.IndentCaseLabels = false;
+  NetBSDStyle.IndentWidth = 8;
+  NetBSDStyle.IncludeStyle.IncludeBlocks = t

r367661 - Don't try emitting dllexported explicitly defaulted non-trivial ctors twice during explicit template instantiation definition (PR42857)

[Hans Wennborg via cfe-commits]

Author: hans
Date: Fri Aug  2 00:51:41 2019
New Revision: 367661

URL: http://llvm.org/viewvc/llvm-project?rev=367661&view=rev
Log:
Don't try emitting dllexported explicitly defaulted non-trivial ctors twice 
during explicit template instantiation definition (PR42857)

Trying to emit the definition twice triggers an assert.

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

Modified:
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/CodeGenCXX/dllexport.cpp

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=367661&r1=367660&r2=367661&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Fri Aug  2 00:51:41 2019
@@ -11543,7 +11543,13 @@ void Sema::ActOnFinishCXXNonNestedClass(
 std::swap(DelayedDllExportMemberFunctions, WorkList);
 for (CXXMethodDecl *M : WorkList) {
   DefineImplicitSpecialMember(*this, M, M->getLocation());
-  ActOnFinishInlineFunctionDef(M);
+
+  // Pass the method to the consumer to get emitted. This is not necessary
+  // for explicit instantiation definitions, as they will get emitted
+  // anyway.
+  if (M->getParent()->getTemplateSpecializationKind() !=
+  TSK_ExplicitInstantiationDefinition)
+ActOnFinishInlineFunctionDef(M);
 }
   }
 }

Modified: cfe/trunk/test/CodeGenCXX/dllexport.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/dllexport.cpp?rev=367661&r1=367660&r2=367661&view=diff
==
--- cfe/trunk/test/CodeGenCXX/dllexport.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/dllexport.cpp Fri Aug  2 00:51:41 2019
@@ -860,6 +860,13 @@ struct PR40006 {
 };
 // M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc 
%"struct.InClassInits::PR40006"* @"??0PR40006@InClassInits@@QAE@XZ"
 
+// PR42857: Clang would try to emit the non-trivial explicitly defaulted
+// dllexport ctor twice when doing an explicit instantiation definition.
+struct Qux { Qux(); };
+template  struct PR42857 { __declspec(dllexport) PR42857() = 
default; Qux q; };
+template struct PR42857;
+// M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc 
%"struct.InClassInits::PR42857"* @"??0?$PR42857@H@InClassInits@@QAE@XZ"
+
 }
 
 // We had an issue where instantiating A would force emission of B's delayed


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

[PATCH] D65579: Don't try emitting dllexported explicitly defaulted non-trivial ctors twice during explicit template instantiation definition (PR42857)

[Hans Wennborg via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367661: Don't try emitting dllexported explicitly 
defaulted non-trivial ctors twice… (authored by hans, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65579?vs=212817&id=212980#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65579

Files:
  cfe/trunk/lib/Sema/SemaDeclCXX.cpp
  cfe/trunk/test/CodeGenCXX/dllexport.cpp


Index: cfe/trunk/test/CodeGenCXX/dllexport.cpp
===
--- cfe/trunk/test/CodeGenCXX/dllexport.cpp
+++ cfe/trunk/test/CodeGenCXX/dllexport.cpp
@@ -860,6 +860,13 @@
 };
 // M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc 
%"struct.InClassInits::PR40006"* @"??0PR40006@InClassInits@@QAE@XZ"
 
+// PR42857: Clang would try to emit the non-trivial explicitly defaulted
+// dllexport ctor twice when doing an explicit instantiation definition.
+struct Qux { Qux(); };
+template  struct PR42857 { __declspec(dllexport) PR42857() = 
default; Qux q; };
+template struct PR42857;
+// M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc 
%"struct.InClassInits::PR42857"* @"??0?$PR42857@H@InClassInits@@QAE@XZ"
+
 }
 
 // We had an issue where instantiating A would force emission of B's delayed
Index: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
===
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp
@@ -11543,7 +11543,13 @@
 std::swap(DelayedDllExportMemberFunctions, WorkList);
 for (CXXMethodDecl *M : WorkList) {
   DefineImplicitSpecialMember(*this, M, M->getLocation());
-  ActOnFinishInlineFunctionDef(M);
+
+  // Pass the method to the consumer to get emitted. This is not necessary
+  // for explicit instantiation definitions, as they will get emitted
+  // anyway.
+  if (M->getParent()->getTemplateSpecializationKind() !=
+  TSK_ExplicitInstantiationDefinition)
+ActOnFinishInlineFunctionDef(M);
 }
   }
 }


Index: cfe/trunk/test/CodeGenCXX/dllexport.cpp
===
--- cfe/trunk/test/CodeGenCXX/dllexport.cpp
+++ cfe/trunk/test/CodeGenCXX/dllexport.cpp
@@ -860,6 +860,13 @@
 };
 // M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc %"struct.InClassInits::PR40006"* @"??0PR40006@InClassInits@@QAE@XZ"
 
+// PR42857: Clang would try to emit the non-trivial explicitly defaulted
+// dllexport ctor twice when doing an explicit instantiation definition.
+struct Qux { Qux(); };
+template  struct PR42857 { __declspec(dllexport) PR42857() = default; Qux q; };
+template struct PR42857;
+// M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc %"struct.InClassInits::PR42857"* @"??0?$PR42857@H@InClassInits@@QAE@XZ"
+
 }
 
 // We had an issue where instantiating A would force emission of B's delayed
Index: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
===
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp
@@ -11543,7 +11543,13 @@
 std::swap(DelayedDllExportMemberFunctions, WorkList);
 for (CXXMethodDecl *M : WorkList) {
   DefineImplicitSpecialMember(*this, M, M->getLocation());
-  ActOnFinishInlineFunctionDef(M);
+
+  // Pass the method to the consumer to get emitted. This is not necessary
+  // for explicit instantiation definitions, as they will get emitted
+  // anyway.
+  if (M->getParent()->getTemplateSpecializationKind() !=
+  TSK_ExplicitInstantiationDefinition)
+ActOnFinishInlineFunctionDef(M);
 }
   }
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D48866: [clang-tidy] Add incorrect-pointer-cast checker

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.
Herald added a subscriber: whisperity.

Do you have some time @Szelethus to check this change?
Your experience and comments would help a lot to finish this.


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

https://reviews.llvm.org/D48866



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

[PATCH] D65525: [clangd] Add new helpers to make tweak tests scale better. Convert most tests. NFC

[Sam McCall via Phabricator via cfe-commits]

sammccall updated this revision to Diff 212985.
sammccall marked 9 inline comments as done.
sammccall added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65525

Files:
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/TweakTesting.cpp
  clang-tools-extra/clangd/unittests/TweakTesting.h
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -9,6 +9,7 @@
 #include "Annotations.h"
 #include "SourceCode.h"
 #include "TestTU.h"
+#include "TweakTesting.h"
 #include "refactor/Tweak.h"
 #include "clang/AST/Expr.h"
 #include "clang/Basic/LLVM.h"
@@ -24,11 +25,16 @@
 
 using llvm::Failed;
 using llvm::Succeeded;
+using ::testing::AllOf;
+using ::testing::HasSubstr;
+using ::testing::StartsWith;
 
 namespace clang {
 namespace clangd {
 namespace {
 
+// FIXME(sammccall): migrate the rest of the tests to use TweakTesting.h and
+// remove these helpers.
 std::string markRange(llvm::StringRef Code, Range R) {
   size_t Begin = llvm::cantFail(positionToOffset(Code, R.start));
   size_t End = llvm::cantFail(positionToOffset(Code, R.end));
@@ -114,13 +120,6 @@
   return applyAllReplacements(Code.code(), *Effect->ApplyEdit);
 }
 
-std::string getMessage(StringRef ID, llvm::StringRef Input) {
-  auto Effect = apply(ID, Input);
-  if (!Effect)
-return "error: " + llvm::toString(Effect.takeError());
-  return Effect->ShowMessage.getValueOr("no message produced!");
-}
-
 void checkTransform(llvm::StringRef ID, llvm::StringRef Input,
 std::string Output) {
   auto Result = applyEdit(ID, Input);
@@ -128,148 +127,72 @@
   EXPECT_EQ(Output, std::string(*Result)) << Input;
 }
 
-/// Check if apply returns an error and that the @ErrorMessage is contained
-/// in that error
-void checkApplyContainsError(llvm::StringRef ID, llvm::StringRef Input,
- const std::string& ErrorMessage) {
-  auto Result = apply(ID, Input);
-  ASSERT_FALSE(Result) << "expected error message:\n   " << ErrorMessage <<
-   "\non input:" << Input;
-  EXPECT_THAT(llvm::toString(Result.takeError()),
-  testing::HasSubstr(ErrorMessage))
-  << Input;
-}
-
-TEST(TweakTest, SwapIfBranches) {
-  llvm::StringLiteral ID = "SwapIfBranches";
-
-  checkAvailable(ID, R"cpp(
-void test() {
-  ^i^f^^(^t^r^u^e^) { return 100; } ^e^l^s^e^ { continue; }
-}
-  )cpp");
-
-  checkNotAvailable(ID, R"cpp(
-void test() {
-  if (true) {^return ^100;^ } else { ^continue^;^ }
-}
-  )cpp");
-
-  llvm::StringLiteral Input = R"cpp(
-void test() {
-  ^if (true) { return 100; } else { continue; }
-}
-  )cpp";
-  llvm::StringLiteral Output = R"cpp(
-void test() {
-  if (true) { continue; } else { return 100; }
-}
-  )cpp";
-  checkTransform(ID, Input, Output);
-
-  Input = R"cpp(
-void test() {
-  ^if () { return 100; } else { continue; }
-}
-  )cpp";
-  Output = R"cpp(
-void test() {
-  if () { continue; } else { return 100; }
-}
-  )cpp";
-  checkTransform(ID, Input, Output);
-
-  // Available in subexpressions of the condition.
-  checkAvailable(ID, R"cpp(
-void test() {
-  if(2 + [[2]] + 2) { return 2 + 2 + 2; } else { continue; }
-}
-  )cpp");
+TWEAK_TEST(SwapIfBranches);
+TEST_F(SwapIfBranchesTest, Test) {
+  Context = Function;
+  EXPECT_EQ(apply("^if (true) {return 100;} else {continue;}"),
+"if (true) {continue;} else {return 100;}");
+  EXPECT_EQ(apply("^if () {return 100;} else {continue;}"),
+"if () {continue;} else {return 100;}") << "broken condition";
+  EXPECT_AVAILABLE("^i^f^^(^t^r^u^e^) { return 100; } ^e^l^s^e^ { continue; }");
+  EXPECT_UNAVAILABLE("if (true) {^return ^100;^ } else { ^continue^;^ }");
+  // Available in subexpressions of the condition;
+  EXPECT_THAT("if(2 + [[2]] + 2) { return 2 + 2 + 2; } else {continue;}",
+  isAvailable());
   // But not as part of the branches.
-  checkNotAvailable(ID, R"cpp(
-void test() {
-  if(2 + 2 + 2) { return 2 + [[2]] + 2; } else { continue; }
-}
-  )cpp");
+  EXPECT_THAT("if(2 + 2 + 2) { return 2 + [[2]] + 2; } else { continue; }",
+  Not(isAvailable()));
   // Range covers the "else" token, so available.
-  checkAvailable(ID, R"cpp(
-void test() {
-  if(2 + 2 + 2) { return 2 + [[2 + 2; } else { continue;]] }
-}
-  )cpp");
+  EXPECT_THAT("if(2 + 2 + 2) { return 2 + [[2 + 2; } else {continue;]]}",
+  isAvailable());
   // Not available in compound statements in condition.
-  checkNotAvailable(ID, R"cpp(
-void test() {
-  if([]{return [[true]];}()) { return 2 + 2 + 2; } else { continue; }

[PATCH] D65445: [CrossTU] Handle case when no USR could be generated during Decl search.

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 212986.
balazske added a comment.

Rebase and add a new testing case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65445

Files:
  clang/include/clang/CrossTU/CrossTranslationUnit.h
  clang/lib/CrossTU/CrossTranslationUnit.cpp
  clang/test/Analysis/Inputs/ctu-other.cpp
  clang/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt
  clang/test/Analysis/ctu-main.cpp
  clang/test/Analysis/func-mapping-test.cpp
  clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp

Index: clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp
===
--- clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp
+++ clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp
@@ -76,7 +76,12 @@
 
 void MapExtDefNamesConsumer::addIfInMain(const DeclaratorDecl *DD,
  SourceLocation defStart) {
-  std::string LookupName = CrossTranslationUnitContext::getLookupName(DD);
+  llvm::Optional LookupName =
+  CrossTranslationUnitContext::getLookupName(DD);
+  if (!LookupName)
+return;
+  assert(!LookupName->empty() && "Lookup name should be non-empty.");
+
   if (CurrentFileName.empty()) {
 CurrentFileName =
 SM.getFileEntryForID(SM.getMainFileID())->tryGetRealPathName();
@@ -89,7 +94,7 @@
   case VisibleNoLinkage:
   case UniqueExternalLinkage:
 if (SM.isInMainFile(defStart))
-  Index[LookupName] = CurrentFileName;
+  Index[*LookupName] = CurrentFileName;
 break;
   default:
 break;
Index: clang/test/Analysis/func-mapping-test.cpp
===
--- clang/test/Analysis/func-mapping-test.cpp
+++ clang/test/Analysis/func-mapping-test.cpp
@@ -41,3 +41,10 @@
 };
 U u = {.a = 6};
 // CHECK-DAG: c:@u
+
+// No USR can be generated for this.
+// Check for no crash in this case.
+static union {
+  float uf;
+  const int ui;
+};
Index: clang/test/Analysis/ctu-main.cpp
===
--- clang/test/Analysis/ctu-main.cpp
+++ clang/test/Analysis/ctu-main.cpp
@@ -112,6 +112,19 @@
   clang_analyzer_eval(obj->fvcl(1) == 8);  // expected-warning{{FALSE}} expected-warning{{TRUE}}
 }
 
+class TestAnonUnionUSR {
+public:
+  inline float f(int value) {
+union {
+  float f;
+  int i;
+};
+i = value;
+return f;
+  }
+  static const int Test;
+};
+
 int main() {
   clang_analyzer_eval(f(3) == 2); // expected-warning{{TRUE}}
   clang_analyzer_eval(f(4) == 3); // expected-warning{{TRUE}}
@@ -144,4 +157,5 @@
   clang_analyzer_eval(extSubSCN.a == 1); // expected-warning{{TRUE}}
   // clang_analyzer_eval(extSCC.a == 7); // TODO
   clang_analyzer_eval(extU.a == 4); // expected-warning{{TRUE}}
+  clang_analyzer_eval(TestAnonUnionUSR::Test == 5); // expected-warning{{TRUE}}
 }
Index: clang/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt
===
--- clang/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt
+++ clang/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt
@@ -25,3 +25,4 @@
 c:@extSubSCN ctu-other.cpp.ast
 c:@extSCC ctu-other.cpp.ast
 c:@extU ctu-other.cpp.ast
+c:@S@TestAnonUnionUSR@Test ctu-other.cpp.ast
Index: clang/test/Analysis/Inputs/ctu-other.cpp
===
--- clang/test/Analysis/Inputs/ctu-other.cpp
+++ clang/test/Analysis/Inputs/ctu-other.cpp
@@ -131,3 +131,17 @@
   const unsigned int b;
 };
 U extU = {.a = 4};
+
+class TestAnonUnionUSR {
+public:
+  inline float f(int value) {
+union {
+  float f;
+  int i;
+};
+i = value;
+return f;
+  }
+  static const int Test;
+};
+const int TestAnonUnionUSR::Test = 5;
Index: clang/lib/CrossTU/CrossTranslationUnit.cpp
===
--- clang/lib/CrossTU/CrossTranslationUnit.cpp
+++ clang/lib/CrossTU/CrossTranslationUnit.cpp
@@ -193,12 +193,13 @@
 
 CrossTranslationUnitContext::~CrossTranslationUnitContext() {}
 
-std::string CrossTranslationUnitContext::getLookupName(const NamedDecl *ND) {
+llvm::Optional
+CrossTranslationUnitContext::getLookupName(const NamedDecl *ND) {
   SmallString<128> DeclUSR;
   bool Ret = index::generateUSRForDecl(ND, DeclUSR);
-  (void)Ret;
-  assert(!Ret && "Unable to generate USR");
-  return DeclUSR.str();
+  if (Ret)
+return {};
+  return std::string(DeclUSR.str());
 }
 
 /// Recursively visits the decls of a DeclContext, and returns one with the
@@ -218,7 +219,8 @@
 const T *ResultDecl;
 if (!ND || !hasBodyOrInit(ND, ResultDecl))
   continue;
-if (getLookupName(ResultDecl) != LookupName)
+llvm::Optional ResultLookupName = getLookupName(ResultDecl);
+if (!ResultLookupName || *ResultLookupName != LookupName)
   continue;
 return ResultDecl;
   }
@@ -233,12 +2

[PATCH] D65574: Added hack to prevent toHalfOpenFileRange assertion fail

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/Selection.cpp:373
+if(!Range)
+  return SelectionTree::Unselected;
 dlog("{1}claimRange: {0}", Range->printToString(SM), indent());

This isn't a sufficient fix, there are 5 callsites that don't check for failure.
Adding defenses to each of them is the right thing if we really can't handle 
failure, but today they assume the invariant that if the inputs were from the 
same file id, the output will be valid. Can we really not provide that 
guarantee?



Comment at: clang-tools-extra/clangd/SourceCode.cpp:314
   while (!FileRange.getBegin().isFileID()) {
-assert(!FileRange.getEnd().isFileID() &&
-   "Both Begin and End should be MacroIDs.");
+// FIXME: Investigate when this assert fails. Added a hack until then.
+// assert(!FileRange.getEnd().isFileID() &&

We have a reproducer, why can't we investigate now?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65574



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

[PATCH] D65525: [clangd] Add new helpers to make tweak tests scale better. Convert most tests. NFC

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/unittests/TweakTesting.h:44
+// Snippet is an expression.
+Expression,
+  };

ilya-biryukov wrote:
> I wonder whether we could use `Function` and get rid of 'expression' mode 
> completely? WDYT?
> One can easily turn an expression into a statement by adding a semicolon.
Unsent draft comments here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65525



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

[PATCH] D65637: [clangd] [WIP] Semantic highlighting prototype for the vscode extension.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom created this revision.
jvikstrom added reviewers: hokein, sammccall, ilya-biryukov.
Herald added subscribers: cfe-commits, kadircet, arphaman, jkorous, MaskRay.
Herald added a project: clang.

Contains all the functionality for the highlighting, is going to get cleaned up 
a lot though. Might end up wanting to create a color theme as well, none of the 
default ones are that great with this...


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65637

Files:
  clang-tools-extra/clangd/clients/clangd-vscode/.gitignore
  clang-tools-extra/clangd/clients/clangd-vscode/src/SemanticHighlighting.ts
  clang-tools-extra/clangd/clients/clangd-vscode/src/TextMate.ts
  clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
  clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts

Index: clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
@@ -2,14 +2,30 @@
 import * as assert from 'assert';
 
 import * as vscode from 'vscode';
-import * as myExtension from '../src/extension';
+import {SemanticHighlighting} from '../src/SemanticHighlighting';
 
-// TODO: add tests
 suite("Extension Tests", () => {
-
-// Defines a Mocha unit test
-test("Something 1", () => {
-assert.equal(-1, [1, 2, 3].indexOf(5));
-assert.equal(-1, [1, 2, 3].indexOf(0));
+test('HighlightingCache caches incrementaly', () => {
+const feature = new SemanticHighlighting.Feature();
+const uri = 'file://text';
+feature.handleNotification({
+textDocument: {uri: uri},
+lines: [{
+line: 1,
+tokens: 'BAABAAA=',
+}],
+});
+feature.handleNotification({
+textDocument: {uri: uri},
+lines: [{
+line: 2,
+tokens: 'BAABAAA=',
+}],
+});
+//const tokens = feature.tokenCache.files.get(vscode.Uri.parse(uri).toString()).tokens;
+//assert.deepEqual(tokens.get(1), [{character: 4, length: 1, scope: 0}]);
+//assert.deepEqual(tokens.get(2), [{character: 4, length: 1, scope: 0}]);
+
+
 });
 });
\ No newline at end of file
Index: clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
@@ -1,5 +1,6 @@
 import * as vscode from 'vscode';
 import * as vscodelc from 'vscode-languageclient';
+import { SemanticHighlighting } from './SemanticHighlighting';
 
 /**
  * Method to get workspace configuration option
@@ -12,9 +13,9 @@
 }
 
 namespace SwitchSourceHeaderRequest {
-export const type =
-new vscodelc.RequestType('textDocument/switchSourceHeader');
+export const type =
+new vscodelc.RequestType('textDocument/switchSourceHeader');
 }
 
 class FileStatus {
@@ -32,8 +33,8 @@
 const path = vscode.window.activeTextEditor.document.fileName;
 const status = this.statuses.get(path);
 if (!status) {
-  this.statusBarItem.hide();
-  return;
+this.statusBarItem.hide();
+return;
 }
 this.statusBarItem.text = `clangd: ` + status.state;
 this.statusBarItem.show();
@@ -73,25 +74,30 @@
 // However, VSCode does not have CUDA as a supported language yet, so we
 // cannot add a corresponding activationEvent for CUDA files and clangd will
 // *not* load itself automatically on '.cu' files.
-const cudaFilePattern: string = '**/*.{' +['cu'].join()+ '}';
+const cudaFilePattern: string = '**/*.{' + ['cu'].join() + '}';
 const clientOptions: vscodelc.LanguageClientOptions = {
 // Register the server for c-family and cuda files.
 documentSelector: [
 { scheme: 'file', language: 'c' },
 { scheme: 'file', language: 'cpp' },
-{ scheme: 'file', language: 'objective-c'},
-{ scheme: 'file', language: 'objective-cpp'},
+{ scheme: 'file', language: 'objective-c' },
+{ scheme: 'file', language: 'objective-cpp' },
 { scheme: 'file', pattern: cudaFilePattern },
 ],
 synchronize: !syncFileEvents ? undefined : {
-// FIXME: send sync file events when clangd provides implemenatations.
+// FIXME: send sync file events when clangd provides implemenatations.
 },
 initializationOptions: { clangdFileStatus: true },
 // Do not switch to output window when clangd returns output
 revealOutputChannelOn: vscodelc.RevealOutputChannelOn.Never
 };
 
-const clangdClient = new vscodelc.LanguageClie

[PATCH] D65625: [clangd] Allow the client to specify multiple compilation databases in the 'initialize' request

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a subscriber: sammccall.
ilya-biryukov added a comment.

Could this be handled outside clangd? If not, what are the complications?

We currently have a capability to specify a path to a single 
`compile_commands.json`.
I would expect clients using this extension (Theia?) also handle generation of 
`compile_commands.json`. If that's the case, could they merge multiple 
`compile_commands.json` files into one and ask clangd to load it using APIs we 
have today?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65625



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

[PATCH] D65562: Move LangStandard*, InputKind::Language to Basic

[Rainer Orth via Phabricator via cfe-commits]

ro updated this revision to Diff 212992.
ro marked an inline comment as done.
ro added a comment.

Change Language to enum class.

Tested as before.


Repository:
  rC Clang

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

https://reviews.llvm.org/D65562

Files:
  include/clang/Basic/LangStandard.h
  include/clang/Basic/LangStandards.def
  include/clang/Driver/Options.td
  include/clang/Frontend/CompilerInvocation.h
  include/clang/Frontend/FrontendOptions.h
  include/clang/Frontend/LangStandard.h
  include/clang/Frontend/LangStandards.def
  include/clang/module.modulemap
  lib/Basic/CMakeLists.txt
  lib/Basic/LangStandards.cpp
  lib/CodeGen/CodeGenAction.cpp
  lib/Frontend/ASTUnit.cpp
  lib/Frontend/CMakeLists.txt
  lib/Frontend/CompilerInstance.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Frontend/FrontendAction.cpp
  lib/Frontend/FrontendActions.cpp
  lib/Frontend/FrontendOptions.cpp
  lib/Frontend/LangStandards.cpp
  lib/Frontend/PrecompiledPreamble.cpp
  lib/Frontend/Rewrite/FrontendActions.cpp
  lib/StaticAnalyzer/Frontend/ModelInjector.cpp
  lib/Tooling/InterpolatingCompilationDatabase.cpp
  unittests/Frontend/CodeGenActionTest.cpp
  unittests/Frontend/FrontendActionTest.cpp
  unittests/Frontend/OutputStreamTest.cpp

Index: unittests/Frontend/OutputStreamTest.cpp
===
--- unittests/Frontend/OutputStreamTest.cpp
+++ unittests/Frontend/OutputStreamTest.cpp
@@ -6,6 +6,7 @@
 //
 //===--===//
 
+#include "clang/Basic/LangStandard.h"
 #include "clang/CodeGen/BackendUtil.h"
 #include "clang/CodeGen/CodeGenAction.h"
 #include "clang/Frontend/CompilerInstance.h"
@@ -24,7 +25,7 @@
   Invocation->getPreprocessorOpts().addRemappedFile(
   "test.cc", MemoryBuffer::getMemBuffer("").release());
   Invocation->getFrontendOpts().Inputs.push_back(
-  FrontendInputFile("test.cc", InputKind::CXX));
+  FrontendInputFile("test.cc", Language::CXX));
   Invocation->getFrontendOpts().ProgramAction = EmitBC;
   Invocation->getTargetOpts().Triple = "i386-unknown-linux-gnu";
   CompilerInstance Compiler;
Index: unittests/Frontend/FrontendActionTest.cpp
===
--- unittests/Frontend/FrontendActionTest.cpp
+++ unittests/Frontend/FrontendActionTest.cpp
@@ -10,6 +10,7 @@
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/Basic/LangStandard.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Frontend/FrontendActions.h"
@@ -84,7 +85,7 @@
   "test.cc",
   MemoryBuffer::getMemBuffer("int main() { float x; }").release());
   invocation->getFrontendOpts().Inputs.push_back(
-  FrontendInputFile("test.cc", InputKind::CXX));
+  FrontendInputFile("test.cc", Language::CXX));
   invocation->getFrontendOpts().ProgramAction = frontend::ParseSyntaxOnly;
   invocation->getTargetOpts().Triple = "i386-unknown-linux-gnu";
   CompilerInstance compiler;
@@ -104,7 +105,7 @@
   "test.cc",
   MemoryBuffer::getMemBuffer("int main() { float x; }").release());
   invocation->getFrontendOpts().Inputs.push_back(
-  FrontendInputFile("test.cc", InputKind::CXX));
+  FrontendInputFile("test.cc", Language::CXX));
   invocation->getFrontendOpts().ProgramAction = frontend::ParseSyntaxOnly;
   invocation->getTargetOpts().Triple = "i386-unknown-linux-gnu";
   CompilerInstance compiler;
@@ -131,7 +132,7 @@
   "};\n"
   "B c() { return B(); }\n").release());
   invocation->getFrontendOpts().Inputs.push_back(
-  FrontendInputFile("test.cc", InputKind::CXX));
+  FrontendInputFile("test.cc", Language::CXX));
   invocation->getFrontendOpts().ProgramAction = frontend::ParseSyntaxOnly;
   invocation->getTargetOpts().Triple = "i386-unknown-linux-gnu";
   CompilerInstance compiler;
@@ -177,7 +178,7 @@
   "test.cc",
   MemoryBuffer::getMemBuffer("int main() { float x; }").release());
   Invocation->getFrontendOpts().Inputs.push_back(
-  FrontendInputFile("test.cc", InputKind::CXX));
+  FrontendInputFile("test.cc", Language::CXX));
   Invocation->getFrontendOpts().ProgramAction = frontend::ParseSyntaxOnly;
   Invocation->getTargetOpts().Triple = "i386-unknown-linux-gnu";
   CompilerInstance Compiler;
@@ -238,7 +239,7 @@
 "int main() { foo(); }")
  .release());
   Invocation->getFrontendOpts().Inputs.push_back(
-  FrontendInputFile("test.cc", InputKind::CXX));
+  FrontendInputFile("test.cc", Language::CXX));
   Invocation->getFrontendOpts().ProgramAction = frontend::ParseSyntaxOnly;
   Invocation->getTargetOpts().Triple = "i386-unknown-linux-gnu";
   CompilerInstance Compiler;
@@ -270,7 +271,7 @@
 "test.h",
 MemoryBuffer::getMemBuffer("int foo(void) { return 1; }\n").re

[PATCH] D65562: Move LangStandard*, InputKind::Language to Basic

[Rainer Orth via Phabricator via cfe-commits]

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



Comment at: include/clang/Basic/LangStandard.h:19
+/// standard and possible actions.
+enum Language {
+  Unknown,

rnk wrote:
> Is it feasible to make this an `enum class`? I'm worried about namespace 
> clashes on these otherwise very short names, like C, CXX, HIP, etc. It should 
> be straightforward and mechanical to replace most existing instances of 
> `InputKind::` with `Language::`. It would also remove the need to make an 
> exception for `LF_OpenCL`.
That works perfectly indeed, and is way clearer than my hack
with LF_OpenCL.

There's only one downside: I had to change InputKind.Lang
from a 4-bit bitfield to Language, otherwise neither assignment
nor comparison would work.  No idea if that's really a problem.


Repository:
  rC Clang

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

https://reviews.llvm.org/D65562



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

[PATCH] D64793: [Driver] Properly use values-X[ca].o, values-xpg[46].o on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro updated this revision to Diff 212993.
ro added a comment.

Account for enum class Language change in D65562 
.

Tested as before.


Repository:
  rC Clang

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

https://reviews.llvm.org/D64793

Files:
  lib/Driver/ToolChains/Solaris.cpp
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/values-Xa.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/values-Xc.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/values-xpg4.o
  test/Driver/Inputs/solaris_sparc_tree/usr/lib/values-xpg6.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/values-Xa.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/values-Xc.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/values-xpg4.o
  test/Driver/Inputs/solaris_x86_tree/usr/lib/values-xpg6.o
  test/Driver/solaris-ld-values.c
  test/Driver/solaris-ld-values.cpp

Index: test/Driver/solaris-ld-values.cpp
===
--- /dev/null
+++ test/Driver/solaris-ld-values.cpp
@@ -0,0 +1,45 @@
+// General tests that the correct versions of values-*.o are used on
+// Solaris targets sane. Note that we use sysroot to make these tests
+// independent of the host system.
+
+// Check sparc-sun-solaris2.11, 32bit
+// RUN: %clang -no-canonical-prefixes -ansi %s -### -o %t.o 2>&1 \
+// RUN: --target=sparc-sun-solaris2.11 \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32-ANSI %s
+// CHECK-LD-SPARC32-ANSI: values-Xc.o
+// CHECK-LD-SPARC32-ANSI: values-xpg6.o
+
+// RUN: %clang -no-canonical-prefixes -std=c++98 %s -### -o %t.o 2>&1 \
+// RUN: --target=sparc-sun-solaris2.11 \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32-CPP98 %s
+// CHECK-LD-SPARC32-CPP98: values-Xc.o
+// CHECK-LD-SPARC32-CPP98: values-xpg6.o
+
+// RUN: %clang -no-canonical-prefixes -std=c++11 %s -### -o %t.o 2>&1 \
+// RUN: --target=sparc-sun-solaris2.11 \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32-CPP11 %s
+// CHECK-LD-SPARC32-CPP11: values-Xc.o
+// CHECK-LD-SPARC32-CPP11: values-xpg6.o
+
+// RUN: %clang -no-canonical-prefixes -std=gnu++98 %s -### -o %t.o 2>&1 \
+// RUN: --target=sparc-sun-solaris2.11 \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32-GNUPP98 %s
+// CHECK-LD-SPARC32-GNUPP98: values-Xa.o
+// CHECK-LD-SPARC32-GNUPP98: values-xpg6.o
+
+// Check i386-pc-solaris2.11, 32bit
+// RUN: %clang -no-canonical-prefixes -ANSI %s -### -o %t.o 2>&1 \
+// RUN: --target=i386-pc-solaris2.11 \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/solaris_x86_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-X32-ANSI %s
+// CHECK-LD-X32-ANSI: values-Xa.o
+// CHECK-LD-X32-ANSI: values-xpg6.o
Index: test/Driver/solaris-ld-values.c
===
--- /dev/null
+++ test/Driver/solaris-ld-values.c
@@ -0,0 +1,77 @@
+// General tests that the correct versions of values-*.o are used on
+// Solaris targets sane. Note that we use sysroot to make these tests
+// independent of the host system.
+
+// Check sparc-sun-solaris2.11, 32bit
+// RUN: %clang -no-canonical-prefixes -ansi %s -### -o %t.o 2>&1 \
+// RUN: --target=sparc-sun-solaris2.11 \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32-ANSI %s
+// CHECK-LD-SPARC32-ANSI: values-Xc.o
+// CHECK-LD-SPARC32-ANSI: values-xpg6.o
+
+// RUN: %clang -no-canonical-prefixes -std=c89 %s -### -o %t.o 2>&1 \
+// RUN: --target=sparc-sun-solaris2.11 \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32-C89 %s
+// CHECK-LD-SPARC32-C89: values-Xc.o
+// CHECK-LD-SPARC32-C89: values-xpg4.o
+
+// RUN: %clang -no-canonical-prefixes -std=c90 %s -### -o %t.o 2>&1 \
+// RUN: --target=sparc-sun-solaris2.11 \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32-C90 %s
+// CHECK-LD-SPARC32-C90: values-Xc.o
+// CHECK-LD-SPARC32-C90: values-xpg4.o
+
+// RUN: %clang -no-canonical-prefixes -std=iso9899:199409 %s -### -o %t.o 2>&1 \
+// RUN: --target=sparc-sun-solaris2.11 \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/solaris_sparc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-SPARC32-C94 %s
+// CHECK-LD-SPARC32-C94: values-Xc.o
+// CHECK-LD-SPARC32-C94: values-xpg4.o
+
+// RUN: %clang -no-canonical-prefixes -std=c11 %s -### -o %t.o 2>&1 \
+// RUN: --target=sparc-sun-solaris2.11 \
+// RUN: --gcc-toolc

[PATCH] D65525: [clangd] Add new helpers to make tweak tests scale better. Convert most tests. NFC

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/unittests/TweakTesting.cpp:74
+return true;
+  llvm::consumeError(PrepareResult.takeError());
+  return false;

ilya-biryukov wrote:
> Maybe print the input in case of failure?
This is a matcher against the input, so gtest will always print it.



Comment at: clang-tools-extra/clangd/unittests/TweakTesting.h:44
+// Snippet is an expression.
+Expression,
+  };

ilya-biryukov wrote:
> I wonder whether we could use `Function` and get rid of 'expression' mode 
> completely? WDYT?
> One can easily turn an expression into a statement by adding a semicolon.
We could, but I think it obfuscates intent a little bit, and doesn't really 
simplify anything (we're already paying for the function wrapping logic, adding 
a couple more strings is ~free)



Comment at: clang-tools-extra/clangd/unittests/TweakTesting.h:86
+  for (const auto &Case : expandCases(MarkedCode)) 
\
+  EXPECT_THAT(Case, isAvailable())
+

ilya-biryukov wrote:
> ilya-biryukov wrote:
> > NIT: add a level of indent
> NIT: fully-qualify in a macro `::clang::clangd::TweakTest::isAvailable()`
Indentation is clang-format's fault. Wrapped it in the do-while-0 to fix


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65525



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

[PATCH] D65525: [clangd] Add new helpers to make tweak tests scale better. Convert most tests. NFC

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65525



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

[clang-tools-extra] r367667 - [clangd] Add new helpers to make tweak tests scale better. Convert most tests. NFC

[Sam McCall via cfe-commits]

Author: sammccall
Date: Fri Aug  2 02:12:39 2019
New Revision: 367667

URL: http://llvm.org/viewvc/llvm-project?rev=367667&view=rev
Log:
[clangd] Add new helpers to make tweak tests scale better. Convert most tests. 
NFC

Summary:
TweakTests.cpp has some pretty good helpers added for the first few
tweaks, but they have some limitations:
 - many assertion failures point at the wrong line
 - need lots of input/output tests, setup code is duplicated across both
 - local helpers make it hard to split the file as it grows

The new helpers in TweakTests.h are based on old ones (same operations)
but try to address these issues and generally make tests more terse
while improving error messages.

This patch converts everything except ExtractVariable (which is complex
and has changes in flight, so will be converted later).
It's LOC-neutral, despite not being able to get rid of the old helpers
until ExtractVariable is done.

Reviewers: ilya-biryukov

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

Tags: #clang

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

Added:
clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp
clang-tools-extra/trunk/clangd/unittests/TweakTesting.h
Modified:
clang-tools-extra/trunk/clangd/unittests/CMakeLists.txt
clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp

Modified: clang-tools-extra/trunk/clangd/unittests/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/CMakeLists.txt?rev=367667&r1=367666&r2=367667&view=diff
==
--- clang-tools-extra/trunk/clangd/unittests/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/unittests/CMakeLists.txt Fri Aug  2 02:12:39 
2019
@@ -68,6 +68,7 @@ add_unittest(ClangdUnitTests ClangdTests
   TraceTests.cpp
   TypeHierarchyTests.cpp
   TweakTests.cpp
+  TweakTesting.cpp
   URITests.cpp
   XRefsTests.cpp
 

Added: clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp?rev=367667&view=auto
==
--- clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp (added)
+++ clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp Fri Aug  2 
02:12:39 2019
@@ -0,0 +1,132 @@
+//===-- TweakTesting.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 "TweakTesting.h"
+
+#include "Annotations.h"
+#include "refactor/Tweak.h"
+#include "SourceCode.h"
+#include "clang/Tooling/Core/Replacement.h"
+#include "llvm/Support/Error.h"
+
+namespace clang {
+namespace clangd {
+namespace {
+using Context = TweakTest::CodeContext;
+
+std::pair wrapping(Context Ctx) {
+  switch (Ctx) {
+case TweakTest::File:
+  return {"",""};
+case TweakTest::Function:
+  return {"void wrapperFunction(){\n", "\n}"};
+case TweakTest::Expression:
+  return {"auto expressionWrapper(){return\n", "\n;}"};
+  }
+}
+
+std::string wrap(Context Ctx, llvm::StringRef Inner) {
+  auto Wrapping = wrapping(Ctx);
+  return (Wrapping.first + Inner + Wrapping.second).str();
+}
+
+llvm::StringRef unwrap(Context Ctx, llvm::StringRef Outer) {
+  auto Wrapping = wrapping(Ctx);
+  // Unwrap only if the code matches the expected wrapping.
+  // Don't allow the begin/end wrapping to overlap!
+  if (Outer.startswith(Wrapping.first) && Outer.endswith(Wrapping.second) &&
+  Outer.size() >= Wrapping.first.size() + Wrapping.second.size())
+return 
Outer.drop_front(Wrapping.first.size()).drop_back(Wrapping.second.size());
+  return Outer;
+}
+
+std::pair rangeOrPoint(const Annotations &A) {
+  Range SelectionRng;
+  if (A.points().size() != 0) {
+assert(A.ranges().size() == 0 &&
+   "both a cursor point and a selection range were specified");
+SelectionRng = Range{A.point(), A.point()};
+  } else {
+SelectionRng = A.range();
+  }
+  return {cantFail(positionToOffset(A.code(), SelectionRng.start)),
+  cantFail(positionToOffset(A.code(), SelectionRng.end))};
+}
+
+MATCHER_P3(TweakIsAvailable, TweakID, Ctx, Header,
+   (TweakID + (negation ? " is unavailable" : " is available")).str()) 
{
+  std::string WrappedCode = wrap(Ctx, arg);
+  Annotations Input(WrappedCode);
+  auto Selection = rangeOrPoint(Input);
+  TestTU TU;
+  TU.HeaderCode = Header;
+  TU.Code = Input.code();
+  ParsedAST AST = TU.build();
+  Tweak::Selection S(AST, Selection.first, Selection.second);
+  auto PrepareResult = prepareTweak(TweakID, S);
+  if (PrepareResult)
+return true;
+  llvm::consumeError(PrepareResult.takeErr

[PATCH] D65525: [clangd] Add new helpers to make tweak tests scale better. Convert most tests. NFC

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367667: [clangd] Add new helpers to make tweak tests scale 
better. Convert most tests. (authored by sammccall, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65525?vs=212985&id=212998#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65525

Files:
  clang-tools-extra/trunk/clangd/unittests/CMakeLists.txt
  clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp
  clang-tools-extra/trunk/clangd/unittests/TweakTesting.h
  clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp
@@ -9,6 +9,7 @@
 #include "Annotations.h"
 #include "SourceCode.h"
 #include "TestTU.h"
+#include "TweakTesting.h"
 #include "refactor/Tweak.h"
 #include "clang/AST/Expr.h"
 #include "clang/Basic/LLVM.h"
@@ -24,11 +25,16 @@
 
 using llvm::Failed;
 using llvm::Succeeded;
+using ::testing::AllOf;
+using ::testing::HasSubstr;
+using ::testing::StartsWith;
 
 namespace clang {
 namespace clangd {
 namespace {
 
+// FIXME(sammccall): migrate the rest of the tests to use TweakTesting.h and
+// remove these helpers.
 std::string markRange(llvm::StringRef Code, Range R) {
   size_t Begin = llvm::cantFail(positionToOffset(Code, R.start));
   size_t End = llvm::cantFail(positionToOffset(Code, R.end));
@@ -114,13 +120,6 @@
   return applyAllReplacements(Code.code(), *Effect->ApplyEdit);
 }
 
-std::string getMessage(StringRef ID, llvm::StringRef Input) {
-  auto Effect = apply(ID, Input);
-  if (!Effect)
-return "error: " + llvm::toString(Effect.takeError());
-  return Effect->ShowMessage.getValueOr("no message produced!");
-}
-
 void checkTransform(llvm::StringRef ID, llvm::StringRef Input,
 std::string Output) {
   auto Result = applyEdit(ID, Input);
@@ -128,148 +127,72 @@
   EXPECT_EQ(Output, std::string(*Result)) << Input;
 }
 
-/// Check if apply returns an error and that the @ErrorMessage is contained
-/// in that error
-void checkApplyContainsError(llvm::StringRef ID, llvm::StringRef Input,
- const std::string& ErrorMessage) {
-  auto Result = apply(ID, Input);
-  ASSERT_FALSE(Result) << "expected error message:\n   " << ErrorMessage <<
-   "\non input:" << Input;
-  EXPECT_THAT(llvm::toString(Result.takeError()),
-  testing::HasSubstr(ErrorMessage))
-  << Input;
-}
-
-TEST(TweakTest, SwapIfBranches) {
-  llvm::StringLiteral ID = "SwapIfBranches";
-
-  checkAvailable(ID, R"cpp(
-void test() {
-  ^i^f^^(^t^r^u^e^) { return 100; } ^e^l^s^e^ { continue; }
-}
-  )cpp");
-
-  checkNotAvailable(ID, R"cpp(
-void test() {
-  if (true) {^return ^100;^ } else { ^continue^;^ }
-}
-  )cpp");
-
-  llvm::StringLiteral Input = R"cpp(
-void test() {
-  ^if (true) { return 100; } else { continue; }
-}
-  )cpp";
-  llvm::StringLiteral Output = R"cpp(
-void test() {
-  if (true) { continue; } else { return 100; }
-}
-  )cpp";
-  checkTransform(ID, Input, Output);
-
-  Input = R"cpp(
-void test() {
-  ^if () { return 100; } else { continue; }
-}
-  )cpp";
-  Output = R"cpp(
-void test() {
-  if () { continue; } else { return 100; }
-}
-  )cpp";
-  checkTransform(ID, Input, Output);
-
-  // Available in subexpressions of the condition.
-  checkAvailable(ID, R"cpp(
-void test() {
-  if(2 + [[2]] + 2) { return 2 + 2 + 2; } else { continue; }
-}
-  )cpp");
+TWEAK_TEST(SwapIfBranches);
+TEST_F(SwapIfBranchesTest, Test) {
+  Context = Function;
+  EXPECT_EQ(apply("^if (true) {return 100;} else {continue;}"),
+"if (true) {continue;} else {return 100;}");
+  EXPECT_EQ(apply("^if () {return 100;} else {continue;}"),
+"if () {continue;} else {return 100;}") << "broken condition";
+  EXPECT_AVAILABLE("^i^f^^(^t^r^u^e^) { return 100; } ^e^l^s^e^ { continue; }");
+  EXPECT_UNAVAILABLE("if (true) {^return ^100;^ } else { ^continue^;^ }");
+  // Available in subexpressions of the condition;
+  EXPECT_THAT("if(2 + [[2]] + 2) { return 2 + 2 + 2; } else {continue;}",
+  isAvailable());
   // But not as part of the branches.
-  checkNotAvailable(ID, R"cpp(
-void test() {
-  if(2 + 2 + 2) { return 2 + [[2]] + 2; } else { continue; }
-}
-  )cpp");
+  EXPECT_THAT("if(2 + 2 + 2) { return 2 + [[2]] + 2; } else { continue; }",
+  Not(isAvailable()));
   // Range covers the "else" token, so available.
-  checkAvailable(ID, R"cpp(
-void test() {
-  if(2 + 2 + 2) { return 2 + [[2 + 2; } else { continue;]] }
-}
-  )cpp");
+  EXPECT_THAT("if(2 + 2 

[PATCH] D48357: [RISCV] Remove duplicated logic when determining the target ABI

[Sam Elliott via Phabricator via cfe-commits]

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

Ok, sure! I think I'm happy for this to land then.


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

https://reviews.llvm.org/D48357



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

[clang-tools-extra] r367672 - [clangd] Remove bad assert: nothing relies on it, and the reasons it was true no longer hold.

[Sam McCall via cfe-commits]

Author: sammccall
Date: Fri Aug  2 03:39:46 2019
New Revision: 367672

URL: http://llvm.org/viewvc/llvm-project?rev=367672&view=rev
Log:
[clangd] Remove bad assert: nothing relies on it, and the reasons it was true 
no longer hold.

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

Modified: clang-tools-extra/trunk/clangd/XRefs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/XRefs.cpp?rev=367672&r1=367671&r2=367672&view=diff
==
--- clang-tools-extra/trunk/clangd/XRefs.cpp (original)
+++ clang-tools-extra/trunk/clangd/XRefs.cpp Fri Aug  2 03:39:46 2019
@@ -208,10 +208,8 @@ public:
 
 private:
   void finish() override {
-if (auto DefinedMacro = locateMacroAt(SearchedLocation, PP)) {
+if (auto DefinedMacro = locateMacroAt(SearchedLocation, PP))
   MacroInfos.push_back(*DefinedMacro);
-  assert(Decls.empty());
-}
   }
 };
 
@@ -438,6 +436,7 @@ std::vector findDocum
   const SourceManager &SM = AST.getSourceManager();
   auto Symbols = getSymbolAtPosition(
   AST, getBeginningOfIdentifier(AST, Pos, SM.getMainFileID()));
+  // FIXME: show references to macro within file?
   auto References = findRefs(Symbols.Decls, AST);
 
   std::vector Result;


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

[PATCH] D65637: [clangd] [WIP] Semantic highlighting prototype for the vscode extension.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom updated this revision to Diff 213011.
jvikstrom added a comment.

Readded guard against rules without scopes that somehow disappeared.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65637

Files:
  clang-tools-extra/clangd/clients/clangd-vscode/.gitignore
  clang-tools-extra/clangd/clients/clangd-vscode/src/SemanticHighlighting.ts
  clang-tools-extra/clangd/clients/clangd-vscode/src/TextMate.ts
  clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
  clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts

Index: clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
@@ -2,14 +2,30 @@
 import * as assert from 'assert';
 
 import * as vscode from 'vscode';
-import * as myExtension from '../src/extension';
+import {SemanticHighlighting} from '../src/SemanticHighlighting';
 
-// TODO: add tests
 suite("Extension Tests", () => {
-
-// Defines a Mocha unit test
-test("Something 1", () => {
-assert.equal(-1, [1, 2, 3].indexOf(5));
-assert.equal(-1, [1, 2, 3].indexOf(0));
+test('HighlightingCache caches incrementaly', () => {
+const feature = new SemanticHighlighting.Feature();
+const uri = 'file://text';
+feature.handleNotification({
+textDocument: {uri: uri},
+lines: [{
+line: 1,
+tokens: 'BAABAAA=',
+}],
+});
+feature.handleNotification({
+textDocument: {uri: uri},
+lines: [{
+line: 2,
+tokens: 'BAABAAA=',
+}],
+});
+//const tokens = feature.tokenCache.files.get(vscode.Uri.parse(uri).toString()).tokens;
+//assert.deepEqual(tokens.get(1), [{character: 4, length: 1, scope: 0}]);
+//assert.deepEqual(tokens.get(2), [{character: 4, length: 1, scope: 0}]);
+
+
 });
 });
\ No newline at end of file
Index: clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
@@ -1,5 +1,6 @@
 import * as vscode from 'vscode';
 import * as vscodelc from 'vscode-languageclient';
+import { SemanticHighlighting } from './SemanticHighlighting';
 
 /**
  * Method to get workspace configuration option
@@ -12,9 +13,9 @@
 }
 
 namespace SwitchSourceHeaderRequest {
-export const type =
-new vscodelc.RequestType('textDocument/switchSourceHeader');
+export const type =
+new vscodelc.RequestType('textDocument/switchSourceHeader');
 }
 
 class FileStatus {
@@ -32,8 +33,8 @@
 const path = vscode.window.activeTextEditor.document.fileName;
 const status = this.statuses.get(path);
 if (!status) {
-  this.statusBarItem.hide();
-  return;
+this.statusBarItem.hide();
+return;
 }
 this.statusBarItem.text = `clangd: ` + status.state;
 this.statusBarItem.show();
@@ -73,25 +74,30 @@
 // However, VSCode does not have CUDA as a supported language yet, so we
 // cannot add a corresponding activationEvent for CUDA files and clangd will
 // *not* load itself automatically on '.cu' files.
-const cudaFilePattern: string = '**/*.{' +['cu'].join()+ '}';
+const cudaFilePattern: string = '**/*.{' + ['cu'].join() + '}';
 const clientOptions: vscodelc.LanguageClientOptions = {
 // Register the server for c-family and cuda files.
 documentSelector: [
 { scheme: 'file', language: 'c' },
 { scheme: 'file', language: 'cpp' },
-{ scheme: 'file', language: 'objective-c'},
-{ scheme: 'file', language: 'objective-cpp'},
+{ scheme: 'file', language: 'objective-c' },
+{ scheme: 'file', language: 'objective-cpp' },
 { scheme: 'file', pattern: cudaFilePattern },
 ],
 synchronize: !syncFileEvents ? undefined : {
-// FIXME: send sync file events when clangd provides implemenatations.
+// FIXME: send sync file events when clangd provides implemenatations.
 },
 initializationOptions: { clangdFileStatus: true },
 // Do not switch to output window when clangd returns output
 revealOutputChannelOn: vscodelc.RevealOutputChannelOn.Never
 };
 
-const clangdClient = new vscodelc.LanguageClient('Clang Language Server',serverOptions, clientOptions);
+const clangdClient = new vscodelc.LanguageClient('Clang Language Server', serverOptions, clientOptions);
+const semanticHighligh

[PATCH] D65574: Added hack to prevent toHalfOpenFileRange assertion fail

[Shaurya Gupta via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/SourceCode.cpp:314
   while (!FileRange.getBegin().isFileID()) {
-assert(!FileRange.getEnd().isFileID() &&
-   "Both Begin and End should be MacroIDs.");
+// FIXME: Investigate when this assert fails. Added a hack until then.
+// assert(!FileRange.getEnd().isFileID() &&

sammccall wrote:
> We have a reproducer, why can't we investigate now?
Doing that. Just wanted to stop the crashes in the meanwhile.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65574



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

r367675 - [OpenCL] Allow OpenCL C style vector initialization in C++

[Anastasia Stulova via cfe-commits]

Author: stulova
Date: Fri Aug  2 04:19:35 2019
New Revision: 367675

URL: http://llvm.org/viewvc/llvm-project?rev=367675&view=rev
Log:
[OpenCL] Allow OpenCL C style vector initialization in C++

Allow creating vector literals from other vectors.

 float4 a = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
 float4 v = (float4)(a.s23, a.s01);

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


Removed:
cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl
cfe/trunk/test/SemaOpenCL/vector_literals_const.cl
Modified:
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
cfe/trunk/test/SemaCXX/vector.cpp

Modified: cfe/trunk/lib/Sema/SemaInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=367675&r1=367674&r2=367675&view=diff
==
--- cfe/trunk/lib/Sema/SemaInit.cpp (original)
+++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Aug  2 04:19:35 2019
@@ -1289,7 +1289,16 @@ void InitListChecker::CheckSubElementTyp
 // FIXME: Better EqualLoc?
 InitializationKind Kind =
 InitializationKind::CreateCopy(expr->getBeginLoc(), SourceLocation());
-InitializationSequence Seq(SemaRef, Entity, Kind, expr,
+
+// Vector elements can be initialized from other vectors in which case
+// we need initialization entity with a type of a vector (and not a vector
+// element!) initializing multiple vector elements.
+auto TmpEntity =
+(ElemType->isExtVectorType() && !Entity.getType()->isExtVectorType())
+? InitializedEntity::InitializeTemporary(ElemType)
+: Entity;
+
+InitializationSequence Seq(SemaRef, TmpEntity, Kind, expr,
/*TopLevelOfInitList*/ true);
 
 // C++14 [dcl.init.aggr]p13:
@@ -1300,8 +1309,7 @@ void InitListChecker::CheckSubElementTyp
 // assignment-expression.
 if (Seq || isa(expr)) {
   if (!VerifyOnly) {
-ExprResult Result =
-  Seq.Perform(SemaRef, Entity, Kind, expr);
+ExprResult Result = Seq.Perform(SemaRef, TmpEntity, Kind, expr);
 if (Result.isInvalid())
   hadError = true;
 

Removed: cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl?rev=367674&view=auto
==
--- cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl (original)
+++ cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl (removed)
@@ -1,23 +0,0 @@
-// RUN: %clang_cc1 %s -emit-llvm -O3 -o - | FileCheck %s
-
-typedef int int2 __attribute((ext_vector_type(2)));
-typedef int int4 __attribute((ext_vector_type(4)));
-
-__constant const int4 itest1 = (int4)(1, 2, ((int2)(3, 4)));
-// CHECK: constant <4 x i32> 
-__constant const int4 itest2 = (int4)(1, 2, ((int2)(3)));
-// CHECK: constant <4 x i32> 
-
-typedef float float2 __attribute((ext_vector_type(2)));
-typedef float float4 __attribute((ext_vector_type(4)));
-
-void ftest1(float4 *p) {
-  *p = (float4)(1.1f, 1.2f, ((float2)(1.3f, 1.4f)));
-// CHECK: store <4 x float> 
-}
-
-float4 ftest2(float4 *p) {
-   *p =  (float4)(1.1f, 1.2f, ((float2)(1.3f)));
-// CHECK: store <4 x float> 
-}
-

Modified: cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl?rev=367675&r1=367674&r2=367675&view=diff
==
--- cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl (original)
+++ cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl Fri Aug  2 04:19:35 
2019
@@ -1,22 +1,65 @@
-// RUN: %clang_cc1 -emit-llvm %s -o %t
+// RUN: %clang_cc1 -emit-llvm %s -o - -O0 | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm %s -o - -cl-std=clc++ -O0 | FileCheck %s
 
-typedef __attribute__(( ext_vector_type(2) ))  int int2;
-typedef __attribute__(( ext_vector_type(3) ))  int int3;
-typedef __attribute__(( ext_vector_type(4) ))  int int4;
-typedef __attribute__(( ext_vector_type(8) ))  int int8;
-typedef __attribute__(( ext_vector_type(4) ))  float float4;
+typedef __attribute__((ext_vector_type(2))) int int2;
+typedef __attribute__((ext_vector_type(3))) int int3;
+typedef __attribute__((ext_vector_type(4)))  int int4;
+typedef __attribute__((ext_vector_type(8)))  int int8;
+typedef __attribute__((ext_vector_type(4))) float float4;
+
+__constant const int4 c1 = (int4)(1, 2, ((int2)(3)));
+// CHECK: constant <4 x i32> 
+
+__constant const int4 c2 = (int4)(1, 2, ((int2)(3, 4)));
+// CHECK: constant <4 x i32> 
 
 void vector_literals_valid() {
-  int4 a_1_1_1_1 = (int4)(1,2,3,4);
-  int4 a_2_1_1 = (int4)((int2)(1,2),3,4);
-  int4 a_1_2_1 = (int4)(1,(int2)(2,3),4);
-  int4 a_1_1_2 = (int4)(1,2,(int2)(3,4));
-  int4 a_2_2 = (int4)((int2)(1,2),(int2)(3,4));
-  int4 a_3_1 = (int4)((int3)(1,2,3),4);
-  int4 a_1_3 = 

[PATCH] D65286: [OpenCL] Allow OpenCL C style vector initialization in C++

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367675: [OpenCL] Allow OpenCL C style vector initialization 
in C++ (authored by stulova, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65286?vs=212358&id=213012#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65286

Files:
  cfe/trunk/lib/Sema/SemaInit.cpp
  cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl
  cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
  cfe/trunk/test/SemaCXX/vector.cpp
  cfe/trunk/test/SemaOpenCL/vector_literals_const.cl

Index: cfe/trunk/test/SemaCXX/vector.cpp
===
--- cfe/trunk/test/SemaCXX/vector.cpp
+++ cfe/trunk/test/SemaCXX/vector.cpp
@@ -334,3 +334,11 @@
 }
 
 } // namespace Templates
+
+typedef int inte2 __attribute__((__ext_vector_type__(2)));
+
+void test_vector_literal(inte4 res) {
+  inte2 a = (inte2)(1, 2); //expected-warning{{expression result unused}}
+  inte4 b = (inte4)(a, a); //expected-error{{C-style cast from vector 'inte2' (vector of 2 'int' values) to vector 'inte4' (vector of 4 'int' values) of different size}} //expected-warning{{expression result unused}}
+}
+
Index: cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
===
--- cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
+++ cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
@@ -1,22 +1,65 @@
-// RUN: %clang_cc1 -emit-llvm %s -o %t
+// RUN: %clang_cc1 -emit-llvm %s -o - -O0 | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm %s -o - -cl-std=clc++ -O0 | FileCheck %s
 
-typedef __attribute__(( ext_vector_type(2) ))  int int2;
-typedef __attribute__(( ext_vector_type(3) ))  int int3;
-typedef __attribute__(( ext_vector_type(4) ))  int int4;
-typedef __attribute__(( ext_vector_type(8) ))  int int8;
-typedef __attribute__(( ext_vector_type(4) ))  float float4;
+typedef __attribute__((ext_vector_type(2))) int int2;
+typedef __attribute__((ext_vector_type(3))) int int3;
+typedef __attribute__((ext_vector_type(4)))  int int4;
+typedef __attribute__((ext_vector_type(8)))  int int8;
+typedef __attribute__((ext_vector_type(4))) float float4;
+
+__constant const int4 c1 = (int4)(1, 2, ((int2)(3)));
+// CHECK: constant <4 x i32> 
+
+__constant const int4 c2 = (int4)(1, 2, ((int2)(3, 4)));
+// CHECK: constant <4 x i32> 
 
 void vector_literals_valid() {
-  int4 a_1_1_1_1 = (int4)(1,2,3,4);
-  int4 a_2_1_1 = (int4)((int2)(1,2),3,4);
-  int4 a_1_2_1 = (int4)(1,(int2)(2,3),4);
-  int4 a_1_1_2 = (int4)(1,2,(int2)(3,4));
-  int4 a_2_2 = (int4)((int2)(1,2),(int2)(3,4));
-  int4 a_3_1 = (int4)((int3)(1,2,3),4);
-  int4 a_1_3 = (int4)(1,(int3)(2,3,4));
+  //CHECK: insertelement <4 x i32> , i32 %{{.+}}, i32 2
+  //CHECK: insertelement <4 x i32> %{{.+}}, i32 %{{.+}}, i32 3
+  int4 a_1_1_1_1 = (int4)(1, 2, c1.s2, c2.s3);
+
+  //CHECK: store <2 x i32> , <2 x i32>*
+  //CHECK: shufflevector <2 x i32> %{{[0-9]+}}, <2 x i32> undef, <4 x i32> 
+  //CHECK: shufflevector <4 x i32> %{{.+}}, <4 x i32> undef, <4 x i32> 
+  //CHECK: insertelement <4 x i32> %{{.+}}, i32 3, i32 2
+  //CHECK: insertelement <4 x i32> %{{.+}}, i32 4, i32 3
+  int4 a_2_1_1 = (int4)((int2)(1, 2), 3, 4);
+
+  //CHECK: store <2 x i32> , <2 x i32>*
+  //CHECK: shufflevector <2 x i32> %{{[0-9]+}}, <2 x i32> undef, <4 x i32> 
+  //CHECK: shufflevector <4 x i32> , <4 x i32> %{{.+}}, <4 x i32> 
+  //CHECK: insertelement <4 x i32> %{{.+}}, i32 4, i32 3
+  int4 a_1_2_1 = (int4)(1, (int2)(2, 3), 4);
+
+  //CHECK: store <2 x i32> , <2 x i32>*
+  //CHECK: shufflevector <2 x i32> %{{[0-9]+}}, <2 x i32> undef, <4 x i32> 
+  //CHECK: shufflevector <4 x i32> , <4 x i32> %{{.+}}, <4 x i32> 
+  int4 a_1_1_2 = (int4)(1, 2, (int2)(3, 4));
+
+  //CHECK: store <2 x i32> , <2 x i32>*
+  //CHECK: shufflevector <2 x i32> %{{[0-9]+}}, <2 x i32> undef, <4 x i32> 
+  //CHECK: shufflevector <4 x i32> %{{.+}}, <4 x i32> undef, <4 x i32> 
+  //CHECK: shufflevector <4 x i32> %{{.+}}, <4 x i32> , <4 x i32> 
+  int4 a_2_2 = (int4)((int2)(1, 2), (int2)(3));
+
+  //CHECK: store <4 x i32> , <4 x i32>*
+  //CHECK: shufflevector <4 x i32> %{{.+}}, <4 x i32> undef, <3 x i32> 
+  //CHECK: shufflevector <3 x i32> %{{.+}}, <3 x i32> undef, <4 x i32> 
+  //CHECK: shufflevector <4 x i32> , <4 x i32> %{{.+}}, <4 x i32> 
+  int4 a_1_3 = (int4)(1, (int3)(2, 3, 4));
+
+  //CHECK: store <4 x i32> , <4 x i32>* %a
   int4 a = (int4)(1);
-  int8 b = (int8)(1,2,a.xy,a);
-  float4 V2 = (float4) (1);
-}
 
+  //CHECK: load <4 x i32>, <4 x i32>* %a, align 16
+  //CHECK: shufflevector <4 x i32> %{{[0-9]+}}, <4 x i32> undef, <2 x i32> 
+  //CHECK: shufflevector <2 x i32> %{{[0-9]+}}, <2 x i32> undef, <8 x i32> 
+  //CHECK: shufflevector <8 x i32> , <8 x i32> %{{.+}}, <8 x i32> 
+  //CHECK: load <4 x i32>, <4 x i32>* %a, align 1

[PATCH] D65637: [clangd] [WIP] Semantic highlighting prototype for the vscode extension.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom updated this revision to Diff 213013.
jvikstrom added a comment.

Fixed bug that made it impossible to find colors that were a perfect match to 
the scope we are looking for (ex: fixes function being color as functions and 
not as entity.name)

Explanation for the bug: When adding the function highlighting definition the 
fully qualified name "entity.name.function" was added to a separate list that 
we did not try to match partial scope matches to.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65637

Files:
  clang-tools-extra/clangd/clients/clangd-vscode/.gitignore
  clang-tools-extra/clangd/clients/clangd-vscode/src/SemanticHighlighting.ts
  clang-tools-extra/clangd/clients/clangd-vscode/src/TextMate.ts
  clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
  clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts

Index: clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
@@ -2,14 +2,30 @@
 import * as assert from 'assert';
 
 import * as vscode from 'vscode';
-import * as myExtension from '../src/extension';
+import {SemanticHighlighting} from '../src/SemanticHighlighting';
 
-// TODO: add tests
 suite("Extension Tests", () => {
-
-// Defines a Mocha unit test
-test("Something 1", () => {
-assert.equal(-1, [1, 2, 3].indexOf(5));
-assert.equal(-1, [1, 2, 3].indexOf(0));
+test('HighlightingCache caches incrementaly', () => {
+const feature = new SemanticHighlighting.Feature();
+const uri = 'file://text';
+feature.handleNotification({
+textDocument: {uri: uri},
+lines: [{
+line: 1,
+tokens: 'BAABAAA=',
+}],
+});
+feature.handleNotification({
+textDocument: {uri: uri},
+lines: [{
+line: 2,
+tokens: 'BAABAAA=',
+}],
+});
+//const tokens = feature.tokenCache.files.get(vscode.Uri.parse(uri).toString()).tokens;
+//assert.deepEqual(tokens.get(1), [{character: 4, length: 1, scope: 0}]);
+//assert.deepEqual(tokens.get(2), [{character: 4, length: 1, scope: 0}]);
+
+
 });
 });
\ No newline at end of file
Index: clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
@@ -1,5 +1,6 @@
 import * as vscode from 'vscode';
 import * as vscodelc from 'vscode-languageclient';
+import { SemanticHighlighting } from './SemanticHighlighting';
 
 /**
  * Method to get workspace configuration option
@@ -12,9 +13,9 @@
 }
 
 namespace SwitchSourceHeaderRequest {
-export const type =
-new vscodelc.RequestType('textDocument/switchSourceHeader');
+export const type =
+new vscodelc.RequestType('textDocument/switchSourceHeader');
 }
 
 class FileStatus {
@@ -32,8 +33,8 @@
 const path = vscode.window.activeTextEditor.document.fileName;
 const status = this.statuses.get(path);
 if (!status) {
-  this.statusBarItem.hide();
-  return;
+this.statusBarItem.hide();
+return;
 }
 this.statusBarItem.text = `clangd: ` + status.state;
 this.statusBarItem.show();
@@ -73,25 +74,30 @@
 // However, VSCode does not have CUDA as a supported language yet, so we
 // cannot add a corresponding activationEvent for CUDA files and clangd will
 // *not* load itself automatically on '.cu' files.
-const cudaFilePattern: string = '**/*.{' +['cu'].join()+ '}';
+const cudaFilePattern: string = '**/*.{' + ['cu'].join() + '}';
 const clientOptions: vscodelc.LanguageClientOptions = {
 // Register the server for c-family and cuda files.
 documentSelector: [
 { scheme: 'file', language: 'c' },
 { scheme: 'file', language: 'cpp' },
-{ scheme: 'file', language: 'objective-c'},
-{ scheme: 'file', language: 'objective-cpp'},
+{ scheme: 'file', language: 'objective-c' },
+{ scheme: 'file', language: 'objective-cpp' },
 { scheme: 'file', pattern: cudaFilePattern },
 ],
 synchronize: !syncFileEvents ? undefined : {
-// FIXME: send sync file events when clangd provides implemenatations.
+// FIXME: send sync file events when clangd provides implemenatations.
 },
 initializationOptions: { clangdFileStatus: true },
 // Do not switch to output window when clangd returns output
   

[PATCH] D65637: [clangd] [WIP] Semantic highlighting prototype for the vscode extension.

[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/clients/clangd-vscode/src/TextMate.ts:20
+const split = scope.split('.');
+while(split.length > 0) {
+split.splice(-1)

I'm pretty sure this matching logic is wrong. An example of the scopes for 
variables in the Light+ theme:

```
variable.css
variable.scss
variable.other.less
variable.language.wildcard.java
variable.language
storage.type.variable.cs
variable
meta.definition.variable.name
support.variable
entity.name.variable
```

With this kind of matching we have now this means that `variable.other.less` 
will match `variable.other` and `variable.other.less`.
As there is no perfect match for `variable.other.field` it will try to match 
`variable.other` and find the color for less.

What should probably be done is remove the divided map. The query function 
should still be the same but  query on this.colors instead of this.divided.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65637



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

[PATCH] D65637: [clangd] [WIP] Semantic highlighting prototype for the vscode extension.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom updated this revision to Diff 213015.
jvikstrom added a comment.

Fix matching logic on TM scopes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65637

Files:
  clang-tools-extra/clangd/clients/clangd-vscode/.gitignore
  clang-tools-extra/clangd/clients/clangd-vscode/src/SemanticHighlighting.ts
  clang-tools-extra/clangd/clients/clangd-vscode/src/TextMate.ts
  clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
  clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts

Index: clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
@@ -2,14 +2,30 @@
 import * as assert from 'assert';
 
 import * as vscode from 'vscode';
-import * as myExtension from '../src/extension';
+import {SemanticHighlighting} from '../src/SemanticHighlighting';
 
-// TODO: add tests
 suite("Extension Tests", () => {
-
-// Defines a Mocha unit test
-test("Something 1", () => {
-assert.equal(-1, [1, 2, 3].indexOf(5));
-assert.equal(-1, [1, 2, 3].indexOf(0));
+test('HighlightingCache caches incrementaly', () => {
+const feature = new SemanticHighlighting.Feature();
+const uri = 'file://text';
+feature.handleNotification({
+textDocument: {uri: uri},
+lines: [{
+line: 1,
+tokens: 'BAABAAA=',
+}],
+});
+feature.handleNotification({
+textDocument: {uri: uri},
+lines: [{
+line: 2,
+tokens: 'BAABAAA=',
+}],
+});
+//const tokens = feature.tokenCache.files.get(vscode.Uri.parse(uri).toString()).tokens;
+//assert.deepEqual(tokens.get(1), [{character: 4, length: 1, scope: 0}]);
+//assert.deepEqual(tokens.get(2), [{character: 4, length: 1, scope: 0}]);
+
+
 });
 });
\ No newline at end of file
Index: clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
@@ -1,5 +1,6 @@
 import * as vscode from 'vscode';
 import * as vscodelc from 'vscode-languageclient';
+import { SemanticHighlighting } from './SemanticHighlighting';
 
 /**
  * Method to get workspace configuration option
@@ -12,9 +13,9 @@
 }
 
 namespace SwitchSourceHeaderRequest {
-export const type =
-new vscodelc.RequestType('textDocument/switchSourceHeader');
+export const type =
+new vscodelc.RequestType('textDocument/switchSourceHeader');
 }
 
 class FileStatus {
@@ -32,8 +33,8 @@
 const path = vscode.window.activeTextEditor.document.fileName;
 const status = this.statuses.get(path);
 if (!status) {
-  this.statusBarItem.hide();
-  return;
+this.statusBarItem.hide();
+return;
 }
 this.statusBarItem.text = `clangd: ` + status.state;
 this.statusBarItem.show();
@@ -73,25 +74,30 @@
 // However, VSCode does not have CUDA as a supported language yet, so we
 // cannot add a corresponding activationEvent for CUDA files and clangd will
 // *not* load itself automatically on '.cu' files.
-const cudaFilePattern: string = '**/*.{' +['cu'].join()+ '}';
+const cudaFilePattern: string = '**/*.{' + ['cu'].join() + '}';
 const clientOptions: vscodelc.LanguageClientOptions = {
 // Register the server for c-family and cuda files.
 documentSelector: [
 { scheme: 'file', language: 'c' },
 { scheme: 'file', language: 'cpp' },
-{ scheme: 'file', language: 'objective-c'},
-{ scheme: 'file', language: 'objective-cpp'},
+{ scheme: 'file', language: 'objective-c' },
+{ scheme: 'file', language: 'objective-cpp' },
 { scheme: 'file', pattern: cudaFilePattern },
 ],
 synchronize: !syncFileEvents ? undefined : {
-// FIXME: send sync file events when clangd provides implemenatations.
+// FIXME: send sync file events when clangd provides implemenatations.
 },
 initializationOptions: { clangdFileStatus: true },
 // Do not switch to output window when clangd returns output
 revealOutputChannelOn: vscodelc.RevealOutputChannelOn.Never
 };
 
-const clangdClient = new vscodelc.LanguageClient('Clang Language Server',serverOptions, clientOptions);
+const clangdClient = new vscodelc.LanguageClient('Clang Language Server', serverOptions, clientOptions);
+const semanticHighlightingFeature = new SemanticHighlighti

[PATCH] D65634: [RISCV] Default to lp64d in 64-bit RISC-V Linux

[Sam Elliott via Phabricator via cfe-commits]

lenary added inline comments.



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:385
+ ? "ilp32"
+ : Triple.getOS() == llvm::Triple::Linux ? "lp64d" : "lp64";
 }

Please may you turn this into a set of if-statements? Nesting ternary operators 
is a recipe for confusion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65634



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

[PATCH] D65634: [RISCV] Default to lp64d in 64-bit RISC-V Linux

[Roger Ferrer Ibanez via Phabricator via cfe-commits]

rogfer01 created this revision.
rogfer01 added reviewers: asb, lenary.
Herald added subscribers: cfe-commits, s.egerton, Jim, benna, psnobl, jocewei, 
PkmX, rkruppe, the_o, brucehoult, MartinMosbeck, edward-jones, zzheng, MaskRay, 
jrtc27, shiva0217, kito-cheng, niosHD, sabuasal, apazos, simoncook, johnrusso, 
rbar.
Herald added a project: clang.

When running clang as a native compiler in 64-bit Linux RISC-V the flag 
`-mabi=lp64d` is always mandatory. This change makes it the default there.

This builds on top of D48357 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65634

Files:
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv64-toolchain.c
  clang/test/Preprocessor/riscv-target-features.c


Index: clang/test/Preprocessor/riscv-target-features.c
===
--- clang/test/Preprocessor/riscv-target-features.c
+++ clang/test/Preprocessor/riscv-target-features.c
@@ -50,7 +50,7 @@
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -x c -E -dM %s 
\
 // RUN: -o - | FileCheck --check-prefix=CHECK-SOFT %s
-// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -x c -E -dM %s 
\
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -mabi=lp64 -x 
c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-SOFT %s
 // CHECK-SOFT: __riscv_float_abi_soft 1
 // CHECK-SOFT-NOT: __riscv_float_abi_single
@@ -66,7 +66,7 @@
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -mabi=ilp32d 
-x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-DOUBLE %s
-// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -mabi=lp64d -x 
c -E -dM %s \
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -x c -E -dM %s 
\
 // RUN: -o - | FileCheck --check-prefix=CHECK-DOUBLE %s
 // CHECK-DOUBLE: __riscv_float_abi_double 1
 // CHECK-DOUBLE-NOT: __riscv_float_abi_soft
Index: clang/test/Driver/riscv64-toolchain.c
===
--- clang/test/Driver/riscv64-toolchain.c
+++ clang/test/Driver/riscv64-toolchain.c
@@ -68,7 +68,7 @@
 // CXX-RV64-BAREMETAL-NOSYSROOT-LP64: 
"{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-elf/8.0.1{{/|}}crtend.o"
 
 // RUN: %clang %s -### -no-canonical-prefixes -fuse-ld=ld \
-// RUN:   -target riscv64-unknown-linux-gnu \
+// RUN:   -target riscv64-unknown-linux-gnu -mabi=lp64 \
 // RUN:   --gcc-toolchain=%S/Inputs/multilib_riscv_linux_sdk \
 // RUN:   --sysroot=%S/Inputs/multilib_riscv_linux_sdk/sysroot 2>&1 \
 // RUN:   | FileCheck -check-prefix=C-RV64-LINUX-MULTI-LP64 %s
@@ -84,7 +84,7 @@
 // C-RV64-LINUX-MULTI-LP64: 
"-L{{.*}}/Inputs/multilib_riscv_linux_sdk/sysroot/usr/lib64/lp64"
 
 // RUN: %clang %s -### -no-canonical-prefixes -fuse-ld=ld \
-// RUN:   -target riscv64-unknown-linux-gnu -march=rv64imafd -mabi=lp64d \
+// RUN:   -target riscv64-unknown-linux-gnu -march=rv64imafd \
 // RUN:   --gcc-toolchain=%S/Inputs/multilib_riscv_linux_sdk \
 // RUN:   --sysroot=%S/Inputs/multilib_riscv_linux_sdk/sysroot 2>&1 \
 // RUN:   | FileCheck -check-prefix=C-RV64-LINUX-MULTI-LP64D %s
Index: clang/lib/Driver/ToolChains/Arch/RISCV.cpp
===
--- clang/lib/Driver/ToolChains/Arch/RISCV.cpp
+++ clang/lib/Driver/ToolChains/Arch/RISCV.cpp
@@ -379,7 +379,8 @@
   if (const Arg *A = Args.getLastArg(options::OPT_mabi_EQ))
 return A->getValue();
 
-  // FIXME: currently defaults to the soft-float ABIs. Will need to be
-  // expanded to select ilp32f, ilp32d, lp64f, lp64d when appropriate.
-  return Triple.getArch() == llvm::Triple::riscv32 ? "ilp32" : "lp64";
+  // 64-bit RISC-V Linux defaults to lp64d.
+  return Triple.getArch() == llvm::Triple::riscv32
+ ? "ilp32"
+ : Triple.getOS() == llvm::Triple::Linux ? "lp64d" : "lp64";
 }


Index: clang/test/Preprocessor/riscv-target-features.c
===
--- clang/test/Preprocessor/riscv-target-features.c
+++ clang/test/Preprocessor/riscv-target-features.c
@@ -50,7 +50,7 @@
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-SOFT %s
-// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -x c -E -dM %s \
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -mabi=lp64 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-SOFT %s
 // CHECK-SOFT: __riscv_float_abi_soft 1
 // CHECK-SOFT-NOT: __riscv_float_abi_single
@@ -66,7 +66,7 @@
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32ifd -mabi=ilp32d -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-DOUBLE %s
-// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -mabi=lp64d -x c -E -dM %s \
+// RUN: %clang -target riscv64-unknown-linux-gnu -march=rv64ifd -x c -E -dM %s \
 // RU

Re: [PATCH] D58418: [clang][DirectoryWatcher] Upstream DirectoryWatcher

[Puyan Lotfi via cfe-commits]

Hi Jan, Thanks for the follow up!

Me and Compnerd narrowed down the issue to the inotify file count limit
being exceeded as the cause. DirectoryWatcherLinux::create() in
DirectoryWatcher-linux.cpp also doesn't properly perror, I'll post a patch
for this shortly to print perror info if the file count is exceeded.

The cause of the inotify limit being exceeded was... drumroll... _Dropbox_

PL



On Thu, Aug 1, 2019 at 11:24 AM Jan Korous via Phabricator via llvm-commits
 wrote:

> jkorous added a comment.
>
> Hi Puyan,
>
> I failed to reproduce with llvm.org/master
> (5faa533e47b0e54b04166b0257c5ebb48e6ffcaa <
> https://reviews.llvm.org/rG5faa533e47b0e54b04166b0257c5ebb48e6ffcaa>) on
> Ubuntu 18.04.1 LTS both in debug and release build.
>
> Since it sounds like you can reproduce "reliably" - can you please share
> more info how to reproduce?
>
>
> Repository:
>   rL LLVM
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D58418/new/
>
> https://reviews.llvm.org/D58418
>
>
>
> ___
> llvm-commits mailing list
> llvm-comm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65634: [RISCV] Default to lp64d in 64-bit RISC-V Linux

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Thank Roger. While we're doing this, I think it would make sense to default to 
ilp32d on 32-bit Linux? I know the glibc support etc is less mature than for 
RV64, but it seems the sensible thing to do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65634



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

[PATCH] D65573: Add User docs for ASTImporter

[Endre Fülöp via Phabricator via cfe-commits]

gamesh411 added a comment.

Lovely documentation with practical use-cases!
I left a few inline remarks.
Also wouldn't it be nice to have a section which introduces the `-ast-merge` 
command-line option. It would be helpful to see an example where a PCH is 
dumped and merged into another TU. You could mention, that this can be used to 
debug ASTImporter functionality.
Cheers!




Comment at: clang/docs/LibASTImporter.rst:26
+Existing clients of the ``ASTImporter`` library are Cross Translation Unit 
(CTU) static analysis and the LLDB expression parser.
+CTU static analysis imports a definition of a function if its definition is 
found in another translation unit (TU), this way the analysis can breach out 
from the single TU limitation.
+LLDB's ``expr`` command parses a user-defined expression, creates an 
``ASTContext`` for that and then imports the missing definitions from the AST 
what we got from the debug information (DWARF, etc).

I'd prefer:
... translation unit (TU). This way, the analysis can ...



Comment at: clang/docs/LibASTImporter.rst:32
+
+By importing one AST node we copy that node into the destination 
``ASTContext``.
+Why do we have to copy the node?

I'd put a comma here:
By importing one AST node,  we copy



Comment at: clang/docs/LibASTImporter.rst:34
+Why do we have to copy the node?
+Isn't enough just to insert the pointer to that node into the destination 
context?
+One reason is that the "from" context may outlive the "to" context.

Leave the just, or rephrase:
Isn't it enough to insert ...



Comment at: clang/docs/LibASTImporter.rst:42
+For instance, if there is a class definition with the same name in both 
translation units, but one of the definition contains a different number of 
fields.
+So, we look up existing definitions and then we check the structural 
equivalency on those nodes.
+The following pseudo-code demonstrates the basics of the import mechanism:

I'd put a comma here:
... existing definitions, and ...



Comment at: clang/docs/LibASTImporter.rst:74
+- record types and all their fields in order of their definition have the same 
identifier names and structurally equivalent types,
+- variable or function declarations and they have the same identifier name and 
their types are structurally equivalent.
+

I'd put a comma here:
... identifier name, and their ...



Comment at: clang/docs/LibASTImporter.rst:154
+We'd like to get the members too, so, we use ``ImportDefinition`` to copy the 
whole definition of ``MyClass`` into the "to" context.
+And then we dump the AST again.
+

Leave the 'And'




Comment at: clang/docs/LibASTImporter.rst:190
+With **normal import**, all dependent declarations are imported normally.
+However, with minimal import, the dependent Decls are imported without 
definition and we have to import their definition for each if we later need 
that.
+

I'd put a comma here:
... without definition, and we have ...



Comment at: clang/docs/LibASTImporter.rst:272
+
+And then we can build and execute the new tool.
+

Leave the 'And'



Comment at: clang/docs/LibASTImporter.rst:283
+However, there may be cases when both of the contexts have a definition for a 
given symbol.
+If these definitions differ then we have a name conflict, otherwise known as 
ODR (one definition rule) violation.
+Let's modify the previous tool we had written and try to import a 
``ClassTemplateSpecializationDecl`` with a conflicting definition:

shafik wrote:
> Note ODR is a C++ concept C does not have ODR
I'd put a comma here:
If these definitions differ, then we ...



Comment at: clang/docs/LibASTImporter.rst:347
+Since we could not import the specified declaration (``From``), we get an 
error in the return value.
+The AST will not contain the conflicting definition, so we are left with the 
original AST.
+

I'd use simple present here:
The AST will not contain the ... -> The AST does not contain the ...



Comment at: clang/docs/LibASTImporter.rst:388
+
+In this case we can see that an error is associated 
(``getImportDeclErrorIfAny``) for the specialization also, not just for the 
field:
+

Not a native, but this stood out:
In this case, we can see that an error is associated 
(``getImportDeclErrorIfAny``) **with/to** the specialization also, not just 
**with/to** the field.




Comment at: clang/docs/LibASTImporter.rst:402
+assert(Importer.getImportDeclErrorIfAny(FromSpec));
+// Btw, the error is set also for the FieldDecl.
+assert(Importer.getImportDeclErrorIfAny(From));

I'd switch these:
set also -> also set



Comment at: clang/docs/LibASTImporter.rst:410
+
+The

[PATCH] D65637: [clangd] [WIP] Semantic highlighting prototype for the vscode extension.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/clients/clangd-vscode/src/TextMate.ts:20
+const split = scope.split('.');
+while(split.length > 0) {
+split.splice(-1)

jvikstrom wrote:
> I'm pretty sure this matching logic is wrong. An example of the scopes for 
> variables in the Light+ theme:
> 
> ```
> variable.css
> variable.scss
> variable.other.less
> variable.language.wildcard.java
> variable.language
> storage.type.variable.cs
> variable
> meta.definition.variable.name
> support.variable
> entity.name.variable
> ```
> 
> With this kind of matching we have now this means that `variable.other.less` 
> will match `variable.other` and `variable.other.less`.
> As there is no perfect match for `variable.other.field` it will try to match 
> `variable.other` and find the color for less.
> 
> What should probably be done is remove the divided map. The query function 
> should still be the same but  query on this.colors instead of this.divided.
The suffix of textmate indicates the language it belongs to (e.g. java), I 
think we can ignore non-C++ textmates, and merely find the longest-prefix match 
in all `c++` textmates?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65637



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

[PATCH] D60943: Delay diagnosing asm constraints that require immediates until after inlining

[Joerg Sonnenberger via Phabricator via cfe-commits]

joerg added a comment.

The combination of D60942 , D06943 and D65280 
 solves the problems for me on all targets I 
have.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60943



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

[PATCH] D64932: [Parser] Emit descriptive diagnostic for misplaced pragma

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff updated this revision to Diff 213023.
sepavloff added a comment.

Updated patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64932

Files:
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/test/Parser/pragma-attribute-context.cpp
  clang/test/Parser/pragma-fp-contract.c
  clang/test/Parser/pragma-fp-contract.cpp

Index: clang/test/Parser/pragma-fp-contract.cpp
===
--- /dev/null
+++ clang/test/Parser/pragma-fp-contract.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+void f1(void) {
+  int x = 0;
+/* expected-error@+1 {{'#pragma fp_contract' can only appear at file scope or at the start of a compound statement}} */
+#pragma STDC FP_CONTRACT ON
+}
+
+void f2(void) {
+  #pragma STDC FP_CONTRACT OFF
+  #pragma STDC FP_CONTRACT ON
+}
+
+struct S1 {
+// expected-error@+1 {{this pragma cannot appear in struct declaration}}
+#pragma STDC FP_CONTRACT ON
+  float f1;
+};
+
+union U1 {
+  float f1;
+  float f2;
+// expected-error@+1 {{this pragma cannot appear in union declaration}}
+#pragma STDC FP_CONTRACT ON
+};
+
+class C1 {
+  float f1;
+// expected-error@+1 {{this pragma cannot appear in class declaration}}
+#pragma STDC FP_CONTRACT ON
+  float f2;
+};
Index: clang/test/Parser/pragma-fp-contract.c
===
--- clang/test/Parser/pragma-fp-contract.c
+++ clang/test/Parser/pragma-fp-contract.c
@@ -10,3 +10,16 @@
   #pragma STDC FP_CONTRACT OFF
   #pragma STDC FP_CONTRACT ON 
 }
+
+struct S1 {
+// expected-error@+1 {{this pragma cannot appear in struct declaration}}
+#pragma STDC FP_CONTRACT ON
+  float f1;
+};
+
+union U1 {
+  float f1;
+  float f2;
+// expected-error@+1 {{this pragma cannot appear in union declaration}}
+#pragma STDC FP_CONTRACT ON
+};
Index: clang/test/Parser/pragma-attribute-context.cpp
===
--- clang/test/Parser/pragma-attribute-context.cpp
+++ clang/test/Parser/pragma-attribute-context.cpp
@@ -31,8 +31,7 @@
 
 struct InStruct {
   // FIXME: This asserts in Objective-C++!
-  // FIXME: This is a horrible diagnostic!
 #ifndef __OBJC__
-  BEGIN_PRAGMA // expected-error {{expected member name or ';' after declaration specifiers}}
+  BEGIN_PRAGMA // expected-error {{this pragma cannot appear in struct declaration}}
 #endif
 };
Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -3134,6 +3134,13 @@
   TagDecl);
 
   default:
+if (tok::isPragmaAnnotation(Tok.getKind())) {
+  Diag(Tok.getLocation(), diag::err_pragma_misplaced_in_decl)
+  << DeclSpec::getSpecifierName(TagType,
+   Actions.getASTContext().getPrintingPolicy());
+  ConsumeAnnotationToken();
+  return nullptr;
+}
 return ParseCXXClassMemberDeclaration(AS, AccessAttrs);
   }
 }
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -4148,6 +4148,14 @@
   continue;
 }
 
+if (tok::isPragmaAnnotation(Tok.getKind())) {
+  Diag(Tok.getLocation(), diag::err_pragma_misplaced_in_decl)
+  << DeclSpec::getSpecifierName(
+ TagType, Actions.getASTContext().getPrintingPolicy());
+  ConsumeAnnotationToken();
+  continue;
+}
+
 if (!Tok.is(tok::at)) {
   auto CFieldCallback = [&](ParsingFieldDeclarator &FD) {
 // Install the declarator into the current TagDecl.
Index: clang/include/clang/Basic/DiagnosticParseKinds.td
===
--- clang/include/clang/Basic/DiagnosticParseKinds.td
+++ clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -976,6 +976,8 @@
 def warn_pragma_invalid_argument : Warning<
   "unexpected argument '%0' to '#pragma %1'%select{|; expected %3}2">, InGroup;
 
+def err_pragma_misplaced_in_decl : Error<"this pragma cannot appear in %0 declaration">;
+
 // '#pragma clang section' related errors
 def err_pragma_expected_clang_section_name : Error<
   "expected one of [bss|data|rodata|text] section kind in '#pragma %0'">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64932: [Parser] Emit descriptive diagnostic for misplaced pragma

[Serge Pavlov via Phabricator via cfe-commits]

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



Comment at: clang/lib/Basic/TokenKinds.cpp:15
 #include "llvm/Support/ErrorHandling.h"
+#include 
 using namespace clang;

rjmccall wrote:
> This is no longer necessary, right?
Sure, removed it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64932



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

[PATCH] D48866: [clang-tidy] Add incorrect-pointer-cast checker

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:69-70
+ "cast from %0 to %1 may lead to access memory based on invalid "
+ "memory layout; pointed to type is strictly aligned than the "
+ "allocated type")
+<< SrcPointedType << DestPointedType;

steakhal wrote:
> lebedev.ri wrote:
> > "*more* strictly aligned" perhaps?
> > Similarly, specify the actual values.
> Which metrics should I use? Bits or char units? For now I will stick to bits.
I tend to think in terms of bytes rather than bits as that's the allocation 
unit for storage. Might be worth adding "bytes" into the diagnostic as well, 
just to be very clear.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:41
+  const ASTContext &Context = *Result.Context;
+  const auto *castExpr = Result.Nodes.getNodeAs("cast");
+  const bool HasCXXStyle = isa(castExpr);

Should be renamed to meet coding style guidelines (but don't reuse `CastExpr` 
please, as that's a type name).



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:42
+  const auto *castExpr = Result.Nodes.getNodeAs("cast");
+  const bool HasCXXStyle = isa(castExpr);
+

Please drop top-level `const` on non-pointer/reference automatics.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:47-50
+  if (!SrcType->isPointerType() || !DestType->isPointerType())
+return;
+
+  if (SrcType->isDependentType() || DestType->isDependentType())

Can these checks be hoisted into the AST matcher?



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:56
+
+  if (SrcPointedType->isIncompleteType() || 
DestPointedType->isIncompleteType())
+return;

This one too.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:60
+  // -Wcast-align already warns for C-style casts increasing alignment
+  // requirements
+  const CharUnits SrcWidth = Context.getTypeSizeInChars(SrcPointedType);

Missing full stop at the end of the comment.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:65
+diag(castExpr->getBeginLoc(),
+ "cast from %0 to %1 may lead to access memory based on invalid memory 
"
+ "layout; new type is wider (%2) than the original type (%3)")

I'd drop the "lead to" from the diagnostic text.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:74
+  // -Wcast-align already warns for C-style casts increasing alignment
+  // requirements
+  const CharUnits SrcAlign = Context.getTypeAlignInChars(SrcPointedType);

Missing full stop. This comment suggests that we should not be diagnosing in C 
mode because it's a duplicate diagnostic, but you're gating it on a config flag 
rather than then language mode. Is that intentional?



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:79
+diag(castExpr->getBeginLoc(),
+ "cast from %0 to %1 may lead to access memory based on invalid "
+ "memory layout; new type is more strictly aligned (%2) than the "

Same comments here as above regarding "lead to" and bytes vs bits.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:88
+
+  // make sure both pointee are structs
+  if (!SrcPointedType->isStructureType() || 
!DestPointedType->isStructureType())

Comments should be full sentences with proper capitalization and punctuation.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:104
+const FieldDecl &DestField = **DestIterator;
+if (SrcField.getType() != DestField.getType()) {
+  FieldsAreSame = false;

Should this be looking at the canonical types as opposed to whatever types are 
written? e.g., will this decide that a field of type `int` and one of type 
`int32_t` are different (assuming that `int32_t` is a typedef to `int`)?

What if the fields have the same type, but have different bit widths? e.g., 
`int i : 2;` vs `int i : 4;`?

Should this consider qualifiers, like _Atomic() for differences, or is that 
already covered by the type comparison?

Should structure packing or alignment attributes impact this?

What if the fields are the same but the layout is still different? e.g., 
`struct S { int i; };` vs 'struct S { virtual ~S() = default; int i; };` ?

What if one record is a struct and the other is a union, but their fields are 
the same? e.g., `struct S { int i; double d; };` vs `union U { int i; double d; 
};` ?



Comment at: 
clang-tools-e

[clang-tools-extra] r367678 - Fix "not all control paths return a value" warning. NFCI.

[Simon Pilgrim via cfe-commits]

Author: rksimon
Date: Fri Aug  2 05:55:04 2019
New Revision: 367678

URL: http://llvm.org/viewvc/llvm-project?rev=367678&view=rev
Log:
Fix "not all control paths return a value" warning. NFCI.

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

Modified: clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp?rev=367678&r1=367677&r2=367678&view=diff
==
--- clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp (original)
+++ clang-tools-extra/trunk/clangd/unittests/TweakTesting.cpp Fri Aug  2 
05:55:04 2019
@@ -28,6 +28,7 @@ std::pairhttps://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65192: [Sema] Make -Wbitwise-op-parentheses and -Wlogical-op-parentheses disabled-by-default

[Aaron Ballman via Phabricator via cfe-commits]

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

Thank you for this! LGTM aside from a testing request (doesn't require further 
review).




Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5645
 def warn_bitwise_op_in_bitwise_op : Warning<
-  "'%0' within '%1'">, InGroup;
+  "'%0' within '%1'">, InGroup, DefaultIgnore;
 

Can you add a test case for this, please?


Repository:
  rC Clang

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

https://reviews.llvm.org/D65192



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

[PATCH] D65526: [Clangd] Initial prototype version of ExtractFunction

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

I guess you're looking for design review at this point.

But the most important part of that is the documentation of the high-level 
structure, which is entirely missing. I can't really infer it from the code 
because most of the design is (presumably) not implemented at this point :-)




Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:36
+
+class ExtractionTarget {
+public:

I think "range" or "region" may be a clearer name here than "target".
(In extract variable, target was used to refer to the destination of extraction)



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:110
+  // FIXME: Bail out when it's partial selected. Wait for selectiontree
+  // semicolon fix.
+  if (CommonAnc->Selected == SelectionTree::Selection::Partial &&

what is the fix you're waiting for?



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:155
+public:
+  enum LocType { PRETARGET, TARGET, POSTTARGET, OUTSIDECONTEXT };
+  struct Reference {

These are important domain structures, can we move them out of the 
RecursiveASTVisitor? (which should be mostly restricted to managing state of 
the traversal itself)



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:156
+  enum LocType { PRETARGET, TARGET, POSTTARGET, OUTSIDECONTEXT };
+  struct Reference {
+Decl *TheDecl = nullptr;

You've called this "reference", but I think it's actually a "referenceddecl" - 
you don't store one of these for each reference do you?



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:189
+
+TargetAnalyzer::Reference &TargetAnalyzer::getReferenceFor(VarDecl *D) {
+  assert(D && "D shouldn't be null!");

why does D need to be a vardecl?



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:190
+TargetAnalyzer::Reference &TargetAnalyzer::getReferenceFor(VarDecl *D) {
+  assert(D && "D shouldn't be null!");
+  // Don't add Decls that are outside the extraction context or in PostTarget.

please don't add messages to asserts that just echo the code. In order of 
preference:
 - take a reference so it clearly can't be null
 - add a message explaining at a *high level* what variant is violated
 - add the assertion with no message



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:197
+
+void TargetAnalyzer::checkIfRecursiveCall(DeclRefExpr *DRE) {
+  if (Target->isInTarget(DRE->getBeginLoc()) &&

why is this handled specially, instead of being part of the general case of 
"referring to a decl not visible in the target scope"?

(in particular, if the context is forward-declared elsewhere, what's the 
problem?



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:203
+
+void TargetAnalyzer::updateReferenceFor(DeclRefExpr *DRE) {
+  VarDecl *D = dyn_cast_or_null(DRE->getDecl());

DRE is just one of the cases where we want to handle names.

I think it'll be easier to handle more cases by changing this to accept a Decl* 
and moving the DRE->getDecl() to the caller



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:207
+return;
+  LocType DRELocType = getLocType(DRE->getBeginLoc());
+  LocType DeclLocType = getLocType(D->getBeginLoc());

(why beginloc rather than loc, throughout?)



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:211
+  // Note that DRELocType is never OUTSIDECONTEXT.
+  if (DeclLocType + 1 != DRELocType)
+return;

this line seems very suspect, what are you trying to do and why?




Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:214
+  Reference &Ref = getReferenceFor(D);
+  if (DRELocType == POSTTARGET)
+Ref.IsReferencedInPostTarget = true;

can't we skip the indirection here and just have something like 
Ref.markOccurrence(DRE->getBeginLoc()), and avoid dealing with the enum here at 
all?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65526



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

[PATCH] D65648: [clang-format] Add support to SpacesBeforeTrailingComments to add spaces before Block comments.

[Manikishan Ghantasala via Phabricator via cfe-commits]

Manikishan created this revision.
Manikishan added reviewers: cfe-commits, mgorny, christos, MyDeveloperDay, 
rdwampler, lebedev.ri.
Manikishan added a project: clang.
Herald added a subscriber: krytarowski.

Patch: SpacesBeforeTrailingBlockComments

This patch is to support ```spacesBeforeTrailingComments``` to support spaces 
before  Trailing BlockComments. According to the Documentation, this was not 
implemented because block comments have different usage patterns and a various 
number of special cases. I am trying to cover as many cases as possible which 
can be useful.
This patch covers some cases such as Declarations, definitions, and Includes

This is also under the Project of Adding NetBSD-KNF support to clang-format.

Example for supported cases:

  Int a;\*foo *\
  int b;\*bar *\
  Int c;\*baz *\
  
  #include ads.h\*foo *\
  #include bar.h\*bar *\

These following tests fail for this patch:

1. FormatTests/FormatTestComments.UnderstandsBlockComments
2. FormatTests/FormatTestJS.AddsLastLinePenaltyIfEndingIsBroken
3. FormatTests/FormatTestJS.TemplateStrings

I have to discuss whether to add support to those cases because I think the 
tests need to be modified while implementing this style.

I would like to discuss more one this specific style to know which cases I 
could work on, as it was chosen not to support. 
It will be good if I can get more inputs on the cases I could cover.


Repository:
  rC Clang

https://reviews.llvm.org/D65648

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


Index: unittests/Format/FormatTestComments.cpp
===
--- unittests/Format/FormatTestComments.cpp
+++ unittests/Format/FormatTestComments.cpp
@@ -2600,6 +2600,33 @@
"  // b");
 }
 
+TEST_F(FormatTestComments, SpacesBeforeTrailingBlockComments){
+  FormatStyle Style = getGoogleStyle();
+  Style.SpacesBeforeTrailingComments = 4;
+  EXPECT_EQ("int a;/*a*/\n"
+"int b;/*a*/\n"
+"int c;/*a*/\n"
+"int d;/*a*/\n"
+"int e;/*a*/\n"
+"int f;/*a*/\n"
+"int g;/*a*/\n"
+"int h;/*a*/",
+format("int a; /*a*/\n"
+   "int b; /*a*/\n"
+   "int c; /*a*/\n"
+   "int d; /*a*/\n"
+   "int e; /*a*/\n"
+   "int f; /*a*/\n"
+   "int g; /*a*/\n"
+   "int h; /*a*/", Style));
+  EXPECT_EQ("#define A   \\\n"
+"  int i;  /*a*/ \\\n"
+"  int jjj;/*b*/",
+format("#define A\\\n"
+   "  int i;   /*a*/ \\\n"
+   "  int jjj; /*b*/", Style));
+
+}
 TEST_F(FormatTestComments, AlignTrailingComments) {
   EXPECT_EQ("#define MACRO(V)   \\\n"
 "  V(Rt2) /* one more char */   \\\n"
Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -3659,6 +3659,8 @@
 }
 
 TEST_F(FormatTest, FormatNestedBlocksInMacros) {
+  FormatStyle Style = getGoogleStyle();
+  Style.SpacesBeforeTrailingComments = 0;
   EXPECT_EQ("#define MACRO() \\\n"
 "  Debug(aaa, /* force line break */ \\\n"
 "{   \\\n"
@@ -3667,7 +3669,7 @@
 "})",
 format("#define   MACRO()   Debug(aaa,  /* force line break */ 
\\\n"
"  {  int   i;  int  j;   })",
-   getGoogleStyle()));
+   Style));
 
   EXPECT_EQ("#define A   \\\n"
 "  [] {  \\\n"
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -2159,6 +2159,14 @@
   while (Current) {
 if (isFunctionDeclarationName(*Current, Line))
   Current->Type = TT_FunctionDeclarationName;
+if (Current->is(TT_BlockComment)){
+  std::cout << "TYPE"isOneOf(TT_TemplateCloser,tok::l_paren) && 
Current->isTrailingComment()){
+  Current->SpacesRequiredBefore = Style.SpacesBeforeTrailingComments;
+}
+  }
+}
 if (Current->is(TT_LineComment)) {
   if (Current->Previous->BlockKind == BK_BracedInit &&
   Current->Previous->opensScope())


Index: unittests/Format/FormatTestComments.cpp
===
--- unittests/Format/FormatTestComments.cpp
+++ unittests/Format/FormatTestComments.cpp
@@ -2600,6 +2600,33 @@
"  // b");
 }
 
+TEST_F(FormatTestComments, SpacesBeforeTrailingBlockComments){

Re: r367675 - [OpenCL] Allow OpenCL C style vector initialization in C++

[Yvan Roux via cfe-commits]

Hi Anastasia,

This commit broke ARMv8 bots, logs are available here:

http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/14655/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Avector_literals_valid.cl

Thanks,
Yvan

On Fri, 2 Aug 2019 at 13:18, Anastasia Stulova via cfe-commits
 wrote:
>
> Author: stulova
> Date: Fri Aug  2 04:19:35 2019
> New Revision: 367675
>
> URL: http://llvm.org/viewvc/llvm-project?rev=367675&view=rev
> Log:
> [OpenCL] Allow OpenCL C style vector initialization in C++
>
> Allow creating vector literals from other vectors.
>
>  float4 a = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
>  float4 v = (float4)(a.s23, a.s01);
>
> Differential revision: https://reviews.llvm.org/D65286
>
>
> Removed:
> cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl
> cfe/trunk/test/SemaOpenCL/vector_literals_const.cl
> Modified:
> cfe/trunk/lib/Sema/SemaInit.cpp
> cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
> cfe/trunk/test/SemaCXX/vector.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaInit.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=367675&r1=367674&r2=367675&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaInit.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Aug  2 04:19:35 2019
> @@ -1289,7 +1289,16 @@ void InitListChecker::CheckSubElementTyp
>  // FIXME: Better EqualLoc?
>  InitializationKind Kind =
>  InitializationKind::CreateCopy(expr->getBeginLoc(), 
> SourceLocation());
> -InitializationSequence Seq(SemaRef, Entity, Kind, expr,
> +
> +// Vector elements can be initialized from other vectors in which case
> +// we need initialization entity with a type of a vector (and not a 
> vector
> +// element!) initializing multiple vector elements.
> +auto TmpEntity =
> +(ElemType->isExtVectorType() && !Entity.getType()->isExtVectorType())
> +? InitializedEntity::InitializeTemporary(ElemType)
> +: Entity;
> +
> +InitializationSequence Seq(SemaRef, TmpEntity, Kind, expr,
> /*TopLevelOfInitList*/ true);
>
>  // C++14 [dcl.init.aggr]p13:
> @@ -1300,8 +1309,7 @@ void InitListChecker::CheckSubElementTyp
>  // assignment-expression.
>  if (Seq || isa(expr)) {
>if (!VerifyOnly) {
> -ExprResult Result =
> -  Seq.Perform(SemaRef, Entity, Kind, expr);
> +ExprResult Result = Seq.Perform(SemaRef, TmpEntity, Kind, expr);
>  if (Result.isInvalid())
>hadError = true;
>
>
> Removed: cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl?rev=367674&view=auto
> ==
> --- cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl (original)
> +++ cfe/trunk/test/CodeGenOpenCL/vector_literals_nested.cl (removed)
> @@ -1,23 +0,0 @@
> -// RUN: %clang_cc1 %s -emit-llvm -O3 -o - | FileCheck %s
> -
> -typedef int int2 __attribute((ext_vector_type(2)));
> -typedef int int4 __attribute((ext_vector_type(4)));
> -
> -__constant const int4 itest1 = (int4)(1, 2, ((int2)(3, 4)));
> -// CHECK: constant <4 x i32> 
> -__constant const int4 itest2 = (int4)(1, 2, ((int2)(3)));
> -// CHECK: constant <4 x i32> 
> -
> -typedef float float2 __attribute((ext_vector_type(2)));
> -typedef float float4 __attribute((ext_vector_type(4)));
> -
> -void ftest1(float4 *p) {
> -  *p = (float4)(1.1f, 1.2f, ((float2)(1.3f, 1.4f)));
> -// CHECK: store <4 x float>  0x3FF34000, float 0x3FF4C000, float 0x3FF66000>
> -}
> -
> -float4 ftest2(float4 *p) {
> -   *p =  (float4)(1.1f, 1.2f, ((float2)(1.3f)));
> -// CHECK: store <4 x float>  0x3FF34000, float 0x3FF4C000, float 0x3FF4C000>
> -}
> -
>
> Modified: cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl?rev=367675&r1=367674&r2=367675&view=diff
> ==
> --- cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl (original)
> +++ cfe/trunk/test/CodeGenOpenCL/vector_literals_valid.cl Fri Aug  2 04:19:35 
> 2019
> @@ -1,22 +1,65 @@
> -// RUN: %clang_cc1 -emit-llvm %s -o %t
> +// RUN: %clang_cc1 -emit-llvm %s -o - -O0 | FileCheck %s
> +// RUN: %clang_cc1 -emit-llvm %s -o - -cl-std=clc++ -O0 | FileCheck %s
>
> -typedef __attribute__(( ext_vector_type(2) ))  int int2;
> -typedef __attribute__(( ext_vector_type(3) ))  int int3;
> -typedef __attribute__(( ext_vector_type(4) ))  int int4;
> -typedef __attribute__(( ext_vector_type(8) ))  int int8;
> -typedef __attribute__(( ext_vector_type(4) ))  float float4;
> +typedef __attribute__((ext_vector_type(2))) int int2;
> +typedef __attribute__((ext_vector_type(3))) int int3

[PATCH] D65650: [Analyzer] Iterator Checkers - Fix for Crash on Iterator Differences

[Balogh, Ádám via Phabricator via cfe-commits]

baloghadamsoftware created this revision.
baloghadamsoftware added reviewers: NoQ, Szelethus.
baloghadamsoftware added a project: clang.
Herald added subscribers: Charusso, gamesh411, donat.nagy, mikhail.ramalho, 
a.sidorin, rnkovacs, szepet, xazax.hun, whisperity.

Iterators differences were mistakenly handled as random decrements which
causes an assertion. This patch fixes this.


Repository:
  rC Clang

https://reviews.llvm.org/D65650

Files:
  lib/StaticAnalyzer/Checkers/IteratorChecker.cpp
  test/Analysis/Inputs/system-header-simulator-cxx.h
  test/Analysis/diagnostics/explicit-suppression.cpp
  test/Analysis/iterator-range.cpp


Index: test/Analysis/iterator-range.cpp
===
--- test/Analysis/iterator-range.cpp
+++ test/Analysis/iterator-range.cpp
@@ -236,3 +236,8 @@
 *i0; // no-warning
   }
 }
+
+void iter_diff(std::vector &V) {
+  auto i0 = V.begin(), i1 = V.end();
+  ptrdiff_t len = i1 - i0; // no-crash
+}
Index: test/Analysis/diagnostics/explicit-suppression.cpp
===
--- test/Analysis/diagnostics/explicit-suppression.cpp
+++ test/Analysis/diagnostics/explicit-suppression.cpp
@@ -19,6 +19,6 @@
 void testCopyNull(C *I, C *E) {
   std::copy(I, E, (C *)0);
 #ifndef SUPPRESSED
-  // expected-warning@../Inputs/system-header-simulator-cxx.h:677 {{Called C++ 
object pointer is null}}
+  // expected-warning@../Inputs/system-header-simulator-cxx.h:680 {{Called C++ 
object pointer is null}}
 #endif
 }
Index: test/Analysis/Inputs/system-header-simulator-cxx.h
===
--- test/Analysis/Inputs/system-header-simulator-cxx.h
+++ test/Analysis/Inputs/system-header-simulator-cxx.h
@@ -70,6 +70,9 @@
 return ptr -= n;
   }
 
+  template
+  difference_type operator-(const __vector_iterator &rhs);
+
   Ref operator*() const { return *ptr; }
   Ptr operator->() const { return *ptr; }
 
Index: lib/StaticAnalyzer/Checkers/IteratorChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/IteratorChecker.cpp
+++ lib/StaticAnalyzer/Checkers/IteratorChecker.cpp
@@ -406,13 +406,15 @@
   } else if (isRandomIncrOrDecrOperator(Func->getOverloadedOperator())) {
 if (const auto *InstCall = dyn_cast(&Call)) {
   // Check for out-of-range incrementions and decrementions
-  if (Call.getNumArgs() >= 1) {
+  if (Call.getNumArgs() >= 1 &&
+  Call.getArgExpr(0)->getType()->isIntegralOrEnumerationType()) {
 verifyRandomIncrOrDecr(C, Func->getOverloadedOperator(),
InstCall->getCXXThisVal(),
Call.getArgSVal(0));
   }
 } else {
-  if (Call.getNumArgs() >= 2) {
+  if (Call.getNumArgs() >= 2 &&
+  Call.getArgExpr(1)->getType()->isIntegralOrEnumerationType()) {
 verifyRandomIncrOrDecr(C, Func->getOverloadedOperator(),
Call.getArgSVal(0), Call.getArgSVal(1));
   }
@@ -590,14 +592,16 @@
   return;
 } else if (isRandomIncrOrDecrOperator(Func->getOverloadedOperator())) {
   if (const auto *InstCall = dyn_cast(&Call)) {
-if (Call.getNumArgs() >= 1) {
+if (Call.getNumArgs() >= 1 &&
+  Call.getArgExpr(0)->getType()->isIntegralOrEnumerationType()) {
   handleRandomIncrOrDecr(C, Func->getOverloadedOperator(),
  Call.getReturnValue(),
  InstCall->getCXXThisVal(), 
Call.getArgSVal(0));
   return;
 }
   } else {
-if (Call.getNumArgs() >= 2) {
+if (Call.getNumArgs() >= 2 &&
+  Call.getArgExpr(1)->getType()->isIntegralOrEnumerationType()) {
   handleRandomIncrOrDecr(C, Func->getOverloadedOperator(),
  Call.getReturnValue(), Call.getArgSVal(0),
  Call.getArgSVal(1));


Index: test/Analysis/iterator-range.cpp
===
--- test/Analysis/iterator-range.cpp
+++ test/Analysis/iterator-range.cpp
@@ -236,3 +236,8 @@
 *i0; // no-warning
   }
 }
+
+void iter_diff(std::vector &V) {
+  auto i0 = V.begin(), i1 = V.end();
+  ptrdiff_t len = i1 - i0; // no-crash
+}
Index: test/Analysis/diagnostics/explicit-suppression.cpp
===
--- test/Analysis/diagnostics/explicit-suppression.cpp
+++ test/Analysis/diagnostics/explicit-suppression.cpp
@@ -19,6 +19,6 @@
 void testCopyNull(C *I, C *E) {
   std::copy(I, E, (C *)0);
 #ifndef SUPPRESSED
-  // expected-warning@../Inputs/system-header-simulator-cxx.h:677 {{Called C++ object pointer is null}}
+  // expected-warning@../Inputs/system-header-simulator-cxx.h:680 {{Called C++ object pointer is null}}
 #endif
 }
Inde

[PATCH] D65637: [clangd] [WIP] Semantic highlighting prototype for the vscode extension.

[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/clients/clangd-vscode/src/TextMate.ts:20
+const split = scope.split('.');
+while(split.length > 0) {
+split.splice(-1)

hokein wrote:
> jvikstrom wrote:
> > I'm pretty sure this matching logic is wrong. An example of the scopes for 
> > variables in the Light+ theme:
> > 
> > ```
> > variable.css
> > variable.scss
> > variable.other.less
> > variable.language.wildcard.java
> > variable.language
> > storage.type.variable.cs
> > variable
> > meta.definition.variable.name
> > support.variable
> > entity.name.variable
> > ```
> > 
> > With this kind of matching we have now this means that 
> > `variable.other.less` will match `variable.other` and `variable.other.less`.
> > As there is no perfect match for `variable.other.field` it will try to 
> > match `variable.other` and find the color for less.
> > 
> > What should probably be done is remove the divided map. The query function 
> > should still be the same but  query on this.colors instead of this.divided.
> The suffix of textmate indicates the language it belongs to (e.g. java), I 
> think we can ignore non-C++ textmates, and merely find the longest-prefix 
> match in all `c++` textmates?
But we have no real way of knowing if a suffix is a language or a more 
"precise" scope.
I don't think it's really possible to differentiate between `variable.other` 
and `variable.css` and say that `variable.css` is not relevant to c++ while 
`variable.other` is. (other than having an exhaustive list of language 
suffixes, which isn't feasible)

The implementation I changed to just saves the full scopes and than when we try 
to find the color of a scope we try to find it in the map, otherwise remove a 
suffix and try to find that scope (over and over)

Ex: Find scope for `variable.other.field.cpp` -> 
  First check for `variable.other.field.cpp` (finds nothing)
  Check `variable.other.field` (finds nothing)
  Check `variable.other` (still finds nothing
  Check `variable` (finds the variable scope and returns that color)

This seems to work, but maybe there's some case I miss. Anyway, there is 
probably a defined order on how you are supposed to find these scopes, I think 
I read a blog post on how VSCode actually does this matching internally. I'll 
try to dig that up and make sure our implementation matches before it's time to 
put up the actual CLs for this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65637



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

[PATCH] D65650: [Analyzer] Iterator Checkers - Fix for Crash on Iterator Differences

[Balogh, Ádám via Phabricator via cfe-commits]

baloghadamsoftware added a comment.

This is an emergency patch. Please someone review this patch as soon as 
possible.


Repository:
  rC Clang

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

https://reviews.llvm.org/D65650



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

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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/bugprone-dynamic-static-initializers.hpp:33-35
+  // This may work fine when optimization is enabled because bar() can
+  // be turned into a constant 7.  But without optimization, it can
+  // cause problems. Therefore, we must err on the side of conservatism.

czhang wrote:
> aaron.ballman wrote:
> > What problems can be caused here? Typically, dynamic init is only 
> > problematic when it happens before main() is executed (because of 
> > initialization order dependencies), but that doesn't apply to local statics.
> Consider the case when synchronization is disabled for static initialization, 
> and two threads call `foo2` for the first time. It may be the case that they 
> both try and initialize the static variable at the same time with different 
> values (since the dynamic initializer may not be pure), creating a race 
> condition.
> Consider the case when synchronization is disabled for static initialization

This is a compiler bug, though: http://eel.is/c++draft/stmt.dcl#4.sentence-3


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] D65655: [clangd] Fix a crash when presenting values for Hover

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov created this revision.
ilya-biryukov added a reviewer: sammccall.
Herald added subscribers: kadircet, arphaman, jkorous, MaskRay.
Herald added a project: clang.

We should pass the expression type, not a variable type when printing
the resulting value. Variable type may be different from what the
pretty-printing function expects, e.g. have references.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65655

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -1793,6 +1793,16 @@
   "int\n"
   "]",
   },
+  {
+  R"cpp(// Should not crash when evaluating the initializer.
+struct Test {};
+void test() { Test && te^st = {}; }
+  )cpp",
+  "text[Declared in]code[test]\n"
+  "codeblock(cpp) [\n"
+  "struct Test &&test = {}\n"
+  "]",
+  },
   };
 
   // Create a tiny index, so tests above can verify documentation is fetched.
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -715,7 +715,7 @@
 HI.Value.emplace();
 llvm::raw_string_ostream ValueOS(*HI.Value);
 Result.Val.printPretty(ValueOS, const_cast(Ctx),
-   Var->getType());
+   Init->getType());
   }
 }
   }


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -1793,6 +1793,16 @@
   "int\n"
   "]",
   },
+  {
+  R"cpp(// Should not crash when evaluating the initializer.
+struct Test {};
+void test() { Test && te^st = {}; }
+  )cpp",
+  "text[Declared in]code[test]\n"
+  "codeblock(cpp) [\n"
+  "struct Test &&test = {}\n"
+  "]",
+  },
   };
 
   // Create a tiny index, so tests above can verify documentation is fetched.
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -715,7 +715,7 @@
 HI.Value.emplace();
 llvm::raw_string_ostream ValueOS(*HI.Value);
 Result.Val.printPretty(ValueOS, const_cast(Ctx),
-   Var->getType());
+   Init->getType());
   }
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65510: [clangd] Fix implicit template instatiations appearing as topLevelDecls.

[Johan Vikström via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/ClangdUnit.cpp:68
+  if (const auto *TD = dyn_cast(D))
+return TD->getTemplateSpecializationKind() == TSK_ImplicitInstantiation;
+  return false;

ilya-biryukov wrote:
> hokein wrote:
> > ilya-biryukov wrote:
> > > We also want to skip `TSK_ExplicitInstantiationDeclaration` and  
> > > `TSK_ExplicitInstantiationDefinition` here.
> > > This covers cases like (not sure which one of the two enum values we get, 
> > > though):
> > > ```
> > > template 
> > > int foo(T) { ... }
> > > 
> > > template int foo(int); // we'd rather not traverse these, highlightings 
> > > will run into the same problems.
> > > ```
> > > 
> > > Semantics I'm describing are roughly similar to 
> > > `isImplicitInstatiation(D) == !isExplicitInstantion(D)`, where 
> > > `isExplicitInstantiation` is taken from `CodeComplete.cpp`. (If we ignore 
> > > `TSK_Undeclared`, which, I believe, should never be encountered in decls 
> > > passed to HandleTopLevelDecl).
> > > 
> > > Please extract the helper from code complete and this one into a separate 
> > > file (e.g. `clangd/AST.h`) and possibly implement one through the other
> > > Semantics I'm describing are roughly similar to isImplicitInstatiation(D) 
> > > == !isExplicitInstantion(D), 
> > 
> > I think there is a typo here, I believe you mean 
> > `isImplicitInstantiation(D) == !isExplicitSpecialization(D) ` (in 
> > CodeComplete.cpp, it checks whether a Decl is an explicit 
> > **specialization**).
> Yes, there's a typo thanks!
Still want me to move this and the helper from CodeComplete to `AST.h` as it 
isn't used anywhere else? (esp. when we can't implement them through of each 
other)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65510



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

[PATCH] D65510: [clangd] Fix implicit template instatiations appearing as topLevelDecls.

[Johan Vikström via Phabricator via cfe-commits]

jvikstrom updated this revision to Diff 213041.
jvikstrom added a comment.

Moved test to ClangdUnitTests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65510

Files:
  clang-tools-extra/clangd/AST.h
  clang-tools-extra/clangd/ClangdUnit.cpp
  clang-tools-extra/clangd/unittests/ClangdUnitTests.cpp


Index: clang-tools-extra/clangd/unittests/ClangdUnitTests.cpp
===
--- clang-tools-extra/clangd/unittests/ClangdUnitTests.cpp
+++ clang-tools-extra/clangd/unittests/ClangdUnitTests.cpp
@@ -103,6 +103,19 @@
   EXPECT_THAT(AST.getLocalTopLevelDecls(), ElementsAre(DeclNamed("main")));
 }
 
+TEST(ClangdUnitTest, DoesNotGetImplicitTemplateTopDecls) {
+  TestTU TU;
+  TU.Code = R"cpp(
+template
+void f(T) {}
+void s() {
+  f(10UL);
+}
+  )cpp";
+  auto AST = TU.build();
+  EXPECT_THAT(AST.getLocalTopLevelDecls(), ElementsAre(DeclNamed("f"), 
DeclNamed("s")));
+}
+
 TEST(ClangdUnitTest, TokensAfterPreamble) {
   TestTU TU;
   TU.AdditionalFiles["foo.h"] = R"(
Index: clang-tools-extra/clangd/ClangdUnit.cpp
===
--- clang-tools-extra/clangd/ClangdUnit.cpp
+++ clang-tools-extra/clangd/ClangdUnit.cpp
@@ -19,8 +19,11 @@
 #include "index/CanonicalIncludes.h"
 #include "index/Index.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/Specifiers.h"
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/CompilerInvocation.h"
@@ -60,6 +63,12 @@
   return Vec.capacity() * sizeof(T);
 }
 
+template  bool isImplicitTemplateInstantiation(const Decl *D) {
+  if (const auto *TD = dyn_cast(D))
+return TD->getTemplateSpecializationKind() == TSK_ImplicitInstantiation;
+  return false;
+}
+
 class DeclTrackingASTConsumer : public ASTConsumer {
 public:
   DeclTrackingASTConsumer(std::vector &TopLevelDecls)
@@ -70,6 +79,10 @@
   auto &SM = D->getASTContext().getSourceManager();
   if (!isInsideMainFile(D->getLocation(), SM))
 continue;
+  if (isImplicitTemplateInstantiation(D) ||
+  isImplicitTemplateInstantiation(D) ||
+  isImplicitTemplateInstantiation(D))
+continue;
 
   // ObjCMethodDecl are not actually top-level decls.
   if (isa(D))
Index: clang-tools-extra/clangd/AST.h
===
--- clang-tools-extra/clangd/AST.h
+++ clang-tools-extra/clangd/AST.h
@@ -81,7 +81,7 @@
 /// Example: shortenNamespace("ns1::MyClass", "ns1")
 ///--> "MyClass"
 std::string  shortenNamespace(const llvm::StringRef OriginalName,
-  const llvm::StringRef CurrentNamespace);
+const llvm::StringRef CurrentNamespace);
 
 
 } // namespace clangd


Index: clang-tools-extra/clangd/unittests/ClangdUnitTests.cpp
===
--- clang-tools-extra/clangd/unittests/ClangdUnitTests.cpp
+++ clang-tools-extra/clangd/unittests/ClangdUnitTests.cpp
@@ -103,6 +103,19 @@
   EXPECT_THAT(AST.getLocalTopLevelDecls(), ElementsAre(DeclNamed("main")));
 }
 
+TEST(ClangdUnitTest, DoesNotGetImplicitTemplateTopDecls) {
+  TestTU TU;
+  TU.Code = R"cpp(
+template
+void f(T) {}
+void s() {
+  f(10UL);
+}
+  )cpp";
+  auto AST = TU.build();
+  EXPECT_THAT(AST.getLocalTopLevelDecls(), ElementsAre(DeclNamed("f"), DeclNamed("s")));
+}
+
 TEST(ClangdUnitTest, TokensAfterPreamble) {
   TestTU TU;
   TU.AdditionalFiles["foo.h"] = R"(
Index: clang-tools-extra/clangd/ClangdUnit.cpp
===
--- clang-tools-extra/clangd/ClangdUnit.cpp
+++ clang-tools-extra/clangd/ClangdUnit.cpp
@@ -19,8 +19,11 @@
 #include "index/CanonicalIncludes.h"
 #include "index/Index.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/Specifiers.h"
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/CompilerInvocation.h"
@@ -60,6 +63,12 @@
   return Vec.capacity() * sizeof(T);
 }
 
+template  bool isImplicitTemplateInstantiation(const Decl *D) {
+  if (const auto *TD = dyn_cast(D))
+return TD->getTemplateSpecializationKind() == TSK_ImplicitInstantiation;
+  return false;
+}
+
 class DeclTrackingASTConsumer : public ASTConsumer {
 public:
   DeclTrackingASTConsumer(std::vector &TopLevelDecls)
@@ -70,6 +79,10 @@
   auto &SM = D->getASTContext().getSourceManager();
   if (!isInsideMainFile(D->getLocation(), SM))
 continue;
+  if (isImplicitTemplateInstantiation(D) ||
+

Re: r367530 - [Preprocessor] Always discard body of #define if we failed to parse it

[Hans Wennborg via cfe-commits]

Merged to release_90 in r367681.

On Thu, Aug 1, 2019 at 11:09 AM Ilya Biryukov via cfe-commits
 wrote:
>
> Author: ibiryukov
> Date: Thu Aug  1 02:10:37 2019
> New Revision: 367530
>
> URL: http://llvm.org/viewvc/llvm-project?rev=367530&view=rev
> Log:
> [Preprocessor] Always discard body of #define if we failed to parse it
>
> Summary:
> Preivously we would only discard it if we failed to parse parameter lists.
> If we do not consume the body, parser sees tokens inside directive. In
> turn, this leads to spurious diagnostics and a crash in TokenBuffer, see
> the added tests.
>
> Reviewers: sammccall
>
> Reviewed By: sammccall
>
> Subscribers: cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D65517
>
> Added:
> cfe/trunk/test/Preprocessor/stringize_skipped.c
> Modified:
> cfe/trunk/lib/Lex/PPDirectives.cpp
> cfe/trunk/unittests/Tooling/Syntax/TokensTest.cpp
>
> Modified: cfe/trunk/lib/Lex/PPDirectives.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPDirectives.cpp?rev=367530&r1=367529&r2=367530&view=diff
> ==
> --- cfe/trunk/lib/Lex/PPDirectives.cpp (original)
> +++ cfe/trunk/lib/Lex/PPDirectives.cpp Thu Aug  1 02:10:37 2019
> @@ -33,6 +33,7 @@
>  #include "clang/Lex/Token.h"
>  #include "clang/Lex/VariadicMacroSupport.h"
>  #include "llvm/ADT/ArrayRef.h"
> +#include "llvm/ADT/ScopeExit.h"
>  #include "llvm/ADT/SmallString.h"
>  #include "llvm/ADT/SmallVector.h"
>  #include "llvm/ADT/STLExtras.h"
> @@ -2399,6 +2400,13 @@ MacroInfo *Preprocessor::ReadOptionalMac
>Token Tok;
>LexUnexpandedToken(Tok);
>
> +  // Ensure we consume the rest of the macro body if errors occur.
> +  auto _ = llvm::make_scope_exit([&]() {
> +// The flag indicates if we are still waiting for 'eod'.
> +if (CurLexer->ParsingPreprocessorDirective)
> +  DiscardUntilEndOfDirective();
> +  });
> +
>// Used to un-poison and then re-poison identifiers of the __VA_ARGS__ ilk
>// within their appropriate context.
>VariadicMacroScopeGuard VariadicMacroScopeGuard(*this);
> @@ -2420,12 +2428,8 @@ MacroInfo *Preprocessor::ReadOptionalMac
>} else if (Tok.is(tok::l_paren)) {
>  // This is a function-like macro definition.  Read the argument list.
>  MI->setIsFunctionLike();
> -if (ReadMacroParameterList(MI, LastTok)) {
> -  // Throw away the rest of the line.
> -  if (CurPPLexer->ParsingPreprocessorDirective)
> -DiscardUntilEndOfDirective();
> +if (ReadMacroParameterList(MI, LastTok))
>return nullptr;
> -}
>
>  // If this is a definition of an ISO C/C++ variadic function-like macro 
> (not
>  // using the GNU named varargs extension) inform our variadic scope guard
>
> Added: cfe/trunk/test/Preprocessor/stringize_skipped.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/stringize_skipped.c?rev=367530&view=auto
> ==
> --- cfe/trunk/test/Preprocessor/stringize_skipped.c (added)
> +++ cfe/trunk/test/Preprocessor/stringize_skipped.c Thu Aug  1 02:10:37 2019
> @@ -0,0 +1,5 @@
> +// RUN: %clang_cc1 -fsyntax-only -verify %s
> +// Ensure we see the error from PP and do not see errors from the parser.
> +
> +// expected-error@+1{{'#' is not followed by a macro parameter}}
> +#define INVALID() #B 10+10
>
> Modified: cfe/trunk/unittests/Tooling/Syntax/TokensTest.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/Syntax/TokensTest.cpp?rev=367530&r1=367529&r2=367530&view=diff
> ==
> --- cfe/trunk/unittests/Tooling/Syntax/TokensTest.cpp (original)
> +++ cfe/trunk/unittests/Tooling/Syntax/TokensTest.cpp Thu Aug  1 02:10:37 2019
> @@ -298,6 +298,21 @@ file './input.cpp'
>spelled tokens:
>  
>no mappings.
> +)"},
> +  // Should not crash on errors inside '#define' directives. Error is 
> that
> +  // stringification (#B) does not refer to a macro parameter.
> +  {
> +  R"cpp(
> +a
> +#define MACRO() A #B
> +)cpp",
> +  R"(expanded tokens:
> +  a
> +file './input.cpp'
> +  spelled tokens:
> +a # define MACRO ( ) A # B
> +  mappings:
> +['#'_1, ''_9) => [''_1, ''_1)
>  )"}};
>for (auto &Test : TestCases)
>  EXPECT_EQ(collectAndDump(Test.first), Test.second)
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65517: [Preprocessor] Always discard body of #define if we failed to parse it

[Hans Wennborg via Phabricator via cfe-commits]

hans added a comment.

In D65517#1609990 , @ilya-biryukov 
wrote:

> SG, just wanted to make sure it's on your list ;-)


Merged in r367681.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D65517



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

[PATCH] D65526: [Clangd] Initial prototype version of ExtractFunction

[Shaurya Gupta via Phabricator via cfe-commits]

SureYeaah marked 2 inline comments as done.
SureYeaah added a comment.

In D65526#1612117 , @sammccall wrote:

> I guess you're looking for design review at this point.
>
> But the most important part of that is the documentation of the high-level 
> structure, which is entirely missing. I can't really infer it from the code 
> because most of the design is (presumably) not implemented at this point :-)


Aaah. Yes. Sorry. Makes sense.




Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:110
+  // FIXME: Bail out when it's partial selected. Wait for selectiontree
+  // semicolon fix.
+  if (CommonAnc->Selected == SelectionTree::Selection::Partial &&

sammccall wrote:
> what is the fix you're waiting for?
The semicolon fix that has already landed now.



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:211
+  // Note that DRELocType is never OUTSIDECONTEXT.
+  if (DeclLocType + 1 != DRELocType)
+return;

sammccall wrote:
> this line seems very suspect, what are you trying to do and why?
> 
This just checks whether (DeclLocType, DRELocType) is either (PRETARGET, 
TARGET) or (TARGET, POSTTARGET). Could explicitly write it if needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65526



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

[PATCH] D65657: [clangd][vscode] clang-format the the extension code.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added reviewers: ilya-biryukov, sammccall, jvikstrom.
Herald added subscribers: kadircet, arphaman, jkorous, MaskRay.
Herald added a project: clang.

As we are going to grow the extension in the near future, it is time to
formalize the TS code format/style of our extension (although we'd lose the
history).

We use default options of clang-format:

- 80 max line length
- 2 space indent


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65657

Files:
  clang-tools-extra/clangd/clients/clangd-vscode/README.md
  clang-tools-extra/clangd/clients/clangd-vscode/package.json
  clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
  clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
  clang-tools-extra/clangd/clients/clangd-vscode/test/index.ts

Index: clang-tools-extra/clangd/clients/clangd-vscode/test/index.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/test/index.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/test/index.ts
@@ -5,18 +5,21 @@
 // By default the test runner in use is Mocha based.
 //
 // You can provide your own test runner if you want to override it by exporting
-// a function run(testRoot: string, clb: (error:Error) => void) that the extension
-// host can call to run the tests. The test runner is expected to use console.log
-// to report the results back to the caller. When the tests are finished, return
-// a possible error to the callback or null if none.
+// a function run(testRoot: string, clb: (error:Error) => void) that the
+// extension host can call to run the tests. The test runner is expected to use
+// console.log to report the results back to the caller. When the tests are
+// finished, return a possible error to the callback or null if none.
 
 var testRunner = require('vscode/lib/testrunner');
 
 // You can directly control Mocha options by uncommenting the following lines
-// See https://github.com/mochajs/mocha/wiki/Using-mocha-programmatically#set-options for more info
+// See
+// https://github.com/mochajs/mocha/wiki/Using-mocha-programmatically#set-options
+// for more info
 testRunner.configure({
-ui: 'tdd', 		// the TDD UI is being used in extension.test.ts (suite, test, etc.)
-useColors: true // colored output from test results
+  ui : 'tdd', // the TDD UI is being used in extension.test.ts (suite, test,
+  // etc.)
+  useColors : true // colored output from test results
 });
 
 module.exports = testRunner;
\ No newline at end of file
Index: clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/test/extension.test.ts
@@ -6,10 +6,9 @@
 
 // TODO: add tests
 suite("Extension Tests", () => {
-
-// Defines a Mocha unit test
-test("Something 1", () => {
-assert.equal(-1, [1, 2, 3].indexOf(5));
-assert.equal(-1, [1, 2, 3].indexOf(0));
-});
+  // Defines a Mocha unit test
+  test("Something 1", () => {
+assert.equal(-1, [ 1, 2, 3 ].indexOf(5));
+assert.equal(-1, [ 1, 2, 3 ].indexOf(0));
+  });
 });
\ No newline at end of file
Index: clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
@@ -7,8 +7,8 @@
  * @param defaultValue default value to return if option is not set
  */
 function getConfig(option: string, defaultValue?: any): T {
-const config = vscode.workspace.getConfiguration('clangd');
-return config.get(option, defaultValue);
+  const config = vscode.workspace.getConfiguration('clangd');
+  return config.get(option, defaultValue);
 }
 
 namespace SwitchSourceHeaderRequest {
@@ -18,35 +18,33 @@
 }
 
 class FileStatus {
-private statuses = new Map();
-private readonly statusBarItem =
-vscode.window.createStatusBarItem(vscode.StatusBarAlignment.Left, 10);
+  private statuses = new Map();
+  private readonly statusBarItem =
+  vscode.window.createStatusBarItem(vscode.StatusBarAlignment.Left, 10);
 
-onFileUpdated(fileStatus: any) {
-const filePath = vscode.Uri.parse(fileStatus.uri);
-this.statuses.set(filePath.fsPath, fileStatus);
-this.updateStatus();
-}
+  onFileUpdated(fileStatus: any) {
+const filePath = vscode.Uri.parse(fileStatus.uri);
+this.statuses.set(filePath.fsPath, fileStatus);
+this.updateStatus();
+  }
 
-updateStatus() {
-const path = vscode.window.activeTextEditor.document.fileName;
-const status = this.statuses.get(path);
-if (!status) {
-  this.statusBarItem.hide();
-  return;
-}
-this.statusBarIte

[PATCH] D65526: [Clangd] Initial prototype version of ExtractFunction

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp:211
+  // Note that DRELocType is never OUTSIDECONTEXT.
+  if (DeclLocType + 1 != DRELocType)
+return;

SureYeaah wrote:
> sammccall wrote:
> > this line seems very suspect, what are you trying to do and why?
> > 
> This just checks whether (DeclLocType, DRELocType) is either (PRETARGET, 
> TARGET) or (TARGET, POSTTARGET). Could explicitly write it if needed.
Definitely needed, apart from the lack of clarity the current version has UB 
sometimes (`DeclLocType + 1` might not be a valid value)

But by "why" i mostly mean - this looks like the place for recording the 
location, not the place for deciding not to record the location because some 
algorithm later may not need it. Seems a lot simpler to record it 
unconditionally and worry about it later.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65526



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

[PATCH] D65510: [clangd] Fix implicit template instatiations appearing as topLevelDecls.

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

the change looks good to me, leave the final approval to Ilya as he knows more 
context.




Comment at: clang-tools-extra/clangd/unittests/ClangdUnitTests.cpp:116
+  auto AST = TU.build();
+  EXPECT_THAT(AST.getLocalTopLevelDecls(), ElementsAre(DeclNamed("f"), 
DeclNamed("s")));
+}

nit: clang-format, the length seems > 80 column.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65510



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

[clang-tools-extra] r367684 - [clangd][vscode] clang-format the the extension code.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Fri Aug  2 07:24:02 2019
New Revision: 367684

URL: http://llvm.org/viewvc/llvm-project?rev=367684&view=rev
Log:
[clangd][vscode] clang-format the the extension code.

Summary:
As we are going to grow the extension in the near future, it is time to
formalize the TS code format/style of our extension (although we'd lose the
history).

We use default options of clang-format:
- 80 max line length
- 2 space indent

Reviewers: ilya-biryukov, sammccall, jvikstrom

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

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/clients/clangd-vscode/README.md
clang-tools-extra/trunk/clangd/clients/clangd-vscode/package.json
clang-tools-extra/trunk/clangd/clients/clangd-vscode/src/extension.ts
clang-tools-extra/trunk/clangd/clients/clangd-vscode/test/extension.test.ts
clang-tools-extra/trunk/clangd/clients/clangd-vscode/test/index.ts

Modified: clang-tools-extra/trunk/clangd/clients/clangd-vscode/README.md
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/clients/clangd-vscode/README.md?rev=367684&r1=367683&r2=367684&view=diff
==
--- clang-tools-extra/trunk/clangd/clients/clangd-vscode/README.md (original)
+++ clang-tools-extra/trunk/clangd/clients/clangd-vscode/README.md Fri Aug  2 
07:24:02 2019
@@ -50,6 +50,11 @@ point to the binary.
# When VS Code starts, press .
 ```
 
+## Contributing
+
+Please follow the exsiting code style when contributing to the extension, we
+recommend to run `npm run format` before sending a patch.
+
 ## Publish to VS Code Marketplace
 
 New changes to `clangd-vscode` are not released until a new version is 
published

Modified: clang-tools-extra/trunk/clangd/clients/clangd-vscode/package.json
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/clients/clangd-vscode/package.json?rev=367684&r1=367683&r2=367684&view=diff
==
--- clang-tools-extra/trunk/clangd/clients/clangd-vscode/package.json (original)
+++ clang-tools-extra/trunk/clangd/clients/clangd-vscode/package.json Fri Aug  
2 07:24:02 2019
@@ -32,6 +32,7 @@
 "vscode:prepublish": "tsc -p ./",
 "compile": "tsc -watch -p ./",
 "postinstall": "node ./node_modules/vscode/bin/install",
+"format": "clang-format --style=LLVM -i --glob=\"{src,test}/*.ts\"",
 "test": "node ./node_modules/vscode/bin/test"
 },
 "dependencies": {
@@ -42,6 +43,7 @@
 "@types/mocha": "^2.2.32",
 "@types/node": "^6.0.40",
 "mocha": "^5.2.0",
+"clang-format": "1.2.4",
 "typescript": "^2.0.3",
 "vscode": "^1.1.0"
 },

Modified: clang-tools-extra/trunk/clangd/clients/clangd-vscode/src/extension.ts
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/clients/clangd-vscode/src/extension.ts?rev=367684&r1=367683&r2=367684&view=diff
==
--- clang-tools-extra/trunk/clangd/clients/clangd-vscode/src/extension.ts 
(original)
+++ clang-tools-extra/trunk/clangd/clients/clangd-vscode/src/extension.ts Fri 
Aug  2 07:24:02 2019
@@ -7,8 +7,8 @@ import * as vscodelc from 'vscode-langua
  * @param defaultValue default value to return if option is not set
  */
 function getConfig(option: string, defaultValue?: any): T {
-const config = vscode.workspace.getConfiguration('clangd');
-return config.get(option, defaultValue);
+  const config = vscode.workspace.getConfiguration('clangd');
+  return config.get(option, defaultValue);
 }
 
 namespace SwitchSourceHeaderRequest {
@@ -18,35 +18,33 @@ export const type =
 }
 
 class FileStatus {
-private statuses = new Map();
-private readonly statusBarItem =
-vscode.window.createStatusBarItem(vscode.StatusBarAlignment.Left, 10);
-
-onFileUpdated(fileStatus: any) {
-const filePath = vscode.Uri.parse(fileStatus.uri);
-this.statuses.set(filePath.fsPath, fileStatus);
-this.updateStatus();
+  private statuses = new Map();
+  private readonly statusBarItem =
+  vscode.window.createStatusBarItem(vscode.StatusBarAlignment.Left, 10);
+
+  onFileUpdated(fileStatus: any) {
+const filePath = vscode.Uri.parse(fileStatus.uri);
+this.statuses.set(filePath.fsPath, fileStatus);
+this.updateStatus();
+  }
+
+  updateStatus() {
+const path = vscode.window.activeTextEditor.document.fileName;
+const status = this.statuses.get(path);
+if (!status) {
+  this.statusBarItem.hide();
+  return;
 }
+this.statusBarItem.text = `clangd: ` + status.state;
+this.statusBarItem.show();
+  }
+
+  clear() {
+this.statuses.clear();
+this.statusBarItem.hide();
+  }
 
-updateStatus() {
-const path = vscode.window.activeTextEditor.

[PATCH] D65657: [clangd][vscode] clang-format the the extension code.

[Haojian Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367684: [clangd][vscode] clang-format the the extension 
code. (authored by hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65657?vs=213045&id=213047#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65657

Files:
  clang-tools-extra/trunk/clangd/clients/clangd-vscode/README.md
  clang-tools-extra/trunk/clangd/clients/clangd-vscode/package.json
  clang-tools-extra/trunk/clangd/clients/clangd-vscode/src/extension.ts
  clang-tools-extra/trunk/clangd/clients/clangd-vscode/test/extension.test.ts
  clang-tools-extra/trunk/clangd/clients/clangd-vscode/test/index.ts

Index: clang-tools-extra/trunk/clangd/clients/clangd-vscode/test/extension.test.ts
===
--- clang-tools-extra/trunk/clangd/clients/clangd-vscode/test/extension.test.ts
+++ clang-tools-extra/trunk/clangd/clients/clangd-vscode/test/extension.test.ts
@@ -6,10 +6,9 @@
 
 // TODO: add tests
 suite("Extension Tests", () => {
-
-// Defines a Mocha unit test
-test("Something 1", () => {
-assert.equal(-1, [1, 2, 3].indexOf(5));
-assert.equal(-1, [1, 2, 3].indexOf(0));
-});
+  // Defines a Mocha unit test
+  test("Something 1", () => {
+assert.equal(-1, [ 1, 2, 3 ].indexOf(5));
+assert.equal(-1, [ 1, 2, 3 ].indexOf(0));
+  });
 });
\ No newline at end of file
Index: clang-tools-extra/trunk/clangd/clients/clangd-vscode/test/index.ts
===
--- clang-tools-extra/trunk/clangd/clients/clangd-vscode/test/index.ts
+++ clang-tools-extra/trunk/clangd/clients/clangd-vscode/test/index.ts
@@ -5,18 +5,21 @@
 // By default the test runner in use is Mocha based.
 //
 // You can provide your own test runner if you want to override it by exporting
-// a function run(testRoot: string, clb: (error:Error) => void) that the extension
-// host can call to run the tests. The test runner is expected to use console.log
-// to report the results back to the caller. When the tests are finished, return
-// a possible error to the callback or null if none.
+// a function run(testRoot: string, clb: (error:Error) => void) that the
+// extension host can call to run the tests. The test runner is expected to use
+// console.log to report the results back to the caller. When the tests are
+// finished, return a possible error to the callback or null if none.
 
 var testRunner = require('vscode/lib/testrunner');
 
 // You can directly control Mocha options by uncommenting the following lines
-// See https://github.com/mochajs/mocha/wiki/Using-mocha-programmatically#set-options for more info
+// See
+// https://github.com/mochajs/mocha/wiki/Using-mocha-programmatically#set-options
+// for more info
 testRunner.configure({
-ui: 'tdd', 		// the TDD UI is being used in extension.test.ts (suite, test, etc.)
-useColors: true // colored output from test results
+  ui : 'tdd', // the TDD UI is being used in extension.test.ts (suite, test,
+  // etc.)
+  useColors : true // colored output from test results
 });
 
 module.exports = testRunner;
\ No newline at end of file
Index: clang-tools-extra/trunk/clangd/clients/clangd-vscode/README.md
===
--- clang-tools-extra/trunk/clangd/clients/clangd-vscode/README.md
+++ clang-tools-extra/trunk/clangd/clients/clangd-vscode/README.md
@@ -50,6 +50,11 @@
# When VS Code starts, press .
 ```
 
+## Contributing
+
+Please follow the exsiting code style when contributing to the extension, we
+recommend to run `npm run format` before sending a patch.
+
 ## Publish to VS Code Marketplace
 
 New changes to `clangd-vscode` are not released until a new version is published
Index: clang-tools-extra/trunk/clangd/clients/clangd-vscode/src/extension.ts
===
--- clang-tools-extra/trunk/clangd/clients/clangd-vscode/src/extension.ts
+++ clang-tools-extra/trunk/clangd/clients/clangd-vscode/src/extension.ts
@@ -7,8 +7,8 @@
  * @param defaultValue default value to return if option is not set
  */
 function getConfig(option: string, defaultValue?: any): T {
-const config = vscode.workspace.getConfiguration('clangd');
-return config.get(option, defaultValue);
+  const config = vscode.workspace.getConfiguration('clangd');
+  return config.get(option, defaultValue);
 }
 
 namespace SwitchSourceHeaderRequest {
@@ -18,35 +18,33 @@
 }
 
 class FileStatus {
-private statuses = new Map();
-private readonly statusBarItem =
-vscode.window.createStatusBarItem(vscode.StatusBarAlignment.Left, 10);
-
-onFileUpdated(fileStatus: any) {
-const filePath = vscode.Uri.parse(fileStatus.uri);
-this.

[PATCH] D65573: Add User docs for ASTImporter

[Gabor Marton via Phabricator via cfe-commits]

martong marked 23 inline comments as done.
martong added a comment.

Thanks for the review!




Comment at: clang/docs/LibASTImporter.rst:19
+``ASTContext`` holds long-lived AST nodes (such as types and decls) that can 
be referred to throughout the semantic analysis of a file.
+There are cases when we would like to work with more than one ``ASTContext``.
+For example, we'd like to parse multiple different files inside the same Clang 
tool.

aprantl wrote:
> Stylistic note: usually LLVM documentation is written avoiding "we". So for 
> example:
> 
> ```
> In some cases it is preferable to work with more than one ``ASTContext``, for 
> example when parsing multiple files inside one Clang-based tool.
> ```
In one hand, I accept that maybe the word "we" is overused in this document.
I'll try to rephrase those sentences where it feels awkward.

On the other hand, I feel if all occurrences of "we" were replaced then the 
document would become filled with passive voice. That would make it too formal 
and would provide harder reading in my opinion.
Also, other AST related documentation uses "we" quite frequently. E.g. 
https://clang.llvm.org/docs/LibASTMatchersTutorial.html has 42 matches of "we".

 l have rephrased those sentences which you explicitly mentioned, please add 
comments to those sentences where you still feel the use of "we" inappropriate.



Comment at: clang/docs/LibASTImporter.rst:32
+
+By importing one AST node we copy that node into the destination 
``ASTContext``.
+Why do we have to copy the node?

gamesh411 wrote:
> I'd put a comma here:
> By importing one AST node,  we copy
I changed to Adrian's suggestion.



Comment at: clang/docs/LibASTImporter.rst:110
+
+Now we create the Importer and do the import:
+

shafik wrote:
> Maybe helpful to link to the [Matching the Clang 
> AST](https://clang.llvm.org/docs/LibASTMatchers.html) and [AST Matcher 
> Reference](https://clang.llvm.org/docs/LibASTMatchersReference.html)
Ok, I've added them to the beginning of the doc.



Comment at: clang/docs/LibASTImporter.rst:283
+However, there may be cases when both of the contexts have a definition for a 
given symbol.
+If these definitions differ then we have a name conflict, otherwise known as 
ODR (one definition rule) violation.
+Let's modify the previous tool we had written and try to import a 
``ClassTemplateSpecializationDecl`` with a conflicting definition:

gamesh411 wrote:
> shafik wrote:
> > Note ODR is a C++ concept C does not have ODR
> I'd put a comma here:
> If these definitions differ, then we ...
Changed to 
"If these definitions differ, then we have a name conflict, in C++ it is known 
as ODR (one definition rule) violation."



Comment at: clang/docs/LibASTImporter.rst:410
+
+There are cases when during the import of a dependent node we recognize an 
error, however, by that time we already created the dependant.
+In these cases we do not remove the existing erroneous node from the "to" 
context, rather we associate an error to that node.

gamesh411 wrote:
> I'd phrase it like this:
> We may recognize an error during the import of a dependent node. However, by 
> that time, we have already created the dependant.
I changed to use past perfect as well to emphasize that the node had been 
created before the error was recognized.
"We may recognize an error during the import of a dependent node. However, by 
that time, we had already created the dependant."


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65573



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

[PATCH] D65573: Add User docs for ASTImporter

[Gabor Marton via Phabricator via cfe-commits]

martong updated this revision to Diff 213046.
martong marked 5 inline comments as done.
martong added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65573

Files:
  clang/docs/LibASTImporter.rst
  clang/docs/index.rst

Index: clang/docs/index.rst
===
--- clang/docs/index.rst
+++ clang/docs/index.rst
@@ -61,6 +61,7 @@
RAVFrontendAction
LibASTMatchersTutorial
LibASTMatchers
+   LibASTImporter
HowToSetupToolingForLLVM
JSONCompilationDatabase
RefactoringEngine
Index: clang/docs/LibASTImporter.rst
===
--- /dev/null
+++ clang/docs/LibASTImporter.rst
@@ -0,0 +1,496 @@
+===
+ASTImporter: Merging Clang ASTs
+===
+
+The ``ASTImporter`` class is part of Clang's core library, the AST library.
+It imports nodes of an ``ASTContext`` into another ``ASTContext``.
+
+In this document, we assume basic knowledge about the Clang AST.  See the :doc:`Introduction
+to the Clang AST ` if you want to learn more
+about how the AST is structured.
+Knowledge about :doc:`matching the Clang AST ` and the `reference for the matchers `_ are also useful.
+
+.. contents::
+   :local:
+
+Introduction
+
+
+``ASTContext`` holds long-lived AST nodes (such as types and decls) that can be referred to throughout the semantic analysis of a file.
+In some cases it is preferable to work with more than one ``ASTContext``.
+For example, we'd like to parse multiple different files inside the same Clang tool.
+It may be convenient if we could view the set of the resulting ASTs as if they were one AST resulting from the parsing of each file together.
+``ASTImporter`` provides the way to copy types or declarations from one ``ASTContext`` to another.
+We refer to the context from which we import as the **"from" context** or *source context*; and the context into which we import as the **"to" context** or *destination context*.
+
+Existing clients of the ``ASTImporter`` library are Cross Translation Unit (CTU) static analysis and the LLDB expression parser.
+CTU static analysis imports a definition of a function if its definition is found in another translation unit (TU).
+This way the analysis can breach out from the single TU limitation.
+LLDB's ``expr`` command parses a user-defined expression, creates an ``ASTContext`` for that and then imports the missing definitions from the AST what we got from the debug information (DWARF, etc).
+
+Algorithm of the import
+---
+
+Importing one AST node copies that node into the destination ``ASTContext``.
+Why do we have to copy the node?
+Isn't enough to insert the pointer to that node into the destination context?
+One reason is that the "from" context may outlive the "to" context.
+Also, the Clang AST consider nodes (or certain properties of nodes) equivalent if they have the same address!
+
+The import algorithm has to ensure that the structurally equivalent nodes in the different translation units are not getting duplicated in the merged AST.
+E.g. if we include the definition of the vector template (``#include ``) in two translation units, then their merged AST should have only one node which represents the template.
+Also, we have to discover *one definition rule* (ODR) violations.
+For instance, if there is a class definition with the same name in both translation units, but one of the definition contains a different number of fields.
+So, we look up existing definitions, and then we check the structural equivalency on those nodes.
+The following pseudo-code demonstrates the basics of the import mechanism:
+
+.. code-block:: cpp
+
+  // Pseudo-code(!) of import:
+  ErrorOrDecl Import(Decl *FromD) {
+Decl *ToDecl = nullptr;
+FoundDeclsList = Look up all Decls in the "to" Ctx with the same name of FromD;
+for (auto FoundDecl : FoundDeclsList) {
+  if (StructurallyEquivalentDecls(FoundDecl, FromD)) {
+ToDecl = FoundDecl;
+Mark FromD as imported;
+break;
+  } else {
+Report ODR violation;
+return error;
+  }
+}
+if (FoundDeclsList is empty) {
+  Import dependent declarations and types of ToDecl;
+  ToDecl = create a new AST node in "to" Ctx;
+  Mark FromD as imported;
+}
+return ToDecl;
+  }
+
+Two AST nodes are *structurally equivalent* if they are
+
+- builtin types and refer to the same type, e.g. ``int`` and ``int`` are structurally equivalent,
+- function types and all their parameters have structurally equivalent types,
+- record types and all their fields in order of their definition have the same identifier names and structurally equivalent types,
+- variable or function declarations and they have the same 

[PATCH] D64932: [Parser] Emit descriptive diagnostic for misplaced pragma

[John McCall via Phabricator via cfe-commits]

rjmccall accepted this revision.
rjmccall 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/D64932/new/

https://reviews.llvm.org/D64932



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

[clang-tools-extra] r367687 - [clangd] Fix a crash when presenting values for Hover

[Ilya Biryukov via cfe-commits]

Author: ibiryukov
Date: Fri Aug  2 08:23:04 2019
New Revision: 367687

URL: http://llvm.org/viewvc/llvm-project?rev=367687&view=rev
Log:
[clangd] Fix a crash when presenting values for Hover

Summary:
We should pass the expression type, not a variable type when printing
the resulting value. Variable type may be different from what the
pretty-printing function expects, e.g. have references.

Reviewers: sammccall

Reviewed By: sammccall

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

Tags: #clang

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

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

Modified: clang-tools-extra/trunk/clangd/XRefs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/XRefs.cpp?rev=367687&r1=367686&r2=367687&view=diff
==
--- clang-tools-extra/trunk/clangd/XRefs.cpp (original)
+++ clang-tools-extra/trunk/clangd/XRefs.cpp Fri Aug  2 08:23:04 2019
@@ -715,7 +715,7 @@ static HoverInfo getHoverContents(const
 HI.Value.emplace();
 llvm::raw_string_ostream ValueOS(*HI.Value);
 Result.Val.printPretty(ValueOS, const_cast(Ctx),
-   Var->getType());
+   Init->getType());
   }
 }
   }

Modified: clang-tools-extra/trunk/clangd/unittests/XRefsTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/XRefsTests.cpp?rev=367687&r1=367686&r2=367687&view=diff
==
--- clang-tools-extra/trunk/clangd/unittests/XRefsTests.cpp (original)
+++ clang-tools-extra/trunk/clangd/unittests/XRefsTests.cpp Fri Aug  2 08:23:04 
2019
@@ -1793,6 +1793,16 @@ TEST(Hover, All) {
   "int\n"
   "]",
   },
+  {
+  R"cpp(// Should not crash when evaluating the initializer.
+struct Test {};
+void test() { Test && te^st = {}; }
+  )cpp",
+  "text[Declared in]code[test]\n"
+  "codeblock(cpp) [\n"
+  "struct Test &&test = {}\n"
+  "]",
+  },
   };
 
   // Create a tiny index, so tests above can verify documentation is fetched.


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

[PATCH] D65655: [clangd] Fix a crash when presenting values for Hover

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367687: [clangd] Fix a crash when presenting values for 
Hover (authored by ibiryukov, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65655?vs=213037&id=213053#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65655

Files:
  clang-tools-extra/trunk/clangd/XRefs.cpp
  clang-tools-extra/trunk/clangd/unittests/XRefsTests.cpp


Index: clang-tools-extra/trunk/clangd/XRefs.cpp
===
--- clang-tools-extra/trunk/clangd/XRefs.cpp
+++ clang-tools-extra/trunk/clangd/XRefs.cpp
@@ -715,7 +715,7 @@
 HI.Value.emplace();
 llvm::raw_string_ostream ValueOS(*HI.Value);
 Result.Val.printPretty(ValueOS, const_cast(Ctx),
-   Var->getType());
+   Init->getType());
   }
 }
   }
Index: clang-tools-extra/trunk/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/XRefsTests.cpp
@@ -1793,6 +1793,16 @@
   "int\n"
   "]",
   },
+  {
+  R"cpp(// Should not crash when evaluating the initializer.
+struct Test {};
+void test() { Test && te^st = {}; }
+  )cpp",
+  "text[Declared in]code[test]\n"
+  "codeblock(cpp) [\n"
+  "struct Test &&test = {}\n"
+  "]",
+  },
   };
 
   // Create a tiny index, so tests above can verify documentation is fetched.


Index: clang-tools-extra/trunk/clangd/XRefs.cpp
===
--- clang-tools-extra/trunk/clangd/XRefs.cpp
+++ clang-tools-extra/trunk/clangd/XRefs.cpp
@@ -715,7 +715,7 @@
 HI.Value.emplace();
 llvm::raw_string_ostream ValueOS(*HI.Value);
 Result.Val.printPretty(ValueOS, const_cast(Ctx),
-   Var->getType());
+   Init->getType());
   }
 }
   }
Index: clang-tools-extra/trunk/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/XRefsTests.cpp
@@ -1793,6 +1793,16 @@
   "int\n"
   "]",
   },
+  {
+  R"cpp(// Should not crash when evaluating the initializer.
+struct Test {};
+void test() { Test && te^st = {}; }
+  )cpp",
+  "text[Declared in]code[test]\n"
+  "codeblock(cpp) [\n"
+  "struct Test &&test = {}\n"
+  "]",
+  },
   };
 
   // Create a tiny index, so tests above can verify documentation is fetched.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65655: [clangd] Fix a crash when presenting values for Hover

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a subscriber: hans.
ilya-biryukov added a comment.

@hans, could we merge this commit into the release branch?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D65655



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

[PATCH] D64464: [CodeGen] Emit destructor calls for non-trivial C structs

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.
Herald added a subscriber: rnkovacs.



Comment at: include/clang/AST/ExprCXX.h:3220
+  /// It's useful to remember the set of blocks and compound literals; we could
+  /// also remember the set of temporaries, but there's currently no need.
+  using CleanupObject = llvm::PointerUnion;

Might be worth spelling out `and block-scoped compound literals` here.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5171
+def note_enters_compound_literal_scope : Note<
+  "jump enters lifetime of a compound literal that is non-trivial to 
destruct">;
 

Ah, good catch.



Comment at: include/clang/Sema/Sema.h:587
   /// cleanup that are created by the current full expression.  The
   /// element type here is ExprWithCleanups::Object.
+  SmallVector ExprCleanupObjects;

I think the second sentence in this comment is no longer useful; you can just 
strike it.



Comment at: lib/CodeGen/CGBlocks.cpp:863
 /// clean up.  This is in this file because, at the moment, the only
 /// kind of cleanup object is a BlockDecl*.
 void CodeGenFunction::enterNonTrivialFullExpression(const FullExpr *E) {

This comment is no longer accurate.  If you want to move the function, please 
do so in a separate commit, though.



Comment at: lib/CodeGen/CGCleanup.cpp:1283
+  // the end of its enclosing block. Push an inactive cleanup here so that its
+  // destructor is called when the lifetime ends.
+  QualType Ty = CLE->getType();

Please include in the comment here that this doesn't apply in C++, where the 
compound literal has temporary lifetime.

Can we clarify that we're talking about block-scope literals in all the new 
method names?



Comment at: lib/CodeGen/CGDecl.cpp:555
+  bool useEHCleanupForArray =
+  flags.isForNormalCleanup() && this->useEHCleanupForArray;
+  CGF.emitDestroy(CGF.CompoundLiteralCleanupInfoMap[CLE].getAddr(),

It'd be nice to not shadow the enclosing variable.



Comment at: lib/CodeGen/CGExpr.cpp:4100
+  if (E->getType().isDestructedType() == QualType::DK_nontrivial_c_struct)
+pushDestroy(QualType::DK_nontrivial_c_struct, DeclPtr, E->getType());
+

rjmccall wrote:
> Unfortunately, the lifetime of compound literals in C is not this simple; 
> they're like blocks in that they're destroyed at the end of the enclosing 
> scope rather than at the end of the current statement. (The cleanup here will 
> be popped at the end of the full-expression if we've entered an 
> `ExprWithCleanups`.) And the l-value case is exactly the case where this 
> matters.
> 
> I think you need to do something like what we do with blocks, where we record 
> all the blocks in the full-expression on the `ExprWithCleanups` so that we 
> can push an inactive cleanup for them and then activate it when we emit the 
> block.
Can we make the check here something like (1) this is a block-scope compound 
literal and (2) it has a non-trivially-destructed type (of any kind)?  That way 
we're not conflating two potentially unrelated elements, the lifetime of the 
object and the kinds of types that can be constructed by the literal.

Oh, actually, there's a concrete reason to do this: C99 compound literals are 
not required to have struct type; they can have any object type, including 
arrays but also scalars.  So we could, even without non-trivial C structs, have 
a block-scope compound of type `__strong id[]`; I guess we've always just 
gotten this wrong.  Please add tests for this case. :)



Comment at: lib/CodeGen/CGExpr.cpp:4647
+pushDestroy(QualType::DK_nontrivial_c_struct, RV.getAggregateAddress(),
+E->getType());
+

Does `EmitCallExpr` not enter a cleanup when it returns an aggregate that's not 
into an externally-destructed slot?  That seems wrong and dangerous.


Repository:
  rC Clang

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

https://reviews.llvm.org/D64464



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

[PATCH] D65300: [clang] [CodeGen] clang-misexpect prototype for compiler warnings

[Paul Kirth via Phabricator via cfe-commits]

paulkirth updated this revision to Diff 213059.
paulkirth marked 2 inline comments as done.
paulkirth added a comment.

Fix typo in comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65300

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CMakeLists.txt
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/MisExpect.cpp
  clang/lib/CodeGen/MisExpect.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Profile/Inputs/misexpect-branch-nonconst-expect-arg.proftext
  clang/test/Profile/Inputs/misexpect-branch.proftext
  clang/test/Profile/Inputs/misexpect-switch-default-only.proftext
  clang/test/Profile/Inputs/misexpect-switch.proftext
  clang/test/Profile/misexpect-branch-cold.c
  clang/test/Profile/misexpect-branch-nonconst-expected-val.c
  clang/test/Profile/misexpect-branch.c
  clang/test/Profile/misexpect-no-warning-without-flag.c
  clang/test/Profile/misexpect-switch-default.c
  clang/test/Profile/misexpect-switch-nonconst.c
  clang/test/Profile/misexpect-switch-only-default-case.c
  clang/test/Profile/misexpect-switch.c

Index: clang/test/Profile/misexpect-switch.c
===
--- /dev/null
+++ clang/test/Profile/misexpect-switch.c
@@ -0,0 +1,68 @@
+// Test that misexpect detects mis-annotated switch statements
+
+// RUN: llvm-profdata merge %S/Inputs/misexpect-switch.proftext -o %t.profdata
+// RUN: %clang_cc1 %s -O2 -o - -disable-llvm-passes -emit-llvm -fprofile-instrument-use-path=%t.profdata -verify -fmisexpect
+
+int sum(int *buff, int size);
+int random_sample(int *buff, int size);
+int rand();
+
+const int inner_loop = 1000;
+const int outer_loop = 20;
+const int arry_size = 25;
+
+int arry[arry_size] = {0};
+
+void init_arry() {
+  int i;
+  for (i = 0; i < arry_size; ++i) {
+arry[i] = rand() % 10;
+  }
+}
+
+int main() {
+  init_arry();
+  int val = 0;
+
+  int j, k;
+  for (j = 0; j < outer_loop; ++j) {
+for (k = 0; k < inner_loop; ++k) {
+  unsigned condition = rand() % 1;
+  switch (__builtin_expect(condition, 0)) { //expected-warning {{Current PGO counters disagree with the use of __builtin_expect().}}
+  case 0:
+val += sum(arry, arry_size);
+break;
+  case 1:
+  case 2:
+  case 3:
+  case 4:
+val += random_sample(arry, arry_size);
+break;
+  default:
+__builtin_unreachable();
+  } // end switch
+}   // end inner_loop
+  } // end outer_loop
+
+  return 0;
+}
+
+int sum(int *buff, int size) {
+  int total = 0;
+  int i = 0;
+  for (i = 0; i < size; ++i) {
+total += buff[i];
+  }
+  return total;
+}
+
+int random_sample(int *buff, int size) {
+  int total = 0;
+  int i;
+  for (i = 0; i < size; ++i) {
+if (rand() % 5 == 0)
+  total += buff[i];
+  }
+
+  return total;
+}
Index: clang/test/Profile/misexpect-switch-only-default-case.c
===
--- /dev/null
+++ clang/test/Profile/misexpect-switch-only-default-case.c
@@ -0,0 +1,62 @@
+// Test that misexpect detects mis-annotated switch statements
+
+// RUN: llvm-profdata merge %S/Inputs/misexpect-switch-default-only.proftext -o %t.profdata
+// RUN: %clang_cc1 %s -O2 -o - -disable-llvm-passes -emit-llvm -fprofile-instrument-use-path=%t.profdata -verify -fmisexpect
+
+// expected-no-diagnostics
+int sum(int *buff, int size);
+int random_sample(int *buff, int size);
+int rand();
+
+const int inner_loop = 1000;
+const int outer_loop = 20;
+const int arry_size = 25;
+
+int arry[arry_size] = {0};
+
+void init_arry() {
+  int i;
+  for (i = 0; i < arry_size; ++i) {
+arry[i] = rand() % 10;
+  }
+}
+
+int main()
+{
+init_arry();
+int val = 0;
+
+int j, k;
+for (j = 0; j < outer_loop; ++j) {
+for (k = 0; k < inner_loop; ++k) {
+unsigned condition = rand() % 1;
+switch (__builtin_expect(condition, 0)) {
+default:
+val += random_sample(arry, arry_size);
+break;
+}; // end switch
+}  // end inner_loop
+}  // end outer_loop
+
+return 0;
+}
+
+int sum(int *buff, int size) {
+  int total = 0;
+  int i = 0;
+  for (i = 0; i < size; ++i) {
+total += buff[i];
+  }
+  return total;
+}
+
+int random_sample(int *buff, int size) {
+  int total = 0;
+  int i;
+  for (i = 0; i < size; ++i) {
+if (rand() % 5 == 0)
+  total += buff[i];
+  }
+
+  return total;
+}
Index: clang/test/Profile/misexpect-switch-nonconst.c
===
--- /dev/null
+++ clang/test/Profile/misexpect-switch-nonconst.c
@@ -0,0 +1,69 @@
+// Test that misexpect detects mis-annotated switch statements
+
+// 

[PATCH] D65192: [Sema] Make -Wbitwise-op-parentheses and -Wlogical-op-parentheses disabled-by-default

[Fangrui Song via Phabricator via cfe-commits]

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

Add bitwise-op-parentheses.c logical-op-parentheses.c


Repository:
  rC Clang

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

https://reviews.llvm.org/D65192

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  test/Sema/bitwise-op-parentheses.c
  test/Sema/logical-op-parentheses.c
  test/Sema/parentheses.c
  test/SemaCXX/parentheses.cpp

Index: test/SemaCXX/parentheses.cpp
===
--- test/SemaCXX/parentheses.cpp
+++ test/SemaCXX/parentheses.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -verify %s
+// RUN: %clang_cc1 -verify -Wlogical-op-parentheses %s
 
 // PR16930, PR16727:
 template
Index: test/Sema/parentheses.c
===
--- test/Sema/parentheses.c
+++ test/Sema/parentheses.c
@@ -1,5 +1,6 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
 // RUN: %clang_cc1 -Wparentheses -fsyntax-only -verify %s
-// RUN: %clang_cc1 -Wparentheses -fsyntax-only -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -DWARN_BITWISE -DWARN_LOGICAL -Wparentheses -fsyntax-only -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
 
 // Test the various warnings under -Wparentheses
 void if_assign(void) {
@@ -44,58 +45,6 @@
   // Eager logical op
   (void)(i == 1 | i == 2 | i == 3);
   (void)(i != 1 & i != 2 & i != 3);
-
-  (void)(i & i | i); // expected-warning {{'&' within '|'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:10-[[@LINE-2]]:10}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:15-[[@LINE-3]]:15}:")"
-
-  (void)(i | i & i); // expected-warning {{'&' within '|'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:19-[[@LINE-3]]:19}:")"
-
-  (void)(i ^ i | i); // expected-warning {{'^' within '|'}} \
- // expected-note {{place parentheses around the '^' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:10-[[@LINE-2]]:10}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:15-[[@LINE-3]]:15}:")"
-
-  (void)(i | i ^ i); // expected-warning {{'^' within '|'}} \
- // expected-note {{place parentheses around the '^' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:19-[[@LINE-3]]:19}:")"
-
-  (void)(i & i ^ i); // expected-warning {{'&' within '^'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:10-[[@LINE-2]]:10}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:15-[[@LINE-3]]:15}:")"
-
-  (void)(i ^ i & i); // expected-warning {{'&' within '^'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:19-[[@LINE-3]]:19}:")"
-
-  (void)(i ||
- i && i); // expected-warning {{'&&' within '||'}} \
-  // expected-note {{place parentheses around the '&&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:20}:")"
-
-  (void)(i || i && "w00t"); // no warning.
-  (void)("w00t" && i || i); // no warning.
-
-  (void)(i || i && "w00t" || i); // expected-warning {{'&&' within '||'}} \
- // expected-note {{place parentheses around the '&&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:15-[[@LINE-2]]:15}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:26-[[@LINE-3]]:26}:")"
-
-  (void)(i || "w00t" && i || i); // expected-warning {{'&&' within '||'}} \
- // expected-note {{place parentheses around the '&&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:15-[[@LINE-2]]:15}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:26-[[@LINE-3]]:26}:")"
-
-  (void)(i && i || 0); // no warning.
-  (void)(0 || i && i); // no warning.
 }
 
 _Bool someConditionFunc();
Index: test/Sema/logical-op-parentheses.c
===
--- /dev/null
+++ test/Sema/logical-op-parentheses.c
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -DSILENCE
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wlogical-op-parentheses
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wparentheses
+// RUN: %clang_cc1 -fsyntax-only -fdiagnostics-parseable-fixits %s -Wlogical-op-parentheses 2>&1 | FileCheck %s
+
+#ifdef SILENCE
+// expected-no-diagnostics
+#

r367690 - [Sema] Disable -Wbitwise-op-parentheses and -Wlogical-op-parentheses by default

[Fangrui Song via cfe-commits]

Author: maskray
Date: Fri Aug  2 09:31:38 2019
New Revision: 367690

URL: http://llvm.org/viewvc/llvm-project?rev=367690&view=rev
Log:
[Sema] Disable -Wbitwise-op-parentheses and -Wlogical-op-parentheses by default

Summary:
The -Wparentheses warnings are enabled by default in clang but they are under
-Wall in gcc (gcc/c-family/c.opt). Some of the operator precedence warnings are
oftentimes criticized as noise (clang: default; gcc: -Wall). If a warning is
very controversial, it is probably not a good idea to enable it by default.
This patch disables the rather annoying ones:

-Wbitwise-op-parentheses, e.g. i & i | i
-Wlogical-op-parentheses, e.g. i && i || i

After this change:

```
* = enabled by default

-Wall
  -Wparentheses
-Wlogical-op-parentheses
-Wlogical-not-parentheses*
-Wbitwise-op-parentheses
-Wshift-op-parentheses*
-Woverloaded-shift-op-parentheses*
-Wparentheses-equality*
-Wdangling-else*
```

-Woverloaded-shift-op-parentheses is typically followed by overload
resolution failure. We can instead improve the error message, and
probably delete -Woverloaded-shift-op-parentheses in the future. Keep it
for now because it gives some diagnostics.

Reviewers: akyrtzi, jyknight, rtrieu, rsmith, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: dexonsmith, cfe-commits

Tags: #clang

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

Added:
cfe/trunk/test/Sema/bitwise-op-parentheses.c
cfe/trunk/test/Sema/logical-op-parentheses.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/test/Sema/parentheses.c
cfe/trunk/test/SemaCXX/parentheses.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=367690&r1=367689&r2=367690&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Aug  2 09:31:38 
2019
@@ -5642,10 +5642,10 @@ def note_logical_instead_of_bitwise_remo
   "remove constant to silence this warning">;
 
 def warn_bitwise_op_in_bitwise_op : Warning<
-  "'%0' within '%1'">, InGroup;
+  "'%0' within '%1'">, InGroup, DefaultIgnore;
 
 def warn_logical_and_in_logical_or : Warning<
-  "'&&' within '||'">, InGroup;
+  "'&&' within '||'">, InGroup, DefaultIgnore;
 
 def warn_overloaded_shift_in_comparison :Warning<
   "overloaded operator %select{>>|<<}0 has higher precedence than "

Added: cfe/trunk/test/Sema/bitwise-op-parentheses.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/bitwise-op-parentheses.c?rev=367690&view=auto
==
--- cfe/trunk/test/Sema/bitwise-op-parentheses.c (added)
+++ cfe/trunk/test/Sema/bitwise-op-parentheses.c Fri Aug  2 09:31:38 2019
@@ -0,0 +1,58 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -DSILENCE
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wbitwise-op-parentheses
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wparentheses
+// RUN: %clang_cc1 -fsyntax-only -fdiagnostics-parseable-fixits %s 
-Wbitwise-op-parentheses 2>&1 | FileCheck %s
+
+#ifdef SILENCE
+// expected-no-diagnostics
+#endif
+
+void bitwise_op_parentheses(unsigned i) {
+  (void)(i & i | i);
+#ifndef SILENCE
+  // expected-warning@-2 {{'&' within '|'}}
+  // expected-note@-3 {{place parentheses around the '&' expression to silence 
this warning}}
+#endif
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-5]]:10-[[@LINE-5]]:10}:"("
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-6]]:15-[[@LINE-6]]:15}:")"
+
+  (void)(i | i & i);
+#ifndef SILENCE
+  // expected-warning@-2 {{'&' within '|'}}
+  // expected-note@-3 {{place parentheses around the '&' expression to silence 
this warning}}
+#endif
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-5]]:14-[[@LINE-5]]:14}:"("
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-6]]:19-[[@LINE-6]]:19}:")"
+
+  (void)(i ^ i | i);
+#ifndef SILENCE
+  // expected-warning@-2 {{'^' within '|'}}
+  // expected-note@-3 {{place parentheses around the '^' expression to silence 
this warning}}
+#endif
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-5]]:10-[[@LINE-5]]:10}:"("
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-6]]:15-[[@LINE-6]]:15}:")"
+
+  (void)(i | i ^ i);
+#ifndef SILENCE
+  // expected-warning@-2 {{'^' within '|'}}
+  // expected-note@-3 {{place parentheses around the '^' expression to silence 
this warning}}
+#endif
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-5]]:14-[[@LINE-5]]:14}:"("
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-6]]:19-[[@LINE-6]]:19}:")"
+
+  (void)(i & i ^ i);
+#ifndef SILENCE
+  // expected-warning@-2 {{'&' within '^'}}
+  // expected-note@-3 {{place parentheses around the '&' expression to silence 
this warning}}
+#endif
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-5]]:10-[[@LINE-5]]:10}:"("
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-6]]:15-[[@LINE-6]]:15}:")"
+
+  (void)(i ^ i & i);
+#ifndef SILENCE
+  

[PATCH] D65192: [Sema] Make -Wbitwise-op-parentheses and -Wlogical-op-parentheses disabled-by-default

[Fangrui Song via Phabricator via cfe-commits]

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

.


Repository:
  rC Clang

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

https://reviews.llvm.org/D65192

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  test/Sema/bitwise-op-parentheses.c
  test/Sema/logical-op-parentheses.c
  test/Sema/parentheses.c
  test/SemaCXX/parentheses.cpp

Index: test/SemaCXX/parentheses.cpp
===
--- test/SemaCXX/parentheses.cpp
+++ test/SemaCXX/parentheses.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -verify %s
+// RUN: %clang_cc1 -verify -Wlogical-op-parentheses %s
 
 // PR16930, PR16727:
 template
Index: test/Sema/parentheses.c
===
--- test/Sema/parentheses.c
+++ test/Sema/parentheses.c
@@ -1,3 +1,4 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
 // RUN: %clang_cc1 -Wparentheses -fsyntax-only -verify %s
 // RUN: %clang_cc1 -Wparentheses -fsyntax-only -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
 
@@ -44,58 +45,6 @@
   // Eager logical op
   (void)(i == 1 | i == 2 | i == 3);
   (void)(i != 1 & i != 2 & i != 3);
-
-  (void)(i & i | i); // expected-warning {{'&' within '|'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:10-[[@LINE-2]]:10}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:15-[[@LINE-3]]:15}:")"
-
-  (void)(i | i & i); // expected-warning {{'&' within '|'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:19-[[@LINE-3]]:19}:")"
-
-  (void)(i ^ i | i); // expected-warning {{'^' within '|'}} \
- // expected-note {{place parentheses around the '^' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:10-[[@LINE-2]]:10}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:15-[[@LINE-3]]:15}:")"
-
-  (void)(i | i ^ i); // expected-warning {{'^' within '|'}} \
- // expected-note {{place parentheses around the '^' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:19-[[@LINE-3]]:19}:")"
-
-  (void)(i & i ^ i); // expected-warning {{'&' within '^'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:10-[[@LINE-2]]:10}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:15-[[@LINE-3]]:15}:")"
-
-  (void)(i ^ i & i); // expected-warning {{'&' within '^'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:19-[[@LINE-3]]:19}:")"
-
-  (void)(i ||
- i && i); // expected-warning {{'&&' within '||'}} \
-  // expected-note {{place parentheses around the '&&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:20}:")"
-
-  (void)(i || i && "w00t"); // no warning.
-  (void)("w00t" && i || i); // no warning.
-
-  (void)(i || i && "w00t" || i); // expected-warning {{'&&' within '||'}} \
- // expected-note {{place parentheses around the '&&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:15-[[@LINE-2]]:15}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:26-[[@LINE-3]]:26}:")"
-
-  (void)(i || "w00t" && i || i); // expected-warning {{'&&' within '||'}} \
- // expected-note {{place parentheses around the '&&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:15-[[@LINE-2]]:15}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:26-[[@LINE-3]]:26}:")"
-
-  (void)(i && i || 0); // no warning.
-  (void)(0 || i && i); // no warning.
 }
 
 _Bool someConditionFunc();
Index: test/Sema/logical-op-parentheses.c
===
--- /dev/null
+++ test/Sema/logical-op-parentheses.c
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s -DSILENCE
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wlogical-op-parentheses
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wparentheses
+// RUN: %clang_cc1 -fsyntax-only -fdiagnostics-parseable-fixits %s -Wlogical-op-parentheses 2>&1 | FileCheck %s
+
+#ifdef SILENCE
+// expected-no-diagnostics
+#endif
+
+void logical_op_parentheses(unsigned i) {
+  (void)(i ||
+ i && i);
+#ifndef SILENCE
+  // expected-warning@-2 {{'&&' within '||'}}
+  // expected-note@-3 {{place parentheses around the '&&' expression to silence this warning}}
+#endif
+

[PATCH] D65192: [Sema] Make -Wbitwise-op-parentheses and -Wlogical-op-parentheses disabled-by-default

[Fangrui Song via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367690: [Sema] Disable -Wbitwise-op-parentheses and 
-Wlogical-op-parentheses by default (authored by MaskRay, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65192

Files:
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/test/Sema/bitwise-op-parentheses.c
  cfe/trunk/test/Sema/logical-op-parentheses.c
  cfe/trunk/test/Sema/parentheses.c
  cfe/trunk/test/SemaCXX/parentheses.cpp

Index: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
@@ -5642,10 +5642,10 @@
   "remove constant to silence this warning">;
 
 def warn_bitwise_op_in_bitwise_op : Warning<
-  "'%0' within '%1'">, InGroup;
+  "'%0' within '%1'">, InGroup, DefaultIgnore;
 
 def warn_logical_and_in_logical_or : Warning<
-  "'&&' within '||'">, InGroup;
+  "'&&' within '||'">, InGroup, DefaultIgnore;
 
 def warn_overloaded_shift_in_comparison :Warning<
   "overloaded operator %select{>>|<<}0 has higher precedence than "
Index: cfe/trunk/test/SemaCXX/parentheses.cpp
===
--- cfe/trunk/test/SemaCXX/parentheses.cpp
+++ cfe/trunk/test/SemaCXX/parentheses.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -verify %s
+// RUN: %clang_cc1 -verify -Wlogical-op-parentheses %s
 
 // PR16930, PR16727:
 template
Index: cfe/trunk/test/Sema/parentheses.c
===
--- cfe/trunk/test/Sema/parentheses.c
+++ cfe/trunk/test/Sema/parentheses.c
@@ -1,3 +1,4 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
 // RUN: %clang_cc1 -Wparentheses -fsyntax-only -verify %s
 // RUN: %clang_cc1 -Wparentheses -fsyntax-only -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
 
@@ -44,58 +45,6 @@
   // Eager logical op
   (void)(i == 1 | i == 2 | i == 3);
   (void)(i != 1 & i != 2 & i != 3);
-
-  (void)(i & i | i); // expected-warning {{'&' within '|'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:10-[[@LINE-2]]:10}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:15-[[@LINE-3]]:15}:")"
-
-  (void)(i | i & i); // expected-warning {{'&' within '|'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:19-[[@LINE-3]]:19}:")"
-
-  (void)(i ^ i | i); // expected-warning {{'^' within '|'}} \
- // expected-note {{place parentheses around the '^' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:10-[[@LINE-2]]:10}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:15-[[@LINE-3]]:15}:")"
-
-  (void)(i | i ^ i); // expected-warning {{'^' within '|'}} \
- // expected-note {{place parentheses around the '^' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:19-[[@LINE-3]]:19}:")"
-
-  (void)(i & i ^ i); // expected-warning {{'&' within '^'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:10-[[@LINE-2]]:10}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:15-[[@LINE-3]]:15}:")"
-
-  (void)(i ^ i & i); // expected-warning {{'&' within '^'}} \
- // expected-note {{place parentheses around the '&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:19-[[@LINE-3]]:19}:")"
-
-  (void)(i ||
- i && i); // expected-warning {{'&&' within '||'}} \
-  // expected-note {{place parentheses around the '&&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:14-[[@LINE-2]]:14}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:20}:")"
-
-  (void)(i || i && "w00t"); // no warning.
-  (void)("w00t" && i || i); // no warning.
-
-  (void)(i || i && "w00t" || i); // expected-warning {{'&&' within '||'}} \
- // expected-note {{place parentheses around the '&&' expression to silence this warning}}
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-2]]:15-[[@LINE-2]]:15}:"("
-  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:26-[[@LINE-3]]:26}:")"
-
-  (void)(i || "w00t" && i || i); // expected-warning {{'&&' within '||'}} \
- // expected-note {{place parentheses around the '&&' expression to silence this warning}}
-  // C

[PATCH] D65517: [Preprocessor] Always discard body of #define if we failed to parse it

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

Thanks!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D65517



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

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

[Charles Zhang via Phabricator via cfe-commits]

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



Comment at: 
clang-tools-extra/test/clang-tidy/bugprone-dynamic-static-initializers.hpp:33-35
+  // This may work fine when optimization is enabled because bar() can
+  // be turned into a constant 7.  But without optimization, it can
+  // cause problems. Therefore, we must err on the side of conservatism.

aaron.ballman wrote:
> czhang wrote:
> > aaron.ballman wrote:
> > > What problems can be caused here? Typically, dynamic init is only 
> > > problematic when it happens before main() is executed (because of 
> > > initialization order dependencies), but that doesn't apply to local 
> > > statics.
> > Consider the case when synchronization is disabled for static 
> > initialization, and two threads call `foo2` for the first time. It may be 
> > the case that they both try and initialize the static variable at the same 
> > time with different values (since the dynamic initializer may not be pure), 
> > creating a race condition.
> > Consider the case when synchronization is disabled for static initialization
> 
> This is a compiler bug, though: http://eel.is/c++draft/stmt.dcl#4.sentence-3
Sorry, I guess I didn't make it clear enough in the rst documentation file, but 
this check is for those who explicitly enable the -fno-threadsafe-statics flag 
because they provide their own synchronization. Then they would like to check 
if the headers they didn't write may possibly run into this issue when 
compiling with this flag.


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] D65663: [analyzer] ConditionBRVisitor: Fix HTML PathDiagnosticPopUpPieces

[Csaba Dabis via Phabricator via cfe-commits]

Charusso added a comment.

It also reverts https://reviews.llvm.org/rL362632 which is not a fix, but a 
problem instead.


Repository:
  rC Clang

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

https://reviews.llvm.org/D65663



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

[PATCH] D65663: [analyzer] ConditionBRVisitor: Fix HTML PathDiagnosticPopUpPieces

[Csaba Dabis via Phabricator via cfe-commits]

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

It also reverts https://reviews.llvm.org/rL362632 which is not a fix, but a 
problem instead.


A condition could be a multi-line expression where we create the highlight
in separated chunks. PathDiagnosticPopUpPiece is not made for that purpose,
it cannot be added to multiple lines because we have only one ending part
which contains all the notes. So that it cannot have multiple endings and
therefore this patch narrows down the ranges of the highlight to the given
interesting variable of the condition. It prevents HTML-breaking injections.


Repository:
  rC Clang

https://reviews.llvm.org/D65663

Files:
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
  clang/test/Analysis/Inputs/expected-plists/cxx-for-range.cpp.plist
  clang/test/Analysis/Inputs/expected-plists/edges-new.mm.plist
  clang/test/Analysis/Inputs/expected-plists/inline-plist.c.plist
  clang/test/Analysis/Inputs/expected-plists/objc-radar17039661.m.plist
  clang/test/Analysis/Inputs/expected-plists/plist-output.m.plist

Index: clang/test/Analysis/Inputs/expected-plists/plist-output.m.plist
===
--- clang/test/Analysis/Inputs/expected-plists/plist-output.m.plist
+++ clang/test/Analysis/Inputs/expected-plists/plist-output.m.plist
@@ -2513,7 +2513,7 @@
 
 
  line96
- col13
+ col8
  file0
 

@@ -2735,7 +2735,7 @@
 
 
  line96
- col13
+ col8
  file0
 

@@ -3554,7 +3554,7 @@
 
 
  line127
- col14
+ col9
  file0
 

@@ -3776,7 +3776,7 @@
 
 
  line127
- col14
+ col9
  file0
 

Index: clang/test/Analysis/Inputs/expected-plists/objc-radar17039661.m.plist
===
--- clang/test/Analysis/Inputs/expected-plists/objc-radar17039661.m.plist
+++ clang/test/Analysis/Inputs/expected-plists/objc-radar17039661.m.plist
@@ -836,7 +836,7 @@
 
 
  line38
- col37
+ col20
  file0
 

Index: clang/test/Analysis/Inputs/expected-plists/inline-plist.c.plist
===
--- clang/test/Analysis/Inputs/expected-plists/inline-plist.c.plist
+++ clang/test/Analysis/Inputs/expected-plists/inline-plist.c.plist
@@ -548,7 +548,7 @@
 
 
  line45
- col12
+ col7
  file0
 

Index: clang/test/Analysis/Inputs/expected-plists/edges-new.mm.plist
===
--- clang/test/Analysis/Inputs/expected-plists/edges-new.mm.plist
+++ clang/test/Analysis/Inputs/expected-plists/edges-new.mm.plist
@@ -2727,7 +2727,7 @@
 
 
  line146
- col13
+ col8
  file0
 

@@ -2949,7 +2949,7 @@
 
 
  line146
- col13
+ col8
  file0
 

@@ -3929,7 +3929,7 @@
 
 
  line178
- col14
+ col9
  file0
 

@@ -4185,7 +4185,7 @@
 
 
  line178
- col14
+ col9
  file0
 

@@ -4281,7 +4281,7 @@
 
 
  line181
- col14
+ col9
  file0
 

@@ -8087,7 +8087,7 @@
  location
  
   line267
-  col18
+  col19
   file0
  
  ranges
@@ -8095,7 +8095,7 @@

 
  line267
- col18
+ col19
  file0
 
 
@@ -8119,12 +8119,12 @@
  
   
line267
-   col18
+   col19
file0
   
   
line267
-   col18
+   col22
file0
   
  
@@ -11983,12 +11983,12 @@
  
   
line457
-   col9
+   col10
file0
   
   
line457
-   col9
+   col14
file0
   
  
@@ -12000,7 +12000,7 @@
  location
  
   line457
-  col9
+  col10
   file0
  
  ranges
@@ -12008,7 +12008,7 @@

 
  line457
- col9
+ col10
  file0
 
 
@@ -12032,12 +12032,12 @@
  
   
line457
-   col9
+   col10
file0
   
   
line457
-   col9
+   col14
  

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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/bugprone-dynamic-static-initializers.hpp:33-35
+  // This may work fine when optimization is enabled because bar() can
+  // be turned into a constant 7.  But without optimization, it can
+  // cause problems. Therefore, we must err on the side of conservatism.

czhang wrote:
> aaron.ballman wrote:
> > czhang wrote:
> > > aaron.ballman wrote:
> > > > What problems can be caused here? Typically, dynamic init is only 
> > > > problematic when it happens before main() is executed (because of 
> > > > initialization order dependencies), but that doesn't apply to local 
> > > > statics.
> > > Consider the case when synchronization is disabled for static 
> > > initialization, and two threads call `foo2` for the first time. It may be 
> > > the case that they both try and initialize the static variable at the 
> > > same time with different values (since the dynamic initializer may not be 
> > > pure), creating a race condition.
> > > Consider the case when synchronization is disabled for static 
> > > initialization
> > 
> > This is a compiler bug, though: http://eel.is/c++draft/stmt.dcl#4.sentence-3
> Sorry, I guess I didn't make it clear enough in the rst documentation file, 
> but this check is for those who explicitly enable the -fno-threadsafe-statics 
> flag because they provide their own synchronization. Then they would like to 
> check if the headers they didn't write may possibly run into this issue when 
> compiling with this flag.
Ah! Thank you for the explanation. In that case, this behavior makes more 
sense, but I think you should only warn if the user has enabled that feature 
flag rather than always warning.


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

[clang-tools-extra] r367694 - [clang-tidy] Adding static analyzer check to list of clang-tidy checks

[Nathan Huckleberry via cfe-commits]

Author: nathan-huckleberry
Date: Fri Aug  2 10:18:31 2019
New Revision: 367694

URL: http://llvm.org/viewvc/llvm-project?rev=367694&view=rev
Log:
[clang-tidy] Adding static analyzer check to list of clang-tidy checks

Summary:
Since clang-tidy supports use of the static analyzer there
should be documentation of how to invoke the static analyzer
checks.

Reviewers: JonasToth, aaron.ballman, NoQ, Szelethus

Reviewed By: aaron.ballman

Subscribers: nickdesaulniers, lebedev.ri, jfb, NoQ, Eugene.Zelenko, xazax.hun, 
baloghadamsoftware, a.sidorin, Szelethus, donat.nagy, dkrupp, cfe-commits

Tags: #clang

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

Added:

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.CallAndMessage.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.DivideZero.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.DynamicTypePropagation.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.NonNullParamChecker.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.NullDereference.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.StackAddressEscape.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.UndefinedBinaryOperatorResult.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.VLASize.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.ArraySubscript.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.Assign.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.Branch.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.CapturedBlockVariable.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.UndefReturn.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-cplusplus.InnerPointer.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-cplusplus.Move.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-cplusplus.NewDelete.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-cplusplus.NewDeleteLeaks.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-deadcode.DeadStores.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-nullability.NullPassedToNonnull.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-nullability.NullReturnedFromNonnull.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-nullability.NullableDereferenced.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-nullability.NullablePassedToNonnull.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-nullability.NullableReturnedFromNonnull.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.cplusplus.UninitializedObject.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.cplusplus.VirtualCall.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.mpi.MPI-Checker.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.osx.OSObjectCStyleCast.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.osx.cocoa.localizability.EmptyLocalizationContextChecker.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.osx.cocoa.localizability.NonLocalizedStringChecker.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.performance.GCDAntipattern.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.performance.Padding.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.portability.UnixAPI.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.API.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.MIG.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.NumberObjectConversion.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.OSObjectRetainCount.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.ObjCProperty.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.SecKeychainAPI.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.AtSync.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.AutoreleaseWrite.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.ClassRelease.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.Dealloc.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.IncompatibleMethodTypes.rst

clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.Loops.rst

clang-tools-extra/trunk/d

[PATCH] D64454: [clang-tidy] Adding static analyzer check to list of clang-tidy checks

[Nathan Huckleberry via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367694: [clang-tidy] Adding static analyzer check to list of 
clang-tidy checks (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/D64454?vs=212889&id=213079#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D64454

Files:
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.CallAndMessage.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.DivideZero.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.DynamicTypePropagation.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.NonNullParamChecker.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.NullDereference.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.StackAddressEscape.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.UndefinedBinaryOperatorResult.rst
  clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.VLASize.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.ArraySubscript.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.Assign.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.Branch.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.CapturedBlockVariable.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-core.uninitialized.UndefReturn.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-cplusplus.InnerPointer.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-cplusplus.Move.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-cplusplus.NewDelete.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-cplusplus.NewDeleteLeaks.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-deadcode.DeadStores.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-nullability.NullPassedToNonnull.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-nullability.NullReturnedFromNonnull.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-nullability.NullableDereferenced.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-nullability.NullablePassedToNonnull.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-nullability.NullableReturnedFromNonnull.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.cplusplus.UninitializedObject.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.cplusplus.VirtualCall.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.mpi.MPI-Checker.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.osx.OSObjectCStyleCast.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.osx.cocoa.localizability.EmptyLocalizationContextChecker.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.osx.cocoa.localizability.NonLocalizedStringChecker.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.performance.GCDAntipattern.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.performance.Padding.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-optin.portability.UnixAPI.rst
  clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.API.rst
  clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.MIG.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.NumberObjectConversion.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.OSObjectRetainCount.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.ObjCProperty.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.SecKeychainAPI.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.AtSync.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.AutoreleaseWrite.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.ClassRelease.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.Dealloc.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.IncompatibleMethodTypes.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.Loops.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.MissingSuperCall.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.NSAutoreleasePool.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/clang-analyzer-osx.cocoa.NSError.rst
 

[PATCH] D65664: [BPF] annotate DIType metadata for builtin preseve_array_access_index()

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song created this revision.
yonghong-song added a reviewer: ast.
Herald added subscribers: llvm-commits, cfe-commits, arphaman, aprantl.
Herald added projects: clang, LLVM.

Previously, debuginfo types are annotated to
IR builtin preserve_struct_access_index() and
preserve_union_access_index(), but not
preserve_array_access_index(). The debug info
is useful to identify the root type name which
later will be used for type comparison.

For user access without explicit type conversions,
the previous scheme works as we can ignore intermediate
compiler generated type conversions (e.g., from union types to
union members) and still generate correct access index string.

The issue comes with user explicit type conversions, e.g.,
converting an array to a structure like below:

  struct t { int a; char b[40]; };
  struct p { int c; int d; };
  struct t *var = ...;
  ... __builtin_preserve_access_index(&(((struct p *)&(var->b[0]))->d)) ...

Although BPF backend can derive the type of &(var->b[0]),
explicit type annotation make checking more consistent
and less error prone.

Another benefit is for multiple dimension array handling.
For example,

  struct p { int c; int d; } g[8][9][10];
  ... __builtin_preserve_access_index(&g[2][3][4].d) ...

It would be possible to calculate the number of "struct p"'s
before accessing its member "d" if array debug info is
available as it contains each dimension range.

This patch enables to annotate IR builtin preserve_array_access_index()
with proper debuginfo type. The unit test case and language reference
is updated as well.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65664

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/test/CodeGen/builtin-preserve-access-index-array.c
  clang/test/CodeGen/builtin-preserve-access-index.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/IR/IRBuilder.h
  llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

Index: llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll
===
--- llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll
+++ llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll
@@ -14,7 +14,7 @@
 define dso_local i32 @test(%struct.s* %arg) local_unnamed_addr #0 !dbg !7 {
 entry:
   call void @llvm.dbg.value(metadata %struct.s* %arg, metadata !17, metadata !DIExpression()), !dbg !18
-  %0 = tail call %struct.s* @llvm.preserve.array.access.index.p0s_struct.ss.p0s_struct.ss(%struct.s* %arg, i32 0, i32 2), !dbg !19
+  %0 = tail call %struct.s* @llvm.preserve.array.access.index.p0s_struct.ss.p0s_struct.ss(%struct.s* %arg, i32 0, i32 2), !dbg !19, !llvm.preserve.access.index !11
   %1 = tail call i32* @llvm.preserve.struct.access.index.p0i32.p0s_struct.ss(%struct.s* %0, i32 1, i32 1), !dbg !19, !llvm.preserve.access.index !12
   %2 = bitcast i32* %1 to i8*, !dbg !19
   %call = tail call i32 @get_value(i8* %2) #4, !dbg !20
Index: llvm/include/llvm/IR/IRBuilder.h
===
--- llvm/include/llvm/IR/IRBuilder.h
+++ llvm/include/llvm/IR/IRBuilder.h
@@ -2484,7 +2484,7 @@
   }
 
   Value *CreatePreserveArrayAccessIndex(Value *Base, unsigned Dimension,
-unsigned LastIndex) {
+unsigned LastIndex, MDNode *DbgInfo) {
 assert(isa(Base->getType()) &&
"Invalid Base ptr type for preserve.array.access.index.");
 auto *BaseType = Base->getType();
@@ -2506,6 +2506,7 @@
 Value *DimV = getInt32(Dimension);
 CallInst *Fn =
 CreateCall(FnPreserveArrayAccessIndex, {Base, DimV, LastIndexV});
+Fn->setMetadata(LLVMContext::MD_preserve_access_index, DbgInfo);
 
 return Fn;
   }
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -17395,6 +17395,10 @@
 into the array. The return type ``ret_type`` is a pointer type to the array element.
 The array ``dim`` and ``index`` are preserved which is more robust than
 getelementptr instruction which may be subject to compiler transformation.
+The ``llvm.preserve.access.index`` type of metadata is attached to this call instruction
+to provide array or pointer debuginfo type.
+The metadata is a ``DICompositeType`` or ``DIDerivedType`` representing the
+debuginfo version of ``type``.
 
 Arguments:
 ""
Index: clang/test/CodeGen/builtin-preserve-access-index.c
===
--- clang/test/CodeGen/builtin-preserve-access-index.c
+++ clang/test/CodeGen/builtin-preserve-access-index.c
@@ -31,16 +31,16 @@
 }
 // CHECK: define dso_local i8* @unit4
 // CHECK-NOT: getelementptr
-// CHECK: call i32* @llvm.preserve.array.access.index.p0i32.p0i32(i32* %{{[0-9a-z]+}}, i32 0, i32 1)
+// CHECK: call i32* @llvm.preserve.array.access.index.p0i32.p0i32(i32* %{{[0-9a-z]+}}, i32 0, i32 1), !dbg !{{[0-9]+}}, !llvm.preserve.access.index ![[POINTER:[0-9]+]]
 
 co

[PATCH] D65615: [BPF] annotate DIType metadata for builtin preseve_array_access_index()

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song abandoned this revision.
yonghong-song added a comment.

abandon this one. use git monorepo https://reviews.llvm.org/D65664 since we 
have llvm/clang inter-dependence here.


Repository:
  rC Clang

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

https://reviews.llvm.org/D65615



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

[PATCH] D65635: Sidestep false positive due to a matching git repository name

[Eli Friedman via Phabricator via cfe-commits]

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

LGTM

It would be cleaner to convert this test to FileCheck, but it's probably not 
worth spending the time at this point.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65635



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

[PATCH] D65665: Support for attributes on @class declarations

[Erik Pilkington via Phabricator via cfe-commits]

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

This is useful to make availability checking work with forward declarations, 
but there also seem to be other attributes that make sense here.

rdar://43118198


Repository:
  rC Clang

https://reviews.llvm.org/D65665

Files:
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseObjc.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/SemaDeclObjC.cpp
  clang/test/CodeGenObjC/objc-asm-attribute-test.m
  clang/test/Misc/pragma-attribute-objc.m
  clang/test/Parser/attributes.mm
  clang/test/SemaObjC/attr-forward-class.m
  clang/test/SemaObjC/objc-asm-attribute-neg-test.m

Index: clang/test/SemaObjC/objc-asm-attribute-neg-test.m
===
--- clang/test/SemaObjC/objc-asm-attribute-neg-test.m
+++ clang/test/SemaObjC/objc-asm-attribute-neg-test.m
@@ -28,7 +28,7 @@
 @end
 
 __attribute__((objc_runtime_name("MySecretNamespace.ForwardClass")))
-@class ForwardClass; // expected-error {{prefix attribute must be followed by an interface, protocol, or implementation}}
+@class ForwardClass;
 
 __attribute__((objc_runtime_name("MySecretNamespace.ForwardProtocol")))
 @protocol ForwardProtocol;
Index: clang/test/SemaObjC/attr-forward-class.m
===
--- /dev/null
+++ clang/test/SemaObjC/attr-forward-class.m
@@ -0,0 +1,36 @@
+// RUN: %clang_cc1 -verify %s -triple x86_64-apple-macos10.14
+
+__attribute__((availability(macos, introduced=1000)))
+@class JustForward; // expected-note{{introduced in macOS 1000 here}}
+
+JustForward *makeIt(); // expected-warning{{'JustForward' is only available on macOS 1000 or newer}} expected-note{{annotate 'makeIt' with an availability attribute to silence this warning}}
+
+__attribute__((availability(macos, introduced=1000)))
+@class FwdDefined;
+
+// FIXME: it'd be nice to point to the declaration with the attribute if its
+// inherited.
+@interface FwdDefined // expected-note{{introduced in macOS 1000 here}}
+@end
+
+FwdDefined *makeIt2(); // expected-warning{{'FwdDefined' is only available on macOS 1000 or newer}} expected-note{{annotate 'makeIt2' with an availability attribute to silence this warning}}
+
+@class FwdDefined2;
+
+__attribute__((availability(macos, introduced=1000)))
+@interface FwdDefined2 // expected-note{{introduced in macOS 1000 here}}
+@end
+
+FwdDefined2 *makeIt3(); // expected-warning{{'FwdDefined2' is only available on macOS 1000 or newer}} expected-note {{annotate}}
+
+
+// expected-error@+1{{postfix attributes are not allowed on Objective-C directives}}
+@class __attribute__((availability(macos, introduced=1000))) InTheMiddle;
+
+#pragma clang attribute push (__attribute__((availability(macos,introduced=1000))), apply_to=objc_interface)
+
+@class PragmaAttribute; // expected-note{{'PragmaAttribute' has been marked as being introduced in macOS 1000 here, but the deployment target is macOS 10.14.0}}
+
+#pragma clang attribute pop
+
+PragmaAttribute *makeIt4();  // expected-warning{{PragmaAttribute' is only available on macOS 1000 or newer}} expected-note {{annotate}}
Index: clang/test/Parser/attributes.mm
===
--- clang/test/Parser/attributes.mm
+++ clang/test/Parser/attributes.mm
@@ -1,8 +1,6 @@
 // RUN: %clang_cc1 -verify -fsyntax-only -Wno-objc-root-class %s
 
-// FIXME: Why isn't this supported? Seems useful for availability attributes at
-// the very least.
-__attribute__((deprecated)) @class B; // expected-error {{prefix attribute must be followed by an interface, protocol, or implementation}}
+__attribute__((deprecated)) @class B;
 
 __attribute__((deprecated)) @interface A @end
 __attribute__((deprecated)) @protocol P0;
@@ -20,7 +18,7 @@
 EXP @implementation I2 @end
 
 @class EXP OC; // expected-error-re {{postfix attributes are not allowed on Objective-C directives{{$
-EXP @class OC2; // expected-error {{prefix attribute must be followed by an interface, protocol, or implementation}}
+EXP @class OC2;
 
 @protocol EXP P @end // expected-error {{postfix attributes are not allowed on Objective-C directives, place them in front of '@protocol'}}
 EXP @protocol P2 @end
Index: clang/test/Misc/pragma-attribute-objc.m
===
--- clang/test/Misc/pragma-attribute-objc.m
+++ clang/test/Misc/pragma-attribute-objc.m
@@ -135,13 +135,13 @@
 
 @end
 
-// @class/@compatibility_alias declarations can't receive explicit attributes,
-// so don't add pragma attributes to them.
 @class testClass;
 // CHECK-LABEL: ObjCInterfaceDecl{{.*}}testClass
-// CHECK-NOT: AnnotateAttr
-// CHECK-NOT: ObjCSubclassingRestrictedAttr
+// CHECK-NEXT: AnnotateAttr
+// CHECK-NEXT: ObjCSubclassingRestrictedAttr
 
+// @compatibility_alias 

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

[Charles Zhang via Phabricator via cfe-commits]

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



Comment at: 
clang-tools-extra/test/clang-tidy/bugprone-dynamic-static-initializers.hpp:33-35
+  // This may work fine when optimization is enabled because bar() can
+  // be turned into a constant 7.  But without optimization, it can
+  // cause problems. Therefore, we must err on the side of conservatism.

aaron.ballman wrote:
> czhang wrote:
> > aaron.ballman wrote:
> > > czhang wrote:
> > > > aaron.ballman wrote:
> > > > > What problems can be caused here? Typically, dynamic init is only 
> > > > > problematic when it happens before main() is executed (because of 
> > > > > initialization order dependencies), but that doesn't apply to local 
> > > > > statics.
> > > > Consider the case when synchronization is disabled for static 
> > > > initialization, and two threads call `foo2` for the first time. It may 
> > > > be the case that they both try and initialize the static variable at 
> > > > the same time with different values (since the dynamic initializer may 
> > > > not be pure), creating a race condition.
> > > > Consider the case when synchronization is disabled for static 
> > > > initialization
> > > 
> > > This is a compiler bug, though: 
> > > http://eel.is/c++draft/stmt.dcl#4.sentence-3
> > Sorry, I guess I didn't make it clear enough in the rst documentation file, 
> > but this check is for those who explicitly enable the 
> > -fno-threadsafe-statics flag because they provide their own 
> > synchronization. Then they would like to check if the headers they didn't 
> > write may possibly run into this issue when compiling with this flag.
> Ah! Thank you for the explanation. In that case, this behavior makes more 
> sense, but I think you should only warn if the user has enabled that feature 
> flag rather than always warning.
I haven't been able to find much documentation on how to actually make a tidy 
check run against a feature flag. Is it possible to do this? I would think that 
said users would manually run this check on their header files.


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] D62829: [clang-tidy] Check for dynamically initialized statics in headers.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/bugprone-dynamic-static-initializers.hpp:33-35
+  // This may work fine when optimization is enabled because bar() can
+  // be turned into a constant 7.  But without optimization, it can
+  // cause problems. Therefore, we must err on the side of conservatism.

czhang wrote:
> aaron.ballman wrote:
> > czhang wrote:
> > > aaron.ballman wrote:
> > > > czhang wrote:
> > > > > aaron.ballman wrote:
> > > > > > What problems can be caused here? Typically, dynamic init is only 
> > > > > > problematic when it happens before main() is executed (because of 
> > > > > > initialization order dependencies), but that doesn't apply to local 
> > > > > > statics.
> > > > > Consider the case when synchronization is disabled for static 
> > > > > initialization, and two threads call `foo2` for the first time. It 
> > > > > may be the case that they both try and initialize the static variable 
> > > > > at the same time with different values (since the dynamic initializer 
> > > > > may not be pure), creating a race condition.
> > > > > Consider the case when synchronization is disabled for static 
> > > > > initialization
> > > > 
> > > > This is a compiler bug, though: 
> > > > http://eel.is/c++draft/stmt.dcl#4.sentence-3
> > > Sorry, I guess I didn't make it clear enough in the rst documentation 
> > > file, but this check is for those who explicitly enable the 
> > > -fno-threadsafe-statics flag because they provide their own 
> > > synchronization. Then they would like to check if the headers they didn't 
> > > write may possibly run into this issue when compiling with this flag.
> > Ah! Thank you for the explanation. In that case, this behavior makes more 
> > sense, but I think you should only warn if the user has enabled that 
> > feature flag rather than always warning.
> I haven't been able to find much documentation on how to actually make a tidy 
> check run against a feature flag. Is it possible to do this? I would think 
> that said users would manually run this check on their header files.
> Sorry, I guess I didn't make it clear enough in the rst documentation file, 
> but this check is for those who explicitly enable the -fno-threadsafe-statics 
> flag because they provide their own synchronization.

I too want to see this explicitly spelled out in documentation.

> Then they would like to check if the headers they didn't write may possibly 
> run into this issue when compiling with this flag.

I'm very much not a fan of this solution.
Are you sure that is not exposed in `LangOptions`, e.g. as `ThreadsafeStatics`?


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] D65668: [Driver][test] Avoid undefined grep in darwin-ld.c

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast created this revision.
hubert.reinterpretcast added reviewers: rnk, daltenty, xingxue, jasonliu.
Herald added a project: clang.

question-mark is not a BRE special character.

POSIX.1-2017 XBD Section 9.3.2 indicates that the interpretation of `\?`
as used by rC366282  is undefined. This 
patch uses an ERE instead.


Repository:
  rC Clang

https://reviews.llvm.org/D65668

Files:
  test/Driver/darwin-ld.c


Index: test/Driver/darwin-ld.c
===
--- test/Driver/darwin-ld.c
+++ test/Driver/darwin-ld.c
@@ -5,9 +5,9 @@
 
 // Make sure we run dsymutil on source input files.
 // RUN: %clang -target i386-apple-darwin9 -### -g %s -o BAR 2> %t.log
-// RUN: grep '".*dsymutil\(.exe\)\?" "-o" "BAR.dSYM" "BAR"' %t.log
+// RUN: grep -E '".*dsymutil(\.exe)?" "-o" "BAR.dSYM" "BAR"' %t.log
 // RUN: %clang -target i386-apple-darwin9 -### -g -filelist FOO %s -o BAR 2> 
%t.log
-// RUN: grep '".*dsymutil\(.exe\)\?" "-o" "BAR.dSYM" "BAR"' %t.log
+// RUN: grep -E '".*dsymutil(\.exe)?" "-o" "BAR.dSYM" "BAR"' %t.log
 
 // Check linker changes that came with new linkedit format.
 // RUN: touch %t.o


Index: test/Driver/darwin-ld.c
===
--- test/Driver/darwin-ld.c
+++ test/Driver/darwin-ld.c
@@ -5,9 +5,9 @@
 
 // Make sure we run dsymutil on source input files.
 // RUN: %clang -target i386-apple-darwin9 -### -g %s -o BAR 2> %t.log
-// RUN: grep '".*dsymutil\(.exe\)\?" "-o" "BAR.dSYM" "BAR"' %t.log
+// RUN: grep -E '".*dsymutil(\.exe)?" "-o" "BAR.dSYM" "BAR"' %t.log
 // RUN: %clang -target i386-apple-darwin9 -### -g -filelist FOO %s -o BAR 2> %t.log
-// RUN: grep '".*dsymutil\(.exe\)\?" "-o" "BAR.dSYM" "BAR"' %t.log
+// RUN: grep -E '".*dsymutil(\.exe)?" "-o" "BAR.dSYM" "BAR"' %t.log
 
 // Check linker changes that came with new linkedit format.
 // RUN: touch %t.o
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65668: [Driver][test] Avoid undefined grep in darwin-ld.c

[Reid Kleckner via Phabricator via cfe-commits]

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

Probably like most programmers, I am not familiar with section 9.3.2 of posix. 
I assume this is affecting a real platform that you care about, but I'm curious 
what it is.

lgtm


Repository:
  rC Clang

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

https://reviews.llvm.org/D65668



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

[PATCH] D65300: [clang] [CodeGen] clang-misexpect prototype for compiler warnings

[Paul Kirth via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/MisExpect.cpp:82
+  if (ExpectedTrueBranch) {
+const llvm::BranchProbability HotFunctionThreshold(1, 100);
+Scaled = HotFunctionThreshold.scale(CurrProfCount);

phosek wrote:
> Are these thresholds defined anywhere as constants?
These thresholds come from [[ 
https://github.com/llvm/llvm-project/blob/7ea131c20c113b78085301a1acd7b28884ec131e/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp#L1084
 |  PGOInstrumentation.cpp:1084 ]]

I will update with a reference to the code that this comes from, but, as noted 
in the TODO we need a better heuristic. 



Comment at: clang/lib/CodeGen/MisExpect.cpp:140-146
+void EmitMisExpectWarning(const CallExpr *Call, CodeGenModule &CGM) {
+  SourceLocation ExprLoc = Call->getBeginLoc();
+  unsigned DiagID = CGM.getDiags().getCustomDiagID(
+  DiagnosticsEngine::Warning, "Current PGO counters disagree with "
+  "the use of __builtin_expect().");
+  CGM.getDiags().Report(ExprLoc, DiagID);
+}

lebedev.ri wrote:
> This is rather undescriptive.
> Can you output some more useful info?
Do you have a suggestion about what feedback would be more useful?

My initial thought with the somewhat generic message was to simply point out 
that this usage looked problematic, and let the developer investigate. I wasn't 
sure we wanted to expose details of the internal heuristic to the user by 
reporting the internal thresholds.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65300



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

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[David Major via Phabricator via cfe-commits]

dmajor added a comment.
Herald added a reviewer: jdoerfert.
Herald added a subscriber: erik.pilkington.

While debugging something else, I noticed that with this patch, `Decl` now has 
33 bits worth of bitfields, so it has gained an extra word. Is that ok? Just 
want to make sure it wasn't unintentional.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56326



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

[PATCH] D65670: Use switch instead of series of comparisons

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff created this revision.
sepavloff added reviewers: rjmccall, alexfh.
Herald added a project: clang.

This is style correction, no functional changes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65670

Files:
  clang/include/clang/Basic/TokenKinds.h
  clang/lib/Basic/TokenKinds.cpp


Index: clang/lib/Basic/TokenKinds.cpp
===
--- clang/lib/Basic/TokenKinds.cpp
+++ clang/lib/Basic/TokenKinds.cpp
@@ -46,6 +46,16 @@
   return nullptr;
 }
 
+bool tok::isAnnotation(TokenKind Kind) {
+  switch (Kind) {
+#define ANNOTATION(X) case annot_ ## X: return true;
+#include "clang/Basic/TokenKinds.def"
+  default:
+break;
+  }
+  return false;
+}
+
 bool tok::isPragmaAnnotation(TokenKind Kind) {
   switch (Kind) {
 #define PRAGMA_ANNOTATION(X) case annot_ ## X: return true;
Index: clang/include/clang/Basic/TokenKinds.h
===
--- clang/include/clang/Basic/TokenKinds.h
+++ clang/include/clang/Basic/TokenKinds.h
@@ -90,13 +90,7 @@
 }
 
 /// Return true if this is any of tok::annot_* kinds.
-inline bool isAnnotation(TokenKind K) {
-#define ANNOTATION(NAME) \
-  if (K == tok::annot_##NAME) \
-return true;
-#include "clang/Basic/TokenKinds.def"
-  return false;
-}
+bool isAnnotation(TokenKind K);
 
 /// Return true if this is an annotation token representing a pragma.
 bool isPragmaAnnotation(TokenKind K);


Index: clang/lib/Basic/TokenKinds.cpp
===
--- clang/lib/Basic/TokenKinds.cpp
+++ clang/lib/Basic/TokenKinds.cpp
@@ -46,6 +46,16 @@
   return nullptr;
 }
 
+bool tok::isAnnotation(TokenKind Kind) {
+  switch (Kind) {
+#define ANNOTATION(X) case annot_ ## X: return true;
+#include "clang/Basic/TokenKinds.def"
+  default:
+break;
+  }
+  return false;
+}
+
 bool tok::isPragmaAnnotation(TokenKind Kind) {
   switch (Kind) {
 #define PRAGMA_ANNOTATION(X) case annot_ ## X: return true;
Index: clang/include/clang/Basic/TokenKinds.h
===
--- clang/include/clang/Basic/TokenKinds.h
+++ clang/include/clang/Basic/TokenKinds.h
@@ -90,13 +90,7 @@
 }
 
 /// Return true if this is any of tok::annot_* kinds.
-inline bool isAnnotation(TokenKind K) {
-#define ANNOTATION(NAME) \
-  if (K == tok::annot_##NAME) \
-return true;
-#include "clang/Basic/TokenKinds.def"
-  return false;
-}
+bool isAnnotation(TokenKind K);
 
 /// Return true if this is an annotation token representing a pragma.
 bool isPragmaAnnotation(TokenKind K);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65670: Use switch instead of series of comparisons

[John McCall via Phabricator via cfe-commits]

rjmccall accepted this revision.
rjmccall 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/D65670/new/

https://reviews.llvm.org/D65670



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

[PATCH] D65405: [Parser] Use special definition for pragma annotations

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

> LGTM, although I don't think it would be ridiculous to make this an inline 
> function definition like isAnnotation.

Thank you!
The fix for `isAnnotation` is D65670 .


Repository:
  rL LLVM

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

https://reviews.llvm.org/D65405



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

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

[Charles Zhang via Phabricator via cfe-commits]

czhang updated this revision to Diff 213102.
czhang marked an inline comment as done.
czhang added a comment.

Be more explicit about -fno-threadsafe-statics


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

https://reviews.llvm.org/D62829

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/DynamicStaticInitializersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/DynamicStaticInitializersCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-dynamic-static-initializers.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/bugprone-dynamic-static-initializers.hpp

Index: clang-tools-extra/test/clang-tidy/bugprone-dynamic-static-initializers.hpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/bugprone-dynamic-static-initializers.hpp
@@ -0,0 +1,44 @@
+// RUN: %check_clang_tidy %s bugprone-dynamic-static-initializers %t
+
+int fact(int n) {
+  return (n == 0) ? 1 : n * fact(n - 1);
+}
+
+int static_thing = fact(5);
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: static variable 'static_thing' may be dynamically initialized in this header file [bugprone-dynamic-static-initializers]
+
+int sample() {
+int x;
+return x;
+}
+
+int dynamic_thing = sample();
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: static variable 'dynamic_thing' may be dynamically initialized in this header file [bugprone-dynamic-static-initializers]
+
+int not_so_bad = 12 + 4942; // no warning
+
+extern int bar();
+
+int foo() {
+  static int k = bar();
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: static variable 'k' may be dynamically initialized in this header file [bugprone-dynamic-static-initializers]
+  return k;
+}
+
+int bar2() {
+  return 7;
+}
+
+int foo2() {
+  // This may work fine when optimization is enabled because bar() can
+  // be turned into a constant 7.  But without optimization, it can
+  // cause problems. Therefore, we must err on the side of conservatism.
+  static int x = bar2();
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: static variable 'x' may be dynamically initialized in this header file [bugprone-dynamic-static-initializers]
+  return x;
+}
+
+int foo3() {
+  static int p = 7 + 83; // no warning
+  return p;
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -43,6 +43,7 @@
bugprone-branch-clone
bugprone-copy-constructor-init
bugprone-dangling-handle
+   bugprone-dynamic-static-initializers
bugprone-exception-escape
bugprone-fold-init-type
bugprone-forward-declaration-namespace
Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-dynamic-static-initializers.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone-dynamic-static-initializers.rst
@@ -0,0 +1,27 @@
+.. title:: clang-tidy - bugprone-dynamic-static-initializers
+
+bugprone-dynamic-static-initializers
+
+
+Finds instances of static variables that are dynamically initialized
+in header files.
+
+This can pose problems in certain multithreaded contexts. For example,
+when disabling compiler generated synchronization instructions for
+static variables initialized at runtime (e.g. by -fno-threadsafe-statics), even if a particular project
+takes the necessary precautions to prevent race conditions during
+initialization by providing their own synchronization, header files included from other projects may
+not. Therefore, such a check is helpful for ensuring that disabling
+compiler generated synchronization for static variable initialization will not cause
+problems.
+
+Consider the following code:
+
+-- code-block:: c
+
+int foo() {
+  static int k = bar();
+  return k;
+}
+
+When synchronization of static initialization is disabled, if two threads both call `foo` for the first time, there is the possibility that `k` will be double initialized, creating a race condition.
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -111,6 +111,12 @@
 
   This checks ensures that ``pipe2()`` is called with the O_CLOEXEC flag.
 
+- New :doc:`bugprone-dynamic-static-initializers
+  ` check.
+
+  Finds instances where variables with static storage are initialized
+  dynamically in header files.
+
 - New :doc:`bugprone-unhandled-self-assignment
   ` check.
 
Index: clang-tools-extra/clang-tidy/bugprone/DynamicStaticInitializersCheck.h
==

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

[Charles Zhang via Phabricator via cfe-commits]

czhang added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/bugprone-dynamic-static-initializers.hpp:33-35
+  // This may work fine when optimization is enabled because bar() can
+  // be turned into a constant 7.  But without optimization, it can
+  // cause problems. Therefore, we must err on the side of conservatism.

lebedev.ri wrote:
> czhang wrote:
> > aaron.ballman wrote:
> > > czhang wrote:
> > > > aaron.ballman wrote:
> > > > > czhang wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > What problems can be caused here? Typically, dynamic init is only 
> > > > > > > problematic when it happens before main() is executed (because of 
> > > > > > > initialization order dependencies), but that doesn't apply to 
> > > > > > > local statics.
> > > > > > Consider the case when synchronization is disabled for static 
> > > > > > initialization, and two threads call `foo2` for the first time. It 
> > > > > > may be the case that they both try and initialize the static 
> > > > > > variable at the same time with different values (since the dynamic 
> > > > > > initializer may not be pure), creating a race condition.
> > > > > > Consider the case when synchronization is disabled for static 
> > > > > > initialization
> > > > > 
> > > > > This is a compiler bug, though: 
> > > > > http://eel.is/c++draft/stmt.dcl#4.sentence-3
> > > > Sorry, I guess I didn't make it clear enough in the rst documentation 
> > > > file, but this check is for those who explicitly enable the 
> > > > -fno-threadsafe-statics flag because they provide their own 
> > > > synchronization. Then they would like to check if the headers they 
> > > > didn't write may possibly run into this issue when compiling with this 
> > > > flag.
> > > Ah! Thank you for the explanation. In that case, this behavior makes more 
> > > sense, but I think you should only warn if the user has enabled that 
> > > feature flag rather than always warning.
> > I haven't been able to find much documentation on how to actually make a 
> > tidy check run against a feature flag. Is it possible to do this? I would 
> > think that said users would manually run this check on their header files.
> > Sorry, I guess I didn't make it clear enough in the rst documentation file, 
> > but this check is for those who explicitly enable the 
> > -fno-threadsafe-statics flag because they provide their own synchronization.
> 
> I too want to see this explicitly spelled out in documentation.
> 
> > Then they would like to check if the headers they didn't write may possibly 
> > run into this issue when compiling with this flag.
> 
> I'm very much not a fan of this solution.
> Are you sure that is not exposed in `LangOptions`, e.g. as 
> `ThreadsafeStatics`?
> I'm very much not a fan of this solution.
> Are you sure that is not exposed in LangOptions, e.g. as ThreadsafeStatics?

Can you clarify what you mean? Are you not a fan of users disabling 
synchronization and providing their own? Or are you agreeing with Aaron that we 
should only enable this check with ThreadsafeStatics is enabled?

Either way, I have put a check against LangOpts for this now. 


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] D65300: [clang] [CodeGen] clang-misexpect prototype for compiler warnings

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added inline comments.



Comment at: clang/lib/CodeGen/MisExpect.cpp:140-146
+void EmitMisExpectWarning(const CallExpr *Call, CodeGenModule &CGM) {
+  SourceLocation ExprLoc = Call->getBeginLoc();
+  unsigned DiagID = CGM.getDiags().getCustomDiagID(
+  DiagnosticsEngine::Warning, "Current PGO counters disagree with "
+  "the use of __builtin_expect().");
+  CGM.getDiags().Report(ExprLoc, DiagID);
+}

paulkirth wrote:
> lebedev.ri wrote:
> > This is rather undescriptive.
> > Can you output some more useful info?
> Do you have a suggestion about what feedback would be more useful?
> 
> My initial thought with the somewhat generic message was to simply point out 
> that this usage looked problematic, and let the developer investigate. I 
> wasn't sure we wanted to expose details of the internal heuristic to the user 
> by reporting the internal thresholds.
Message is currently confusing a bit. I really miss clear info like

“This compiler hint seems to be incorrect according to current PGO counters. 
Please check the hint if it is still valid and perf-profitable”.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65300



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

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

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

I think this last update clarified the concerns i raised in last comment.
But, did you mean to update the tests? They should have broke now that you 
require `!getLangOpts().ThreadsafeStatics`.




Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-dynamic-static-initializers.rst:11
+when disabling compiler generated synchronization instructions for
+static variables initialized at runtime (e.g. by -fno-threadsafe-statics), 
even if a particular project
+takes the necessary precautions to prevent race conditions during

escape it:
```
``-fno-threadsafe-statics``
```


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] D65622: [clang-doc] Update documentation

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: clang-tools-extra/docs/clang-doc.rst:93
+--public   - Document only public declarations.
+--stylesheets= - CSS stylesheets to extend the default styles.

It'll be reasonable to mention that this options make sense only for HTML 
output.


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

https://reviews.llvm.org/D65622



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

[PATCH] D65668: [Driver][test] Avoid undefined grep in darwin-ld.c

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added a comment.

In D65668#1612711 , @rnk wrote:

> I assume this is affecting a real platform that you care about, but I'm 
> curious what it is.


Yes, this is affecting our tests on AIX. `\?` there matches a literal `?` 
character.


Repository:
  rC Clang

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

https://reviews.llvm.org/D65668



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

[PATCH] D65627: [clang-doc] Continue after mapping error

[Jake Ehrlich via Phabricator via cfe-commits]

jakehehrlich added a comment.

What's the use case for this and how do we handle return codes when an error 
occurs but we continue on?


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

https://reviews.llvm.org/D65627



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