[PATCH] D95017: [clang-format] add case aware include sorting

2021-01-20 Thread Kent Sommer via Phabricator via cfe-commits
kentsommer updated this revision to Diff 317790.
kentsommer added a comment.

Fix unittests

Fixes both failing unit tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95017

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Tooling/Inclusions/IncludeStyle.h
  clang/lib/Format/Format.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/SortIncludesTest.cpp

Index: clang/unittests/Format/SortIncludesTest.cpp
===
--- clang/unittests/Format/SortIncludesTest.cpp
+++ clang/unittests/Format/SortIncludesTest.cpp
@@ -598,6 +598,22 @@
  "a.cc"));
 }
 
+TEST_F(SortIncludesTest, SupportOptionalCaseAwareSorting) {
+  Style.IncludeSortCaseAware = true;
+
+  EXPECT_EQ("#include \"A/B.h\"\n"
+"#include \"A/b.h\"\n"
+"#include \"a/b.h\"\n"
+"#include \"B/A.h\"\n"
+"#include \"B/a.h\"\n",
+sort("#include \"B/a.h\"\n"
+ "#include \"B/A.h\"\n"
+ "#include \"A/B.h\"\n"
+ "#include \"a/b.h\"\n"
+ "#include \"A/b.h\"\n",
+ "a.h"));
+}
+
 TEST_F(SortIncludesTest, SupportCaseInsensitiveMatching) {
   // Setup an regex for main includes so we can cover those as well.
   Style.IncludeIsMainRegex = "([-_](test|unittest))?$";
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -14395,6 +14395,8 @@
   CHECK_PARSE_BOOL(DeriveLineEnding);
   CHECK_PARSE_BOOL(DerivePointerAlignment);
   CHECK_PARSE_BOOL_FIELD(DerivePointerAlignment, "DerivePointerBinding");
+  CHECK_PARSE_BOOL_FIELD(IncludeStyle.IncludeSortCaseAware,
+ "IncludeSortCaseAware");
   CHECK_PARSE_BOOL(DisableFormat);
   CHECK_PARSE_BOOL(IndentCaseLabels);
   CHECK_PARSE_BOOL(IndentCaseBlocks);
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -556,6 +556,8 @@
 IO.mapOptional("IncludeIsMainRegex", Style.IncludeStyle.IncludeIsMainRegex);
 IO.mapOptional("IncludeIsMainSourceRegex",
Style.IncludeStyle.IncludeIsMainSourceRegex);
+IO.mapOptional("IncludeSortCaseAware",
+   Style.IncludeStyle.IncludeSortCaseAware);
 IO.mapOptional("IndentCaseLabels", Style.IndentCaseLabels);
 IO.mapOptional("IndentCaseBlocks", Style.IndentCaseBlocks);
 IO.mapOptional("IndentGotoLabels", Style.IndentGotoLabels);
@@ -2180,6 +2182,14 @@
 Indices.push_back(i);
   }
   llvm::stable_sort(Indices, [&](unsigned LHSI, unsigned RHSI) {
+if (Style.IncludeStyle.IncludeSortCaseAware) {
+  const auto LHSFilenameLower = Includes[LHSI].Filename.lower();
+  const auto RHSFilenameLower = Includes[RHSI].Filename.lower();
+  return std::tie(Includes[LHSI].Priority, LHSFilenameLower,
+  Includes[LHSI].Filename) <
+ std::tie(Includes[RHSI].Priority, RHSFilenameLower,
+  Includes[RHSI].Filename);
+}
 return std::tie(Includes[LHSI].Priority, Includes[LHSI].Filename) <
std::tie(Includes[RHSI].Priority, Includes[RHSI].Filename);
   });
Index: clang/include/clang/Tooling/Inclusions/IncludeStyle.h
===
--- clang/include/clang/Tooling/Inclusions/IncludeStyle.h
+++ clang/include/clang/Tooling/Inclusions/IncludeStyle.h
@@ -147,6 +147,33 @@
   /// ``ClassImpl.hpp`` would not have the main include file put on top
   /// before any other include.
   std::string IncludeIsMainSourceRegex;
+
+  /// Specify if sorting should be done in a case aware fashion.
+  ///
+  /// By default, clang-format sorts includes in an ASCIIbetical
+  /// fashion. For instance:
+  ///
+  /// \code
+  ///#include "B/a.h"   into  #include "A/B.h"
+  ///#include "B/A.h" #include "A/b.h"
+  ///#include "A/B.h" #include "B/A.h"
+  ///#include "a/b.h" #include "B/a.h"
+  ///#include "A/b.h" #include "a/b.h"
+  /// \endcode
+  ///
+  /// This option will cause includes to be sorted alphabetically with case
+  /// used as a tie-breaker. For instance:
+  ///
+  /// \code
+  ///#include "B/a.h"   into  #include "A/B.h"
+  ///#include "B/A.h" #include "A/b.h"
+  ///#include "A/B.h" #include "a/b.h"
+  ///#include "a/b.h" #include "B/A.h"
+  ///#include "A/b.h" #include "B/a.h"
+  /// \endcode
+  ///
+  /// This option is off by default.
+  bool IncludeSortCaseAware;
 };
 
 

[PATCH] D94955: [clang-format] Treat ForEachMacros as loops

2021-01-20 Thread Jiashu Zou via Phabricator via cfe-commits
GoBigorGoHome updated this revision to Diff 317794.
GoBigorGoHome added a comment.

Update Clang release notes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94955

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -993,9 +993,12 @@
 
 TEST_F(FormatTest, ForEachLoops) {
   verifyFormat("void f() {\n"
-   "  foreach (Item *item, itemlist) {}\n"
-   "  Q_FOREACH (Item *item, itemlist) {}\n"
-   "  BOOST_FOREACH (Item *item, itemlist) {}\n"
+   "  foreach (Item *item, itemlist) {\n"
+   "  }\n"
+   "  Q_FOREACH (Item *item, itemlist) {\n"
+   "  }\n"
+   "  BOOST_FOREACH (Item *item, itemlist) {\n"
+   "  }\n"
"  UNKNOWN_FORACH(Item * item, itemlist) {}\n"
"}");
 
@@ -1003,9 +1006,12 @@
   Style.SpaceBeforeParens =
   FormatStyle::SBPO_ControlStatementsExceptForEachMacros;
   verifyFormat("void f() {\n"
-   "  foreach(Item *item, itemlist) {}\n"
-   "  Q_FOREACH(Item *item, itemlist) {}\n"
-   "  BOOST_FOREACH(Item *item, itemlist) {}\n"
+   "  foreach(Item *item, itemlist) {\n"
+   "  }\n"
+   "  Q_FOREACH(Item *item, itemlist) {\n"
+   "  }\n"
+   "  BOOST_FOREACH(Item *item, itemlist) {\n"
+   "  }\n"
"  UNKNOWN_FORACH(Item * item, itemlist) {}\n"
"}",
Style);
@@ -17838,6 +17844,18 @@
 "}",
 format(Source, Style));
 }
+
+TEST_F(FormatTest, TreatForEachMacrosAsLoops) {
+  FormatStyle Style = getLLVMStyle();
+  Style.ForEachMacros.push_back("rng");
+  Style.AllowShortBlocksOnASingleLine = FormatStyle::SBS_Always;
+  verifyFormat("rng (i, 0, 10) { int j = 1; }", Style);
+  Style.AllowShortBlocksOnASingleLine = FormatStyle::SBS_Never;
+  verifyFormat("rng (i, 0, 10) {\n"
+   "  int j = 1;\n"
+   "}",
+   Style);
+}
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -306,7 +306,8 @@
 }
 // Try to merge a control statement block with left brace unwrapped
 if (TheLine->Last->is(tok::l_brace) && TheLine->First != TheLine->Last &&
-TheLine->First->isOneOf(tok::kw_if, tok::kw_while, tok::kw_for)) {
+TheLine->First->isOneOf(tok::kw_if, tok::kw_while, tok::kw_for,
+TT_ForEachMacro)) {
   return Style.AllowShortBlocksOnASingleLine != FormatStyle::SBS_Never
  ? tryMergeSimpleBlock(I, E, Limit)
  : 0;
@@ -421,7 +422,8 @@
  ? tryMergeSimpleControlStatement(I, E, Limit)
  : 0;
 }
-if (TheLine->First->isOneOf(tok::kw_for, tok::kw_while, tok::kw_do)) {
+if (TheLine->First->isOneOf(tok::kw_for, tok::kw_while, tok::kw_do,
+TT_ForEachMacro)) {
   return Style.AllowShortLoopsOnASingleLine
  ? tryMergeSimpleControlStatement(I, E, Limit)
  : 0;
@@ -474,7 +476,7 @@
 if (1 + I[1]->Last->TotalLength > Limit)
   return 0;
 if (I[1]->First->isOneOf(tok::semi, tok::kw_if, tok::kw_for, tok::kw_while,
- TT_LineComment))
+ TT_ForEachMacro, TT_LineComment))
   return 0;
 // Only inline simple if's (no nested if or else), unless specified
 if (Style.AllowShortIfStatementsOnASingleLine != FormatStyle::SIS_Always) {
@@ -578,12 +580,14 @@
   I + 2 != E && !I[2]->First->is(tok::r_brace))
 return 0;
   if (!Style.AllowShortLoopsOnASingleLine &&
-  Line.First->isOneOf(tok::kw_while, tok::kw_do, tok::kw_for) &&
+  Line.First->isOneOf(tok::kw_while, tok::kw_do, tok::kw_for,
+  TT_ForEachMacro) &&
   !Style.BraceWrapping.AfterControlStatement &&
   !I[1]->First->is(tok::r_brace))
 return 0;
   if (!Style.AllowShortLoopsOnASingleLine &&
-  Line.First->isOneOf(tok::kw_while, tok::kw_do, tok::kw_for) &&
+  Line.First->isOneOf(tok::kw_while, tok::kw_do, tok::kw_for,
+  TT_ForEachMacro) &&
   Style.BraceWrapping.AfterControlStatement ==
   FormatStyle::BWACS_Always &&
   I + 2 != E && !I[2]->First->is(tok::r_brace))
Index: clang/docs/ReleaseNotes.rst

[PATCH] D94820: Support for instrumenting only selected files or functions

2021-01-20 Thread Petr Hosek via Phabricator via cfe-commits
phosek updated this revision to Diff 317796.
phosek marked 3 inline comments as done.
Herald added a reviewer: jansvoboda11.

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

https://reviews.llvm.org/D94820

Files:
  clang/docs/SourceBasedCodeCoverage.rst
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Basic/ProfileList.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/ProfileList.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/CodeGen/CodeGenPGO.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/profile-filter.c
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Transforms/PGOProfile/noprofile.ll

Index: llvm/test/Transforms/PGOProfile/noprofile.ll
===
--- /dev/null
+++ llvm/test/Transforms/PGOProfile/noprofile.ll
@@ -0,0 +1,25 @@
+; RUN: opt < %s -pgo-instr-gen -S | FileCheck %s
+; RUN: opt < %s -passes=pgo-instr-gen -S | FileCheck %s
+
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+@i = dso_local global i32 0, align 4
+
+define i32 @test1() {
+entry:
+; CHECK: call void @llvm.instrprof.increment
+  %0 = load i32, i32* @i, align 4
+  %add = add i32 %0, 1
+  ret i32 %add
+}
+
+define i32 @test2() #0 {
+entry:
+; CHECK-NOT: call void @llvm.instrprof.increment
+  %0 = load i32, i32* @i, align 4
+  %sub = sub i32 %0, 1
+  ret i32 %sub
+}
+
+attributes #0 = { noprofile }
Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
===
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp
@@ -974,6 +974,7 @@
   case Attribute::UWTable:
   case Attribute::NoCfCheck:
   case Attribute::MustProgress:
+  case Attribute::NoProfile:
 break;
   }
 
Index: llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
===
--- llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
+++ llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
@@ -1591,6 +1591,8 @@
   for (auto &F : M) {
 if (F.isDeclaration())
   continue;
+if (F.hasFnAttribute(llvm::Attribute::NoProfile))
+  continue;
 auto &TLI = LookupTLI(F);
 auto *BPI = LookupBPI(F);
 auto *BFI = LookupBFI(F);
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1639,6 +1639,7 @@
   case Attribute::StrictFP:
   case Attribute::NullPointerIsValid:
   case Attribute::MustProgress:
+  case Attribute::NoProfile:
 return true;
   default:
 break;
Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -403,6 +403,8 @@
 return "nocf_check";
   if (hasAttribute(Attribute::NoRecurse))
 return "norecurse";
+  if (hasAttribute(Attribute::NoProfile))
+return "noprofile";
   if (hasAttribute(Attribute::NoUnwind))
 return "nounwind";
   if (hasAttribute(Attribute::OptForFuzzing))
Index: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -680,6 +680,8 @@
 return bitc::ATTR_KIND_NOSYNC;
   case Attribute::NoCfCheck:
 return bitc::ATTR_KIND_NOCF_CHECK;
+  case Attribute::NoProfile:
+return bitc::ATTR_KIND_NO_PROFILE;
   case Attribute::NoUnwind:
 return bitc::ATTR_KIND_NO_UNWIND;
   case Attribute::NullPointerIsValid:
Index: llvm/lib/AsmParser/LLToken.h
===
--- llvm/lib/AsmParser/LLToken.h
+++ llvm/lib/AsmParser/LLToken.h
@@ -210,6 +210,7 @@
   kw_nonlazybind,
   kw_nomerge,
   kw_nonnull,
+  kw_noprofile,
   kw_noredzone,
   kw_noreturn,
   kw_nosync,
Index: llvm/lib/AsmParser/LLParser.cpp
===
--- llvm/lib/AsmParser/LLParser.cpp
+++ llvm/lib/AsmParser/LLParser.cpp
@@ -1368,6 +1368,7 @@
 case lltok::kw_noreturn: B.addAttribute(Attribute::NoReturn); break;
 case lltok::kw_nosync: B.addAttribute(Attribute::NoSync); bre

[PATCH] D94820: Support for instrumenting only selected files or functions

2021-01-20 Thread Petr Hosek via Phabricator via cfe-commits
phosek added inline comments.



Comment at: clang/docs/SourceBasedCodeCoverage.rst:86
+.. code-block:: none
+
+  # all functions whose name starts with foo will be instrumented.

davidxl wrote:
> what is the default section name?
It's `*` which always matches.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:2569
+  // If the profile list is empty, then instrument everything.
+  if (ProfileList.isEmpty())
+return true;

davidxl wrote:
> Should the option to turn on instrumentation also be checked?
Currently, this method is only invoked from `CodeGenFunction` which does its 
own check, but I'm happy to include a check here in case there are ever other 
callers.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:2591
+  }
+  return false;
+}

davidxl wrote:
> If the profile list contains only one line of exclude list, it seems that all 
> functions will be rejected as the function returns 'false' by default for all 
> other functions?
That's correct, would you expect a different behavior and if so what should 
that behavior be?

Currently, the profile list is used to build up a list of functions and files 
that should be instrumented. Any function or file that's not covered by the 
profile list is automatically excluded (not included may be more correct). 
Having just excludes without any includes means that nothing will be 
instrumented.


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

https://reviews.llvm.org/D94820

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


[PATCH] D93986: [clang-format] Add the possibility to align assignments spanning empty lines or comments

2021-01-20 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added a comment.

How is it going? I would like to add some new alignment options and it would be 
stupid not to do it on top of this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93986

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


[PATCH] D93986: [clang-format] Add the possibility to align assignments spanning empty lines or comments

2021-01-20 Thread Lukas Barth via Phabricator via cfe-commits
tinloaf added a comment.

In D93986#2509045 , 
@HazardyKnusperkeks wrote:

> How is it going? I would like to add some new alignment options and it would 
> be stupid not to do it on top of this.

Sorry, much to do work-wise currently. I'll get to the last details today and 
finish this!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93986

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


[PATCH] D94599: [clang][Tooling] Get rid of a hack in SymbolOccurrences, NFCI

2021-01-20 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham accepted this revision.
simon_tatham added a comment.

Thanks. LGTM now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94599

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


[PATCH] D93110: [analyzer] Implement a first version of suppressions via attributes

2021-01-20 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 317805.
vsavchenko added a comment.
Herald added a subscriber: mgorny.

Squash all three commits, introduce new attribute and add documentation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93110

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugSuppression.h
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/lib/StaticAnalyzer/Core/BugSuppression.cpp
  clang/lib/StaticAnalyzer/Core/CMakeLists.txt
  clang/test/Analysis/suppression-attr.m
  clang/test/SemaCXX/attr-analyzer-suppress.cpp
  clang/test/SemaCXX/suppress.cpp
  clang/test/SemaObjC/attr-analyzer-suppress.m

Index: clang/test/SemaObjC/attr-analyzer-suppress.m
===
--- /dev/null
+++ clang/test/SemaObjC/attr-analyzer-suppress.m
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks %s -verify
+
+#define SUPPRESS1 __attribute__((analyzer_suppress))
+#define SUPPRESS2(...) __attribute__((analyzer_suppress(__VA_ARGS__)))
+
+SUPPRESS1 int global = 42;
+
+SUPPRESS1 void foo() {
+  // expected-warning@-1 {{'analyzer_suppress' attribute only applies to variables}}
+  SUPPRESS1 int *p;
+
+  SUPPRESS1 int a = 0;   // no-warning
+  SUPPRESS2() int b = 1; // no-warning
+  SUPPRESS2("a") int c = a + b;  // no-warning
+  SUPPRESS2("a", "b") { b = c - a; } // no-warning
+
+  SUPPRESS2("a", "b") if (b == 10) a += 4; // no-warning
+  SUPPRESS1 while (1) {}   // no-warning
+  SUPPRESS1 switch (a) {   // no-warning
+  default:
+c -= 10;
+  }
+
+  // GNU-style attributes and C++11 attributes apply to different things when
+  // written like this.  GNU  attribute gets attached to the declaration, while
+  // C++11 attribute ends up on the type.
+  int SUPPRESS2("r") z;
+  SUPPRESS2(foo) float f;
+  // expected-error@-1 {{'analyzer_suppress' attribute requires a string}}
+}
+
+union SUPPRESS2("type.1") U {
+  // expected-warning@-1 {{'analyzer_suppress' attribute only applies to variables}}
+  int i;
+  float f;
+};
+
+SUPPRESS1 @interface Test {
+  // expected-warning@-1 {{'analyzer_suppress' attribute only applies to variables}}
+}
+@property SUPPRESS2("prop") int *prop;
+// expected-warning@-1 {{'analyzer_suppress' attribute only applies to variables}}
+- (void)bar:(int) x SUPPRESS1;
+// expected-warning@-1 {{'analyzer_suppress' attribute only applies to variables}}
+@end
Index: clang/test/SemaCXX/suppress.cpp
===
--- clang/test/SemaCXX/suppress.cpp
+++ clang/test/SemaCXX/suppress.cpp
@@ -6,16 +6,15 @@
   [[gsl::suppress("in-a-namespace")]];
 }
 
-[[gsl::suppress("readability-identifier-naming")]]
-void f_() {
+[[gsl::suppress("readability-identifier-naming")]] void f_() {
   int *p;
   [[gsl::suppress("type", "bounds")]] {
 p = reinterpret_cast(7);
   }
 
-  [[gsl::suppress]] int x; // expected-error {{'suppress' attribute takes at least 1 argument}}
-  [[gsl::suppress()]] int y; // expected-error {{'suppress' attribute takes at least 1 argument}}
-  int [[gsl::suppress("r")]] z; // expected-error {{'suppress' attribute cannot be applied to types}}
+  [[gsl::suppress]] int x;   // expected-error {{'suppress' attribute takes at least 1 argument}}
+  [[gsl::suppress()]] int y; // expected-error {{'suppress' attribute takes at least 1 argument}}
+  int [[gsl::suppress("r")]] z;  // expected-error {{'suppress' attribute cannot be applied to types}}
   [[gsl::suppress(f_)]] float f; // expected-error {{'suppress' attribute requires a string}}
 }
 
Index: clang/test/SemaCXX/attr-analyzer-suppress.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/attr-analyzer-suppress.cpp
@@ -0,0 +1,39 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only %s -verify
+
+[[clang::analyzer_suppress]];
+// expected-warning@-1 {{'analyzer_suppress' attribute only applies to variables}}
+
+namespace N {
+[[clang::analyzer_suppress("in-a-namespace")]];
+// expected-warning@-1 {{'analyzer_suppress' attribute only applies to variables}}
+}
+
+[[clang::analyzer_suppress]] int global = 42;
+
+[[clang::analyzer_suppress]] void foo() {
+  // expected-warning@-1 {{'analyzer_suppress' attribute only applies to variables}}
+  [[clang::analyzer_suppress]] int *p;
+
+  [[clang::analyzer_suppress]] int a = 0;   // no-warning
+  [[clang::analyzer_suppress()]] int b = 1; // no-warning
+  [[clang::analyzer_suppress("a")]] int c = a + b;  // no-warning
+  [[clang::analyzer_suppress("a", "b")]] b = c - a; // no-warning
+
+  [[clang::analyzer_suppress("a", "b")]] if (b == 10) a += 4; // no-warning
+  

[PATCH] D94596: [clang][AST] Encapsulate DeclarationNameLoc, NFCI

2021-01-20 Thread Mikhail Maltsev via Phabricator via cfe-commits
miyuki added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94596

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


[PATCH] D92277: [OpenCL] Refactor of targets OpenCL option settings

2021-01-20 Thread Anton Zabaznov via Phabricator via cfe-commits
azabaznov added inline comments.



Comment at: clang/lib/Basic/TargetInfo.cpp:360
+// Set core features based on OpenCL version
+for (auto CoreExt : clang::getCoreFeatures(Opts))
+  getTargetOpts().OpenCLFeaturesMap[CoreExt] = true;

Anastasia wrote:
> azabaznov wrote:
> > azabaznov wrote:
> > > Anastasia wrote:
> > > > azabaznov wrote:
> > > > > Anastasia wrote:
> > > > > > I still think the target map should be immutable and especially we 
> > > > > > should not change it silently based on the language compiled even 
> > > > > > if we have done it before but that caused incorrect behavior i.e. 
> > > > > > successfully compiling for the architectures that didn't support 
> > > > > > the features.
> > > > > > 
> > > > > > If I look at existing targets they already set most of the core 
> > > > > > features apart from 3d image writes. Perhaps it is reasonable to 
> > > > > > just drop this code? I don't think it makes the issue worse, in 
> > > > > > fact, I think it will make the behavior slightly better because now 
> > > > > > a diagnostic will occur if there is an attempt to use the 
> > > > > > unsupported feature although the diagnostic won't be the optimal 
> > > > > > one.  After all it will still remain the responsibility of the user 
> > > > > > to get the right combination of a language version and a target.
> > > > > > 
> > > > > > It would be reasonable however to introduce a diagnostic that would 
> > > > > > report a mismatch between the language version and the hardware 
> > > > > > support available. We report similar diagnostics in 
> > > > > > `CompilerInvocation` already. But I don't think we have to do it in 
> > > > > > this patch because it doesn't introduce any regression. We already 
> > > > > > have a bug although the behavior of this bug will change. And 
> > > > > > perhaps if we add `OpenCLOptions` as a part of `LangOpts` at some 
> > > > > > point this will become straightforward to diagnose. However, I 
> > > > > > suggest we add information about this issue in a FIXME or perhaps 
> > > > > > this deserves a clang bug!
> > > > > > I still think the target map should be immutable and especially we 
> > > > > > should not change it silently based on the language compiled
> > > > > 
> > > > > I'm confused. I think we have agreed to unconditionally support core 
> > > > > features for a specific language version. Did I miss something?
> > > > > 
> > > > > > successfully compiling for the architectures that didn't support 
> > > > > > the features.
> > > > > 
> > > > > I like idea providing diagnostics in that case. Something like: 
> > > > > "Warning: r600 target doesn't support 
> > > > > cl_khr_3d_image_writes which is core in OpenCL C 2.0, consider using 
> > > > > OpenCL C 3.0". I also think this should be done in a separate commit.
> > > > > 
> > > > > > If I look at existing targets they already set most of the core 
> > > > > > features apart from 3d image writes. Perhaps it is reasonable to 
> > > > > > just drop this code?
> > > > > 
> > > > > Oh, I haven't noticed that target set core features. For example 
> > > > > //cl_khr_global_int32_base_atomics// is being set by NVPTX and 
> > > > > AMDGPU, so I agree that this should be removed from target settings.
> > > > It is correct that the core features should be set unconditionally but 
> > > > not in the `TargetInfo`. If core features are used for targets that 
> > > > don't support them then it should not succeed silently as it does now 
> > > > i.e. this means we need to know what is supported by the targets.
> > > > 
> > > > Setting target features in `TargetInfo` is correct and should stay.  We 
> > > > should not change them here though because the language version doesn't 
> > > > change the target capabilities. It can either expose or hide them from 
> > > > the user but it should not modify targets. This is why `TargetInfo` is 
> > > > immutable after its creation and this is how it should stay. I think 
> > > > it's better if we remove the code here completely and introduce a 
> > > > diagnostic in the subsequent patches that would just check that the 
> > > > features required in the language version are supported by the target.
> > > > 
> > > > If we do this then during the parsing we will only use feature 
> > > > information from `OpenCLOptions` not the targets, but we will know that 
> > > > the target have support of all the features because the check has been 
> > > > performed earlier.
> > > I'm not generally against of removing core features set up, but I do have 
> > > some questions and arguments:
> > > 
> > > > It is correct that the core features should be set unconditionally but 
> > > > not in the TargetInfo
> > > 
> > > Just to make sure: where do you mean core features should be set 
> > > unconditionally? 
> > > 
> > > > Setting target features in TargetInfo is correct and should stay. We 
> > > > should not change them here though because the langu

[clang] e20d466 - [clang][cli] Port more options to new parsing system

2021-01-20 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-01-20T10:48:22+01:00
New Revision: e20d46628a31a984074f2e1029e67734d5c2ab0d

URL: 
https://github.com/llvm/llvm-project/commit/e20d46628a31a984074f2e1029e67734d5c2ab0d
DIFF: 
https://github.com/llvm/llvm-project/commit/e20d46628a31a984074f2e1029e67734d5c2ab0d.diff

LOG: [clang][cli] Port more options to new parsing system

This patch adds marshalling information to more options.

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Frontend/CompilerInvocation.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 8150b24e337b..500022c2c99b 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3071,10 +3071,10 @@ def mwavefrontsize64 : Flag<["-"], "mwavefrontsize64">, 
Group,
 def mno_wavefrontsize64 : Flag<["-"], "mno-wavefrontsize64">, Group,
   HelpText<"Specify wavefront size 32 mode (AMDGPU only)">;
 
-def munsafe_fp_atomics : Flag<["-"], "munsafe-fp-atomics">, Group,
-  HelpText<"Enable unsafe floating point atomic instructions (AMDGPU only)">,
-  Flags<[CC1Option]>;
-def mno_unsafe_fp_atomics : Flag<["-"], "mno-unsafe-fp-atomics">, 
Group;
+defm unsafe_fp_atomics : BoolCC1Option<"unsafe-fp-atomics",
+  TargetOpts<"AllowAMDGPUUnsafeFPAtomics">, DefaultsToFalse,
+  ChangedBy,
+  ResetBy, BothFlags<[]>, "m">, Group;
 
 def faltivec : Flag<["-"], "faltivec">, Group, Flags<[NoXarchOption]>;
 def fno_altivec : Flag<["-"], "fno-altivec">, Group, 
Flags<[NoXarchOption]>;
@@ -4378,7 +4378,10 @@ def analyzer_checker_option_help_developer : Flag<["-"], 
"analyzer-checker-optio
   MarshallingInfoFlag>;
 
 def analyzer_config_compatibility_mode : Separate<["-"], 
"analyzer-config-compatibility-mode">,
-  HelpText<"Don't emit errors on invalid analyzer-config inputs">;
+  HelpText<"Don't emit errors on invalid analyzer-config inputs">,
+  Values<"true,false">, NormalizedValues<[[{false}], [{true}]]>,
+  MarshallingInfoString, 
[{true}]>,
+  AutoNormalizeEnum;
 
 def analyzer_config_compatibility_mode_EQ : Joined<["-"], 
"analyzer-config-compatibility-mode=">,
   Alias;
@@ -4842,7 +4845,8 @@ def plugin_arg : JoinedAndSeparate<["-"], "plugin-arg-">,
 MetaVarName<" ">,
 HelpText<"Pass  to plugin ">;
 def add_plugin : Separate<["-"], "add-plugin">, MetaVarName<"">,
-  HelpText<"Use the named plugin action in addition to the default action">;
+  HelpText<"Use the named plugin action in addition to the default action">,
+  MarshallingInfoStringVector>;
 def ast_dump_filter : Separate<["-"], "ast-dump-filter">,
   MetaVarName<"">,
   HelpText<"Use with -ast-dump or -ast-print to dump/print only AST 
declaration"
@@ -5118,10 +5122,13 @@ def fhalf_no_semantic_interposition : Flag<["-"], 
"fhalf-no-semantic-interpositi
 def fno_validate_pch : Flag<["-"], "fno-validate-pch">,
   HelpText<"Disable validation of precompiled headers">,
   MarshallingInfoFlag>;
-def fallow_pch_with_errors : Flag<["-"], "fallow-pch-with-compiler-errors">,
-  HelpText<"Accept a PCH file that was created with compiler errors">;
 def fallow_pcm_with_errors : Flag<["-"], "fallow-pcm-with-compiler-errors">,
-  HelpText<"Accept a PCM file that was created with compiler errors">;
+  HelpText<"Accept a PCM file that was created with compiler errors">,
+  MarshallingInfoFlag>;
+def fallow_pch_with_errors : Flag<["-"], "fallow-pch-with-compiler-errors">,
+  HelpText<"Accept a PCH file that was created with compiler errors">,
+  MarshallingInfoFlag>,
+  ImpliedByAnyOf<[fallow_pcm_with_errors]>;
 def dump_deserialized_pch_decls : Flag<["-"], "dump-deserialized-decls">,
   HelpText<"Dump declarations that are deserialized from PCH, for testing">,
   MarshallingInfoFlag>;

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index dac0dc6921a5..24b8fd19dd50 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -634,13 +634,6 @@ static bool ParseAnalyzerArgs(AnalyzerOptions &Opts, 
ArgList &Args,
 }
   }
 
-  Opts.ShouldEmitErrorsOnInvalidConfigValue =
-  /* negated */!llvm::StringSwitch(
-   
Args.getLastArgValue(OPT_analyzer_config_compatibility_mode))
-.Case("true", true)
-.Case("false", false)
-.Default(false);
-
   Opts.CheckersAndPackages.clear();
   for (const Arg *A :
Args.filtered(OPT_analyzer_checker, OPT_analyzer_disable_checker)) {
@@ -828,10 +821,6 @@ static void parseAnalyzerConfigs(AnalyzerOptions &AnOpts,
<< "a filename";
 }
 
-static void ParseCommentArgs(CommentOptions &Opts, ArgList &Args) {
-  Opts.ParseAllComments = Args.hasArg(OPT_fparse_all_comments);
-}
-
 /// Create a new Regex instance out

[PATCH] D94957: [clang][cli] Port more options to new parsing system

2021-01-20 Thread Jan Svoboda via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe20d46628a31: [clang][cli] Port more options to new parsing 
system (authored by jansvoboda11).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94957

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Frontend/CompilerInvocation.cpp

Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -634,13 +634,6 @@
 }
   }
 
-  Opts.ShouldEmitErrorsOnInvalidConfigValue =
-  /* negated */!llvm::StringSwitch(
-   Args.getLastArgValue(OPT_analyzer_config_compatibility_mode))
-.Case("true", true)
-.Case("false", false)
-.Default(false);
-
   Opts.CheckersAndPackages.clear();
   for (const Arg *A :
Args.filtered(OPT_analyzer_checker, OPT_analyzer_disable_checker)) {
@@ -828,10 +821,6 @@
<< "a filename";
 }
 
-static void ParseCommentArgs(CommentOptions &Opts, ArgList &Args) {
-  Opts.ParseAllComments = Args.hasArg(OPT_fparse_all_comments);
-}
-
 /// Create a new Regex instance out of the string value in \p RpassArg.
 /// It returns a pointer to the newly generated Regex instance.
 static std::shared_ptr
@@ -1645,7 +1634,6 @@
 Opts.ProgramAction = frontend::PluginAction;
 Opts.ActionName = A->getValue();
   }
-  Opts.AddPluginActions = Args.getAllArgValues(OPT_add_plugin);
   for (const auto *AA : Args.filtered(OPT_plugin_arg))
 Opts.PluginArgs[AA->getValue(0)].emplace_back(AA->getValue(1));
 
@@ -1686,7 +1674,6 @@
 if (Val.find('=') == StringRef::npos)
   Opts.ModuleFiles.push_back(std::string(Val));
   }
-  Opts.AllowPCMWithCompilerErrors = Args.hasArg(OPT_fallow_pcm_with_errors);
 
   if (Opts.ProgramAction != frontend::GenerateModule && Opts.IsSystemModule)
 Diags.Report(diag::err_drv_argument_only_allowed_with) << "-fsystem-module"
@@ -2845,8 +2832,6 @@
   frontend::ActionKind Action) {
   Opts.PCHWithHdrStop = Args.hasArg(OPT_pch_through_hdrstop_create) ||
 Args.hasArg(OPT_pch_through_hdrstop_use);
-  Opts.AllowPCHWithCompilerErrors =
-  Args.hasArg(OPT_fallow_pch_with_errors, OPT_fallow_pcm_with_errors);
 
   for (const auto *A : Args.filtered(OPT_error_on_deserialized_pch_decl))
 Opts.DeserializedPCHDeclsToErrorOn.insert(A->getValue());
@@ -2930,9 +2915,6 @@
 
 static void ParseTargetArgs(TargetOptions &Opts, ArgList &Args,
 DiagnosticsEngine &Diags) {
-  Opts.AllowAMDGPUUnsafeFPAtomics =
-  Args.hasFlag(options::OPT_munsafe_fp_atomics,
-   options::OPT_mno_unsafe_fp_atomics, false);
   if (Arg *A = Args.getLastArg(options::OPT_target_sdk_version_EQ)) {
 llvm::VersionTuple Version;
 if (Version.tryParse(A->getValue()))
@@ -2987,7 +2969,6 @@
   }
   Success &= ParseDiagnosticArgs(Res.getDiagnosticOpts(), Args, &Diags,
  /*DefaultDiagColor=*/false);
-  ParseCommentArgs(LangOpts.CommentOpts, Args);
   // FIXME: We shouldn't have to pass the DashX option around here
   InputKind DashX = ParseFrontendArgs(Res.getFrontendOpts(), Args, Diags,
   LangOpts.IsHeaderFile);
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3071,10 +3071,10 @@
 def mno_wavefrontsize64 : Flag<["-"], "mno-wavefrontsize64">, Group,
   HelpText<"Specify wavefront size 32 mode (AMDGPU only)">;
 
-def munsafe_fp_atomics : Flag<["-"], "munsafe-fp-atomics">, Group,
-  HelpText<"Enable unsafe floating point atomic instructions (AMDGPU only)">,
-  Flags<[CC1Option]>;
-def mno_unsafe_fp_atomics : Flag<["-"], "mno-unsafe-fp-atomics">, Group;
+defm unsafe_fp_atomics : BoolCC1Option<"unsafe-fp-atomics",
+  TargetOpts<"AllowAMDGPUUnsafeFPAtomics">, DefaultsToFalse,
+  ChangedBy,
+  ResetBy, BothFlags<[]>, "m">, Group;
 
 def faltivec : Flag<["-"], "faltivec">, Group, Flags<[NoXarchOption]>;
 def fno_altivec : Flag<["-"], "fno-altivec">, Group, Flags<[NoXarchOption]>;
@@ -4378,7 +4378,10 @@
   MarshallingInfoFlag>;
 
 def analyzer_config_compatibility_mode : Separate<["-"], "analyzer-config-compatibility-mode">,
-  HelpText<"Don't emit errors on invalid analyzer-config inputs">;
+  HelpText<"Don't emit errors on invalid analyzer-config inputs">,
+  Values<"true,false">, NormalizedValues<[[{false}], [{true}]]>,
+  MarshallingInfoString, [{true}]>,
+  AutoNormalizeEnum;
 
 def analyzer_config_compatibility_mode_EQ : Joined<["-"], "analyzer-config-compatibility-mode=">,
   Alias;
@@ -4842,7 +4845,8 @@
 MetaVarName<" ">,
 HelpText<"Pass  to plugin "

[PATCH] D94961: [OpenMP] Add OpenMP offloading toolchain skeleton for AMDGPU

2021-01-20 Thread Pushpinder Singh via Phabricator via cfe-commits
pdhaliwal updated this revision to Diff 317810.
pdhaliwal added a comment.
Herald added a subscriber: mgorny.

> Won't this just prevent us from building clang due to the missing cmake 
> changes?

It compiles and builds fine, however, I wasn't actually aware such sanity 
checking being present. It turns out
the unknown files inside llvm/ will lead cmake to report error but such 
reporting will not happen inside clang. Maybe such checks
were not enabled inside clang. Anyways thanks for pointing out. I will keep 
that in mind in future.

The idea for this patch was basically to introduce AMDGPUToolChain classes 
without much of the functionality in order
to keep its size in check. And the second patch would have integrated the 
toolchain with driver along with testing.
But during the intermediate time of the two patches, bare files would have 
existed (never built and tested).

I have updated this patch to now include somewhat functional driver along with 
tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94961

Files:
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
  clang/test/Driver/amdgpu-openmp-toolchain.c

Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- /dev/null
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -0,0 +1,35 @@
+// REQUIRES: amdgpu-registered-target
+// RUN:   %clang -### -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target -march=gfx906 %s 2>&1 \
+// RUN:   | FileCheck %s
+
+// verify the tools invocations
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "c"{{.*}}
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "ir"{{.*}}
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa" "-aux-triple" "x86_64-unknown-linux-gnu" "-emit-llvm-bc" "-emit-llvm-uselists"{{.*}}"-target-cpu" "gfx906" "-fcuda-is-device"{{.*}}"-fopenmp" "-fopenmp-cuda-parallel-target-regions"{{.*}}"-fopenmp-is-device"{{.*}}"-o" {{.*}}amdgpu-openmp-toolchain-{{.*}}.bc{{.*}}"-x" "c"{{.*}}amdgpu-openmp-toolchain.c{{.*}}
+// CHECK: llvm-link{{.*}}amdgpu-openmp-toolchain-{{.*}}.bc" "-o" "{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc"
+// CHECK: opt{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}} "-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-optimized-{{.*}}.bc"
+// CHECK: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-optimized-{{.*}}.bc" "-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=obj" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
+// CHECK: lld{{.*}}"-flavor" "gnu" "--no-undefined" "-shared" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}.out" "{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
+// CHECK: clang-offload-wrapper{{.*}}"-target" "x86_64-unknown-linux-gnu" "-o" "{{.*}}a-{{.*}}.bc" {{.*}}amdgpu-openmp-toolchain-{{.*}}.out"
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-o" "{{.*}}a-{{.*}}.o" "-x" "ir" "{{.*}}a-{{.*}}.bc"
+// CHECK: ld{{.*}}"-o" "a.out"{{.*}}"{{.*}}amdgpu-openmp-toolchain-{{.*}}.o" "{{.*}}a-{{.*}}.o" "-lomp" "-lomptarget"
+
+// RUN:   %clang -ccc-print-phases -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target -march=gfx906 %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-PHASES %s
+// phases
+// CHECK-PHASES: 0: input, "{{.*}}amdgpu-openmp-toolchain.c", c, (host-openmp)
+// CHECK-PHASES: 1: preprocessor, {0}, cpp-output, (host-openmp)
+// CHECK-PHASES: 2: compiler, {1}, ir, (host-openmp)
+// CHECK-PHASES: 3: backend, {2}, assembler, (host-openmp)
+// CHECK-PHASES: 4: assembler, {3}, object, (host-openmp)
+// CHECK-PHASES: 5: input, "{{.*}}amdgpu-openmp-toolchain.c", c, (device-openmp)
+// CHECK-PHASES: 6: preprocessor, {5}, cpp-output, (device-openmp)
+// CHECK-PHASES: 7: compiler, {6}, ir, (device-openmp)
+// CHECK-PHASES: 8: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa)" {7}, ir
+// CHECK-PHASES: 9: linker, {8}, image, (device-openmp)
+// CHECK-PHASES: 10: offload, "device-openmp (amdgcn-amd-amdhsa)" {9}, image
+// CHECK-PHASES: 11: clang-offload-wrapper, {10}, ir, (host-openmp)
+// CHECK-PHASES: 12: backend, {11}, assembler, (host-openmp)
+// CHECK-PHASES: 13: assembler, {12}, object, (host-openmp)
+// CHECK-PHASES: 14: linker, {4, 13}, image, (host-openmp)
+
Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
===
--- /dev/null
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
@@ -0,0 +1,123 @@
+//===- AMDGPUOpenMP.h - AMDGPUOpenMP ToolChain Implementation -*- C++ -*---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-Lic

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

2021-01-20 Thread Alexey Bader via Phabricator via cfe-commits
bader added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89909

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


[clang-tools-extra] 536a1b0 - [clangd] Allow CDBs to have background work to block on.

2021-01-20 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2021-01-20T11:11:01+01:00
New Revision: 536a1b0ea21163eaee53652c527ea20cf45bc675

URL: 
https://github.com/llvm/llvm-project/commit/536a1b0ea21163eaee53652c527ea20cf45bc675
DIFF: 
https://github.com/llvm/llvm-project/commit/536a1b0ea21163eaee53652c527ea20cf45bc675.diff

LOG: [clangd] Allow CDBs to have background work to block on.

In preparation for moving DirectoryBasedCompilationDatabase broadcasting off
the main thread.

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

Added: 


Modified: 
clang-tools-extra/clangd/ClangdServer.cpp
clang-tools-extra/clangd/ClangdServer.h
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
clang-tools-extra/clangd/GlobalCompilationDatabase.h

Removed: 




diff  --git a/clang-tools-extra/clangd/ClangdServer.cpp 
b/clang-tools-extra/clangd/ClangdServer.cpp
index a76250fa168e7..0818d08811e0d 100644
--- a/clang-tools-extra/clangd/ClangdServer.cpp
+++ b/clang-tools-extra/clangd/ClangdServer.cpp
@@ -139,7 +139,8 @@ ClangdServer::Options::operator TUScheduler::Options() 
const {
 ClangdServer::ClangdServer(const GlobalCompilationDatabase &CDB,
const ThreadsafeFS &TFS, const Options &Opts,
Callbacks *Callbacks)
-: ConfigProvider(Opts.ConfigProvider), TFS(TFS), 
ServerCallbacks(Callbacks),
+: ConfigProvider(Opts.ConfigProvider), CDB(CDB), TFS(TFS),
+  ServerCallbacks(Callbacks),
   DynamicIdx(Opts.BuildDynamicSymbolIndex
  ? new FileIndex(Opts.HeavyweightDynamicSymbolIndex,
  Opts.CollectMainFileRefs)
@@ -870,6 +871,7 @@ Context ClangdServer::createProcessingContext(PathRef File) 
const {
 LLVM_NODISCARD bool
 ClangdServer::blockUntilIdleForTest(llvm::Optional TimeoutSeconds) {
   return WorkScheduler.blockUntilIdle(timeoutSeconds(TimeoutSeconds)) &&
+ CDB.blockUntilIdle(timeoutSeconds(TimeoutSeconds)) &&
  (!BackgroundIdx ||
   BackgroundIdx->blockUntilIdleForTest(TimeoutSeconds));
 }

diff  --git a/clang-tools-extra/clangd/ClangdServer.h 
b/clang-tools-extra/clangd/ClangdServer.h
index ff2fc85781038..d10c54f402b42 100644
--- a/clang-tools-extra/clangd/ClangdServer.h
+++ b/clang-tools-extra/clangd/ClangdServer.h
@@ -362,6 +362,7 @@ class ClangdServer {
   Context createProcessingContext(PathRef) const;
   config::Provider *ConfigProvider = nullptr;
 
+  const GlobalCompilationDatabase &CDB;
   const ThreadsafeFS &TFS;
   Callbacks *ServerCallbacks = nullptr;
   mutable std::mutex ConfigDiagnosticsMu;

diff  --git a/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp 
b/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
index fde4e56ac72d8..457cdef2bd8b5 100644
--- a/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
+++ b/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
@@ -636,5 +636,11 @@ tooling::CompileCommand 
DelegatingCDB::getFallbackCommand(PathRef File) const {
   return Base->getFallbackCommand(File);
 }
 
+bool DelegatingCDB::blockUntilIdle(Deadline D) const {
+  if (!Base)
+return true;
+  return Base->blockUntilIdle(D);
+}
+
 } // namespace clangd
 } // namespace clang

diff  --git a/clang-tools-extra/clangd/GlobalCompilationDatabase.h 
b/clang-tools-extra/clangd/GlobalCompilationDatabase.h
index 125bd77a52073..d009905bbecf2 100644
--- a/clang-tools-extra/clangd/GlobalCompilationDatabase.h
+++ b/clang-tools-extra/clangd/GlobalCompilationDatabase.h
@@ -51,6 +51,10 @@ class GlobalCompilationDatabase {
   /// Clangd should treat the results as unreliable.
   virtual tooling::CompileCommand getFallbackCommand(PathRef File) const;
 
+  /// If the CDB does any asynchronous work, wait for it to complete.
+  /// For use in tests.
+  virtual bool blockUntilIdle(Deadline D) const { return true; }
+
   using CommandChanged = Event>;
   /// The callback is notified when files may have new compile commands.
   /// The argument is a list of full file paths.
@@ -75,6 +79,8 @@ class DelegatingCDB : public GlobalCompilationDatabase {
 
   tooling::CompileCommand getFallbackCommand(PathRef File) const override;
 
+  bool blockUntilIdle(Deadline D) const override;
+
 private:
   const GlobalCompilationDatabase *Base;
   std::unique_ptr BaseOwner;



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


[PATCH] D94603: [clangd] Allow CDBs to have background work to block on.

2021-01-20 Thread Sam McCall via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG536a1b0ea211: [clangd] Allow CDBs to have background work to 
block on. (authored by sammccall).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94603

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


Index: clang-tools-extra/clangd/GlobalCompilationDatabase.h
===
--- clang-tools-extra/clangd/GlobalCompilationDatabase.h
+++ clang-tools-extra/clangd/GlobalCompilationDatabase.h
@@ -51,6 +51,10 @@
   /// Clangd should treat the results as unreliable.
   virtual tooling::CompileCommand getFallbackCommand(PathRef File) const;
 
+  /// If the CDB does any asynchronous work, wait for it to complete.
+  /// For use in tests.
+  virtual bool blockUntilIdle(Deadline D) const { return true; }
+
   using CommandChanged = Event>;
   /// The callback is notified when files may have new compile commands.
   /// The argument is a list of full file paths.
@@ -75,6 +79,8 @@
 
   tooling::CompileCommand getFallbackCommand(PathRef File) const override;
 
+  bool blockUntilIdle(Deadline D) const override;
+
 private:
   const GlobalCompilationDatabase *Base;
   std::unique_ptr BaseOwner;
Index: clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
===
--- clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
+++ clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
@@ -636,5 +636,11 @@
   return Base->getFallbackCommand(File);
 }
 
+bool DelegatingCDB::blockUntilIdle(Deadline D) const {
+  if (!Base)
+return true;
+  return Base->blockUntilIdle(D);
+}
+
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -362,6 +362,7 @@
   Context createProcessingContext(PathRef) const;
   config::Provider *ConfigProvider = nullptr;
 
+  const GlobalCompilationDatabase &CDB;
   const ThreadsafeFS &TFS;
   Callbacks *ServerCallbacks = nullptr;
   mutable std::mutex ConfigDiagnosticsMu;
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -139,7 +139,8 @@
 ClangdServer::ClangdServer(const GlobalCompilationDatabase &CDB,
const ThreadsafeFS &TFS, const Options &Opts,
Callbacks *Callbacks)
-: ConfigProvider(Opts.ConfigProvider), TFS(TFS), 
ServerCallbacks(Callbacks),
+: ConfigProvider(Opts.ConfigProvider), CDB(CDB), TFS(TFS),
+  ServerCallbacks(Callbacks),
   DynamicIdx(Opts.BuildDynamicSymbolIndex
  ? new FileIndex(Opts.HeavyweightDynamicSymbolIndex,
  Opts.CollectMainFileRefs)
@@ -870,6 +871,7 @@
 LLVM_NODISCARD bool
 ClangdServer::blockUntilIdleForTest(llvm::Optional TimeoutSeconds) {
   return WorkScheduler.blockUntilIdle(timeoutSeconds(TimeoutSeconds)) &&
+ CDB.blockUntilIdle(timeoutSeconds(TimeoutSeconds)) &&
  (!BackgroundIdx ||
   BackgroundIdx->blockUntilIdleForTest(TimeoutSeconds));
 }


Index: clang-tools-extra/clangd/GlobalCompilationDatabase.h
===
--- clang-tools-extra/clangd/GlobalCompilationDatabase.h
+++ clang-tools-extra/clangd/GlobalCompilationDatabase.h
@@ -51,6 +51,10 @@
   /// Clangd should treat the results as unreliable.
   virtual tooling::CompileCommand getFallbackCommand(PathRef File) const;
 
+  /// If the CDB does any asynchronous work, wait for it to complete.
+  /// For use in tests.
+  virtual bool blockUntilIdle(Deadline D) const { return true; }
+
   using CommandChanged = Event>;
   /// The callback is notified when files may have new compile commands.
   /// The argument is a list of full file paths.
@@ -75,6 +79,8 @@
 
   tooling::CompileCommand getFallbackCommand(PathRef File) const override;
 
+  bool blockUntilIdle(Deadline D) const override;
+
 private:
   const GlobalCompilationDatabase *Base;
   std::unique_ptr BaseOwner;
Index: clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
===
--- clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
+++ clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
@@ -636,5 +636,11 @@
   return Base->getFallbackCommand(File);
 }
 
+bool DelegatingCDB::blockUntilIdle(Deadline D) const {
+  if (!Base)
+return true;
+  return Base->blockUntilIdle(D);
+}
+
 } // namespace clangd
 }

[clang-tools-extra] de4ba70 - [clangd] Move DirBasedCDB broadcasting onto its own thread.

2021-01-20 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2021-01-20T11:22:55+01:00
New Revision: de4ba7073bd7e200aca704e6a26403e07bc246a5

URL: 
https://github.com/llvm/llvm-project/commit/de4ba7073bd7e200aca704e6a26403e07bc246a5
DIFF: 
https://github.com/llvm/llvm-project/commit/de4ba7073bd7e200aca704e6a26403e07bc246a5.diff

LOG: [clangd] Move DirBasedCDB broadcasting onto its own thread.

This is on the critical path (it blocks getting the compile command for
the first file).

It's not trivially fast: it involves processing all filenames in the CDB
and doing some IO to look for shadowing CDBs.

And we may make this slower soon - making CDB configurable implies evaluating
the config for each listed to see which ones really are owned by the
broadcasted CDB.

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

Added: 


Modified: 
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
clang-tools-extra/clangd/GlobalCompilationDatabase.h
clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp 
b/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
index 457cdef2bd8b..3ee2d2d5dec0 100644
--- a/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
+++ b/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
@@ -11,6 +11,7 @@
 #include "SourceCode.h"
 #include "support/Logger.h"
 #include "support/Path.h"
+#include "support/Threading.h"
 #include "support/ThreadsafeFS.h"
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Tooling/ArgumentsAdjusters.h"
@@ -22,12 +23,15 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/ScopeExit.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/ADT/StringMap.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FileUtilities.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Program.h"
 #include "llvm/Support/VirtualFileSystem.h"
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -357,7 +361,7 @@ bool 
DirectoryBasedGlobalCompilationDatabase::DirectoryCache::load(
 
 DirectoryBasedGlobalCompilationDatabase::
 DirectoryBasedGlobalCompilationDatabase(const Options &Opts)
-: Opts(Opts) {
+: Opts(Opts), Broadcaster(std::make_unique(*this)) {
   if (Opts.CompileCommandsDir)
 OnlyDirCache = std::make_unique(*Opts.CompileCommandsDir);
 }
@@ -472,25 +476,107 @@ DirectoryBasedGlobalCompilationDatabase::lookupCDB(
   Result.CDB = std::move(CDB);
   Result.PI.SourceRoot = DirCache->Path;
 
-  // FIXME: Maybe make the following part async, since this can block
-  // retrieval of compile commands.
   if (ShouldBroadcast)
 broadcastCDB(Result);
   return Result;
 }
 
-void DirectoryBasedGlobalCompilationDatabase::broadcastCDB(
-CDBLookupResult Result) const {
-  vlog("Broadcasting compilation database from {0}", Result.PI.SourceRoot);
-  assert(Result.CDB && "Trying to broadcast an invalid CDB!");
+// The broadcast thread announces files with new compile commands to the world.
+// Primarily this is used to enqueue them for background indexing.
+//
+// It's on a separate thread because:
+//  - otherwise it would block the first parse of the initial file
+//  - we need to enumerate all files in the CDB, of which there are many
+//  - we (will) have to evaluate config for every file in the CDB, which is 
slow
+class DirectoryBasedGlobalCompilationDatabase::BroadcastThread {
+  class Filter;
+  DirectoryBasedGlobalCompilationDatabase &Parent;
+
+  std::mutex Mu;
+  std::condition_variable CV;
+  // Shutdown flag (CV is notified after writing).
+  // This is atomic so that broadcasts can also observe it and abort early.
+  std::atomic ShouldStop = {false};
+  struct Task {
+CDBLookupResult Lookup;
+Context Ctx;
+  };
+  std::deque Queue;
+  llvm::Optional ActiveTask;
+  std::thread Thread; // Must be last member.
+
+  // Thread body: this is just the basic queue procesing boilerplate.
+  void run() {
+std::unique_lock Lock(Mu);
+while (true) {
+  bool Stopping = false;
+  CV.wait(Lock, [&] {
+return (Stopping = ShouldStop.load(std::memory_order_acquire)) ||
+   !Queue.empty();
+  });
+  if (Stopping) {
+Queue.clear();
+CV.notify_all();
+return;
+  }
+  ActiveTask = std::move(Queue.front());
+  Queue.pop_front();
 
-  std::vector AllFiles = Result.CDB->getAllFiles();
+  Lock.unlock();
+  {
+WithContext WithCtx(std::move(ActiveTask->Ctx));
+process(ActiveTask->Lookup);
+  }
+  Lock.lock();
+  ActiveTask.reset();
+  CV.notify_all();
+}
+  }
+
+  // Inspects a new CDB and broadcasts the files it owns.
+  void process(const CDBLookupResult &T);
+
+public:
+  BroadcastThread(DirectoryBasedGlobalCompilationDatabase &Parent)
+  : Parent(Parent), Thread([this] { run(); }) {}
+
+  void enqueue(CDBLookupResult Lookup) {
+ 

[PATCH] D94606: [clangd] Move DirBasedCDB broadcasting onto its own thread.

2021-01-20 Thread Sam McCall via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGde4ba7073bd7: [clangd] Move DirBasedCDB broadcasting onto 
its own thread. (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D94606?vs=317365&id=317814#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94606

Files:
  clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
  clang-tools-extra/clangd/GlobalCompilationDatabase.h
  clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp

Index: clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
===
--- clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
+++ clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
@@ -217,11 +217,13 @@
 });
 
 DB.getCompileCommand(testPath("build/../a.cc"));
+ASSERT_TRUE(DB.blockUntilIdle(timeoutSeconds(10)));
 EXPECT_THAT(DiscoveredFiles, UnorderedElementsAre(AllOf(
  EndsWith("a.cc"), Not(HasSubstr("..");
 DiscoveredFiles.clear();
 
 DB.getCompileCommand(testPath("build/gen.cc"));
+ASSERT_TRUE(DB.blockUntilIdle(timeoutSeconds(10)));
 EXPECT_THAT(DiscoveredFiles, UnorderedElementsAre(EndsWith("gen.cc")));
   }
 
@@ -237,12 +239,14 @@
 });
 
 DB.getCompileCommand(testPath("a.cc"));
+ASSERT_TRUE(DB.blockUntilIdle(timeoutSeconds(10)));
 EXPECT_THAT(DiscoveredFiles,
 UnorderedElementsAre(EndsWith("a.cc"), EndsWith("gen.cc"),
  EndsWith("gen2.cc")));
 DiscoveredFiles.clear();
 
 DB.getCompileCommand(testPath("build/gen.cc"));
+ASSERT_TRUE(DB.blockUntilIdle(timeoutSeconds(10)));
 EXPECT_THAT(DiscoveredFiles, IsEmpty());
   }
 }
Index: clang-tools-extra/clangd/GlobalCompilationDatabase.h
===
--- clang-tools-extra/clangd/GlobalCompilationDatabase.h
+++ clang-tools-extra/clangd/GlobalCompilationDatabase.h
@@ -120,6 +120,8 @@
   /// \p File's parents.
   llvm::Optional getProjectInfo(PathRef File) const override;
 
+  bool blockUntilIdle(Deadline Timeout) const override;
+
 private:
   Options Opts;
 
@@ -152,6 +154,9 @@
   };
   llvm::Optional lookupCDB(CDBLookupRequest Request) const;
 
+  class BroadcastThread;
+  std::unique_ptr Broadcaster;
+
   // Performs broadcast on governed files.
   void broadcastCDB(CDBLookupResult Res) const;
 
Index: clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
===
--- clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
+++ clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
@@ -11,6 +11,7 @@
 #include "SourceCode.h"
 #include "support/Logger.h"
 #include "support/Path.h"
+#include "support/Threading.h"
 #include "support/ThreadsafeFS.h"
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Tooling/ArgumentsAdjusters.h"
@@ -22,12 +23,15 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/ScopeExit.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/ADT/StringMap.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FileUtilities.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Program.h"
 #include "llvm/Support/VirtualFileSystem.h"
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -357,7 +361,7 @@
 
 DirectoryBasedGlobalCompilationDatabase::
 DirectoryBasedGlobalCompilationDatabase(const Options &Opts)
-: Opts(Opts) {
+: Opts(Opts), Broadcaster(std::make_unique(*this)) {
   if (Opts.CompileCommandsDir)
 OnlyDirCache = std::make_unique(*Opts.CompileCommandsDir);
 }
@@ -472,25 +476,107 @@
   Result.CDB = std::move(CDB);
   Result.PI.SourceRoot = DirCache->Path;
 
-  // FIXME: Maybe make the following part async, since this can block
-  // retrieval of compile commands.
   if (ShouldBroadcast)
 broadcastCDB(Result);
   return Result;
 }
 
-void DirectoryBasedGlobalCompilationDatabase::broadcastCDB(
-CDBLookupResult Result) const {
-  vlog("Broadcasting compilation database from {0}", Result.PI.SourceRoot);
-  assert(Result.CDB && "Trying to broadcast an invalid CDB!");
+// The broadcast thread announces files with new compile commands to the world.
+// Primarily this is used to enqueue them for background indexing.
+//
+// It's on a separate thread because:
+//  - otherwise it would block the first parse of the initial file
+//  - we need to enumerate all files in the CDB, of which there are many
+//  - we (will) have to evaluate config for every file in the CDB, which is slow
+class DirectoryBasedGlobalCompilationDatabase::BroadcastThread {
+  class Filter;
+  DirectoryBasedGlobalCompilationDatabase &Parent;
+
+  std::mutex Mu;
+  std::conditi

[PATCH] D94727: [clangd] Retire some flags for uncontroversial, stable features.

2021-01-20 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/ClangdServer.h:147
 
-bool SuggestMissingIncludes = false;
-

hokein wrote:
> our internal client explicitly set this to `true`, so we need a migration 
> plan for this, otherwise this would break our build of internal client during 
> the integration, a possible plan is
> 
> 1. set this flag to true by default in upstream, wait for the integration
> 2. remove the explicit setting internally
> 3. remove this flag (this patch) in upstream
> 
> Or just remove the flag internally, then land this patch in upstream (but 
> internal release has to pick-up these two together)
Discussed offline - there's no reason to block for out-of-tree clients here.

(We're removing support for a configuration - SuggestMissingIncludes = false - 
which is AFAIK unused anywhere. And we're removing the flag as well, but this 
is a trivial API change to adapt to)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94727

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


[clang-tools-extra] e6be5c7 - [clangd] Remove the recovery-ast options.

2021-01-20 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2021-01-20T11:23:57+01:00
New Revision: e6be5c7cd6d227144f874623e2764890f80cad32

URL: 
https://github.com/llvm/llvm-project/commit/e6be5c7cd6d227144f874623e2764890f80cad32
DIFF: 
https://github.com/llvm/llvm-project/commit/e6be5c7cd6d227144f874623e2764890f80cad32.diff

LOG: [clangd] Remove the recovery-ast options.

These force a couple of flags or that are now on by default.
So the flags don't currently do anything unless the compile command has
-fno-recovery-ast explicitly.

(For turning recovery *off* for debugging we can inject the flag with config)

This leaves the command-line flags around with no effect, I'm planning to add
a "retired flag" mechanism shortly in a separate patch.

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

Added: 


Modified: 
clang-tools-extra/clangd/ClangdServer.cpp
clang-tools-extra/clangd/ClangdServer.h
clang-tools-extra/clangd/Compiler.cpp
clang-tools-extra/clangd/Compiler.h
clang-tools-extra/clangd/tool/ClangdMain.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/ClangdServer.cpp 
b/clang-tools-extra/clangd/ClangdServer.cpp
index 0818d08811e0..123d755f267e 100644
--- a/clang-tools-extra/clangd/ClangdServer.cpp
+++ b/clang-tools-extra/clangd/ClangdServer.cpp
@@ -147,8 +147,6 @@ ClangdServer::ClangdServer(const GlobalCompilationDatabase 
&CDB,
  : nullptr),
   ClangTidyProvider(Opts.ClangTidyProvider),
   SuggestMissingIncludes(Opts.SuggestMissingIncludes),
-  BuildRecoveryAST(Opts.BuildRecoveryAST),
-  PreserveRecoveryASTType(Opts.PreserveRecoveryASTType),
   WorkspaceRoot(Opts.WorkspaceRoot),
   // Pass a callback into `WorkScheduler` to extract symbols from a newly
   // parsed file and rebuild the file index synchronously each time an AST
@@ -214,8 +212,6 @@ void ClangdServer::addDocument(PathRef File, 
llvm::StringRef Contents,
   Inputs.Opts = std::move(Opts);
   Inputs.Index = Index;
   Inputs.ClangTidyProvider = ClangTidyProvider;
-  Inputs.Opts.BuildRecoveryAST = BuildRecoveryAST;
-  Inputs.Opts.PreserveRecoveryASTType = PreserveRecoveryASTType;
   bool NewFile = WorkScheduler.update(File, Inputs, WantDiags);
   // If we loaded Foo.h, we want to make sure Foo.cpp is indexed.
   if (NewFile && BackgroundIdx)
@@ -253,8 +249,6 @@ void ClangdServer::codeComplete(PathRef File, Position Pos,
 }
 ParseInputs ParseInput{IP->Command, &TFS, IP->Contents.str()};
 ParseInput.Index = Index;
-ParseInput.Opts.BuildRecoveryAST = BuildRecoveryAST;
-ParseInput.Opts.PreserveRecoveryASTType = PreserveRecoveryASTType;
 
 CodeCompleteOpts.MainFileSignals = IP->Signals;
 // FIXME(ibiryukov): even if Preamble is non-null, we may want to check
@@ -300,8 +294,6 @@ void ClangdServer::signatureHelp(PathRef File, Position Pos,
 
 ParseInputs ParseInput{IP->Command, &TFS, IP->Contents.str()};
 ParseInput.Index = Index;
-ParseInput.Opts.BuildRecoveryAST = BuildRecoveryAST;
-ParseInput.Opts.PreserveRecoveryASTType = PreserveRecoveryASTType;
 CB(clangd::signatureHelp(File, Pos, *PreambleData, ParseInput));
   };
 

diff  --git a/clang-tools-extra/clangd/ClangdServer.h 
b/clang-tools-extra/clangd/ClangdServer.h
index d10c54f402b4..832f8b04a11d 100644
--- a/clang-tools-extra/clangd/ClangdServer.h
+++ b/clang-tools-extra/clangd/ClangdServer.h
@@ -118,14 +118,6 @@ class ClangdServer {
 /// checks will be disabled.
 TidyProviderRef ClangTidyProvider;
 
-/// If true, force -frecovery-ast flag.
-/// If false, respect the value in clang.
-bool BuildRecoveryAST = false;
-
-/// If true, force -frecovery-ast-type flag.
-/// If false, respect the value in clang.
-bool PreserveRecoveryASTType = false;
-
 /// Clangd's workspace root. Relevant for "workspace" operations not bound
 /// to a particular file.
 /// FIXME: If not set, should use the current working directory.
@@ -388,11 +380,6 @@ class ClangdServer {
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
 
-  // If true, preserve expressions in AST for broken code.
-  bool BuildRecoveryAST = true;
-  // If true, preserve the type for recovery AST.
-  bool PreserveRecoveryASTType = false;
-
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;

diff  --git a/clang-tools-extra/clangd/Compiler.cpp 
b/clang-tools-extra/clangd/Compiler.cpp
index 3d5c7113f852..bcae67d82050 100644
--- a/clang-tools-extra/clangd/Compiler.cpp
+++ b/clang-tools-extra/clangd/Compiler.cpp
@@ -85,11 +85,6 @@ buildCompilerInvocation(const ParseInputs &Inputs, 
clang::DiagnosticConsumer &D,
   // Don't crash on `#pragma clang __debug parser_crash`
   CI->getPreprocessorOpts().DisablePragmaDebugCrash = true;
 
-  if (Inputs.Opts.BuildRecoveryAST)
-CI->getLangOpt

[PATCH] D94724: [clangd] Remove the recovery-ast options.

2021-01-20 Thread Sam McCall via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe6be5c7cd6d2: [clangd] Remove the recovery-ast options. 
(authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D94724?vs=316783&id=317816#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94724

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/Compiler.cpp
  clang-tools-extra/clangd/Compiler.h
  clang-tools-extra/clangd/tool/ClangdMain.cpp

Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -312,14 +312,15 @@
 "recovery-ast",
 cat(Features),
 desc("Preserve expressions in AST for broken code."),
-init(ClangdServer::Options().BuildRecoveryAST),
+init(false),
+Hidden,
 };
 
 opt RecoveryASTType{
 "recovery-ast-type",
 cat(Features),
 desc("Preserve the type for recovery AST."),
-init(ClangdServer::Options().PreserveRecoveryASTType),
+init(false),
 Hidden,
 };
 
@@ -813,8 +814,6 @@
 Opts.StaticIndex = PAI.get();
   }
   Opts.AsyncThreadsCount = WorkerThreadsCount;
-  Opts.BuildRecoveryAST = RecoveryAST;
-  Opts.PreserveRecoveryASTType = RecoveryASTType;
   Opts.FoldingRanges = FoldingRanges;
   Opts.MemoryCleanup = getMemoryCleanupFunction();
 
Index: clang-tools-extra/clangd/Compiler.h
===
--- clang-tools-extra/clangd/Compiler.h
+++ clang-tools-extra/clangd/Compiler.h
@@ -38,8 +38,6 @@
 // Options to run clang e.g. when parsing AST.
 struct ParseOptions {
   bool SuggestMissingIncludes = false;
-  bool BuildRecoveryAST = false;
-  bool PreserveRecoveryASTType = false;
 };
 
 /// Information required to run clang, e.g. to parse AST or do code completion.
Index: clang-tools-extra/clangd/Compiler.cpp
===
--- clang-tools-extra/clangd/Compiler.cpp
+++ clang-tools-extra/clangd/Compiler.cpp
@@ -85,11 +85,6 @@
   // Don't crash on `#pragma clang __debug parser_crash`
   CI->getPreprocessorOpts().DisablePragmaDebugCrash = true;
 
-  if (Inputs.Opts.BuildRecoveryAST)
-CI->getLangOpts()->RecoveryAST = true;
-  if (Inputs.Opts.PreserveRecoveryASTType)
-CI->getLangOpts()->RecoveryASTType = true;
-
   return CI;
 }
 
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -118,14 +118,6 @@
 /// checks will be disabled.
 TidyProviderRef ClangTidyProvider;
 
-/// If true, force -frecovery-ast flag.
-/// If false, respect the value in clang.
-bool BuildRecoveryAST = false;
-
-/// If true, force -frecovery-ast-type flag.
-/// If false, respect the value in clang.
-bool PreserveRecoveryASTType = false;
-
 /// Clangd's workspace root. Relevant for "workspace" operations not bound
 /// to a particular file.
 /// FIXME: If not set, should use the current working directory.
@@ -388,11 +380,6 @@
   // can be caused by missing includes (e.g. member access in incomplete type).
   bool SuggestMissingIncludes = false;
 
-  // If true, preserve expressions in AST for broken code.
-  bool BuildRecoveryAST = true;
-  // If true, preserve the type for recovery AST.
-  bool PreserveRecoveryASTType = false;
-
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -147,8 +147,6 @@
  : nullptr),
   ClangTidyProvider(Opts.ClangTidyProvider),
   SuggestMissingIncludes(Opts.SuggestMissingIncludes),
-  BuildRecoveryAST(Opts.BuildRecoveryAST),
-  PreserveRecoveryASTType(Opts.PreserveRecoveryASTType),
   WorkspaceRoot(Opts.WorkspaceRoot),
   // Pass a callback into `WorkScheduler` to extract symbols from a newly
   // parsed file and rebuild the file index synchronously each time an AST
@@ -214,8 +212,6 @@
   Inputs.Opts = std::move(Opts);
   Inputs.Index = Index;
   Inputs.ClangTidyProvider = ClangTidyProvider;
-  Inputs.Opts.BuildRecoveryAST = BuildRecoveryAST;
-  Inputs.Opts.PreserveRecoveryASTType = PreserveRecoveryASTType;
   bool NewFile = WorkScheduler.update(File, Inputs, WantDiags);
   // If we loaded Foo.h, we want to make sure Foo.cpp is indexed.
   if (NewFile && BackgroundIdx)
@@ -253,8 +249,6 @@
 }
 ParseInputs ParseInput{IP->Command, &TFS, IP->Contents.str()};
 ParseInput.Index = Index;
-   

[clang-tools-extra] 2ab5fd2 - [clangd] Retire some flags for uncontroversial, stable features.

2021-01-20 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2021-01-20T11:47:12+01:00
New Revision: 2ab5fd2c8567ac89d7e7639563babdfc78dbcf78

URL: 
https://github.com/llvm/llvm-project/commit/2ab5fd2c8567ac89d7e7639563babdfc78dbcf78
DIFF: 
https://github.com/llvm/llvm-project/commit/2ab5fd2c8567ac89d7e7639563babdfc78dbcf78.diff

LOG: [clangd] Retire some flags for uncontroversial, stable features.

And mark a couple to be retired afther the next release branch.

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

Added: 


Modified: 
clang-tools-extra/clangd/ClangdServer.cpp
clang-tools-extra/clangd/ClangdServer.h
clang-tools-extra/clangd/Compiler.h
clang-tools-extra/clangd/ParsedAST.cpp
clang-tools-extra/clangd/tool/ClangdMain.cpp
clang-tools-extra/clangd/unittests/TestTU.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/ClangdServer.cpp 
b/clang-tools-extra/clangd/ClangdServer.cpp
index 123d755f267e..32e08e688f44 100644
--- a/clang-tools-extra/clangd/ClangdServer.cpp
+++ b/clang-tools-extra/clangd/ClangdServer.cpp
@@ -146,7 +146,6 @@ ClangdServer::ClangdServer(const GlobalCompilationDatabase 
&CDB,
  Opts.CollectMainFileRefs)
  : nullptr),
   ClangTidyProvider(Opts.ClangTidyProvider),
-  SuggestMissingIncludes(Opts.SuggestMissingIncludes),
   WorkspaceRoot(Opts.WorkspaceRoot),
   // Pass a callback into `WorkScheduler` to extract symbols from a newly
   // parsed file and rebuild the file index synchronously each time an AST
@@ -201,7 +200,6 @@ void ClangdServer::addDocument(PathRef File, 
llvm::StringRef Contents,
llvm::StringRef Version,
WantDiagnostics WantDiags, bool ForceRebuild) {
   ParseOptions Opts;
-  Opts.SuggestMissingIncludes = SuggestMissingIncludes;
 
   // Compile command is set asynchronously during update, as it can be slow.
   ParseInputs Inputs;

diff  --git a/clang-tools-extra/clangd/ClangdServer.h 
b/clang-tools-extra/clangd/ClangdServer.h
index 832f8b04a11d..926de39b507a 100644
--- a/clang-tools-extra/clangd/ClangdServer.h
+++ b/clang-tools-extra/clangd/ClangdServer.h
@@ -136,8 +136,6 @@ class ClangdServer {
 /*RebuildRatio=*/1,
 };
 
-bool SuggestMissingIncludes = false;
-
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
@@ -376,10 +374,6 @@ class ClangdServer {
   // When set, provides clang-tidy options for a specific file.
   TidyProviderRef ClangTidyProvider;
 
-  // If this is true, suggest include insertion fixes for diagnostic errors 
that
-  // can be caused by missing includes (e.g. member access in incomplete type).
-  bool SuggestMissingIncludes = false;
-
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;

diff  --git a/clang-tools-extra/clangd/Compiler.h 
b/clang-tools-extra/clangd/Compiler.h
index c46fb764d317..13fd4da33e3c 100644
--- a/clang-tools-extra/clangd/Compiler.h
+++ b/clang-tools-extra/clangd/Compiler.h
@@ -37,7 +37,7 @@ class IgnoreDiagnostics : public DiagnosticConsumer {
 
 // Options to run clang e.g. when parsing AST.
 struct ParseOptions {
-  bool SuggestMissingIncludes = false;
+  // (empty at present, formerly controlled recovery AST, include-fixer etc)
 };
 
 /// Information required to run clang, e.g. to parse AST or do code completion.

diff  --git a/clang-tools-extra/clangd/ParsedAST.cpp 
b/clang-tools-extra/clangd/ParsedAST.cpp
index 228db29b2be3..a8c4eea54540 100644
--- a/clang-tools-extra/clangd/ParsedAST.cpp
+++ b/clang-tools-extra/clangd/ParsedAST.cpp
@@ -351,8 +351,7 @@ ParsedAST::build(llvm::StringRef Filename, const 
ParseInputs &Inputs,
   // (e.g. incomplete type) and attach include insertion fixes to diagnostics.
   llvm::Optional FixIncludes;
   auto BuildDir = VFS->getCurrentWorkingDirectory();
-  if (Inputs.Opts.SuggestMissingIncludes && Inputs.Index &&
-  !BuildDir.getError()) {
+  if (Inputs.Index && !BuildDir.getError()) {
 auto Style = getFormatStyleForFile(Filename, Inputs.Contents, *Inputs.TFS);
 auto Inserter = std::make_shared(
 Filename, Inputs.Contents, Style, BuildDir.get(),

diff  --git a/clang-tools-extra/clangd/tool/ClangdMain.cpp 
b/clang-tools-extra/clangd/tool/ClangdMain.cpp
index 5cbf8aa0df90..fe69079bfe67 100644
--- a/clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ b/clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -80,8 +80,21 @@ OptionCategory CompileCommands("clangd compilation flags 
options");
 OptionCategory Features("clangd feature options");
 OptionCategory Misc("clangd miscellaneous options");
 OptionCategory Protocol("clangd protocol and logging options");
+OptionCategory Retired("clangd flags no longer in use");
 const OptionCategory *ClangdCategories[] = {&Features, &Proto

[PATCH] D94727: [clangd] Retire some flags for uncontroversial, stable features.

2021-01-20 Thread Sam McCall via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2ab5fd2c8567: [clangd] Retire some flags for 
uncontroversial, stable features. (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D94727?vs=316787&id=317819#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94727

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/Compiler.h
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/tool/ClangdMain.cpp
  clang-tools-extra/clangd/unittests/TestTU.cpp

Index: clang-tools-extra/clangd/unittests/TestTU.cpp
===
--- clang-tools-extra/clangd/unittests/TestTU.cpp
+++ clang-tools-extra/clangd/unittests/TestTU.cpp
@@ -62,8 +62,6 @@
   if (ClangTidyProvider)
 Inputs.ClangTidyProvider = ClangTidyProvider;
   Inputs.Index = ExternalIndex;
-  if (Inputs.Index)
-Inputs.Opts.SuggestMissingIncludes = true;
   return Inputs;
 }
 
Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -80,8 +80,21 @@
 OptionCategory Features("clangd feature options");
 OptionCategory Misc("clangd miscellaneous options");
 OptionCategory Protocol("clangd protocol and logging options");
+OptionCategory Retired("clangd flags no longer in use");
 const OptionCategory *ClangdCategories[] = {&Features, &Protocol,
-&CompileCommands, &Misc};
+&CompileCommands, &Misc, &Retired};
+
+template  class RetiredFlag {
+  opt Option;
+
+public:
+  RetiredFlag(llvm::StringRef Name)
+  : Option(Name, cat(Retired), desc("Obsolete flag, ignored"), Hidden,
+   llvm::cl::callback([Name](const T &) {
+ llvm::errs()
+ << "The flag `-" << Name << "` is obsolete and ignored.\n";
+   })) {}
+};
 
 enum CompileArgsFrom { LSPCompileArgs, FilesystemCompileArgs };
 opt CompileArgsFrom{
@@ -267,15 +280,7 @@
 Hidden,
 };
 
-opt EnableIndex{
-"index",
-cat(Features),
-desc("Enable index-based features. By default, clangd maintains an index "
- "built from symbols in opened files. Global index support needs to "
- "enabled separatedly"),
-init(true),
-Hidden,
-};
+RetiredFlag EnableIndex("index");
 
 opt LimitResults{
 "limit-results",
@@ -285,13 +290,7 @@
 init(100),
 };
 
-opt SuggestMissingIncludes{
-"suggest-missing-includes",
-cat(Features),
-desc("Attempts to fix diagnostic errors caused by missing "
- "includes using index"),
-init(true),
-};
+RetiredFlag SuggestMissingIncludes("suggest-missing-includes");
 
 list TweakList{
 "tweaks",
@@ -308,21 +307,8 @@
 init(true),
 };
 
-opt RecoveryAST{
-"recovery-ast",
-cat(Features),
-desc("Preserve expressions in AST for broken code."),
-init(false),
-Hidden,
-};
-
-opt RecoveryASTType{
-"recovery-ast-type",
-cat(Features),
-desc("Preserve the type for recovery AST."),
-init(false),
-Hidden,
-};
+RetiredFlag RecoveryAST("recovery-ast");
+RetiredFlag RecoveryASTType("recovery-ast-type");
 
 opt FoldingRanges{
 "folding-ranges",
@@ -464,6 +450,7 @@
 init(false),
 };
 
+// FIXME: retire this flag in llvm 13 release cycle.
 opt AsyncPreamble{
 "async-preamble",
 cat(Misc),
@@ -487,11 +474,13 @@
 init(true),
 };
 
+// FIXME: retire this flag in llvm 13 release cycle.
 opt CollectMainFileRefs{
 "collect-main-file-refs",
 cat(Misc),
 desc("Store references to main-file-only symbols in the index"),
 init(ClangdServer::Options().CollectMainFileRefs),
+Hidden,
 };
 
 #if defined(__GLIBC__) && CLANGD_MALLOC_TRIM
@@ -770,12 +759,12 @@
   }
   if (!ResourceDir.empty())
 Opts.ResourceDir = ResourceDir;
-  Opts.BuildDynamicSymbolIndex = EnableIndex;
+  Opts.BuildDynamicSymbolIndex = true;
   Opts.CollectMainFileRefs = CollectMainFileRefs;
   std::vector> IdxStack;
   std::unique_ptr StaticIdx;
   std::future AsyncIndexLoad; // Block exit while loading the index.
-  if (EnableIndex && !IndexFile.empty()) {
+  if (!IndexFile.empty()) {
 // Load the index asynchronously. Meanwhile SwapIndex returns no results.
 SwapIndex *Placeholder;
 StaticIdx.reset(Placeholder = new SwapIndex(std::make_unique()));
@@ -872,7 +861,6 @@
 Opts.ClangTidyProvider = ClangTidyOptProvider;
   }
   Opts.AsyncPreambleBuilds = AsyncPreamble;
-  Opts.SuggestMissingIncludes = SuggestMissingIncludes;
   Opts.QueryDriverGlobs = std::move(QueryDriverGlobs);
   Opts.TweakFilter = [&](const Tweak &T) {
 if (T.hidden() && !HiddenFeatures)
Index: clang-tools-extra/clangd/ParsedAST.cpp
==

[PATCH] D92277: [OpenCL] Refactor of targets OpenCL option settings

2021-01-20 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/lib/Basic/TargetInfo.cpp:360
+// Set core features based on OpenCL version
+for (auto CoreExt : clang::getCoreFeatures(Opts))
+  getTargetOpts().OpenCLFeaturesMap[CoreExt] = true;

azabaznov wrote:
> Anastasia wrote:
> > azabaznov wrote:
> > > azabaznov wrote:
> > > > Anastasia wrote:
> > > > > azabaznov wrote:
> > > > > > Anastasia wrote:
> > > > > > > I still think the target map should be immutable and especially 
> > > > > > > we should not change it silently based on the language compiled 
> > > > > > > even if we have done it before but that caused incorrect behavior 
> > > > > > > i.e. successfully compiling for the architectures that didn't 
> > > > > > > support the features.
> > > > > > > 
> > > > > > > If I look at existing targets they already set most of the core 
> > > > > > > features apart from 3d image writes. Perhaps it is reasonable to 
> > > > > > > just drop this code? I don't think it makes the issue worse, in 
> > > > > > > fact, I think it will make the behavior slightly better because 
> > > > > > > now a diagnostic will occur if there is an attempt to use the 
> > > > > > > unsupported feature although the diagnostic won't be the optimal 
> > > > > > > one.  After all it will still remain the responsibility of the 
> > > > > > > user to get the right combination of a language version and a 
> > > > > > > target.
> > > > > > > 
> > > > > > > It would be reasonable however to introduce a diagnostic that 
> > > > > > > would report a mismatch between the language version and the 
> > > > > > > hardware support available. We report similar diagnostics in 
> > > > > > > `CompilerInvocation` already. But I don't think we have to do it 
> > > > > > > in this patch because it doesn't introduce any regression. We 
> > > > > > > already have a bug although the behavior of this bug will change. 
> > > > > > > And perhaps if we add `OpenCLOptions` as a part of `LangOpts` at 
> > > > > > > some point this will become straightforward to diagnose. However, 
> > > > > > > I suggest we add information about this issue in a FIXME or 
> > > > > > > perhaps this deserves a clang bug!
> > > > > > > I still think the target map should be immutable and especially 
> > > > > > > we should not change it silently based on the language compiled
> > > > > > 
> > > > > > I'm confused. I think we have agreed to unconditionally support 
> > > > > > core features for a specific language version. Did I miss something?
> > > > > > 
> > > > > > > successfully compiling for the architectures that didn't support 
> > > > > > > the features.
> > > > > > 
> > > > > > I like idea providing diagnostics in that case. Something like: 
> > > > > > "Warning: r600 target doesn't support 
> > > > > > cl_khr_3d_image_writes which is core in OpenCL C 2.0, consider 
> > > > > > using OpenCL C 3.0". I also think this should be done in a separate 
> > > > > > commit.
> > > > > > 
> > > > > > > If I look at existing targets they already set most of the core 
> > > > > > > features apart from 3d image writes. Perhaps it is reasonable to 
> > > > > > > just drop this code?
> > > > > > 
> > > > > > Oh, I haven't noticed that target set core features. For example 
> > > > > > //cl_khr_global_int32_base_atomics// is being set by NVPTX and 
> > > > > > AMDGPU, so I agree that this should be removed from target settings.
> > > > > It is correct that the core features should be set unconditionally 
> > > > > but not in the `TargetInfo`. If core features are used for targets 
> > > > > that don't support them then it should not succeed silently as it 
> > > > > does now i.e. this means we need to know what is supported by the 
> > > > > targets.
> > > > > 
> > > > > Setting target features in `TargetInfo` is correct and should stay.  
> > > > > We should not change them here though because the language version 
> > > > > doesn't change the target capabilities. It can either expose or hide 
> > > > > them from the user but it should not modify targets. This is why 
> > > > > `TargetInfo` is immutable after its creation and this is how it 
> > > > > should stay. I think it's better if we remove the code here 
> > > > > completely and introduce a diagnostic in the subsequent patches that 
> > > > > would just check that the features required in the language version 
> > > > > are supported by the target.
> > > > > 
> > > > > If we do this then during the parsing we will only use feature 
> > > > > information from `OpenCLOptions` not the targets, but we will know 
> > > > > that the target have support of all the features because the check 
> > > > > has been performed earlier.
> > > > I'm not generally against of removing core features set up, but I do 
> > > > have some questions and arguments:
> > > > 
> > > > > It is correct that the core features should be set unconditionally 
> > > > > but not in the TargetInfo
> > > > 
> > > > Just to make s

[PATCH] D95031: [clangd] Log warning when using legacy (theia) semantic highlighting.

2021-01-20 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: kadircet.
Herald added subscribers: usaxena95, arphaman.
sammccall requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang.

The legacy protocol will be removed on trunk after the 12 branch cut,
and gone in clangd 13.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95031

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp


Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -487,6 +487,11 @@
 "semanticTokens request, choosing the latter (no notifications).");
 Opts.TheiaSemanticHighlighting = false;
   }
+  if (Opts.TheiaSemanticHighlighting) {
+log("Using legacy semanticHighlights notification, which will be removed "
+"in clangd 13. Clients should use the standard semanticTokens "
+"request instead.");
+  }
 
   if (Params.rootUri && *Params.rootUri)
 Opts.WorkspaceRoot = std::string(Params.rootUri->file());


Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -487,6 +487,11 @@
 "semanticTokens request, choosing the latter (no notifications).");
 Opts.TheiaSemanticHighlighting = false;
   }
+  if (Opts.TheiaSemanticHighlighting) {
+log("Using legacy semanticHighlights notification, which will be removed "
+"in clangd 13. Clients should use the standard semanticTokens "
+"request instead.");
+  }
 
   if (Params.rootUri && *Params.rootUri)
 Opts.WorkspaceRoot = std::string(Params.rootUri->file());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D94617: [RISCV] Add Zba feature and move add.uw and slli.uw to it.

2021-01-20 Thread Fraser Cormack via Phabricator via cfe-commits
frasercrmck accepted this revision.
frasercrmck 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/D94617/new/

https://reviews.llvm.org/D94617

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


[clang-tools-extra] a1d4649 - [clangd] Fix division by zero when computing scores

2021-01-20 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2021-01-20T12:50:25+01:00
New Revision: a1d4649a5b176bf826685cac5cc4416b6498bdf9

URL: 
https://github.com/llvm/llvm-project/commit/a1d4649a5b176bf826685cac5cc4416b6498bdf9
DIFF: 
https://github.com/llvm/llvm-project/commit/a1d4649a5b176bf826685cac5cc4416b6498bdf9.diff

LOG: [clangd] Fix division by zero when computing scores

NameMatch could be a float close to zero, in such cases we were
dividing by zero and moreover propogating a "NaN" to clients, which is invalid
per JSON.

This fixes the issue by only using Quality scores whenever the NameMatch is low,
as we do in CodeCompletion ranking.

Fixes https://github.com/clangd/clangd/issues/648.

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

Added: 


Modified: 
clang-tools-extra/clangd/CodeComplete.cpp
clang-tools-extra/clangd/FindSymbols.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/CodeComplete.cpp 
b/clang-tools-extra/clangd/CodeComplete.cpp
index 9cc18ae789d5..976025b6353e 100644
--- a/clang-tools-extra/clangd/CodeComplete.cpp
+++ b/clang-tools-extra/clangd/CodeComplete.cpp
@@ -70,6 +70,7 @@
 #include "llvm/Support/ScopedPrinter.h"
 #include 
 #include 
+#include 
 
 // We log detailed candidate here if you run with -debug-only=codecomplete.
 #define DEBUG_TYPE "CodeComplete"
@@ -1655,9 +1656,10 @@ class CodeCompleteFlow {
   evaluateSymbolAndRelevance(Scores.Quality, Scores.Relevance);
   // NameMatch is in fact a multiplier on total score, so rescoring is
   // sound.
-  Scores.ExcludingName = Relevance.NameMatch
- ? Scores.Total / Relevance.NameMatch
- : Scores.Quality;
+  Scores.ExcludingName =
+  Relevance.NameMatch > std::numeric_limits::epsilon()
+  ? Scores.Total / Relevance.NameMatch
+  : Scores.Quality;
   return Scores;
 
 case RM::DecisionForest:

diff  --git a/clang-tools-extra/clangd/FindSymbols.cpp 
b/clang-tools-extra/clangd/FindSymbols.cpp
index 0a10e3efb05c..e75a74b4b05c 100644
--- a/clang-tools-extra/clangd/FindSymbols.cpp
+++ b/clang-tools-extra/clangd/FindSymbols.cpp
@@ -25,6 +25,7 @@
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/ScopedPrinter.h"
+#include 
 #include 
 
 #define DEBUG_TYPE "FindSymbols"
@@ -146,8 +147,9 @@ getWorkspaceSymbols(llvm::StringRef Query, int Limit,
   return;
 }
 Relevance.merge(Sym);
-auto Score = evaluateSymbolAndRelevance(Quality.evaluateHeuristics(),
-Relevance.evaluateHeuristics());
+auto QualScore = Quality.evaluateHeuristics();
+auto RelScore = Relevance.evaluateHeuristics();
+auto Score = evaluateSymbolAndRelevance(QualScore, RelScore);
 dlog("FindSymbols: {0}{1} = {2}\n{3}{4}\n", Sym.Scope, Sym.Name, Score,
  Quality, Relevance);
 
@@ -159,7 +161,9 @@ getWorkspaceSymbols(llvm::StringRef Query, int Limit,
 Info.containerName = Scope.str();
 
 // Exposed score excludes fuzzy-match component, for client-side 
re-ranking.
-Info.score = Score / Relevance.NameMatch;
+Info.score = Relevance.NameMatch > std::numeric_limits::epsilon()
+ ? Score / Relevance.NameMatch
+ : QualScore;
 Top.push({Score, std::move(Info)});
   });
   for (auto &R : std::move(Top).items())



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


[PATCH] D94755: [clangd] Fix division by zero when computing scores

2021-01-20 Thread Kadir Cetinkaya via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa1d4649a5b17: [clangd] Fix division by zero when computing 
scores (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94755

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/FindSymbols.cpp


Index: clang-tools-extra/clangd/FindSymbols.cpp
===
--- clang-tools-extra/clangd/FindSymbols.cpp
+++ clang-tools-extra/clangd/FindSymbols.cpp
@@ -25,6 +25,7 @@
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/ScopedPrinter.h"
+#include 
 #include 
 
 #define DEBUG_TYPE "FindSymbols"
@@ -146,8 +147,9 @@
   return;
 }
 Relevance.merge(Sym);
-auto Score = evaluateSymbolAndRelevance(Quality.evaluateHeuristics(),
-Relevance.evaluateHeuristics());
+auto QualScore = Quality.evaluateHeuristics();
+auto RelScore = Relevance.evaluateHeuristics();
+auto Score = evaluateSymbolAndRelevance(QualScore, RelScore);
 dlog("FindSymbols: {0}{1} = {2}\n{3}{4}\n", Sym.Scope, Sym.Name, Score,
  Quality, Relevance);
 
@@ -159,7 +161,9 @@
 Info.containerName = Scope.str();
 
 // Exposed score excludes fuzzy-match component, for client-side 
re-ranking.
-Info.score = Score / Relevance.NameMatch;
+Info.score = Relevance.NameMatch > std::numeric_limits::epsilon()
+ ? Score / Relevance.NameMatch
+ : QualScore;
 Top.push({Score, std::move(Info)});
   });
   for (auto &R : std::move(Top).items())
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -70,6 +70,7 @@
 #include "llvm/Support/ScopedPrinter.h"
 #include 
 #include 
+#include 
 
 // We log detailed candidate here if you run with -debug-only=codecomplete.
 #define DEBUG_TYPE "CodeComplete"
@@ -1655,9 +1656,10 @@
   evaluateSymbolAndRelevance(Scores.Quality, Scores.Relevance);
   // NameMatch is in fact a multiplier on total score, so rescoring is
   // sound.
-  Scores.ExcludingName = Relevance.NameMatch
- ? Scores.Total / Relevance.NameMatch
- : Scores.Quality;
+  Scores.ExcludingName =
+  Relevance.NameMatch > std::numeric_limits::epsilon()
+  ? Scores.Total / Relevance.NameMatch
+  : Scores.Quality;
   return Scores;
 
 case RM::DecisionForest:


Index: clang-tools-extra/clangd/FindSymbols.cpp
===
--- clang-tools-extra/clangd/FindSymbols.cpp
+++ clang-tools-extra/clangd/FindSymbols.cpp
@@ -25,6 +25,7 @@
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/ScopedPrinter.h"
+#include 
 #include 
 
 #define DEBUG_TYPE "FindSymbols"
@@ -146,8 +147,9 @@
   return;
 }
 Relevance.merge(Sym);
-auto Score = evaluateSymbolAndRelevance(Quality.evaluateHeuristics(),
-Relevance.evaluateHeuristics());
+auto QualScore = Quality.evaluateHeuristics();
+auto RelScore = Relevance.evaluateHeuristics();
+auto Score = evaluateSymbolAndRelevance(QualScore, RelScore);
 dlog("FindSymbols: {0}{1} = {2}\n{3}{4}\n", Sym.Scope, Sym.Name, Score,
  Quality, Relevance);
 
@@ -159,7 +161,9 @@
 Info.containerName = Scope.str();
 
 // Exposed score excludes fuzzy-match component, for client-side re-ranking.
-Info.score = Score / Relevance.NameMatch;
+Info.score = Relevance.NameMatch > std::numeric_limits::epsilon()
+ ? Score / Relevance.NameMatch
+ : QualScore;
 Top.push({Score, std::move(Info)});
   });
   for (auto &R : std::move(Top).items())
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -70,6 +70,7 @@
 #include "llvm/Support/ScopedPrinter.h"
 #include 
 #include 
+#include 
 
 // We log detailed candidate here if you run with -debug-only=codecomplete.
 #define DEBUG_TYPE "CodeComplete"
@@ -1655,9 +1656,10 @@
   evaluateSymbolAndRelevance(Scores.Quality, Scores.Relevance);
   // NameMatch is in fact a multiplier on total score, so rescoring is
   // sound.
-  Scores.ExcludingName = Relevance.NameMatch
- ? Scores.Total / Relevance.NameMatch
- : Scores.Quality;
+  Scores.ExcludingName =
+  Relevance.NameMatch > std::numeric_limits::epsilon()
+  ? S

[PATCH] D94961: [OpenMP] Add OpenMP offloading toolchain for AMDGPU

2021-01-20 Thread Pushpinder Singh via Phabricator via cfe-commits
pdhaliwal updated this revision to Diff 317831.
pdhaliwal added a comment.

Fixed failing debian tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94961

Files:
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
  clang/test/Driver/amdgpu-openmp-toolchain.c

Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- /dev/null
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -0,0 +1,35 @@
+// REQUIRES: amdgpu-registered-target
+// RUN:   %clang -### -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s 2>&1 \
+// RUN:   | FileCheck %s
+
+// verify the tools invocations
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "c"{{.*}}
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "ir"{{.*}}
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa"{{.*}}"-target-cpu" "gfx906" "-fcuda-is-device"{{.*}}amdgpu-openmp-toolchain-{{.*}}.bc{{.*}}"-x" "c"{{.*}}amdgpu-openmp-toolchain.c{{.*}}
+// CHECK: llvm-link{{.*}}amdgpu-openmp-toolchain-{{.*}}.bc" "-o" "{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc"
+// CHECK: opt{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}} "-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-optimized-{{.*}}.bc"
+// CHECK: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-optimized-{{.*}}.bc" "-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=obj" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
+// CHECK: lld{{.*}}"-flavor" "gnu" "--no-undefined" "-shared" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}.out" "{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
+// CHECK: clang-offload-wrapper{{.*}}"-target" "x86_64-unknown-linux-gnu" "-o" "{{.*}}a-{{.*}}.bc" {{.*}}amdgpu-openmp-toolchain-{{.*}}.out"
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-o" "{{.*}}a-{{.*}}.o" "-x" "ir" "{{.*}}a-{{.*}}.bc"
+// CHECK: ld{{.*}}"-o" "a.out"{{.*}}"{{.*}}amdgpu-openmp-toolchain-{{.*}}.o" "{{.*}}a-{{.*}}.o" "-lomp" "-lomptarget"
+
+// RUN:   %clang -ccc-print-phases -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-PHASES %s
+// phases
+// CHECK-PHASES: 0: input, "{{.*}}amdgpu-openmp-toolchain.c", c, (host-openmp)
+// CHECK-PHASES: 1: preprocessor, {0}, cpp-output, (host-openmp)
+// CHECK-PHASES: 2: compiler, {1}, ir, (host-openmp)
+// CHECK-PHASES: 3: backend, {2}, assembler, (host-openmp)
+// CHECK-PHASES: 4: assembler, {3}, object, (host-openmp)
+// CHECK-PHASES: 5: input, "{{.*}}amdgpu-openmp-toolchain.c", c, (device-openmp)
+// CHECK-PHASES: 6: preprocessor, {5}, cpp-output, (device-openmp)
+// CHECK-PHASES: 7: compiler, {6}, ir, (device-openmp)
+// CHECK-PHASES: 8: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa)" {7}, ir
+// CHECK-PHASES: 9: linker, {8}, image, (device-openmp)
+// CHECK-PHASES: 10: offload, "device-openmp (amdgcn-amd-amdhsa)" {9}, image
+// CHECK-PHASES: 11: clang-offload-wrapper, {10}, ir, (host-openmp)
+// CHECK-PHASES: 12: backend, {11}, assembler, (host-openmp)
+// CHECK-PHASES: 13: assembler, {12}, object, (host-openmp)
+// CHECK-PHASES: 14: linker, {4, 13}, image, (host-openmp)
+
Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
===
--- /dev/null
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
@@ -0,0 +1,123 @@
+//===- AMDGPUOpenMP.h - AMDGPUOpenMP ToolChain Implementation -*- C++ -*---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_AMDGPUOPENMP_H
+#define LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_AMDGPUOPENMP_H
+
+#include "AMDGPU.h"
+#include "clang/Driver/Tool.h"
+#include "clang/Driver/ToolChain.h"
+
+namespace clang {
+namespace driver {
+
+namespace tools {
+
+namespace AMDGCN {
+// Runs llvm-link/opt/llc/lld, which links multiple LLVM bitcode, together with
+// device library, then compiles it to ISA in a shared object.
+class LLVM_LIBRARY_VISIBILITY OpenMPLinker : public Tool {
+public:
+  OpenMPLinker(const ToolChain &TC)
+  : Tool("AMDGCN::OpenMPLinker", "amdgcn-link", TC) {}
+
+  bool hasIntegratedCPP() const override { return false; }
+
+  void ConstructJob(Compilation &C, const JobAction &JA,
+const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::opt::ArgList &TCArgs,
+

[PATCH] D81678: Introduce noundef attribute at call sites for stricter poison analysis

2021-01-20 Thread Evgenii Stepanov via Phabricator via cfe-commits
eugenis added a comment.

In D81678#2503931 , @nikic wrote:

> As the discussion is spread out across multiple threads, do I understand 
> correctly that the current consensus is to introduce the 
> `-disable-noundef-analysis` flag, and explicitly add it to all the relevant 
> tests (rather than adding it to the substitutions)?

Yes, I think so.

> In any case, I'd recommend changing this patch to default 
> `-disable-noundef-analysis` to true (so you need to compile with 
> `-disable-noundef-analysis=0` to get undef attributes). The flag can then be 
> flipped together with the test changes. That should help get the main 
> technical change landed directly, and avoid the need of landing patches at 
> the same time.

This is a great idea! Aside from splitting the complexity of landing the large 
change, it also makes our downstream cleanup easier.

In that case we should probably give the flag a positive name: 
-enable-noundef-analysis=(0|1).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81678

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


[PATCH] D95016: [Clang][RISCV] Add custom TableGen backend for riscv-vector intrinsics.

2021-01-20 Thread Zakk Chen via Phabricator via cfe-commits
khchen created this revision.
khchen added reviewers: craig.topper, rogfer01, frasercrmck, HsiangKai, 
evandro, liaolucy, arcbbb, monkchiang.
Herald added subscribers: dexonsmith, NickHung, luismarques, apazos, 
sameer.abuasal, pzheng, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, 
brucehoult, MartinMosbeck, edward-jones, zzheng, jrtc27, shiva0217, kito-cheng, 
niosHD, sabuasal, simoncook, johnrusso, rbar, asb, kristof.beyls, mgorny.
khchen requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, MaskRay.
Herald added projects: clang, LLVM.

Demonstrate how to generate vadd/vfadd intrinsic functions
(explicitly api) and tests.

1. add -gen-riscv-vector-builtins for clang builtins.
2. add -gen-riscv-vector-builtin-codegen for clang codegen.
3. add -gen-riscv-vector-header for riscv_vector.h. It also generates

ifdef directives with extension checking, base on D94403 
.

4. add -gen-riscv-vector-generic-header for riscv_vector_generic.h.

Generate overloading version Header for generic api.
https://github.com/riscv/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md#c11-generic-interface

5. add -gen-riscv-vector-test and -gen-riscv-vector-generic-test for clang

tests. I think using the same td file to generate tests can avoid duplicate 
works
but there is no test generator are writen in tablengen backend now. (ArmNeonTest
was deprecated). In order to generate separated test files, I need modify
clang_generate_header function of CMake to support passing more arguments.

6. add gen-riscv-v-tests.sh which generates all clang tests and use

'update_cc_test_checks.py' to update expected result.

7. update tblgen doc for riscv related options.

riscv_vector.td also defines some unused type transformers for vadd,
because I think it could demonstrate how tranfer type work and we need them
for whole intrinsic functions implementation in the future.

Authored-by: Roger Ferrer Ibanez 
Co-Authored-by: Zakk Cehn 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95016

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/riscv_vector.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/test/CodeGen/RISCV/riscv-rvv-intrinsics-generic/vadd.c
  clang/test/CodeGen/RISCV/riscv-rvv-intrinsics-generic/vfadd.c
  clang/test/CodeGen/RISCV/riscv-rvv-intrinsics/vadd.c
  clang/test/CodeGen/RISCV/riscv-rvv-intrinsics/vfadd.c
  clang/test/CodeGen/RISCV/vadd.c
  clang/test/Headers/riscv-vector-header.c
  clang/utils/TableGen/CMakeLists.txt
  clang/utils/TableGen/RISCVVEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h
  clang/utils/TestUtils/gen-riscv-v-tests.sh
  llvm/docs/CommandGuide/tblgen.rst

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


[PATCH] D95016: [Clang][RISCV] Add custom TableGen backend for riscv-vector intrinsics.

2021-01-20 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

This is a very incomplete review, but I need to go eat dinner




Comment at: clang/include/clang/Basic/riscv_vector.td:201
+// gen-riscv-vector-test.
+// gen-riscv-v-tests.sh will define each marco to generate each intrinsic test
+// in different files. It mean adding the new definition also need to update

marco->macro



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:124
+
+// TODO rafactor Intrinsic class design after support all intrinsic 
combination.
+class Intrinsic {

rafactor->refactor



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:1000
+  SmallVector ProtoSeq;
+  const StringRef Pirmaries("evwqom0ztc");
+  size_t start = 0;

Is this supposed to be Primaries or some other word?



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:1055
+  RVVTypes Types;
+  for (std::string Proto : PrototypeSeq) {
+auto T = computeType(BT, LMUL, Proto);

Can Proto be a const std::string & ?



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:1057
+auto T = computeType(BT, LMUL, Proto);
+if (!T.hasValue()) {
+  return llvm::None;

Drop curly braces



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:1068
+ StringRef Proto) {
+  TypeString Idx = Twine(BT + utostr(LMUL) + Proto).str();
+  // search first

Use Twine(LMUL)  instead of utostr. That should avoid creating std::string



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:1112
+}
+if (ExtStrings.size())
+  OS << "#endif\n\n";

!ExtStrings.empty()



Comment at: clang/utils/TestUtils/gen-riscv-v-tests.sh:21
+gen_tests(){
+# op_list have marco name used in riscv_vector.td
+  local op_list="VADD VFADD"

marco->macro



Comment at: clang/utils/TestUtils/gen-riscv-v-tests.sh:22
+# op_list have marco name used in riscv_vector.td
+  local op_list="VADD VFADD"
+  local option="$1"

It feels a little weird that this list is in the script and not derived from 
the td file automatically somehow. Ideally we wouldn't have to update the 
script every time a new set of intrinsics is added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95016

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


[PATCH] D95016: [Clang][RISCV] Add custom TableGen backend for riscv-vector intrinsics.

2021-01-20 Thread Jessica Clarke via Phabricator via cfe-commits
jrtc27 added inline comments.



Comment at: clang/include/clang/Basic/riscv_vector.td:9
+//
+// This file defines builtins for RISCV-V V-extension. See:
+//

"the"



Comment at: clang/include/clang/Basic/riscv_vector.td:23
+// The elements of this collection are defined by an instantiation process the
+// range of which is specified by cross product of the LMUL attribute and every
+// element in the attribute TypeRange. By default builtins have LMUL = [1, 2,

Missing "the"



Comment at: clang/include/clang/Basic/riscv_vector.td:25
+// element in the attribute TypeRange. By default builtins have LMUL = [1, 2,
+// 4, 8, -2, -4, -8] so the process is repeated 7 times. A negative LMUL -x
+// in that list is used to represent the fractional LMUL 1/x.

Why not just make it an exponent instead? Then that falls out naturally rather 
than having this weird split interpretation.



Comment at: clang/include/clang/Basic/riscv_vector.td:42
+//   i: int (32-bit)
+//   l: long (64-bit)
+//   h: half (16-bit)

If this is a C long, that's not true for RV32. If it's not a C long, call all 
these something else.

Though either way it'd be better to use the architectural names or LLVM-ish 
names for these things rather than something approximating the C language-level 
names.



Comment at: clang/include/clang/Basic/riscv_vector.td:47
+//
+// This way, given an LMUL, a record with a TypeRange "sil" will cause the
+// definition of 3 builtins. Each type "t" in the TypeRange (in this example

Strings that are really lists is a bit gross. I'd use TableGen sequences of 
LLVM types.



Comment at: clang/include/clang/Basic/riscv_vector.td:56
+//
+//   e: type of "t" as is (identity)
+//   v: computes a vector type whose element type is "t" for the current LMUL

Do we really need to invent an esoteric DSL?



Comment at: clang/include/clang/Basic/riscv_vector.td:66
+//  element type which is bool
+//   0: void type, ignores "t"
+//   z: size_t, ignores "t"

Then why aren't these just base types? We don't have to follow the brain-dead 
nature of printf.



Comment at: clang/include/clang/Basic/riscv_vector.td:116
+class RVVBuiltin
+{

Curly braces almost always go on the same line in .td files.



Comment at: clang/include/clang/Basic/riscv_vector.td:118
+{
+  // Base name that will be prepended __builtin_rvv_ and appended the computed
+  // Suffix.

Grammar



Comment at: clang/include/clang/Basic/riscv_vector.td:123
+  // If not empty, each instantiated builtin will have this appended after an
+  // underscore (_). Suffix is instantiated like Prototype.
+  string Suffix = suffix;

Don't need to repeat the field name.



Comment at: clang/include/clang/Basic/riscv_vector.td:130
+
+  // For each type described in TypeRange we instantiate this Prototype.
+  string Prototype = prototype;

Could do with a better explanation (you don't instantiate the prototype, you 
use the prototype to instantiate a specific element of the set of builtins 
being defined).



Comment at: clang/include/clang/Basic/riscv_vector.td:139
+
+  // If HasMask == 1, this flag states that this builtin has a first merge
+  // operand.

What's a "first merge" operand? Is the first important? Because the field 
itself is called HasMergeOperand, no mention of first. If merge operands are 
always first then rephrase the comment to not make it sound like coming first 
is special.



Comment at: clang/include/clang/Basic/riscv_vector.td:146
+
+  // This builtin supprot function overloading and has a mangled name
+  bit HasGeneric = 1;

support



Comment at: clang/include/clang/Basic/riscv_vector.td:149
+
+  // Reads or writes "memory".
+  bit HasSideEffects = 0;

If it's solely memory then call the field something to do with that. If there 
can be other side effects then don't make the comment so specific.



Comment at: clang/include/clang/Basic/riscv_vector.td:152
+
+  // This builtin is valid for the given LMUL.
+  list LMUL = [1, 2, 4, 8, -2, -4, -8];

Plural



Comment at: clang/include/clang/Basic/riscv_vector.td:155-161
+  // emit the automatic clang codegen. It describes
+  // what types we have to use to obtain the specific LLVM intrinsic.
+  //
+  // -1 means the return type,
+  // otherwise, k >= 0 meaning the k-th operand (counting from zero) of the
+  // codegen'd parameter of the unmasked version. k can't be the mask operand's
+  // position.

This needs proper formatting and capitalisation.



Comment at: clang/include/clang/Ba

[PATCH] D95016: [Clang][RISCV] Add custom TableGen backend for riscv-vector intrinsics.

2021-01-20 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:70
+  // passing to the BUILTIN() macro in Builtins.def.
+  std::string builtin_str() const { return BuiltinStr; }
+

Return a const std::string & or a StringRef.



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:85
+  bool isScalar() const {
+return (Vscale.hasValue() && Vscale.getValue() == 0);
+  }

Drop parentheses



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:154
+  // Return the architecture preprocessor definitions.
+  static SmallVector getExtStrings(uint8_t Extensions);
+

Does this need to be in Intrinsic? Can it just be in the emitter class?



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:984
+  StringRef MangledSuffix = R->getValueAsString("MangledSuffix");
+  std::string Prototypes = R->getValueAsString("Prototype").data();
+  StringRef TypeRange = R->getValueAsString("TypeRange");

Use str() not data().

But I'm not sure why it can't just a be StringRef?



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:997
+
+  // Parse prototype and create a list of primitve type with transformers
+  // (operand) in ProtoSeq. ProtoSeq[0] is output operand.

primitive*



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:1070
+  // search first
+  if (LegalTypes.count(Idx)) {
+return Optional(LegalTypes[Idx]);

Use LegalTypes.find() so you don't have to two look ups.



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:1076
+  // compute type and record the result
+  auto T = std::make_shared(BT, LMUL, Proto);
+  if (T->isValid()) {

Does this need to be shared_ptr? Can we just arrange for LegalTypes to own the 
types and give every one else a pointer? LegalTypes would just need to outlive 
the references to the types.



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:1102
+if (ExtStrings.size()) {
+  std::string ArchMacro = std::accumulate(
+  ExtStrings.begin() + 1, ExtStrings.end(), "(" + ExtStrings[0] + ")",

Can we just stream this out to OS instead of accumulating a string before 
streaming?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95016

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


[PATCH] D95016: [Clang][RISCV] Add custom TableGen backend for riscv-vector intrinsics.

2021-01-20 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:687
+  [this](const std::vector &IntrinsicTypes) {
+std::string S = "  ID = Intrinsic::riscv_" + getIRName() + ";\n";
+

Might be better to use raw_string_ostream here so you can use stream operators 
and not keep creating temporary std::strings and then appending them.



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:707
+return getIntrinsicTypesString(getIntrinsicTypes());
+  } else {
+// IntrinsicTypes is ummasked version index

Drop else since previous if returned.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95016

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


[PATCH] D94390: [clangd] Extend find-refs to include overrides.

2021-01-20 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 317832.
hokein marked an inline comment as done.
hokein added a comment.

address review comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94390

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
@@ -1845,6 +1845,31 @@
   }
 }
 
+TEST(FindReferences, IncludeOverrides) {
+  llvm::StringRef Test =
+  R"cpp(
+class Base {
+public:
+  virtual void [[f^unc]]() = 0;
+};
+class Derived : public Base {
+public:
+  void [[func]]() override;
+};
+void test(Derived* D) {
+  D->[[func]]();
+})cpp";
+  Annotations T(Test);
+  auto TU = TestTU::withCode(T.code());
+  auto AST = TU.build();
+  std::vector> ExpectedLocations;
+  for (const auto &R : T.ranges())
+ExpectedLocations.push_back(RangeIs(R));
+  EXPECT_THAT(findReferences(AST, T.point(), 0, TU.index().get()).References,
+  ElementsAreArray(ExpectedLocations))
+  << Test;
+}
+
 TEST(FindReferences, MainFileReferencesOnly) {
   llvm::StringRef Test =
   R"cpp(
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -879,11 +879,8 @@
   };
 
   ReferenceFinder(const ParsedAST &AST,
-  const std::vector &TargetDecls)
-  : AST(AST) {
-for (const NamedDecl *D : TargetDecls)
-  CanonicalTargets.insert(D->getCanonicalDecl());
-  }
+  const llvm::DenseSet &TargetIDs)
+  : AST(AST), TargetIDs(TargetIDs) {}
 
   std::vector take() && {
 llvm::sort(References, [](const Reference &L, const Reference &R) {
@@ -908,9 +905,9 @@
llvm::ArrayRef Relations,
SourceLocation Loc,
index::IndexDataConsumer::ASTNodeInfo ASTNode) override {
-assert(D->isCanonicalDecl() && "expect D to be a canonical declaration");
 const SourceManager &SM = AST.getSourceManager();
-if (!CanonicalTargets.count(D) || !isInsideMainFile(Loc, SM))
+if (!isInsideMainFile(Loc, SM) ||
+TargetIDs.find(getSymbolID(D)) == TargetIDs.end())
   return true;
 const auto &TB = AST.getTokens();
 Loc = SM.getFileLoc(Loc);
@@ -920,14 +917,14 @@
   }
 
 private:
-  llvm::SmallSet CanonicalTargets;
   std::vector References;
   const ParsedAST &AST;
+  const llvm::DenseSet &TargetIDs;
 };
 
 std::vector
-findRefs(const std::vector &Decls, ParsedAST &AST) {
-  ReferenceFinder RefFinder(AST, Decls);
+findRefs(const llvm::DenseSet &IDs, ParsedAST &AST) {
+  ReferenceFinder RefFinder(AST, IDs);
   index::IndexingOptions IndexOpts;
   IndexOpts.SystemSymbolFilter =
   index::IndexingOptions::SystemSymbolFilterKind::All;
@@ -1217,7 +1214,11 @@
   if (!Decls.empty()) {
 // FIXME: we may get multiple DocumentHighlights with the same location
 // and different kinds, deduplicate them.
-for (const auto &Ref : findRefs({Decls.begin(), Decls.end()}, AST))
+llvm::DenseSet Targets;
+for (const NamedDecl *ND : Decls)
+  if (auto ID = getSymbolID(ND))
+Targets.insert(ID);
+for (const auto &Ref : findRefs(Targets, AST))
   Result.push_back(toHighlight(Ref, SM));
 return true;
   }
@@ -1295,13 +1296,14 @@
 llvm::consumeError(CurLoc.takeError());
 return {};
   }
-  llvm::Optional Macro;
-  if (const auto *IdentifierAtCursor =
-  syntax::spelledIdentifierTouching(*CurLoc, AST.getTokens())) {
-Macro = locateMacroAt(*IdentifierAtCursor, AST.getPreprocessor());
-  }
 
   RefsRequest Req;
+
+  const auto *IdentifierAtCursor =
+  syntax::spelledIdentifierTouching(*CurLoc, AST.getTokens());
+  llvm::Optional Macro;
+  if (IdentifierAtCursor)
+Macro = locateMacroAt(*IdentifierAtCursor, AST.getPreprocessor());
   if (Macro) {
 // Handle references to macro.
 if (auto MacroSID = getSymbolID(Macro->Name, Macro->Info, SM)) {
@@ -1325,9 +1327,35 @@
 DeclRelation::TemplatePattern | DeclRelation::Alias;
 std::vector Decls =
 getDeclAtPosition(AST, *CurLoc, Relations);
+llvm::DenseSet Targets;
+for (const NamedDecl *D : Decls)
+  if (auto ID = getSymbolID(D))
+Targets.insert(ID);
+
+llvm::DenseSet Overrides;
+if (Index) {
+  RelationsRequest FindOverrides;
+  FindOverrides.Predicate = RelationKind::OverriddenBy;
+  for (const NamedDecl *ND : Decls) {
+// Special case: virtual void meth^od() = 0 includes refs of overrides.
+if (const auto *CMD = llvm::

[PATCH] D94390: [clangd] Extend find-refs to include overrides.

2021-01-20 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

In D94390#2491046 , @njames93 wrote:

> Should we be providing virtual method overrides when finding references, 
> surely that's what query implementations is for?

yeah, go-to-implementation is designed for this purpose. However, not every 
LSP-client would expose a UI for go-to-implementation, we want to surface these 
results for these clients as well via other common features like go-to-def, 
find-references, hover etc.




Comment at: clang-tools-extra/clangd/unittests/XRefsTests.cpp:1834
 
+TEST(FindReferences, IncludeOverrides) {
+  llvm::StringRef Test =

usaxena95 wrote:
> nit: May be include tests for CRTP too.
I think CRTP is about class inheritance, while in this patch we just handle 
virtual methods which seems not related to CRTP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94390

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


[PATCH] D94390: [clangd] Extend find-refs to include overrides.

2021-01-20 Thread Haojian Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG42830f8bdc8f: [clangd] Extend find-refs to include 
overrides. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94390

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
@@ -1845,6 +1845,31 @@
   }
 }
 
+TEST(FindReferences, IncludeOverrides) {
+  llvm::StringRef Test =
+  R"cpp(
+class Base {
+public:
+  virtual void [[f^unc]]() = 0;
+};
+class Derived : public Base {
+public:
+  void [[func]]() override;
+};
+void test(Derived* D) {
+  D->[[func]]();
+})cpp";
+  Annotations T(Test);
+  auto TU = TestTU::withCode(T.code());
+  auto AST = TU.build();
+  std::vector> ExpectedLocations;
+  for (const auto &R : T.ranges())
+ExpectedLocations.push_back(RangeIs(R));
+  EXPECT_THAT(findReferences(AST, T.point(), 0, TU.index().get()).References,
+  ElementsAreArray(ExpectedLocations))
+  << Test;
+}
+
 TEST(FindReferences, MainFileReferencesOnly) {
   llvm::StringRef Test =
   R"cpp(
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -879,11 +879,8 @@
   };
 
   ReferenceFinder(const ParsedAST &AST,
-  const std::vector &TargetDecls)
-  : AST(AST) {
-for (const NamedDecl *D : TargetDecls)
-  CanonicalTargets.insert(D->getCanonicalDecl());
-  }
+  const llvm::DenseSet &TargetIDs)
+  : AST(AST), TargetIDs(TargetIDs) {}
 
   std::vector take() && {
 llvm::sort(References, [](const Reference &L, const Reference &R) {
@@ -908,9 +905,9 @@
llvm::ArrayRef Relations,
SourceLocation Loc,
index::IndexDataConsumer::ASTNodeInfo ASTNode) override {
-assert(D->isCanonicalDecl() && "expect D to be a canonical declaration");
 const SourceManager &SM = AST.getSourceManager();
-if (!CanonicalTargets.count(D) || !isInsideMainFile(Loc, SM))
+if (!isInsideMainFile(Loc, SM) ||
+TargetIDs.find(getSymbolID(D)) == TargetIDs.end())
   return true;
 const auto &TB = AST.getTokens();
 Loc = SM.getFileLoc(Loc);
@@ -920,14 +917,14 @@
   }
 
 private:
-  llvm::SmallSet CanonicalTargets;
   std::vector References;
   const ParsedAST &AST;
+  const llvm::DenseSet &TargetIDs;
 };
 
 std::vector
-findRefs(const std::vector &Decls, ParsedAST &AST) {
-  ReferenceFinder RefFinder(AST, Decls);
+findRefs(const llvm::DenseSet &IDs, ParsedAST &AST) {
+  ReferenceFinder RefFinder(AST, IDs);
   index::IndexingOptions IndexOpts;
   IndexOpts.SystemSymbolFilter =
   index::IndexingOptions::SystemSymbolFilterKind::All;
@@ -1217,7 +1214,11 @@
   if (!Decls.empty()) {
 // FIXME: we may get multiple DocumentHighlights with the same location
 // and different kinds, deduplicate them.
-for (const auto &Ref : findRefs({Decls.begin(), Decls.end()}, AST))
+llvm::DenseSet Targets;
+for (const NamedDecl *ND : Decls)
+  if (auto ID = getSymbolID(ND))
+Targets.insert(ID);
+for (const auto &Ref : findRefs(Targets, AST))
   Result.push_back(toHighlight(Ref, SM));
 return true;
   }
@@ -1295,13 +1296,14 @@
 llvm::consumeError(CurLoc.takeError());
 return {};
   }
-  llvm::Optional Macro;
-  if (const auto *IdentifierAtCursor =
-  syntax::spelledIdentifierTouching(*CurLoc, AST.getTokens())) {
-Macro = locateMacroAt(*IdentifierAtCursor, AST.getPreprocessor());
-  }
 
   RefsRequest Req;
+
+  const auto *IdentifierAtCursor =
+  syntax::spelledIdentifierTouching(*CurLoc, AST.getTokens());
+  llvm::Optional Macro;
+  if (IdentifierAtCursor)
+Macro = locateMacroAt(*IdentifierAtCursor, AST.getPreprocessor());
   if (Macro) {
 // Handle references to macro.
 if (auto MacroSID = getSymbolID(Macro->Name, Macro->Info, SM)) {
@@ -1325,9 +1327,35 @@
 DeclRelation::TemplatePattern | DeclRelation::Alias;
 std::vector Decls =
 getDeclAtPosition(AST, *CurLoc, Relations);
+llvm::DenseSet Targets;
+for (const NamedDecl *D : Decls)
+  if (auto ID = getSymbolID(D))
+Targets.insert(ID);
+
+llvm::DenseSet Overrides;
+if (Index) {
+  RelationsRequest FindOverrides;
+  FindOverrides.Predicate = RelationKind::OverriddenBy;
+  for (const NamedDecl *ND : Decls) {
+// Special 

[clang-tools-extra] 42830f8 - [clangd] Extend find-refs to include overrides.

2021-01-20 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2021-01-20T13:23:20+01:00
New Revision: 42830f8bdc8f064fee648541f79f8e8d66072cce

URL: 
https://github.com/llvm/llvm-project/commit/42830f8bdc8f064fee648541f79f8e8d66072cce
DIFF: 
https://github.com/llvm/llvm-project/commit/42830f8bdc8f064fee648541f79f8e8d66072cce.diff

LOG: [clangd] Extend find-refs to include overrides.

find-references on `virtual void meth^od() = 0` will include override 
references.

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

Added: 


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

Removed: 




diff  --git a/clang-tools-extra/clangd/XRefs.cpp 
b/clang-tools-extra/clangd/XRefs.cpp
index 8027e0564126..d4dc6212553f 100644
--- a/clang-tools-extra/clangd/XRefs.cpp
+++ b/clang-tools-extra/clangd/XRefs.cpp
@@ -879,11 +879,8 @@ class ReferenceFinder : public index::IndexDataConsumer {
   };
 
   ReferenceFinder(const ParsedAST &AST,
-  const std::vector &TargetDecls)
-  : AST(AST) {
-for (const NamedDecl *D : TargetDecls)
-  CanonicalTargets.insert(D->getCanonicalDecl());
-  }
+  const llvm::DenseSet &TargetIDs)
+  : AST(AST), TargetIDs(TargetIDs) {}
 
   std::vector take() && {
 llvm::sort(References, [](const Reference &L, const Reference &R) {
@@ -908,9 +905,9 @@ class ReferenceFinder : public index::IndexDataConsumer {
llvm::ArrayRef Relations,
SourceLocation Loc,
index::IndexDataConsumer::ASTNodeInfo ASTNode) override 
{
-assert(D->isCanonicalDecl() && "expect D to be a canonical declaration");
 const SourceManager &SM = AST.getSourceManager();
-if (!CanonicalTargets.count(D) || !isInsideMainFile(Loc, SM))
+if (!isInsideMainFile(Loc, SM) ||
+TargetIDs.find(getSymbolID(D)) == TargetIDs.end())
   return true;
 const auto &TB = AST.getTokens();
 Loc = SM.getFileLoc(Loc);
@@ -920,14 +917,14 @@ class ReferenceFinder : public index::IndexDataConsumer {
   }
 
 private:
-  llvm::SmallSet CanonicalTargets;
   std::vector References;
   const ParsedAST &AST;
+  const llvm::DenseSet &TargetIDs;
 };
 
 std::vector
-findRefs(const std::vector &Decls, ParsedAST &AST) {
-  ReferenceFinder RefFinder(AST, Decls);
+findRefs(const llvm::DenseSet &IDs, ParsedAST &AST) {
+  ReferenceFinder RefFinder(AST, IDs);
   index::IndexingOptions IndexOpts;
   IndexOpts.SystemSymbolFilter =
   index::IndexingOptions::SystemSymbolFilterKind::All;
@@ -1217,7 +1214,11 @@ std::vector 
findDocumentHighlights(ParsedAST &AST,
   if (!Decls.empty()) {
 // FIXME: we may get multiple DocumentHighlights with the same location
 // and 
diff erent kinds, deduplicate them.
-for (const auto &Ref : findRefs({Decls.begin(), Decls.end()}, AST))
+llvm::DenseSet Targets;
+for (const NamedDecl *ND : Decls)
+  if (auto ID = getSymbolID(ND))
+Targets.insert(ID);
+for (const auto &Ref : findRefs(Targets, AST))
   Result.push_back(toHighlight(Ref, SM));
 return true;
   }
@@ -1295,13 +1296,14 @@ ReferencesResult findReferences(ParsedAST &AST, 
Position Pos, uint32_t Limit,
 llvm::consumeError(CurLoc.takeError());
 return {};
   }
-  llvm::Optional Macro;
-  if (const auto *IdentifierAtCursor =
-  syntax::spelledIdentifierTouching(*CurLoc, AST.getTokens())) {
-Macro = locateMacroAt(*IdentifierAtCursor, AST.getPreprocessor());
-  }
 
   RefsRequest Req;
+
+  const auto *IdentifierAtCursor =
+  syntax::spelledIdentifierTouching(*CurLoc, AST.getTokens());
+  llvm::Optional Macro;
+  if (IdentifierAtCursor)
+Macro = locateMacroAt(*IdentifierAtCursor, AST.getPreprocessor());
   if (Macro) {
 // Handle references to macro.
 if (auto MacroSID = getSymbolID(Macro->Name, Macro->Info, SM)) {
@@ -1325,9 +1327,35 @@ ReferencesResult findReferences(ParsedAST &AST, Position 
Pos, uint32_t Limit,
 DeclRelation::TemplatePattern | DeclRelation::Alias;
 std::vector Decls =
 getDeclAtPosition(AST, *CurLoc, Relations);
+llvm::DenseSet Targets;
+for (const NamedDecl *D : Decls)
+  if (auto ID = getSymbolID(D))
+Targets.insert(ID);
+
+llvm::DenseSet Overrides;
+if (Index) {
+  RelationsRequest FindOverrides;
+  FindOverrides.Predicate = RelationKind::OverriddenBy;
+  for (const NamedDecl *ND : Decls) {
+// Special case: virtual void meth^od() = 0 includes refs of overrides.
+if (const auto *CMD = llvm::dyn_cast(ND)) {
+  if (CMD->isPure())
+if (IdentifierAtCursor && SM.getSpellingLoc(CMD->getLocation()) ==
+  IdentifierAtCursor->location())
+  if (auto ID = getSymbolID(CMD))
+FindOverrides.Subjects.insert(ID);
+}
+  }
+

[PATCH] D94622: [clang-tidy] add concurrency-async-no-new-threads

2021-01-20 Thread Vasily Kulikov via Phabricator via cfe-commits
segoon added a comment.

Eugene.Zelenko, njames93, any comments on the patch?


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

https://reviews.llvm.org/D94622

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


[PATCH] D94621: [clang-tidy] add concurrency-async-fs

2021-01-20 Thread Vasily Kulikov via Phabricator via cfe-commits
segoon added a comment.

Eugene.Zelenko, njames93, any comments on the patch?


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

https://reviews.llvm.org/D94621

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


[PATCH] D93940: [clang-tidy] Add a check for blocking types and functions.

2021-01-20 Thread Vasily Kulikov via Phabricator via cfe-commits
segoon added a comment.

Eugene.Zelenko, njames93, any comments on the patch?


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

https://reviews.llvm.org/D93940

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


[PATCH] D95031: [clangd] Log warning when using legacy (theia) semantic highlighting.

2021-01-20 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet accepted this revision.
kadircet added a subscriber: nridge.
kadircet added a comment.
This revision is now accepted and ready to land.

LGTM, a friendly ping to @nridge though, as he was working on theia related 
stuff (at least in the past, not sure if you still do :D), to give him a 
heads-up if this is going to require some changes on their end.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95031

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


[PATCH] D93464: [analyzer] Refine suppression mechanism to better support AST checks

2021-01-20 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko abandoned this revision.
vsavchenko added a comment.

This change was squashed into https://reviews.llvm.org/D93110


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93464

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


[PATCH] D94177: [analyze] Add better support for leaks (and similar diagnostics)

2021-01-20 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko abandoned this revision.
vsavchenko added a comment.

This change was squashed into https://reviews.llvm.org/D93110


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94177

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


[PATCH] D93585: [AArch64][Clang][Linux] Enable out-of-line atomics by default.

2021-01-20 Thread Pavel Iliin via Phabricator via cfe-commits
ilinpv updated this revision to Diff 317849.
ilinpv retitled this revision from "[AArch64] Enable out-of-line atomics by 
default." to "[AArch64][Clang][Linux] Enable out-of-line atomics by default.".
ilinpv edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93585

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/lib/Driver/ToolChains/Linux.h


Index: clang/lib/Driver/ToolChains/Linux.h
===
--- clang/lib/Driver/ToolChains/Linux.h
+++ clang/lib/Driver/ToolChains/Linux.h
@@ -36,6 +36,8 @@
   void AddIAMCUIncludeArgs(const llvm::opt::ArgList &DriverArgs,
llvm::opt::ArgStringList &CC1Args) const override;
   CXXStdlibType GetDefaultCXXStdlibType() const override;
+  bool
+  IsAArch64OutlineAtomicsDefault(const llvm::opt::ArgList &Args) const 
override;
   bool isPIEDefault() const override;
   bool isNoExecStackDefault() const override;
   bool IsMathErrnoDefault() const override;
Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -836,6 +836,21 @@
   getTriple().isMusl() || getSanitizerArgs().requiresPIE();
 }
 
+bool Linux::IsAArch64OutlineAtomicsDefault(const ArgList &Args) const {
+  if (!getTriple().isAArch64())
+return false;
+  // Outline atomics for AArch64 are supported by compiler-rt
+  // and libgcc since 9.3.1
+  if (GetRuntimeLibType(Args) == ToolChain::RLT_Libgcc) {
+const GCCVersion &Ver = GCCInstallation.getVersion();
+if (Ver.isOlderThan(9, 3, 1))
+  return false;
+  } else if (GetRuntimeLibType(Args) != ToolChain::RLT_CompilerRT) {
+return false;
+  }
+  return true;
+}
+
 bool Linux::isNoExecStackDefault() const {
 return getTriple().isAndroid();
 }
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6441,6 +6441,12 @@
   CmdArgs.push_back("-target-feature");
   CmdArgs.push_back("-outline-atomics");
 }
+  } else {
+if (Triple.isAArch64() &&
+getToolChain().IsAArch64OutlineAtomicsDefault(Args)) {
+  CmdArgs.push_back("-target-feature");
+  CmdArgs.push_back("+outline-atomics");
+}
   }
 
   if (Args.hasFlag(options::OPT_faddrsig, options::OPT_fno_addrsig,
Index: clang/include/clang/Driver/ToolChain.h
===
--- clang/include/clang/Driver/ToolChain.h
+++ clang/include/clang/Driver/ToolChain.h
@@ -456,6 +456,12 @@
   /// by default.
   virtual bool IsUnwindTablesDefault(const llvm::opt::ArgList &Args) const;
 
+  /// Test whether this toolchain supports outline atomics by default.
+  virtual bool
+  IsAArch64OutlineAtomicsDefault(const llvm::opt::ArgList &Args) const {
+return false;
+  }
+
   /// Test whether this toolchain defaults to PIC.
   virtual bool isPICDefault() const = 0;
 


Index: clang/lib/Driver/ToolChains/Linux.h
===
--- clang/lib/Driver/ToolChains/Linux.h
+++ clang/lib/Driver/ToolChains/Linux.h
@@ -36,6 +36,8 @@
   void AddIAMCUIncludeArgs(const llvm::opt::ArgList &DriverArgs,
llvm::opt::ArgStringList &CC1Args) const override;
   CXXStdlibType GetDefaultCXXStdlibType() const override;
+  bool
+  IsAArch64OutlineAtomicsDefault(const llvm::opt::ArgList &Args) const override;
   bool isPIEDefault() const override;
   bool isNoExecStackDefault() const override;
   bool IsMathErrnoDefault() const override;
Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -836,6 +836,21 @@
   getTriple().isMusl() || getSanitizerArgs().requiresPIE();
 }
 
+bool Linux::IsAArch64OutlineAtomicsDefault(const ArgList &Args) const {
+  if (!getTriple().isAArch64())
+return false;
+  // Outline atomics for AArch64 are supported by compiler-rt
+  // and libgcc since 9.3.1
+  if (GetRuntimeLibType(Args) == ToolChain::RLT_Libgcc) {
+const GCCVersion &Ver = GCCInstallation.getVersion();
+if (Ver.isOlderThan(9, 3, 1))
+  return false;
+  } else if (GetRuntimeLibType(Args) != ToolChain::RLT_CompilerRT) {
+return false;
+  }
+  return true;
+}
+
 bool Linux::isNoExecStackDefault() const {
 return getTriple().isAndroid();
 }
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6441,6 +6

[PATCH] D95038: [OpenCL][Docs] Describe tablegen BIFs declaration

2021-01-20 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia created this revision.
Anastasia added a reviewer: svenvh.
Herald added subscribers: ebevhan, yaxunl.
Anastasia requested review of this revision.

Added documentation for the fast builtin function declaration with 
`-fdeclare-opencl-builtins`.


https://reviews.llvm.org/D95038

Files:
  clang/docs/OpenCLSupport.rst
  clang/docs/UsersManual.rst


Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -3021,6 +3021,11 @@
 
  $ clang -target spir-unknown-unknown -c -emit-llvm -Xclang 
-finclude-default-header -fmodules -fimplicit-module-maps 
-fmodules-cache-path= test.cl
 
+Another way to circumvent long parsing latency for the OpenCL builtin
+declarations is to use mechanism enabled by ``-fdeclare-opencl-builtins`` flag
+that is available as an experimental feature (see more information in
+:doc:`OpenCLSupport`).
+
 OpenCL Extensions
 -
 
Index: clang/docs/OpenCLSupport.rst
===
--- clang/docs/OpenCLSupport.rst
+++ clang/docs/OpenCLSupport.rst
@@ -112,6 +112,25 @@
 `_ or via `Bugzilla
 `__.
 
+Fast builtin function declaration
+-
+
+In addition to regular header includes with builtin types/functions using
+``-finclude-default-header`` explained in :doc:`UsersManual` clang
+support fast mechanism to declare builtin functions with
+``-fdeclare-opencl-builtins``. This does not declare the builtin types and
+therefore it has to be used in combination with ``-finclude-default-header``
+if full functionality is required.
+
+**Example of Use**:
+
+.. code-block:: console
+ 
+  $ clang -Xclang -finclude-default-header test.cl
+
+Note that this is a frontend-only flag and therefore it requires the use of
+flags that forward options to the frontend, e.g. ``-cc1`` or ``-Xclang``.
+
 C++ libraries for OpenCL
 
 


Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -3021,6 +3021,11 @@
 
  $ clang -target spir-unknown-unknown -c -emit-llvm -Xclang -finclude-default-header -fmodules -fimplicit-module-maps -fmodules-cache-path= test.cl
 
+Another way to circumvent long parsing latency for the OpenCL builtin
+declarations is to use mechanism enabled by ``-fdeclare-opencl-builtins`` flag
+that is available as an experimental feature (see more information in
+:doc:`OpenCLSupport`).
+
 OpenCL Extensions
 -
 
Index: clang/docs/OpenCLSupport.rst
===
--- clang/docs/OpenCLSupport.rst
+++ clang/docs/OpenCLSupport.rst
@@ -112,6 +112,25 @@
 `_ or via `Bugzilla
 `__.
 
+Fast builtin function declaration
+-
+
+In addition to regular header includes with builtin types/functions using
+``-finclude-default-header`` explained in :doc:`UsersManual` clang
+support fast mechanism to declare builtin functions with
+``-fdeclare-opencl-builtins``. This does not declare the builtin types and
+therefore it has to be used in combination with ``-finclude-default-header``
+if full functionality is required.
+
+**Example of Use**:
+
+.. code-block:: console
+ 
+  $ clang -Xclang -finclude-default-header test.cl
+
+Note that this is a frontend-only flag and therefore it requires the use of
+flags that forward options to the frontend, e.g. ``-cc1`` or ``-Xclang``.
+
 C++ libraries for OpenCL
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D95038: [OpenCL][Docs] Describe tablegen BIFs declaration

2021-01-20 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh added a comment.

Thanks for working on this!




Comment at: clang/docs/OpenCLSupport.rst:118
+
+In addition to regular header includes with builtin types/functions using
+``-finclude-default-header`` explained in :doc:`UsersManual` clang





Comment at: clang/docs/OpenCLSupport.rst:119
+In addition to regular header includes with builtin types/functions using
+``-finclude-default-header`` explained in :doc:`UsersManual` clang
+support fast mechanism to declare builtin functions with





Comment at: clang/docs/OpenCLSupport.rst:120
+``-finclude-default-header`` explained in :doc:`UsersManual` clang
+support fast mechanism to declare builtin functions with
+``-fdeclare-opencl-builtins``. This does not declare the builtin types and





Comment at: clang/docs/OpenCLSupport.rst:132
+Note that this is a frontend-only flag and therefore it requires the use of
+flags that forward options to the frontend, e.g. ``-cc1`` or ``-Xclang``.
+

We should also mention that this is (still) an experimental flag, and that 
behavior of the flag may change in the future.


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

https://reviews.llvm.org/D95038

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


[PATCH] D93095: Introduce -Wreserved-identifier

2021-01-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/Sema.cpp:2421-2428
+// Perform a lookup at TUScope. If it succeeds, we're at global scope and a
+// single '_' is enough to be reserved.
+LookupResult IdentifierLookup(*this, II, SourceLocation(),
+  Sema::LookupAnyName,
+  Sema::ForExternalRedeclaration);
+IdentifierLookup.suppressDiagnostics();
+if (LookupName(IdentifierLookup, TUScope))

rsmith wrote:
> I don't understand why name lookup is involved here. Whether an identifier is 
> reserved doesn't depend on whether it's already been declared in the global 
> namespace or not. It's valid to declare `_foo` in some user-defined namespace 
> regardless of whether there's already a `_foo` in the global namespace, and 
> it's invalid to declare `_foo` in the global namespace regardless of whether 
> there's already a `_foo` in the global namespace.
> 
> If you're trying to detect whether the name is being introduced in the global 
> namespace scope, per C++ [lex.name]/3.2, you can't do that like this; you'll 
> need to look at the `DeclContext` of the declaration instead of just the 
> identifier.
Sorry @serge-sans-paille for my think-o, Richard is right.

My thinking was "if the declaration can be found at the global namespace, then 
it's reserved", but.. that's a hypothetical declaration, not an actual one, so 
of course the name lookup won't find it. Derp.

I guess we really do have to look at the `DeclContext`.

@rsmith -- just to be clear, from http://eel.is/c++draft/lex.name#3.2, does 
"for use as a name in the global namespace" imply macros as well? e.g., can an 
implementation decide to use this reservation to `#define _foo 12`, which would 
cause problems with a `_foo` declared in a user-defined namespace? If so, then 
we can ignore what the declaration context is because the name could be 
snatched out from under the user via a macro anyway.


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

https://reviews.llvm.org/D93095

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


[PATCH] D94554: [clangd][WIP] Add a Filesystem that overlays Dirty files.

2021-01-20 Thread Nathan James via Phabricator via cfe-commits
njames93 updated this revision to Diff 317856.
njames93 added a comment.

Start Splitting this patch up


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94554

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

Index: clang-tools-extra/clangd/unittests/DraftStoreTests.cpp
===
--- clang-tools-extra/clangd/unittests/DraftStoreTests.cpp
+++ clang-tools-extra/clangd/unittests/DraftStoreTests.cpp
@@ -52,8 +52,8 @@
 llvm::Expected Result =
 DS.updateDraft(Path, llvm::None, {Event});
 ASSERT_TRUE(!!Result);
-EXPECT_EQ(Result->Contents, SrcAfter.code());
-EXPECT_EQ(DS.getDraft(Path)->Contents, SrcAfter.code());
+EXPECT_EQ(*Result->Contents, SrcAfter.code());
+EXPECT_EQ(*DS.getDraft(Path)->Contents, SrcAfter.code());
 EXPECT_EQ(Result->Version, static_cast(i));
   }
 }
@@ -84,8 +84,8 @@
   DS.updateDraft(Path, llvm::None, Changes);
 
   ASSERT_TRUE(!!Result) << llvm::toString(Result.takeError());
-  EXPECT_EQ(Result->Contents, FinalSrc.code());
-  EXPECT_EQ(DS.getDraft(Path)->Contents, FinalSrc.code());
+  EXPECT_EQ(*Result->Contents, FinalSrc.code());
+  EXPECT_EQ(*DS.getDraft(Path)->Contents, FinalSrc.code());
   EXPECT_EQ(Result->Version, 1);
 }
 
@@ -345,7 +345,7 @@
 
   Optional Contents = DS.getDraft(File);
   EXPECT_TRUE(Contents);
-  EXPECT_EQ(Contents->Contents, OriginalContents);
+  EXPECT_EQ(*Contents->Contents, OriginalContents);
   EXPECT_EQ(Contents->Version, 0);
 }
 
Index: clang-tools-extra/clangd/DraftStore.h
===
--- clang-tools-extra/clangd/DraftStore.h
+++ clang-tools-extra/clangd/DraftStore.h
@@ -11,6 +11,7 @@
 
 #include "Protocol.h"
 #include "support/Path.h"
+#include "support/ThreadsafeFS.h"
 #include "clang/Basic/LLVM.h"
 #include "llvm/ADT/StringMap.h"
 #include 
@@ -20,6 +21,20 @@
 namespace clang {
 namespace clangd {
 
+/// A Reference counted string that is used to hold the contents of open files.
+class RefCntString : public llvm::ThreadSafeRefCountedBase {
+public:
+  RefCntString(std::string Str) : Data(std::move(Str)) {}
+
+  StringRef str() const { return Data; }
+
+  operator const std::string &() const { return Data; }
+  operator StringRef() const { return str(); }
+
+private:
+  std::string Data;
+};
+
 /// A thread-safe container for files opened in a workspace, addressed by
 /// filenames. The contents are owned by the DraftStore. This class supports
 /// both whole and incremental updates of the documents.
@@ -28,10 +43,14 @@
 class DraftStore {
 public:
   struct Draft {
-std::string Contents;
+llvm::IntrusiveRefCntPtr Contents;
 int64_t Version = -1;
   };
 
+  DraftStore(const ThreadsafeFS &BaseFS);
+
+  DraftStore() = default;
+
   /// \return Contents of the stored document.
   /// For untracked files, a llvm::None is returned.
   llvm::Optional getDraft(PathRef File) const;
@@ -59,9 +78,20 @@
   /// Remove the draft from the store.
   void removeDraft(PathRef File);
 
+  const ThreadsafeFS &getDraftFS() const {
+assert(DraftFS && "No draft fs has been set up");
+return *DraftFS;
+  }
+
 private:
+  struct DraftAndTime {
+Draft Draft;
+llvm::sys::TimePoint<> MTime;
+  };
+  class DraftstoreFS;
+  std::unique_ptr DraftFS;
   mutable std::mutex Mutex;
-  llvm::StringMap Drafts;
+  llvm::StringMap Drafts;
 };
 
 } // namespace clangd
Index: clang-tools-extra/clangd/DraftStore.cpp
===
--- clang-tools-extra/clangd/DraftStore.cpp
+++ clang-tools-extra/clangd/DraftStore.cpp
@@ -9,7 +9,9 @@
 #include "DraftStore.h"
 #include "SourceCode.h"
 #include "support/Logger.h"
+#include "llvm/Support/Chrono.h"
 #include "llvm/Support/Errc.h"
+#include 
 
 namespace clang {
 namespace clangd {
@@ -21,7 +23,7 @@
   if (It == Drafts.end())
 return None;
 
-  return It->second;
+  return It->second.Draft;
 }
 
 std::vector DraftStore::getActiveFiles() const {
@@ -47,14 +49,19 @@
   }
 }
 
+static void updateTime(llvm::sys::TimePoint<> &Time) {
+  Time = llvm::sys::TimePoint<>::clock::now();
+}
+
 int64_t DraftStore::addDraft(PathRef File, llvm::Optional Version,
  llvm::StringRef Contents) {
   std::lock_guard Lock(Mutex);
 
-  Draft &D = Drafts[File];
-  updateVersion(D, Version);
-  D.Contents = Contents.str();
-  return D.Version;
+  DraftAndTime &D = Drafts[File];
+  updateVersion(D.Draft, Version);
+  updateTime(D.MTime);
+  D.Draft.Contents = llvm::makeIntrusiveRefCnt(Contents.str());
+  return D.Draft.Version;
 }
 
 llvm::Expected DraftStore::updateDraft(
@@ -68,8 +75,8 @@
  "T

[PATCH] D94878: Make it possible to store a ASTNodeKind in VariantValue

2021-01-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94878

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


[PATCH] D94879: Implement dynamic mapAnyOf in terms of ASTNodeKinds

2021-01-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!




Comment at: clang/lib/ASTMatchers/Dynamic/Marshallers.h:948
+  return {};
+auto VM = Arg.Value.getMatcher();
+if (VM.hasTypedMatcher(NK)) {

steveire wrote:
> aaron.ballman wrote:
> > Note, this is an example of why use of `auto` is discouraged in the project 
> > when the type is not spelled out explicitly in the initialization -- this 
> > was accidentally creating a non-const copy of the `VariantMatcher`, not 
> > getting a const reference as `getMatcher()` returns. Not the worst problem 
> > in the world, but it takes a lot of review effort to find these issues when 
> > you use `auto`, which is why the guidance is what it is.
> > Note, this is an example of why use of auto is discouraged 
> 
> Nope, this isn't a good example of that. It's actually the opposite. `auto` 
> does no harm here.
> 
> If I had written 
> 
> ```
> VariantMatcher VM = Arg.Value.getMatcher();
> ```
> 
> you would either already-know what the return type of `getMatcher()` is and 
> see the copy, or you would be satisfied that the variable type is not `auto` 
> (dangerously, potentially) and move on, or you would go and check the return 
> type of `getMatcher()` if you had a suspicion.
> 
> If I had written 
> 
> ```
> SomeTypedefName VM = Arg.Value.getMatcher();
> ```
> 
> you wouldn't see an `auto`, which again might be satisfying, but you would 
> have to go and look at the typedef to see if it contains a `const` or a `&` 
> (for example see `ValueParamT` in `SmallVector` which is either `const T&` or 
> `T`, depending on `T`).
> 
> Requiring non-use of `auto` is not a way around knowing or checking the 
> return value of methods, and can actually give you a false sense of security! 
> 
> I don't think you'll ever convince me that your way doesn't make the code 
> worse :).
> Nope, this isn't a good example of that. It's actually the opposite. auto 
> does no harm here.

Here's a simplified example showing what I meant: https://godbolt.org/z/svbx4f. 
Note how the use with just `auto` executes the copy constructor while the other 
two forms do not.

That said, I can see your point about `VariantMatcher VM = 
Arg.Value.getMatcher();` having the same issues when reading the code, so 
you're right that this isn't a particularly good example of why not to use 
`auto`.

> I don't think you'll ever convince me that your way doesn't make the code 
> worse :).

That's fine, I probably shouldn't have even tried to begin with. :-)



Comment at: clang/lib/ASTMatchers/Dynamic/Marshallers.h:988
+  *LeastDerivedKind = CladeNodeKind;
+return true;
   }

steveire wrote:
> aaron.ballman wrote:
> > We used to traverse the list of matcher functions to see if one is 
> > convertible or not and now we're always assuming that the conversion is 
> > fine -- was that previous checking unnecessary or has it been subsumed by 
> > checking somewhere else?
> Yes, the checking was not necessary. Because this matcher is basically a 
> convenient implementation of `stmt(anyOf(ifStmt(innerMatchers), 
> forStmt(innerMatchers)))`, it's the outer `stmt` that it is convertible to.
Ahh, thank you for the explanation, that makes more sense to me now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94879

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


[PATCH] D95043: [clangd] Use Dirty Filesystem for cross file rename.

2021-01-20 Thread Nathan James via Phabricator via cfe-commits
njames93 created this revision.
njames93 added reviewers: sammccall, kadircet.
Herald added subscribers: usaxena95, arphaman, javed.absar.
njames93 requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang.

Refactor cross file rename to use a Filesystem instead of a function for 
getting buffer contents of open files.

Depends on D94554 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95043

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

Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -33,6 +33,19 @@
 using testing::UnorderedElementsAre;
 using testing::UnorderedElementsAreArray;
 
+llvm::IntrusiveRefCntPtr
+createOverlay(llvm::IntrusiveRefCntPtr Base,
+  llvm::IntrusiveRefCntPtr Overlay) {
+  auto OFS =
+  llvm::makeIntrusiveRefCnt(std::move(Base));
+  OFS->pushOverlay(std::move(Overlay));
+  return OFS;
+}
+
+llvm::IntrusiveRefCntPtr getVFSFromAST(ParsedAST &AST) {
+  return &AST.getSourceManager().getFileManager().getVirtualFileSystem();
+}
+
 // Convert a Range to a Ref.
 Ref refWithRange(const clangd::Range &Range, const std::string &URI) {
   Ref Result;
@@ -833,8 +846,8 @@
 TU.ExtraArgs.push_back("-xobjective-c++");
 auto AST = TU.build();
 for (const auto &RenamePos : Code.points()) {
-  auto RenameResult =
-  rename({RenamePos, NewName, AST, testPath(TU.Filename)});
+  auto RenameResult = rename(
+  {RenamePos, NewName, AST, testPath(TU.Filename), getVFSFromAST(AST)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError();
   ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
   EXPECT_EQ(
@@ -1040,8 +1053,8 @@
 }
 auto AST = TU.build();
 llvm::StringRef NewName = Case.NewName;
-auto Results =
-rename({T.point(), NewName, AST, testPath(TU.Filename), Case.Index});
+auto Results = rename({T.point(), NewName, AST, testPath(TU.Filename),
+   getVFSFromAST(AST), Case.Index});
 bool WantRename = true;
 if (T.ranges().empty())
   WantRename = false;
@@ -1081,8 +1094,8 @@
   auto AST = TU.build();
   llvm::StringRef NewName = "abcde";
 
-  auto RenameResult =
-  rename({Code.point(), NewName, AST, testPath(TU.Filename)});
+  auto RenameResult = rename(
+  {Code.point(), NewName, AST, testPath(TU.Filename), getVFSFromAST(AST)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError() << Code.point();
   ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
   EXPECT_EQ(applyEdits(std::move(RenameResult->GlobalChanges)).front().second,
@@ -1098,7 +,8 @@
   )cpp";
   TU.HeaderFilename = "protobuf.pb.h";
   auto AST = TU.build();
-  auto Results = rename({Code.point(), "newName", AST, testPath(TU.Filename)});
+  auto Results = rename({Code.point(), "newName", AST, testPath(TU.Filename),
+ getVFSFromAST(AST)});
   EXPECT_FALSE(Results);
   EXPECT_THAT(llvm::toString(Results.takeError()),
   testing::HasSubstr("not a supported kind"));
@@ -1170,12 +1184,10 @@
 
   Annotations MainCode("class  [[Fo^o]] {};");
   auto MainFilePath = testPath("main.cc");
-  // Dirty buffer for foo.cc.
-  auto GetDirtyBuffer = [&](PathRef Path) -> llvm::Optional {
-if (Path == FooPath)
-  return FooDirtyBuffer.code().str();
-return llvm::None;
-  };
+  llvm::IntrusiveRefCntPtr InMemFS =
+  new llvm::vfs::InMemoryFileSystem;
+  InMemFS->addFile(FooPath, 0,
+   llvm::MemoryBuffer::getMemBuffer(FooDirtyBuffer.code()));
 
   // Run rename on Foo, there is a dirty buffer for foo.cc, rename should
   // respect the dirty buffer.
@@ -1186,9 +1198,9 @@
  NewName,
  AST,
  MainFilePath,
+ createOverlay(getVFSFromAST(AST), InMemFS),
  Index.get(),
- {/*CrossFile=*/true},
- GetDirtyBuffer});
+ {/*CrossFile=*/true}});
   ASSERT_TRUE(bool(Results)) << Results.takeError();
   EXPECT_THAT(
   applyEdits(std::move(Results->GlobalChanges)),
@@ -1207,9 +1219,9 @@
 NewName,
 AST,
 MainFilePath,
+createOverlay(getVFSFromAST(AST), InMemFS),
 Index.get(),
-{/*CrossFile=*/true},
-GetDirtyBuffer});
+{/*CrossFile=*/true}});
   ASSERT_TRUE(bool(Resul

[PATCH] D93978: [clangd] DefineOutline doesn't require implementation file being saved

2021-01-20 Thread Nathan James via Phabricator via cfe-commits
njames93 updated this revision to Diff 317862.
njames93 added a comment.

Change implementation to use DirtyFS instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93978

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/DraftStore.cpp
  clang-tools-extra/clangd/DraftStore.h
  clang-tools-extra/clangd/refactor/Tweak.cpp
  clang-tools-extra/clangd/refactor/Tweak.h
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/tool/Check.cpp
  clang-tools-extra/clangd/unittests/DraftStoreTests.cpp
  clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp

Index: clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
@@ -74,7 +74,8 @@
   SelectionTree::createEach(AST.getASTContext(), AST.getTokens(), Range.first,
 Range.second, [&](SelectionTree ST) {
   Tweak::Selection S(Index, AST, Range.first,
- Range.second, std::move(ST));
+ Range.second, std::move(ST),
+ nullptr);
   if (auto T = prepareTweak(TweakID, S)) {
 Result = (*T)->apply(S);
 return true;
Index: clang-tools-extra/clangd/unittests/DraftStoreTests.cpp
===
--- clang-tools-extra/clangd/unittests/DraftStoreTests.cpp
+++ clang-tools-extra/clangd/unittests/DraftStoreTests.cpp
@@ -52,8 +52,8 @@
 llvm::Expected Result =
 DS.updateDraft(Path, llvm::None, {Event});
 ASSERT_TRUE(!!Result);
-EXPECT_EQ(Result->Contents, SrcAfter.code());
-EXPECT_EQ(DS.getDraft(Path)->Contents, SrcAfter.code());
+EXPECT_EQ(*Result->Contents, SrcAfter.code());
+EXPECT_EQ(*DS.getDraft(Path)->Contents, SrcAfter.code());
 EXPECT_EQ(Result->Version, static_cast(i));
   }
 }
@@ -84,8 +84,8 @@
   DS.updateDraft(Path, llvm::None, Changes);
 
   ASSERT_TRUE(!!Result) << llvm::toString(Result.takeError());
-  EXPECT_EQ(Result->Contents, FinalSrc.code());
-  EXPECT_EQ(DS.getDraft(Path)->Contents, FinalSrc.code());
+  EXPECT_EQ(*Result->Contents, FinalSrc.code());
+  EXPECT_EQ(*DS.getDraft(Path)->Contents, FinalSrc.code());
   EXPECT_EQ(Result->Version, 1);
 }
 
@@ -345,7 +345,7 @@
 
   Optional Contents = DS.getDraft(File);
   EXPECT_TRUE(Contents);
-  EXPECT_EQ(Contents->Contents, OriginalContents);
+  EXPECT_EQ(*Contents->Contents, OriginalContents);
   EXPECT_EQ(Contents->Version, 0);
 }
 
Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Check.cpp
@@ -203,7 +203,8 @@
   vlog("  {0} {1}", Pos, Tok.text(AST->getSourceManager()));
   auto Tree = SelectionTree::createRight(AST->getASTContext(),
  AST->getTokens(), Start, End);
-  Tweak::Selection Selection(&Index, *AST, Start, End, std::move(Tree));
+  Tweak::Selection Selection(&Index, *AST, Start, End, std::move(Tree),
+ nullptr);
   for (const auto &T : prepareTweaks(Selection, Opts.TweakFilter)) {
 auto Result = T->apply(Selection);
 if (!Result) {
Index: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
@@ -63,10 +63,9 @@
 }
 
 llvm::Optional getSourceFile(llvm::StringRef FileName,
-   const Tweak::Selection &Sel) {
-  if (auto Source = getCorrespondingHeaderOrSource(
-  FileName,
-  &Sel.AST->getSourceManager().getFileManager().getVirtualFileSystem()))
+   const Tweak::Selection &Sel,
+   llvm::vfs::FileSystem *FS) {
+  if (auto Source = getCorrespondingHeaderOrSource(FileName, FS))
 return *Source;
   return getCorrespondingHeaderOrSource(FileName, *Sel.AST, Sel.Index);
 }
@@ -403,13 +402,14 @@
 if (!MainFileName)
   return error("Couldn't get absolute path for main file.");
 
-auto CCFile = getSourceFile(*MainFileName, Sel);
+auto *FS = Sel.FS;
+assert(FS && "FS Must be set in apply");
+
+auto CCFile = getSourceFile(*MainFileName, Sel, FS);
+
 if (!CCFile)
   return error("Couldn't find a suitable implementation file.");
-

[PATCH] D93978: [clangd] DefineOutline doesn't require implementation file being saved

2021-01-20 Thread Nathan James via Phabricator via cfe-commits
njames93 updated this revision to Diff 317864.
njames93 added a comment.

Fixed last series being a little corrupted.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93978

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/refactor/Tweak.cpp
  clang-tools-extra/clangd/refactor/Tweak.h
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/tool/Check.cpp
  clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp

Index: clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/TweakTesting.cpp
@@ -74,7 +74,8 @@
   SelectionTree::createEach(AST.getASTContext(), AST.getTokens(), Range.first,
 Range.second, [&](SelectionTree ST) {
   Tweak::Selection S(Index, AST, Range.first,
- Range.second, std::move(ST));
+ Range.second, std::move(ST),
+ nullptr);
   if (auto T = prepareTweak(TweakID, S)) {
 Result = (*T)->apply(S);
 return true;
Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Check.cpp
@@ -203,7 +203,8 @@
   vlog("  {0} {1}", Pos, Tok.text(AST->getSourceManager()));
   auto Tree = SelectionTree::createRight(AST->getASTContext(),
  AST->getTokens(), Start, End);
-  Tweak::Selection Selection(&Index, *AST, Start, End, std::move(Tree));
+  Tweak::Selection Selection(&Index, *AST, Start, End, std::move(Tree),
+ nullptr);
   for (const auto &T : prepareTweaks(Selection, Opts.TweakFilter)) {
 auto Result = T->apply(Selection);
 if (!Result) {
Index: clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
@@ -63,10 +63,9 @@
 }
 
 llvm::Optional getSourceFile(llvm::StringRef FileName,
-   const Tweak::Selection &Sel) {
-  if (auto Source = getCorrespondingHeaderOrSource(
-  FileName,
-  &Sel.AST->getSourceManager().getFileManager().getVirtualFileSystem()))
+   const Tweak::Selection &Sel,
+   llvm::vfs::FileSystem *FS) {
+  if (auto Source = getCorrespondingHeaderOrSource(FileName, FS))
 return *Source;
   return getCorrespondingHeaderOrSource(FileName, *Sel.AST, Sel.Index);
 }
@@ -403,13 +402,14 @@
 if (!MainFileName)
   return error("Couldn't get absolute path for main file.");
 
-auto CCFile = getSourceFile(*MainFileName, Sel);
+auto *FS = Sel.FS;
+assert(FS && "FS Must be set in apply");
+
+auto CCFile = getSourceFile(*MainFileName, Sel, FS);
+
 if (!CCFile)
   return error("Couldn't find a suitable implementation file.");
-
-auto &FS =
-Sel.AST->getSourceManager().getFileManager().getVirtualFileSystem();
-auto Buffer = FS.getBufferForFile(*CCFile);
+auto Buffer = FS->getBufferForFile(*CCFile);
 // FIXME: Maybe we should consider creating the implementation file if it
 // doesn't exist?
 if (!Buffer)
Index: clang-tools-extra/clangd/refactor/Tweak.h
===
--- clang-tools-extra/clangd/refactor/Tweak.h
+++ clang-tools-extra/clangd/refactor/Tweak.h
@@ -48,7 +48,8 @@
   /// Input to prepare and apply tweaks.
   struct Selection {
 Selection(const SymbolIndex *Index, ParsedAST &AST, unsigned RangeBegin,
-  unsigned RangeEnd, SelectionTree ASTSelection);
+  unsigned RangeEnd, SelectionTree ASTSelection,
+  llvm::vfs::FileSystem *VFS);
 /// The text of the active document.
 llvm::StringRef Code;
 /// The Index for handling codebase related queries.
@@ -64,6 +65,11 @@
 unsigned SelectionEnd;
 /// The AST nodes that were selected.
 SelectionTree ASTSelection;
+/// File system used to access source code (for cross-file tweaks).
+/// This can be used to overlay the "dirty" contents of files open in the
+/// editor, which (in case of headers) may not match the saved contents used
+/// for building the AST.
+llvm::vfs::FileSystem *FS = nullptr;
 // FIXME: provide a way to get sources and ASTs for other files.
   };
 
Index: clang-tools-extra/clangd/

[PATCH] D94865: [ASTMatchers] Add callOrConstruct matcher

2021-01-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added reviewers: klimek, sammccall, dblaikie, echristo.
aaron.ballman added a comment.

Adding some reviewers to see if we can bikeshed a somewhat better name than 
`callOrConstruct`, or to see if my concerns are unfounded.




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2867
+extern const internal::MapAnyOfMatcher
+callOrConstruct;
+

steveire wrote:
> aaron.ballman wrote:
> > I'm not super keen on this name. It's certainly descriptive, but I do 
> > wonder if it's a bit too specific and should perhaps be something more like 
> > `callableExpr()`, `callLikeExpr()`, or something more generic. For 
> > instance, I could imagine wanting this to match on something like:
> > ```
> > struct S {
> >   void setter(int val) {}
> >   __declspec(property(put = setter)) int x;
> > };
> > 
> > int main() {
> >   S s;
> >   s.x = 12; // Match here
> >   // Because the above code actually does this:
> >   // s.setter(12);
> > }
> > ```
> > because this also has an expression that isn't really a call (as far as our 
> > AST is concerned) but is a call as far as program semantics are concerned. 
> > I'm not suggesting to make the matcher support that right now (unless you 
> > felt like doing it), but thinking about the future and avoiding a name that 
> > may paint us into a corner.
> > 
> > WDYT about using a more generic name?
> I haven't seen code like that before (ms extension?) 
> https://godbolt.org/z/anvd43 but I think that should be matched by 
> `binaryOperator` instead. That already matches based on what the code looks 
> like, rather than what it is in the AST.
> 
> This `callOrConstruct` is really for using `hasArgument` and related 
> submatchers with nodes which support it. As such I think the name is fine. I 
> don't like `callableExpr` or `callLikeExpr` because they don't bring to mind 
> the possibility that construction is also supported.
> I haven't seen code like that before (ms extension?)

Yes, it's an MS extension.

> That already matches based on what the code looks like, rather than what it 
> is in the AST.

Yes, but these are AST matchers, so it's reasonable to match on what's in the 
AST (as well as what the code looks like, of course). I'm not arguing it needs 
to be supported so much as pointing out that there are other AST nodes this 
notionally applies to where the name is a bit too specific.

> This callOrConstruct is really for using hasArgument and related submatchers 
> with nodes which support it. As such I think the name is fine. I don't like 
> callableExpr or callLikeExpr because they don't bring to mind the possibility 
> that construction is also supported.

I'm pretty sure we've extended what `hasArgument` can be applied to in the past 
(but I've not verified), so the part that worries me is specifically naming the 
nodes as part of the identifier. This effectively means that if we ever find 
another AST node for `hasArgument`, we either need a different API like 
`callConstructOrWhatever` or we're stuck with a poor name.

Another (smaller) concern with the name is that `callOrConstruct` can describe 
declarations as well as expressions, to some degree as you can declare calls 
and constructors. It's a smaller concern because those at least share a common 
base class. `callOrConstructExpr` would clarify this easily enough.

I see you added `ObjCMessageExpr` as well, thank you for that! It's a perhaps 
better example of why this name feels awkward to me. In ObjC, you don't call an 
`ObjCMessageExpr`, you "send" it to the given object or class. That suggests to 
me that `callableExpr` or `callLikeExpr` is also not a great name either.

Perhaps `executableExpr` because you're executing some code?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94865

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


[PATCH] D94533: [clang] Add AddClang.cmake to the list of the CMake modules that are installed

2021-01-20 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added a comment.

Ping.

Would anyone be able to take a look? Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94533

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


[PATCH] D95046: [clangd] Add option to use dirty file contents when building preambles.

2021-01-20 Thread Nathan James via Phabricator via cfe-commits
njames93 created this revision.
njames93 added reviewers: sammccall, kadircet.
Herald added subscribers: usaxena95, arphaman.
njames93 requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang.

Adds a option `use-dirty-preambles` to enable using unsaved in editor contents 
when building pre-ambles.
This enables a more seamless user experience when switching between header and 
implementation files and forgetting to save inbetween.
It's also in line with the LSP spec that states open files in the editor should 
be used instead of on the contents on disk - 
https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/
For now the option is defaulted to off and hidden, Though I have a feeling it 
should be moved into the `.clangd` config and possibly defaulted to true.

Depends on D94554 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95046

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


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -493,6 +493,12 @@
 init(ClangdServer::Options().CollectMainFileRefs),
 };
 
+opt UseDirtyPreambles{"use-dirty-preambles", cat(Misc),
+desc("Use files open in the editor when building "
+ "pre-ambles instead of reading from the 
disk"),
+Hidden,
+init(ClangdServer::Options().UseDirtyPreambles)};
+
 #if defined(__GLIBC__) && CLANGD_MALLOC_TRIM
 opt EnableMallocTrim{
 "malloc-trim",
@@ -873,6 +879,7 @@
 Opts.ClangTidyProvider = ClangTidyOptProvider;
   }
   Opts.AsyncPreambleBuilds = AsyncPreamble;
+  Opts.UseDirtyPreambles = UseDirtyPreambles;
   Opts.SuggestMissingIncludes = SuggestMissingIncludes;
   Opts.QueryDriverGlobs = std::move(QueryDriverGlobs);
   Opts.TweakFilter = [&](const Tweak &T) {
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -156,6 +156,9 @@
 /// Enable preview of FoldingRanges feature.
 bool FoldingRanges = false;
 
+/// If true, use the dirty buffer contents when building Preambles.
+bool UseDirtyPreambles = false;
+
 explicit operator TUScheduler::Options() const;
   };
   // Sensible default options for use in tests.
@@ -358,6 +361,10 @@
   ArrayRef Ranges,
   Callback CB);
 
+  const ThreadsafeFS &getPreambleFS() const {
+return UseDirtyPreambles ? DirtyFS : TFS;
+  }
+
   /// Derives a context for a task processing the specified source file.
   /// This includes the current configuration (see Options::ConfigProvider).
   /// The empty string means no particular file is the target.
@@ -399,6 +406,8 @@
   // If true, preserve the type for recovery AST.
   bool PreserveRecoveryASTType = false;
 
+  bool UseDirtyPreambles = false;
+
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -149,6 +149,7 @@
   SuggestMissingIncludes(Opts.SuggestMissingIncludes),
   BuildRecoveryAST(Opts.BuildRecoveryAST),
   PreserveRecoveryASTType(Opts.PreserveRecoveryASTType),
+  UseDirtyPreambles(Opts.UseDirtyPreambles),
   WorkspaceRoot(Opts.WorkspaceRoot),
   // Pass a callback into `WorkScheduler` to extract symbols from a newly
   // parsed file and rebuild the file index synchronously each time an AST
@@ -209,7 +210,7 @@
 
   // Compile command is set asynchronously during update, as it can be slow.
   ParseInputs Inputs;
-  Inputs.TFS = &TFS;
+  Inputs.TFS = &getPreambleFS();
   Inputs.Contents = std::string(Contents);
   Inputs.Version = Version.str();
   Inputs.ForceRebuild = ForceRebuild;
@@ -253,7 +254,7 @@
 SpecFuzzyFind->CachedReq = 
CachedCompletionFuzzyFindRequestByFile[File];
   }
 }
-ParseInputs ParseInput{IP->Command, &TFS, IP->Contents.str()};
+ParseInputs ParseInput{IP->Command, &getPreambleFS(), IP->Contents.str()};
 ParseInput.Index = Index;
 ParseInput.Opts.BuildRecoveryAST = BuildRecoveryAST;
 ParseInput.Opts.PreserveRecoveryASTType = PreserveRecoveryASTType;
@@ -300,7 +301,7 @@
 if (!PreambleData)
   return CB(error("Failed to parse includes"));
 
-ParseInputs ParseInput{IP->Command, &TFS, IP->Contents.str()};
+ParseInputs ParseInput{IP->Command, &getPreambleFS(), I

Re: [clang] 5a391d3 - Following up on PR48517, fix handling of template arguments that refer

2021-01-20 Thread Hans Wennborg via cfe-commits
Combined with da986511fb9da1a46a0ca4dba2e49e2426036303 this broke
Chromium's build. See
https://bugs.chromium.org/p/chromium/issues/detail?id=1168494#c1 for a
repro.

I've reverted this change and the changes that depended on it in
8ba442bc2136c9ab91c74826db7195e406b94fb7 in the meantime.

On Tue, Jan 19, 2021 at 6:06 AM Richard Smith via cfe-commits
 wrote:
>
>
> Author: Richard Smith
> Date: 2021-01-18T21:05:01-08:00
> New Revision: 5a391d38ac6c561ba908334d427f26124ed9132e
>
> URL: 
> https://github.com/llvm/llvm-project/commit/5a391d38ac6c561ba908334d427f26124ed9132e
> DIFF: 
> https://github.com/llvm/llvm-project/commit/5a391d38ac6c561ba908334d427f26124ed9132e.diff
>
> LOG: Following up on PR48517, fix handling of template arguments that refer
> to dependent declarations.
>
> Treat an id-expression that names a local variable in a templated
> function as being instantiation-dependent.
>
> This addresses a language defect whereby a reference to a dependent
> declaration can be formed without any construct being value-dependent.
> Fixing that through value-dependence turns out to be problematic, so
> instead this patch takes the approach (proposed on the core reflector)
> of allowing the use of pointers or references to (but not values of)
> dependent declarations inside value-dependent expressions, and instead
> treating template arguments as dependent if they evaluate to a constant
> involving such dependent declarations.
>
> This ends up affecting a bunch of OpenMP tests, due to OpenMP
> imprecisely handling instantiation-dependent constructs, bailing out
> early instead of processing dependent constructs to the extent possible
> when handling the template.
>
> Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and
> reverted because a dependency commit was reverted.
>
> Added:
> clang/test/SemaTemplate/temp_arg_nontype_cxx17.cpp
>
> Modified:
> clang/include/clang/AST/Expr.h
> clang/include/clang/AST/TemplateBase.h
> clang/include/clang/Sema/Sema.h
> clang/lib/AST/ComputeDependence.cpp
> clang/lib/AST/Expr.cpp
> clang/lib/AST/ExprCXX.cpp
> clang/lib/AST/ExprConstant.cpp
> clang/lib/AST/TemplateBase.cpp
> clang/lib/Sema/SemaOverload.cpp
> clang/lib/Sema/SemaTemplate.cpp
> clang/lib/Sema/SemaTemplateInstantiate.cpp
> clang/test/OpenMP/distribute_dist_schedule_messages.cpp
> clang/test/OpenMP/distribute_parallel_for_dist_schedule_messages.cpp
> clang/test/OpenMP/distribute_parallel_for_simd_dist_schedule_messages.cpp
> clang/test/OpenMP/distribute_simd_dist_schedule_messages.cpp
> clang/test/OpenMP/target_parallel_for_simd_collapse_messages.cpp
> clang/test/OpenMP/target_parallel_for_simd_ordered_messages.cpp
> clang/test/OpenMP/target_simd_collapse_messages.cpp
> clang/test/OpenMP/target_teams_distribute_dist_schedule_messages.cpp
> 
> clang/test/OpenMP/target_teams_distribute_parallel_for_dist_schedule_messages.cpp
> 
> clang/test/OpenMP/target_teams_distribute_parallel_for_simd_dist_schedule_messages.cpp
> clang/test/OpenMP/target_teams_distribute_simd_dist_schedule_messages.cpp
> clang/test/OpenMP/target_update_from_messages.cpp
> clang/test/OpenMP/target_update_to_messages.cpp
> clang/test/OpenMP/task_messages.cpp
> clang/test/OpenMP/teams_distribute_dist_schedule_messages.cpp
> clang/test/OpenMP/teams_distribute_parallel_for_dist_schedule_messages.cpp
> 
> clang/test/OpenMP/teams_distribute_parallel_for_simd_dist_schedule_messages.cpp
> clang/test/OpenMP/teams_distribute_simd_dist_schedule_messages.cpp
> clang/test/SemaCXX/warn-unused-lambda-capture.cpp
> clang/test/SemaTemplate/temp_arg_nontype_cxx20.cpp
>
> Removed:
> clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
>
>
> 
> diff  --git a/clang/include/clang/AST/Expr.h b/clang/include/clang/AST/Expr.h
> index a44d06967431..c963be98d3cb 100644
> --- a/clang/include/clang/AST/Expr.h
> +++ b/clang/include/clang/AST/Expr.h
> @@ -578,12 +578,12 @@ class Expr : public ValueStmt {
>struct EvalStatus {
>  /// Whether the evaluated expression has side effects.
>  /// For example, (f() && 0) can be folded, but it still has side effects.
> -bool HasSideEffects;
> +bool HasSideEffects = false;
>
>  /// Whether the evaluation hit undefined behavior.
>  /// For example, 1.0 / 0.0 can be folded to Inf, but has undefined 
> behavior.
>  /// Likewise, INT_MAX + 1 can be folded to INT_MIN, but has UB.
> -bool HasUndefinedBehavior;
> +bool HasUndefinedBehavior = false;
>
>  /// Diag - If this is non-null, it will be filled in with a stack of 
> notes
>  /// indicating why evaluation failed (or why it failed to produce a 
> constant
> @@ -592,10 +592,7 @@ class Expr : public ValueStmt {
>  /// foldable. If the expression is foldable, but not a constant 
> expression,
>  /// the notes w

[PATCH] D94814: [HIP] Support `__managed__` attribute

2021-01-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:5426
+The ``__managed__`` attribute can be applied to a global variable declaration 
in HIP.
+A managed variable is emitted as a undefined global symbol in device binary and
+registered by ``__hipRegisterManagedVariable`` in init functions. HIP runtime 
allocates





Comment at: clang/include/clang/Basic/AttrDocs.td:5427-5429
+registered by ``__hipRegisterManagedVariable`` in init functions. HIP runtime 
allocates
+managed memory and use it to define the symbol when loading the device binary.
+A managed variable can be accessed in both device and host code.





Comment at: clang/lib/Sema/SemaDeclAttr.cpp:7728
+  case ParsedAttr::AT_HIPManaged:
+handleSimpleAttributeWithExclusions(S, D,
+AL);

tra wrote:
> The code changes in the patch appear to treat `__managed__` variable as a 
> superset of a `__device__` var. If that's indeed the case, adding an implicit 
> `__device__` attribute here would help to simplify the code. This way the 
> existing code can handle generic  `__device__` var functionality without 
> additional changes, and would use `__managed__` checks for the cases specific 
> for managed vars only.
> 
I think you're missing changes to the CUDA global attr to check for mutual 
exclusions with `__managed__` as well. Also, I think this won't do the right 
thing for redeclarations, like:
```
__device__ extern int i;
__managed__ extern int i;
```



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:7728
+  case ParsedAttr::AT_HIPManaged:
+handleSimpleAttributeWithExclusions(S, D,
+AL);

aaron.ballman wrote:
> tra wrote:
> > The code changes in the patch appear to treat `__managed__` variable as a 
> > superset of a `__device__` var. If that's indeed the case, adding an 
> > implicit `__device__` attribute here would help to simplify the code. This 
> > way the existing code can handle generic  `__device__` var functionality 
> > without additional changes, and would use `__managed__` checks for the 
> > cases specific for managed vars only.
> > 
> I think you're missing changes to the CUDA global attr to check for mutual 
> exclusions with `__managed__` as well. Also, I think this won't do the right 
> thing for redeclarations, like:
> ```
> __device__ extern int i;
> __managed__ extern int i;
> ```
> This way the existing code can handle generic __device__ var functionality 
> without additional changes, and would use __managed__ checks for the cases 
> specific for managed vars only.

Another alternative to consider is to not create a new semantic attribute named 
`HIPManagedAttr` but to instead add a new spelling to `CUDADevice` in 
`Attr.td`, giving the class an `Accessor` to distinguish which spelling the 
user wrote in code, and use that accessor for the specific cases for managed 
vars.


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

https://reviews.llvm.org/D94814

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


[PATCH] D91303: [clang-tidy] readability-container-size-empty: simplify implementation

2021-01-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability-container-size-empty.cpp:480-482
-// CHECK-MESSAGES: :[[@LINE-1]]:24: warning: the 'empty' method should be used
-// CHECK-MESSAGES: :101:18: note: method 'Lazy'::empty() defined here
-// CHECK-FIXES: {{^  }}void func() noexcept(!L.empty());

alexfh wrote:
> Wait, is losing these diagnostics necessary?
I think it's an improvement. The `noexcept`-ness of `size()` need not relate to 
the `noexcept`-ness of `empty()` (notionally it should, but it's not a 
requirement users must follow), so there's no guarantee that the change will 
have the same semantic effect on the declaration of `func()`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91303

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


[PATCH] D93940: [clang-tidy] Add a check for blocking types and functions.

2021-01-20 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

In D93940#2509325 , @segoon wrote:

> Eugene.Zelenko, njames93, any comments on the patch?

Sorry, you need to wait for approval from one of maintainer mentioned as 
reviewers. I check only documentation and for minor code issues.


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

https://reviews.llvm.org/D93940

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


[PATCH] D93986: [clang-format] Add the possibility to align assignments spanning empty lines or comments

2021-01-20 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added a comment.

In D93986#2509079 , @tinloaf wrote:

> In D93986#2509045 , 
> @HazardyKnusperkeks wrote:
>
>> How is it going? I would like to add some new alignment options and it would 
>> be stupid not to do it on top of this.
>
> Sorry, much to do work-wise currently. I'll get to the last details today and 
> finish this!

No problem, and no need to haste. I know that sometimes the available time is 
way to short.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93986

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


[PATCH] D94621: [clang-tidy] add concurrency-async-fs

2021-01-20 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

In D94621#2509324 , @segoon wrote:

> Eugene.Zelenko, njames93, any comments on the patch?

Sorry, you need to wait for approval from one of maintainers mentioned as 
reviewers. I check only documentation and for minor code issues.


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

https://reviews.llvm.org/D94621

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


[PATCH] D94622: [clang-tidy] add concurrency-async-no-new-threads

2021-01-20 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

In D94622#2509323 , @segoon wrote:

> Eugene.Zelenko, njames93, any comments on the patch?

Sorry, you need to wait for approval from one of maintainers mentioned as 
reviewers. I check only documentation and for minor code issues.


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

https://reviews.llvm.org/D94622

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


[PATCH] D93525: [OpenMP] Add unbundling of archives containing bundled object files into device specific archives

2021-01-20 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam added a comment.

In D93525#2495937 , @t-tye wrote:

> In D93525#2495374 , @saiislam wrote:
>
>> In D93525#2493752 , @t-tye wrote:
>>
>>> In D93525#2493024 , @yaxunl wrote:
>>>
 can you document this in ClangOffloadBundler.rst ? I think we need a clear 
 description about how clang-offload-bundler knows which file in the .a 
 file belongs to which target.
>>>
>>> How does the .a relate to bundled code objects? Does the .a have a number 
>>> of bundled code objects? If so wouldn't the identity of code objects be 
>>> defined by the existing bundled code object ABI already documented? If the 
>>> .a is a set of non-bundled code objects then defining how they are 
>>> identified is not part of the clang-offload-bundler documentation as there 
>>> are no bundled code objects involved. It would seem that the documentation 
>>> belongs with the OpenMP runtime/compiler that is choosing to use .a files 
>>> in this manner.
>>
>> Bundles (created using clang-offload-bundler) are passed to llvm-ar to 
>> create an archive of bundled objects (*.a file). An archive can have bundles 
>> for multiple device types. So, yes, the identity of code objects is defined 
>> by the existing bundled code object ABI.
>> This patch reads such an archive and produces a device-specific archive for 
>> each of the target devices given as input. Each device-specific archive 
>> contains all the code objects corresponding to that particular device and 
>> are written as per llvm archive format.
>>
>> Here is a snippet of relevant lit run lines:
>>
>>   // RUN: %clang -O0 -target %itanium_abi_triple %s -c -o %t.o
>>   
>>   // RUN: echo 'Content of device file 1' > %t.tgt1
>>   // RUN: clang-offload-bundler -type=o 
>> -targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa-gfx900 
>> -inputs=%t.o,%t.tgt1 -outputs=%t.abundle1.o
>>
>>   // RUN: echo 'Content of device file 2' > %t.tgt2
>>   // RUN: clang-offload-bundler -type=o 
>> -targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa-gfx900 
>> -inputs=%t.o,%t.tgt2 -outputs=%t.abundle2.o
>>
>>   // RUN: llvm-ar cr %t.lib.a %t.abundle1.o %t.abundle2.o
>>   
>>   This patch ==>
>>   // RUN: clang-offload-bundler -unbundle -type=a 
>> -targets=openmp-amdgcn-amd-amdhsa-gfx900 -inputs=%t.lib.a 
>> -outputs=%t.devicelib.a
>>   
>>   %t.devicelib.a will contain all devices objects corresponding to gfx900
>>
>> Though my interest originates from OpenMP side, Device-specific Archive 
>> Libraries created like this can be used by other offloading languages like 
>> HIP, CUDA, and OpenCL. Pelase refer D81109  
>> for the an earlier patch in the series of patches which will enable this.
>
> The naming of code objects in a bundled code object includes the processor 
> name and the settings for target features (see 
> https://clang.llvm.org/docs/ClangOffloadBundler.html#target-id and 
> https://llvm.org/docs/AMDGPUUsage.html#target-id). The compatibility of code 
> objects considers both target processor matching and target feature 
> compatibility. Target features can have three settings: on, off and any. The 
> compatibility is that each feature that is on/off must exactly match, but any 
> will match either on or off.
>
> So when unbundling an archive how is the desired code object being requested? 
> How is it handling the target features? For example, if code objects that 
> will be compatible with a feature being on is required, then matching code 
> objects in the archive would be those that have that feature either on or any.

At the moment this patch defines compatibility as exact string match of bundler 
entry ID. So, it doesn't support target ID concept fully. But, following 
example work.
Supporting target ID requires little more work and discussion.

  // RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa--gfx908 
-inputs=%t.o,%t.tgt1 -outputs=%t.abundle1.o
  // RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa--gfx908:sramecc+:xnack+,openmp-amdgcn-amd-amdhsa--gfx908:sramecc-:xnack+
 -inputs=%t.o,%t.tgt1,%t.tgt2 -outputs=%t.targetIDbundle.o
  // RUN: llvm-ar cr %t.targetIDlib.a %t.abundle1.o %t.targetIDbundle.o
  // RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx908:sramecc+:xnack+ 
-inputs=%t.targetIDlib.a -outputs=%t.devicelibt-sramecc+.a
  // RUN: llvm-ar t %t.devicelibt-sramecc+.a | FileCheck %s 
-check-prefix=SRAMECCplus
  // SRAMECCplus: targetIDbundle.bc
  // SRAMECCplus-NOT: abundle1.bc


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93525

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https

[clang] 8000c77 - Make it possible to store a ASTNodeKind in VariantValue

2021-01-20 Thread Stephen Kelly via cfe-commits

Author: Stephen Kelly
Date: 2021-01-20T15:44:45Z
New Revision: 8000c778532bfe1cc74191e41e19272e54477ed0

URL: 
https://github.com/llvm/llvm-project/commit/8000c778532bfe1cc74191e41e19272e54477ed0
DIFF: 
https://github.com/llvm/llvm-project/commit/8000c778532bfe1cc74191e41e19272e54477ed0.diff

LOG: Make it possible to store a ASTNodeKind in VariantValue

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

Added: 


Modified: 
clang/include/clang/ASTMatchers/Dynamic/VariantValue.h
clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
clang/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp

Removed: 




diff  --git a/clang/include/clang/ASTMatchers/Dynamic/VariantValue.h 
b/clang/include/clang/ASTMatchers/Dynamic/VariantValue.h
index 140b41dffc40..fa033f49bc90 100644
--- a/clang/include/clang/ASTMatchers/Dynamic/VariantValue.h
+++ b/clang/include/clang/ASTMatchers/Dynamic/VariantValue.h
@@ -251,6 +251,7 @@ class VariantValue {
   VariantValue(double Double);
   VariantValue(unsigned Unsigned);
   VariantValue(StringRef String);
+  VariantValue(ASTNodeKind NodeKind);
   VariantValue(const VariantMatcher &Matchers);
 
   /// Constructs an \c unsigned value (disambiguation from bool).
@@ -280,6 +281,10 @@ class VariantValue {
   const std::string &getString() const;
   void setString(StringRef String);
 
+  bool isNodeKind() const;
+  const ASTNodeKind &getNodeKind() const;
+  void setNodeKind(ASTNodeKind NodeKind);
+
   /// Matcher value functions.
   bool isMatcher() const;
   const VariantMatcher &getMatcher() const;
@@ -316,7 +321,8 @@ class VariantValue {
 VT_Double,
 VT_Unsigned,
 VT_String,
-VT_Matcher
+VT_Matcher,
+VT_NodeKind
   };
 
   /// All supported value types.
@@ -326,6 +332,7 @@ class VariantValue {
 bool Boolean;
 std::string *String;
 VariantMatcher *Matcher;
+ASTNodeKind *NodeKind;
   };
 
   ValueType Type;

diff  --git a/clang/lib/ASTMatchers/Dynamic/VariantValue.cpp 
b/clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
index f31dda82a932..d1ecb1e00b91 100644
--- a/clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
+++ b/clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
@@ -268,6 +268,10 @@ VariantValue::VariantValue(StringRef String) : 
Type(VT_Nothing) {
   setString(String);
 }
 
+VariantValue::VariantValue(ASTNodeKind NodeKind) : Type(VT_Nothing) {
+  setNodeKind(NodeKind);
+}
+
 VariantValue::VariantValue(const VariantMatcher &Matcher) : Type(VT_Nothing) {
   setMatcher(Matcher);
 }
@@ -290,6 +294,9 @@ VariantValue &VariantValue::operator=(const VariantValue 
&Other) {
   case VT_String:
 setString(Other.getString());
 break;
+  case VT_NodeKind:
+setNodeKind(Other.getNodeKind());
+break;
   case VT_Matcher:
 setMatcher(Other.getMatcher());
 break;
@@ -308,6 +315,9 @@ void VariantValue::reset() {
   case VT_Matcher:
 delete Value.Matcher;
 break;
+  case VT_NodeKind:
+delete Value.NodeKind;
+break;
   // Cases that do nothing.
   case VT_Boolean:
   case VT_Double:
@@ -378,6 +388,19 @@ void VariantValue::setString(StringRef NewValue) {
   Value.String = new std::string(NewValue);
 }
 
+bool VariantValue::isNodeKind() const { return Type == VT_NodeKind; }
+
+const ASTNodeKind &VariantValue::getNodeKind() const {
+  assert(isNodeKind());
+  return *Value.NodeKind;
+}
+
+void VariantValue::setNodeKind(ASTNodeKind NewValue) {
+  reset();
+  Type = VT_NodeKind;
+  Value.NodeKind = new ASTNodeKind(NewValue);
+}
+
 bool VariantValue::isMatcher() const {
   return Type == VT_Matcher;
 }
@@ -449,6 +472,8 @@ std::string VariantValue::getTypeAsString() const {
   case VT_Boolean: return "Boolean";
   case VT_Double: return "Double";
   case VT_Unsigned: return "Unsigned";
+  case VT_NodeKind:
+return getNodeKind().asStringRef().str();
   case VT_Nothing: return "Nothing";
   }
   llvm_unreachable("Invalid Type");

diff  --git a/clang/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp 
b/clang/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp
index c08d7fc3ff74..c62a6b385e28 100644
--- a/clang/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp
+++ b/clang/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp
@@ -184,6 +184,25 @@ TEST(VariantValueTest, Matcher) {
   .getTypedMatcher()));
 }
 
+TEST(VariantValueTest, NodeKind) {
+  VariantValue Value = ASTNodeKind::getFromNodeKind();
+  EXPECT_TRUE(Value.isNodeKind());
+  
EXPECT_TRUE(Value.getNodeKind().isSame(ASTNodeKind::getFromNodeKind()));
+
+  Value = ASTNodeKind::getFromNodeKind();
+  EXPECT_TRUE(Value.isNodeKind());
+  EXPECT_TRUE(Value.getNodeKind().isSame(
+  ASTNodeKind::getFromNodeKind()));
+
+  Value.setNodeKind(ASTNodeKind::getFromNodeKind());
+  EXPECT_TRUE(Value.isNodeKind());
+  EXPECT_TRUE(
+  Value.getNodeKind().isSame(ASTNodeKind::getFromNodeKind()));
+
+  Value = 42;
+  EXPECT_TRUE(!Value.isNodeKind());
+}
+
 } // end anonymous namespace

[PATCH] D94878: Make it possible to store a ASTNodeKind in VariantValue

2021-01-20 Thread Stephen Kelly via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8000c778532b: Make it possible to store a ASTNodeKind in 
VariantValue (authored by stephenkelly).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94878

Files:
  clang/include/clang/ASTMatchers/Dynamic/VariantValue.h
  clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
  clang/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp

Index: clang/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp
===
--- clang/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp
+++ clang/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp
@@ -184,6 +184,25 @@
   .getTypedMatcher()));
 }
 
+TEST(VariantValueTest, NodeKind) {
+  VariantValue Value = ASTNodeKind::getFromNodeKind();
+  EXPECT_TRUE(Value.isNodeKind());
+  EXPECT_TRUE(Value.getNodeKind().isSame(ASTNodeKind::getFromNodeKind()));
+
+  Value = ASTNodeKind::getFromNodeKind();
+  EXPECT_TRUE(Value.isNodeKind());
+  EXPECT_TRUE(Value.getNodeKind().isSame(
+  ASTNodeKind::getFromNodeKind()));
+
+  Value.setNodeKind(ASTNodeKind::getFromNodeKind());
+  EXPECT_TRUE(Value.isNodeKind());
+  EXPECT_TRUE(
+  Value.getNodeKind().isSame(ASTNodeKind::getFromNodeKind()));
+
+  Value = 42;
+  EXPECT_TRUE(!Value.isNodeKind());
+}
+
 } // end anonymous namespace
 } // end namespace dynamic
 } // end namespace ast_matchers
Index: clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
===
--- clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
+++ clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
@@ -268,6 +268,10 @@
   setString(String);
 }
 
+VariantValue::VariantValue(ASTNodeKind NodeKind) : Type(VT_Nothing) {
+  setNodeKind(NodeKind);
+}
+
 VariantValue::VariantValue(const VariantMatcher &Matcher) : Type(VT_Nothing) {
   setMatcher(Matcher);
 }
@@ -290,6 +294,9 @@
   case VT_String:
 setString(Other.getString());
 break;
+  case VT_NodeKind:
+setNodeKind(Other.getNodeKind());
+break;
   case VT_Matcher:
 setMatcher(Other.getMatcher());
 break;
@@ -308,6 +315,9 @@
   case VT_Matcher:
 delete Value.Matcher;
 break;
+  case VT_NodeKind:
+delete Value.NodeKind;
+break;
   // Cases that do nothing.
   case VT_Boolean:
   case VT_Double:
@@ -378,6 +388,19 @@
   Value.String = new std::string(NewValue);
 }
 
+bool VariantValue::isNodeKind() const { return Type == VT_NodeKind; }
+
+const ASTNodeKind &VariantValue::getNodeKind() const {
+  assert(isNodeKind());
+  return *Value.NodeKind;
+}
+
+void VariantValue::setNodeKind(ASTNodeKind NewValue) {
+  reset();
+  Type = VT_NodeKind;
+  Value.NodeKind = new ASTNodeKind(NewValue);
+}
+
 bool VariantValue::isMatcher() const {
   return Type == VT_Matcher;
 }
@@ -449,6 +472,8 @@
   case VT_Boolean: return "Boolean";
   case VT_Double: return "Double";
   case VT_Unsigned: return "Unsigned";
+  case VT_NodeKind:
+return getNodeKind().asStringRef().str();
   case VT_Nothing: return "Nothing";
   }
   llvm_unreachable("Invalid Type");
Index: clang/include/clang/ASTMatchers/Dynamic/VariantValue.h
===
--- clang/include/clang/ASTMatchers/Dynamic/VariantValue.h
+++ clang/include/clang/ASTMatchers/Dynamic/VariantValue.h
@@ -251,6 +251,7 @@
   VariantValue(double Double);
   VariantValue(unsigned Unsigned);
   VariantValue(StringRef String);
+  VariantValue(ASTNodeKind NodeKind);
   VariantValue(const VariantMatcher &Matchers);
 
   /// Constructs an \c unsigned value (disambiguation from bool).
@@ -280,6 +281,10 @@
   const std::string &getString() const;
   void setString(StringRef String);
 
+  bool isNodeKind() const;
+  const ASTNodeKind &getNodeKind() const;
+  void setNodeKind(ASTNodeKind NodeKind);
+
   /// Matcher value functions.
   bool isMatcher() const;
   const VariantMatcher &getMatcher() const;
@@ -316,7 +321,8 @@
 VT_Double,
 VT_Unsigned,
 VT_String,
-VT_Matcher
+VT_Matcher,
+VT_NodeKind
   };
 
   /// All supported value types.
@@ -326,6 +332,7 @@
 bool Boolean;
 std::string *String;
 VariantMatcher *Matcher;
+ASTNodeKind *NodeKind;
   };
 
   ValueType Type;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D94177: [analyze] Add better support for leaks (and similar diagnostics)

2021-01-20 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

For the record, please rename this revision to have the `analyzer` tag.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94177

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


[clang] e377c8e - Implement dynamic mapAnyOf in terms of ASTNodeKinds

2021-01-20 Thread Stephen Kelly via cfe-commits

Author: Stephen Kelly
Date: 2021-01-20T15:53:05Z
New Revision: e377c8eeb4aa2eb239a651f1fe12c27fc77deda3

URL: 
https://github.com/llvm/llvm-project/commit/e377c8eeb4aa2eb239a651f1fe12c27fc77deda3
DIFF: 
https://github.com/llvm/llvm-project/commit/e377c8eeb4aa2eb239a651f1fe12c27fc77deda3.diff

LOG: Implement dynamic mapAnyOf in terms of ASTNodeKinds

This reduces template bloat, but more importantly, makes it possible to
construct one from clang-query without template types.

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

Added: 


Modified: 
clang/lib/ASTMatchers/Dynamic/Marshallers.h

Removed: 




diff  --git a/clang/lib/ASTMatchers/Dynamic/Marshallers.h 
b/clang/lib/ASTMatchers/Dynamic/Marshallers.h
index 23e26dcd9db6..690b52162e2b 100644
--- a/clang/lib/ASTMatchers/Dynamic/Marshallers.h
+++ b/clang/lib/ASTMatchers/Dynamic/Marshallers.h
@@ -925,32 +925,50 @@ class VariadicOperatorMatcherDescriptor : public 
MatcherDescriptor {
   const StringRef MatcherName;
 };
 
-template 
 class MapAnyOfMatcherDescriptor : public MatcherDescriptor {
-  std::vector Funcs;
+  ASTNodeKind CladeNodeKind;
+  std::vector NodeKinds;
 
 public:
-  MapAnyOfMatcherDescriptor(StringRef MatcherName)
-  : Funcs{DynCastAllOfMatcherDescriptor(
-ast_matchers::internal::VariadicDynCastAllOfMatcher{},
-MatcherName)...} {}
+  MapAnyOfMatcherDescriptor(ASTNodeKind CladeNodeKind,
+std::vector NodeKinds)
+  : CladeNodeKind(CladeNodeKind), NodeKinds(NodeKinds) {}
 
   VariantMatcher create(SourceRange NameRange, ArrayRef Args,
 Diagnostics *Error) const override {
-std::vector InnerArgs;
 
-for (auto const &F : Funcs) {
-  InnerArgs.push_back(F.create(NameRange, Args, Error));
-  if (!Error->errors().empty())
-return {};
+std::vector NodeArgs;
+
+for (auto NK : NodeKinds) {
+  std::vector InnerArgs;
+
+  for (const auto &Arg : Args) {
+if (!Arg.Value.isMatcher())
+  return {};
+const VariantMatcher &VM = Arg.Value.getMatcher();
+if (VM.hasTypedMatcher(NK)) {
+  auto DM = VM.getTypedMatcher(NK);
+  InnerArgs.push_back(DM);
+}
+  }
+
+  if (InnerArgs.empty()) {
+NodeArgs.push_back(
+DynTypedMatcher::trueMatcher(NK).dynCastTo(CladeNodeKind));
+  } else {
+NodeArgs.push_back(
+DynTypedMatcher::constructVariadic(
+ast_matchers::internal::DynTypedMatcher::VO_AllOf, NK,
+InnerArgs)
+.dynCastTo(CladeNodeKind));
+  }
 }
-return VariantMatcher::SingleMatcher(
-ast_matchers::internal::BindableMatcher(
-VariantMatcher::VariadicOperatorMatcher(
-ast_matchers::internal::DynTypedMatcher::VO_AnyOf,
-std::move(InnerArgs))
-.getTypedMatcher()));
+
+auto Result = DynTypedMatcher::constructVariadic(
+ast_matchers::internal::DynTypedMatcher::VO_AnyOf, CladeNodeKind,
+NodeArgs);
+Result.setAllowBind(true);
+return VariantMatcher::SingleMatcher(Result);
   }
 
   bool isVariadic() const override { return true; }
@@ -963,9 +981,11 @@ class MapAnyOfMatcherDescriptor : public MatcherDescriptor 
{
 
   bool isConvertibleTo(ASTNodeKind Kind, unsigned *Specificity,
ASTNodeKind *LeastDerivedKind) const override {
-return llvm::all_of(Funcs, [=](const auto &F) {
-  return F.isConvertibleTo(Kind, Specificity, LeastDerivedKind);
-});
+if (Specificity)
+  *Specificity = 1;
+if (LeastDerivedKind)
+  *LeastDerivedKind = CladeNodeKind;
+return true;
   }
 };
 
@@ -1077,8 +1097,9 @@ template 
 std::unique_ptr makeMatcherAutoMarshall(
 ast_matchers::internal::MapAnyOfMatcherImpl,
 StringRef MatcherName) {
-  return std::make_unique>(
-  MatcherName);
+  return std::make_unique(
+  ASTNodeKind::getFromNodeKind(),
+  std::vector{ASTNodeKind::getFromNodeKind()...});
 }
 
 } // namespace internal



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


[PATCH] D94879: Implement dynamic mapAnyOf in terms of ASTNodeKinds

2021-01-20 Thread Stephen Kelly via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe377c8eeb4aa: Implement dynamic mapAnyOf in terms of 
ASTNodeKinds (authored by stephenkelly).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94879

Files:
  clang/lib/ASTMatchers/Dynamic/Marshallers.h


Index: clang/lib/ASTMatchers/Dynamic/Marshallers.h
===
--- clang/lib/ASTMatchers/Dynamic/Marshallers.h
+++ clang/lib/ASTMatchers/Dynamic/Marshallers.h
@@ -925,32 +925,50 @@
   const StringRef MatcherName;
 };
 
-template 
 class MapAnyOfMatcherDescriptor : public MatcherDescriptor {
-  std::vector Funcs;
+  ASTNodeKind CladeNodeKind;
+  std::vector NodeKinds;
 
 public:
-  MapAnyOfMatcherDescriptor(StringRef MatcherName)
-  : Funcs{DynCastAllOfMatcherDescriptor(
-ast_matchers::internal::VariadicDynCastAllOfMatcher{},
-MatcherName)...} {}
+  MapAnyOfMatcherDescriptor(ASTNodeKind CladeNodeKind,
+std::vector NodeKinds)
+  : CladeNodeKind(CladeNodeKind), NodeKinds(NodeKinds) {}
 
   VariantMatcher create(SourceRange NameRange, ArrayRef Args,
 Diagnostics *Error) const override {
-std::vector InnerArgs;
 
-for (auto const &F : Funcs) {
-  InnerArgs.push_back(F.create(NameRange, Args, Error));
-  if (!Error->errors().empty())
-return {};
+std::vector NodeArgs;
+
+for (auto NK : NodeKinds) {
+  std::vector InnerArgs;
+
+  for (const auto &Arg : Args) {
+if (!Arg.Value.isMatcher())
+  return {};
+const VariantMatcher &VM = Arg.Value.getMatcher();
+if (VM.hasTypedMatcher(NK)) {
+  auto DM = VM.getTypedMatcher(NK);
+  InnerArgs.push_back(DM);
+}
+  }
+
+  if (InnerArgs.empty()) {
+NodeArgs.push_back(
+DynTypedMatcher::trueMatcher(NK).dynCastTo(CladeNodeKind));
+  } else {
+NodeArgs.push_back(
+DynTypedMatcher::constructVariadic(
+ast_matchers::internal::DynTypedMatcher::VO_AllOf, NK,
+InnerArgs)
+.dynCastTo(CladeNodeKind));
+  }
 }
-return VariantMatcher::SingleMatcher(
-ast_matchers::internal::BindableMatcher(
-VariantMatcher::VariadicOperatorMatcher(
-ast_matchers::internal::DynTypedMatcher::VO_AnyOf,
-std::move(InnerArgs))
-.getTypedMatcher()));
+
+auto Result = DynTypedMatcher::constructVariadic(
+ast_matchers::internal::DynTypedMatcher::VO_AnyOf, CladeNodeKind,
+NodeArgs);
+Result.setAllowBind(true);
+return VariantMatcher::SingleMatcher(Result);
   }
 
   bool isVariadic() const override { return true; }
@@ -963,9 +981,11 @@
 
   bool isConvertibleTo(ASTNodeKind Kind, unsigned *Specificity,
ASTNodeKind *LeastDerivedKind) const override {
-return llvm::all_of(Funcs, [=](const auto &F) {
-  return F.isConvertibleTo(Kind, Specificity, LeastDerivedKind);
-});
+if (Specificity)
+  *Specificity = 1;
+if (LeastDerivedKind)
+  *LeastDerivedKind = CladeNodeKind;
+return true;
   }
 };
 
@@ -1077,8 +1097,9 @@
 std::unique_ptr makeMatcherAutoMarshall(
 ast_matchers::internal::MapAnyOfMatcherImpl,
 StringRef MatcherName) {
-  return std::make_unique>(
-  MatcherName);
+  return std::make_unique(
+  ASTNodeKind::getFromNodeKind(),
+  std::vector{ASTNodeKind::getFromNodeKind()...});
 }
 
 } // namespace internal


Index: clang/lib/ASTMatchers/Dynamic/Marshallers.h
===
--- clang/lib/ASTMatchers/Dynamic/Marshallers.h
+++ clang/lib/ASTMatchers/Dynamic/Marshallers.h
@@ -925,32 +925,50 @@
   const StringRef MatcherName;
 };
 
-template 
 class MapAnyOfMatcherDescriptor : public MatcherDescriptor {
-  std::vector Funcs;
+  ASTNodeKind CladeNodeKind;
+  std::vector NodeKinds;
 
 public:
-  MapAnyOfMatcherDescriptor(StringRef MatcherName)
-  : Funcs{DynCastAllOfMatcherDescriptor(
-ast_matchers::internal::VariadicDynCastAllOfMatcher{},
-MatcherName)...} {}
+  MapAnyOfMatcherDescriptor(ASTNodeKind CladeNodeKind,
+std::vector NodeKinds)
+  : CladeNodeKind(CladeNodeKind), NodeKinds(NodeKinds) {}
 
   VariantMatcher create(SourceRange NameRange, ArrayRef Args,
 Diagnostics *Error) const override {
-std::vector InnerArgs;
 
-for (auto const &F : Funcs) {
-  InnerArgs.push_back(F.create(NameRange, Args, Error));
-  if (!Error->errors().empty())
-return {};
+std::vector NodeArgs;
+
+for (auto NK : NodeKinds) {
+  std::vector InnerArgs;
+
+  for (const auto &Arg : Args) {
+if (!Arg.Value.isMatcher())
+  return {};
+const VariantMatcher &VM 

[PATCH] D93525: [OpenMP] Add unbundling of archives containing bundled object files into device specific archives

2021-01-20 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

> At the moment this patch defines compatibility as exact string match of 
> bundler entry ID.
> [...]
> Supporting target ID requires little more work and discussion.

Let's get this in first, then revisit target ID support as we need it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93525

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


[PATCH] D94865: [ASTMatchers] Add callOrConstruct matcher

2021-01-20 Thread Stephen Kelly via Phabricator via cfe-commits
steveire added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2867
+extern const internal::MapAnyOfMatcher
+callOrConstruct;
+

aaron.ballman wrote:
> steveire wrote:
> > aaron.ballman wrote:
> > > I'm not super keen on this name. It's certainly descriptive, but I do 
> > > wonder if it's a bit too specific and should perhaps be something more 
> > > like `callableExpr()`, `callLikeExpr()`, or something more generic. For 
> > > instance, I could imagine wanting this to match on something like:
> > > ```
> > > struct S {
> > >   void setter(int val) {}
> > >   __declspec(property(put = setter)) int x;
> > > };
> > > 
> > > int main() {
> > >   S s;
> > >   s.x = 12; // Match here
> > >   // Because the above code actually does this:
> > >   // s.setter(12);
> > > }
> > > ```
> > > because this also has an expression that isn't really a call (as far as 
> > > our AST is concerned) but is a call as far as program semantics are 
> > > concerned. I'm not suggesting to make the matcher support that right now 
> > > (unless you felt like doing it), but thinking about the future and 
> > > avoiding a name that may paint us into a corner.
> > > 
> > > WDYT about using a more generic name?
> > I haven't seen code like that before (ms extension?) 
> > https://godbolt.org/z/anvd43 but I think that should be matched by 
> > `binaryOperator` instead. That already matches based on what the code looks 
> > like, rather than what it is in the AST.
> > 
> > This `callOrConstruct` is really for using `hasArgument` and related 
> > submatchers with nodes which support it. As such I think the name is fine. 
> > I don't like `callableExpr` or `callLikeExpr` because they don't bring to 
> > mind the possibility that construction is also supported.
> > I haven't seen code like that before (ms extension?)
> 
> Yes, it's an MS extension.
> 
> > That already matches based on what the code looks like, rather than what it 
> > is in the AST.
> 
> Yes, but these are AST matchers, so it's reasonable to match on what's in the 
> AST (as well as what the code looks like, of course). I'm not arguing it 
> needs to be supported so much as pointing out that there are other AST nodes 
> this notionally applies to where the name is a bit too specific.
> 
> > This callOrConstruct is really for using hasArgument and related 
> > submatchers with nodes which support it. As such I think the name is fine. 
> > I don't like callableExpr or callLikeExpr because they don't bring to mind 
> > the possibility that construction is also supported.
> 
> I'm pretty sure we've extended what `hasArgument` can be applied to in the 
> past (but I've not verified), so the part that worries me is specifically 
> naming the nodes as part of the identifier. This effectively means that if we 
> ever find another AST node for `hasArgument`, we either need a different API 
> like `callConstructOrWhatever` or we're stuck with a poor name.
> 
> Another (smaller) concern with the name is that `callOrConstruct` can 
> describe declarations as well as expressions, to some degree as you can 
> declare calls and constructors. It's a smaller concern because those at least 
> share a common base class. `callOrConstructExpr` would clarify this easily 
> enough.
> 
> I see you added `ObjCMessageExpr` as well, thank you for that! It's a perhaps 
> better example of why this name feels awkward to me. In ObjC, you don't call 
> an `ObjCMessageExpr`, you "send" it to the given object or class. That 
> suggests to me that `callableExpr` or `callLikeExpr` is also not a great name 
> either.
> 
> Perhaps `executableExpr` because you're executing some code?
> Perhaps `executableExpr` because you're executing some code?

The thing that this really does is make it possible to use `hasArgument` and 
related matchers with the nodes that that matcher supports. So, something with 
`argument` in the name probably makes sense. Like `argumentExpr`. 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94865

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


[PATCH] D86465: [analyzer][solver] Redesign constraint ranges data structure

2021-01-20 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.

My propositions for the function `negate`.




Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:421
+  ContainerType Result;
+  Result.reserve(What.getMinValue() == MIN ? What.size() + 1 : What.size());
 

Here you can reuse `SampleValue` and simplify a bit this snippet.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:433-434
+if (To == MAX) {
+  Result.insert(Result.end(), What.begin(), What.end());
+  return makePersistent(std::move(Result));
+}

Here you can just move `What`. And after that you can do `Result.reserve`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86465

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


[PATCH] D94941: Add minor version to libclang.so and libclang-cpp.so SONAME

2021-01-20 Thread Sylvestre Ledru via Phabricator via cfe-commits
sylvestre.ledru added a comment.

I might be wrong but if the ABI is incompatible, are we not supposed to update 
the SONAME itself?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94941

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


[PATCH] D93525: [OpenMP] Add unbundling of archives containing bundled object files into device specific archives

2021-01-20 Thread Tony Tye via Phabricator via cfe-commits
t-tye requested changes to this revision.
t-tye added a comment.
This revision now requires changes to proceed.

In D93525#2509796 , @jdoerfert wrote:

>> At the moment this patch defines compatibility as exact string match of 
>> bundler entry ID.
>> [...]
>> Supporting target ID requires little more work and discussion.
>
> Let's get this in first, then revisit target ID support as we need it.

I do not think this patch should ignore target ID as that is now upstreamed and 
documented. What is involved in correcting the compatibility test to be correct 
by the target ID rules? There are examples of doing this in all the runtimes 
and I can help if that is useful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93525

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


[PATCH] D94941: Add minor version to libclang.so and libclang-cpp.so SONAME

2021-01-20 Thread Tom Stellard via Phabricator via cfe-commits
tstellar added a comment.

In D94941#2509829 , @sylvestre.ledru 
wrote:

> I might be wrong but if the ABI is incompatible, are we not supposed to 
> update the SONAME itself?

That's what this patch does, it updates the SONAME from *-11 to *-11.1.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94941

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


[PATCH] D94941: Add minor version to libclang.so and libclang-cpp.so SONAME

2021-01-20 Thread Sylvestre Ledru via Phabricator via cfe-commits
sylvestre.ledru added a comment.

Yeah, my question is more "is that enough for distro?"
https://www.debian.org/doc/manuals/maint-guide/advanced.en.html
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html

I might be wrong but if 11.1 and 11.0 aren't compatible (not just adding a new 
function), I was wondering if if should not be 12 (I know it is terrible).
Maybe we can expect that packagers will know that 11.1 is like a 12 in term of 
soname


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94941

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


[PATCH] D94941: Add minor version to libclang.so and libclang-cpp.so SONAME

2021-01-20 Thread Josh Stone via Phabricator via cfe-commits
cuviper added a comment.

If the SONAME is different in any way, it is totally distinct to the dynamic 
linker. There's no semver parsing or anything like that. That's all we can do 
from a technical perspective, and the rest is just communication in the release.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94941

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


[PATCH] D93222: [RFC][analyzer] Introduce MacroExpansionContext to libAnalysis

2021-01-20 Thread Gabor Marton via Phabricator via cfe-commits
martong accepted this revision.
martong added a comment.
This revision is now accepted and ready to land.

Nice work! Thanks!




Comment at: clang/lib/Analysis/MacroExpansionContext.cpp:210
+}
\ No newline at end of file


Missing newline?



Comment at: clang/lib/Analysis/MacroExpansionContext.cpp:39
+
+  SourceLocation ExpansionEnd = [Range, &SM = SM, &MacroName] {
+// If the range is empty, use the length of the macro.

steakhal wrote:
> xazax.hun wrote:
> > martong wrote:
> > > ?
> > Why do you need the assignment in `&SM = SM`?
> `SM` is an object member.
> The lambda should either capture the `this` pointer or a pointer/reference to 
> the referred member (`SM`).
> I preferred the latter as the lambda doesn't want to access all of the 
> members except this one.
`[Range, &SM,  &MacroName]` would not work? (why?)


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

https://reviews.llvm.org/D93222

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


[PATCH] D95031: [clangd] Log warning when using legacy (theia) semantic highlighting.

2021-01-20 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a comment.

Thanks for the heads up! It would be nice to get D77702 
 landed before the removal of 
`TheiaSemanticHighlighting`. I'll try to find some time to rebase it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95031

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


[PATCH] D95053: [Demangle] Support demangling Swift calling convention in MS demangler.

2021-01-20 Thread Varun Gandhi via Phabricator via cfe-commits
varungandhi-apple created this revision.
varungandhi-apple added a reviewer: compnerd.
Herald added a subscriber: hiraditya.
varungandhi-apple requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Previously, Clang was able to mangle the Swift calling
convention but 'MicrosoftDemangle.cpp' was not able to demangle it.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95053

Files:
  clang/lib/AST/MicrosoftMangle.cpp
  llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h
  llvm/lib/Demangle/MicrosoftDemangle.cpp
  llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
  llvm/test/Demangle/ms-mangle.test


Index: llvm/test/Demangle/ms-mangle.test
===
--- llvm/test/Demangle/ms-mangle.test
+++ llvm/test/Demangle/ms-mangle.test
@@ -338,6 +338,9 @@
 ?vector_func@@YQXXZ
 ; CHECK: void __vectorcall vector_func(void)
 
+?swift_func@@YSXXZ
+; CHECK: void __attribute__((__swiftcall__))swift_func(void)
+
 ??$fn_tmpl@$1?extern_c_func@@YAXXZ@@YAXXZ
 ; CHECK: void __cdecl fn_tmpl<&void __cdecl extern_c_func(void)>(void)
 
Index: llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
===
--- llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
+++ llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
@@ -107,6 +107,9 @@
   case CallingConv::Clrcall:
 OS << "__clrcall";
 break;
+  case CallingConv::Swift:
+OS << "__attribute__((__swiftcall__))";
+break;
   default:
 break;
   }
Index: llvm/lib/Demangle/MicrosoftDemangle.cpp
===
--- llvm/lib/Demangle/MicrosoftDemangle.cpp
+++ llvm/lib/Demangle/MicrosoftDemangle.cpp
@@ -1711,6 +1711,8 @@
 return CallingConv::Eabi;
   case 'Q':
 return CallingConv::Vectorcall;
+  case 'S':
+return CallingConv::Swift;
   }
 
   return CallingConv::None;
Index: llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h
===
--- llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h
+++ llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h
@@ -67,6 +67,7 @@
   Eabi,
   Vectorcall,
   Regcall,
+  Swift, // Clang-only
 };
 
 enum class ReferenceKind : uint8_t { None, LValueRef, RValueRef };
Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -2695,6 +2695,7 @@
   //  ::= I # __fastcall
   //  ::= J # __export __fastcall
   //  ::= Q # __vectorcall
+  //  ::= S # __attribute__((__swiftcall__)) // Clang-only
   //  ::= w # __regcall
   // The 'export' calling conventions are from a bygone era
   // (*cough*Win16*cough*) when functions were declared for export with


Index: llvm/test/Demangle/ms-mangle.test
===
--- llvm/test/Demangle/ms-mangle.test
+++ llvm/test/Demangle/ms-mangle.test
@@ -338,6 +338,9 @@
 ?vector_func@@YQXXZ
 ; CHECK: void __vectorcall vector_func(void)
 
+?swift_func@@YSXXZ
+; CHECK: void __attribute__((__swiftcall__))swift_func(void)
+
 ??$fn_tmpl@$1?extern_c_func@@YAXXZ@@YAXXZ
 ; CHECK: void __cdecl fn_tmpl<&void __cdecl extern_c_func(void)>(void)
 
Index: llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
===
--- llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
+++ llvm/lib/Demangle/MicrosoftDemangleNodes.cpp
@@ -107,6 +107,9 @@
   case CallingConv::Clrcall:
 OS << "__clrcall";
 break;
+  case CallingConv::Swift:
+OS << "__attribute__((__swiftcall__))";
+break;
   default:
 break;
   }
Index: llvm/lib/Demangle/MicrosoftDemangle.cpp
===
--- llvm/lib/Demangle/MicrosoftDemangle.cpp
+++ llvm/lib/Demangle/MicrosoftDemangle.cpp
@@ -1711,6 +1711,8 @@
 return CallingConv::Eabi;
   case 'Q':
 return CallingConv::Vectorcall;
+  case 'S':
+return CallingConv::Swift;
   }
 
   return CallingConv::None;
Index: llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h
===
--- llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h
+++ llvm/include/llvm/Demangle/MicrosoftDemangleNodes.h
@@ -67,6 +67,7 @@
   Eabi,
   Vectorcall,
   Regcall,
+  Swift, // Clang-only
 };
 
 enum class ReferenceKind : uint8_t { None, LValueRef, RValueRef };
Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -2695,6 +2695,7 @@
   //  ::= I # __fastcall
   //  ::= J # __export __fastcall
   //  ::= Q # __vector

[PATCH] D94941: Add minor version to libclang.so and libclang-cpp.so SONAME

2021-01-20 Thread Sylvestre Ledru via Phabricator via cfe-commits
sylvestre.ledru accepted this revision.
sylvestre.ledru added a comment.
This revision is now accepted and ready to land.

Let's do it then :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94941

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


[PATCH] D94941: Add minor version to libclang.so and libclang-cpp.so SONAME

2021-01-20 Thread Sylvestre Ledru via Phabricator via cfe-commits
sylvestre.ledru added a comment.

I guess this will be clearly mentioned in the release notes :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94941

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


[PATCH] D93224: [RFC][analyzer] Use the MacroExpansionContext for macro expansions in plists

2021-01-20 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

In D93224#2497632 , @steakhal wrote:

> It seems quite a challenge to hook the `Preprocessor` for all possible 
> configurations for every `CompilerInvocation`.
> The underlying machinery is somewhat complex and spaghetti to me.
>
> Here is what I suggest:
> For now, this expansion is better than the previous was. Macro expansions 
> will work for the main TU even in any CTU configuration. For the imported 
> TUs, it will just not expand any macros.
> This is a regression in some way, but we should live with that until we 
> implement it completely.
> I think the users would prefer a non-crashing partial implementation to a 
> crashing one.
>
> If you think it's an appropriate, I will update the CTU tests to expect no 
> macro expansion in any imported TU.
> And also remove the `XFAIL`.
> This way we could still target clang-12.
>
> Do you think it's acceptable?
> @xazax.hun @NoQ

Sounds good to me!


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

https://reviews.llvm.org/D93224

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


[PATCH] D94786: [clang][ASTImporter] Add support for importing CXXFoldExpr.

2021-01-20 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 317894.
balazske added a comment.

Removed use of `auto`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94786

Files:
  clang/lib/AST/ASTImporter.cpp
  clang/unittests/AST/ASTImporterTest.cpp


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -639,6 +639,38 @@
   hasUnqualifiedDesugaredType(constantArrayType(hasSize(7));
 }
 
+const internal::VariadicDynCastAllOfMatcher cxxFoldExpr;
+
+AST_MATCHER_P(CXXFoldExpr, hasOperator, BinaryOperatorKind, Op) {
+  return Node.getOperator() == Op;
+}
+AST_MATCHER(CXXFoldExpr, hasInit) { return Node.getInit(); }
+AST_MATCHER(CXXFoldExpr, isRightFold) { return Node.isRightFold(); }
+AST_MATCHER(CXXFoldExpr, isLeftFold) { return Node.isLeftFold(); }
+
+TEST_P(ImportExpr, ImportCXXFoldExpr) {
+  auto Match1 =
+  cxxFoldExpr(hasOperator(BO_Add), isLeftFold(), unless(hasInit()));
+  auto Match2 = cxxFoldExpr(hasOperator(BO_Sub), isLeftFold(), hasInit());
+  auto Match3 =
+  cxxFoldExpr(hasOperator(BO_Mul), isRightFold(), unless(hasInit()));
+  auto Match4 = cxxFoldExpr(hasOperator(BO_Div), isRightFold(), hasInit());
+
+  MatchVerifier Verifier;
+  testImport("template "
+ "void declToImport(Ts... args) {"
+ "  const int i1 = (... + args);"
+ "  const int i2 = (1 - ... - args);"
+ "  const int i3 = (args * ...);"
+ "  const int i4 = (args / ... / 1);"
+ "};"
+ "void g() { declToImport(1, 2, 3, 4, 5); }",
+ Lang_CXX17, "", Lang_CXX17, Verifier,
+ functionTemplateDecl(hasDescendant(Match1), hasDescendant(Match2),
+  hasDescendant(Match3),
+  hasDescendant(Match4)));
+}
+
 /// \brief Matches __builtin_types_compatible_p:
 /// GNU extension to check equivalent types
 /// Given
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -644,6 +644,7 @@
 ExpectedStmt 
VisitSubstNonTypeTemplateParmExpr(SubstNonTypeTemplateParmExpr *E);
 ExpectedStmt VisitTypeTraitExpr(TypeTraitExpr *E);
 ExpectedStmt VisitCXXTypeidExpr(CXXTypeidExpr *E);
+ExpectedStmt VisitCXXFoldExpr(CXXFoldExpr *E);
 
 template
 Error ImportArrayChecked(IIter Ibegin, IIter Iend, OIter Obegin) {
@@ -8011,6 +8012,25 @@
   *ToTypeOrErr, *ToExprOperandOrErr, *ToSourceRangeOrErr);
 }
 
+ExpectedStmt ASTNodeImporter::VisitCXXFoldExpr(CXXFoldExpr *E) {
+  Error Err = Error::success();
+
+  QualType ToType = importChecked(Err, E->getType());
+  UnresolvedLookupExpr *ToCallee = importChecked(Err, E->getCallee());
+  SourceLocation ToLParenLoc = importChecked(Err, E->getLParenLoc());
+  Expr *ToLHS = importChecked(Err, E->getLHS());
+  SourceLocation ToEllipsisLoc = importChecked(Err, E->getEllipsisLoc());
+  Expr *ToRHS = importChecked(Err, E->getRHS());
+  SourceLocation ToRParenLoc = importChecked(Err, E->getRParenLoc());
+
+  if (Err)
+return std::move(Err);
+
+  return new (Importer.getToContext())
+  CXXFoldExpr(ToType, ToCallee, ToLParenLoc, ToLHS, E->getOperator(),
+  ToEllipsisLoc, ToRHS, ToRParenLoc, E->getNumExpansions());
+}
+
 Error ASTNodeImporter::ImportOverriddenMethods(CXXMethodDecl *ToMethod,
CXXMethodDecl *FromMethod) {
   Error ImportErrors = Error::success();


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -639,6 +639,38 @@
   hasUnqualifiedDesugaredType(constantArrayType(hasSize(7));
 }
 
+const internal::VariadicDynCastAllOfMatcher cxxFoldExpr;
+
+AST_MATCHER_P(CXXFoldExpr, hasOperator, BinaryOperatorKind, Op) {
+  return Node.getOperator() == Op;
+}
+AST_MATCHER(CXXFoldExpr, hasInit) { return Node.getInit(); }
+AST_MATCHER(CXXFoldExpr, isRightFold) { return Node.isRightFold(); }
+AST_MATCHER(CXXFoldExpr, isLeftFold) { return Node.isLeftFold(); }
+
+TEST_P(ImportExpr, ImportCXXFoldExpr) {
+  auto Match1 =
+  cxxFoldExpr(hasOperator(BO_Add), isLeftFold(), unless(hasInit()));
+  auto Match2 = cxxFoldExpr(hasOperator(BO_Sub), isLeftFold(), hasInit());
+  auto Match3 =
+  cxxFoldExpr(hasOperator(BO_Mul), isRightFold(), unless(hasInit()));
+  auto Match4 = cxxFoldExpr(hasOperator(BO_Div), isRightFold(), hasInit());
+
+  MatchVerifier Verifier;
+  testImport("template "
+ "void declToImport(Ts... args) {"
+ "  const int i1 = (... + args);"
+ "  const int i2 = (1 - ... - args);"
+ "  const int i3 

[PATCH] D93525: [OpenMP] Add unbundling of archives containing bundled object files into device specific archives

2021-01-20 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D93525#2509836 , @t-tye wrote:

> In D93525#2509796 , @jdoerfert wrote:
>
>>> At the moment this patch defines compatibility as exact string match of 
>>> bundler entry ID.
>>> [...]
>>> Supporting target ID requires little more work and discussion.
>>
>> Let's get this in first, then revisit target ID support as we need it.
>
> I do not think this patch should ignore target ID as that is now upstreamed 
> and documented. What is involved in correcting the compatibility test to be 
> correct by the target ID rules? There are examples of doing this in all the 
> runtimes and I can help if that is useful.

First, there is no reason not to have multiple patches as long as they are self 
contained and testable. Arguably, smaller patches are better.

That said, target ID is a new feature and, as discussed in the OpenMP call 
today, there is a chance we have to revisit this to support more involved 
information. As this discussion is open ended (and hasn't started yet), it 
seems absolutely sensible to continue with a tested and working patch that 
provides features we need for sure instead of forcing some support of a feature 
we don't use right now anyway.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93525

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


[PATCH] D93922: Mangle `__alignof__` differently than `alignof`.

2021-01-20 Thread James Y Knight via Phabricator via cfe-commits
jyknight added a comment.

Was the "group" libc++abi accept intended to be an accept for the whole 
revision? Or should still ping for review from rsmith or someone else?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93922

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


[PATCH] D93747: Rename debug linkage name with -funique-internal-linkage-names

2021-01-20 Thread Wenlei He via Phabricator via cfe-commits
wenlei added a subscriber: lxfind.
wenlei added a comment.

In D93747#2475852 , @dblaikie wrote:

> In D93747#2470504 , @hoy wrote:
>
>> In D93747#2470387 , @dblaikie wrote:
>>
>>> Please remove the clang test change - if this is an LLVM change with LLVM 
>>> test coverage, that's enough. (we don't generally test every LLVM change 
>>> from both LLVM and Clang)
>>
>> Sounds good.
>>
>>> I'd still be curious if you could look around to see whether there are 
>>> other cases of function splitting/cloning/etc to see how they deal with 
>>> updating the DISubprograms, to see if there's some prior art that should be 
>>> used here.
>>
>> To the best of my knowledge, existing code does not change the linkage name 
>> field of a DISubprogram once created. You can create a new DISubprogram 
>> record with any linkage name you want but bear in mind how the debugger will 
>> consume the record. Looks like we are the first one to change existing 
>> record which will confuse the debugger.
>
> Sure enough - do any other transforms have similar requirements (of creating 
> a record for something that looks like the same function but isn't quite) but 
> take a different approach? Be good to know if other approaches were 
> chosen/how/why they are applicable there but not here, etc. (conversely 
> perhaps other passes worked around the issue in less than ideal ways and 
> could benefit from using this new approach).
>
> Looks like some places that could use this functionality aren't quite there 
> yet - 
> The Attributor has an internalizing feature (added in 
> 87a85f3d57f55f5652ec44f77816c7c9457545fa 
>  ) that 
> produces invalid IR (ends up with two !dbg attachments of the same 
> DISubprogram) if the function it's internalizing has a DISubprogram - but if 
> it succeeded it'd have the same problem that the linkage name on the 
> DISubprogram wouldn't match the actual symbol/function name. (@jdoerfert 
> @bbn).
> The IR Outliner (@AndrewLitteken ) seems to be only a few months old and 
> appears to have no debug info handling - probably results in the same problem.
> The Partial Inliner does clone a function into a new name & so would have an 
> invalid DISubprogram, though it only uses the clone for inlining (this 
> probably then goes on to produce the desired debug info, where the inlining 
> appears to come from the original function)
> ThinLTO does some function cloning within a module for aliases, but it then 
> renames the clone to the aliasees name so I think the name works out to match 
> again.

Another place where mismatch between linkage name and DISubprogram happens is 
the cloning for coroutines (.resume, .destroy and cleanup funclets). We found 
that out again through different kind of AutoFDO profile fidelity issue (cc: 
@lxfind).

> If this is an invariant, that the linkage name on the DISubprogram should 
> match the actual llvm::Function name (@aprantl @JDevlieghere - verifier 
> check, perhaps?) - it'd be nice to make that more reliable, either by 
> removing the name and relying on the llvm::Function name (perhaps with a 
> boolean on the DISubprogram as to whether the linkage name should be emitted 
> or not - I think currently Clang's IRGen makes choices about which 
> DISubprograms will get linkage names) or a verifier and utilities to keep 
> them in sync.

Agreed, clarity on the rules and sanity check built into verifier would be 
beneficial.

> But I'll leave that alone for now/for this review, unless someone else wants 
> to chime in on it.
>
> In D93747#2470178 , @tmsriram wrote:
>
>> In D93747#2469556 , @hoy wrote:
>>
 In D93656 , @dblaikie wrote:
 Though the C case is interesting - it means you'll end up with C functions 
 with the same DWARF 'name' but different linkage name. I don't know what 
 that'll do to DWARF consumers - I guess they'll probably be OK-ish with 
 it, as much as they are with C++ overloading. I think there are some cases 
 of C name mangling so it's probably supported/OK-ish with DWARF Consumers. 
 Wouldn't hurt for you to take a look/see what happens in that case with a 
 debugger like gdb/check other cases of C name mangling to see what DWARF 
 they end up creating (with both GCC and Clang).
>>>
>>> I did a quick experiment with C name managing with GCC and -flto. It turns 
>>> out the `DW_AT_linkage_name` field of `DW_TAG_subprogram` is never set for 
>>> C programs. If set, the gdb debugger will use that field to match the user 
>>> input and set breakpoints. Therefore, giving `DW_AT_linkage_name` a 
>>> uniquefied name prevents the debugger from setting a breakpoint based on 
>>> source names unless the user specifies a dec

[PATCH] D95055: [clang] Don't look into for C++ headers if they are found alongside the toolchain

2021-01-20 Thread Louis Dionne via Phabricator via cfe-commits
ldionne created this revision.
ldionne added reviewers: tstellar, dexonsmith.
Herald added a subscriber: jkorous.
ldionne requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Currently, Clang looks for libc++ headers alongside the installation
directory of Clang, and it also adds a search path for headers in the
-isysroot. This is problematic if headers are found in both the toolchain
and in the sysroot, since #include_next will end up finding the libc++
headers in the sysroot instead of the intended system headers.

This patch changes the logic such that if the toolchain contains libc++
headers, no C++ header paths are added in the sysroot. However, if the
toolchain does *not* contain libc++ headers, the sysroot is searched as
usual.

This should not be a breaking change, since any code that previously
relied on some libc++ headers being found in the sysroot suffered from
the #include_next issue described above, which renders any libc++ header
basically useless.

This is a cherry-pick of commit a3a24316087d0e1b4db0b8fee19cdee8b7968032 
.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95055

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/Inputs/basic_darwin_sdk_usr_cxx_v1/usr/include/c++/v1/.keep
  clang/test/Driver/Inputs/basic_darwin_sdk_usr_cxx_v1/usr/lib/.keep
  clang/test/Driver/darwin-header-search-libcxx.cpp

Index: clang/test/Driver/darwin-header-search-libcxx.cpp
===
--- clang/test/Driver/darwin-header-search-libcxx.cpp
+++ clang/test/Driver/darwin-header-search-libcxx.cpp
@@ -13,39 +13,57 @@
 // RUN:   | FileCheck --check-prefix=CHECK-LIBCXX-NONE %s
 // CHECK-LIBCXX-NONE: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 
-// Check with only headers alongside the installation (those should be used,
-// but we should still add /usr/include/c++/v1 after to preserve legacy).
+// Check with only headers alongside the installation (those should be used).
 //
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
 // RUN: -target x86_64-apple-darwin \
 // RUN: -stdlib=libc++ \
 // RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain/usr/bin \
 // RUN: --sysroot="" \
-// RUN:   | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain --check-prefix=CHECK-LIBCXX-TOOLCHAIN-1 %s
+// RUN:   | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain \
+// RUN:   --check-prefix=CHECK-LIBCXX-TOOLCHAIN-1 %s
 // CHECK-LIBCXX-TOOLCHAIN-1: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 // CHECK-LIBCXX-TOOLCHAIN-1: "-internal-isystem" "[[TOOLCHAIN]]/usr/bin/../include/c++/v1"
-// CHECK-LIBCXX-TOOLCHAIN-1: "-internal-isystem" "/usr/include/c++/v1"
+// CHECK-LIBCXX-TOOLCHAIN-1-NOT: "-internal-isystem" "/usr/include/c++/v1"
 //
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
 // RUN: -target x86_64-apple-darwin \
 // RUN: -stdlib=libc++ \
 // RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain/usr/bin \
 // RUN: -isysroot %S/Inputs/basic_darwin_sdk_no_libcxx \
-// RUN:   | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain --check-prefix=CHECK-LIBCXX-TOOLCHAIN-2 %s
+// RUN:   | FileCheck -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain \
+// RUN:   -DSYSROOT=%S/Inputs/basic_darwin_sdk_no_libcxx \
+// RUN:   --check-prefix=CHECK-LIBCXX-TOOLCHAIN-2 %s
 // CHECK-LIBCXX-TOOLCHAIN-2: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
 // CHECK-LIBCXX-TOOLCHAIN-2: "-internal-isystem" "[[TOOLCHAIN]]/usr/bin/../include/c++/v1"
+// CHECK-LIBCXX-TOOLCHAIN-2-NOT: "-internal-isystem" "[[SYSROOT]]/usr/include/c++/v1"
+
+// Check with only headers in the sysroot (those should be used).
+//
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
+// RUN: -target x86_64-apple-darwin \
+// RUN: -stdlib=libc++ \
+// RUN: -ccc-install-dir %S/Inputs/basic_darwin_toolchain_no_libcxx/usr/bin \
+// RUN: -isysroot %S/Inputs/basic_darwin_sdk_usr_cxx_v1 \
+// RUN:   | FileCheck -DSYSROOT=%S/Inputs/basic_darwin_sdk_usr_cxx_v1 \
+// RUN:   -DTOOLCHAIN=%S/Inputs/basic_darwin_toolchain_no_libcxx \
+// RUN:   --check-prefix=CHECK-LIBCXX-SYSROOT-1 %s
+// CHECK-LIBCXX-SYSROOT-1: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
+// CHECK-LIBCXX-SYSROOT-1: "-internal-isystem" "[[SYSROOT]]/usr/include/c++/v1"
+// CHECK-LIBCXX-SYSROOT-1-NOT: "-internal-isystem" "[[TOOLCHAIN]]/usr/bin/../include/c++/v1"
 
 // Check with both headers in the sysroot and headers alongside the installation
-// (the headers in  should be added after the toolchain headers).
-// Ensure that both -isysroot and --sysroot work, and that isysroot has precedence.
+// (the headers in the toolchain should be preferred over the  headers).
+// Ensure that both -isysroot and --sysroot work, and that isysroot has precedence
+// over --sysroot.
 //
 // RUN: %clang -no-canonic

[PATCH] D94786: [clang][ASTImporter] Add support for importing CXXFoldExpr.

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

Thanks for the update!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94786

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


[PATCH] D95055: [clang] Don't look into for C++ headers if they are found alongside the toolchain

2021-01-20 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added a comment.

I would like to cherry-pick this change onto LLVM 11.1.0, if there is still 
time to do so. It is breaking Clang when the `sysroot` contains headers for 
libc++. Is it too late?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95055

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


[PATCH] D95057: [clangd] WIP: configurable compilation database directory

2021-01-20 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
Herald added subscribers: usaxena95, kadircet, jfb, arphaman.
sammccall requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95057

Files:
  clang-tools-extra/clangd/Config.h
  clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
  clang-tools-extra/clangd/GlobalCompilationDatabase.h

Index: clang-tools-extra/clangd/GlobalCompilationDatabase.h
===
--- clang-tools-extra/clangd/GlobalCompilationDatabase.h
+++ clang-tools-extra/clangd/GlobalCompilationDatabase.h
@@ -103,8 +103,10 @@
 // (This is more expensive to check frequently, as we check many locations).
 std::chrono::steady_clock::duration RevalidateMissingAfter =
 std::chrono::seconds(30);
+// Used to provide per-file configuration.
+std::function ContextProvider;
 // Only look for a compilation database in this one fixed directory.
-llvm::Optional CompileCommandsDir;
+llvm::Optional CompileCommandsDir; // XXX
   };
 
   DirectoryBasedGlobalCompilationDatabase(const Options &Opts);
Index: clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
===
--- clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
+++ clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "GlobalCompilationDatabase.h"
+#include "Config.h"
 #include "FS.h"
 #include "SourceCode.h"
 #include "support/Logger.h"
@@ -20,6 +21,7 @@
 #include "clang/Tooling/JSONCompilationDatabase.h"
 #include "llvm/ADT/None.h"
 #include "llvm/ADT/Optional.h"
+#include "llvm/ADT/PointerIntPair.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/ScopeExit.h"
 #include "llvm/ADT/SmallString.h"
@@ -362,6 +364,10 @@
 DirectoryBasedGlobalCompilationDatabase::
 DirectoryBasedGlobalCompilationDatabase(const Options &Opts)
 : Opts(Opts), Broadcaster(std::make_unique(*this)) {
+  if (!this->Opts.ContextProvider)
+this->Opts.ContextProvider = [](llvm::StringRef) {
+  return Context::current().clone();
+};
   if (Opts.CompileCommandsDir)
 OnlyDirCache = std::make_unique(*Opts.CompileCommandsDir);
 }
@@ -405,14 +411,6 @@
 #endif
 }
 
-static bool pathEqual(PathRef A, PathRef B) {
-#if defined(_WIN32) || defined(__APPLE__)
-  return A.equals_lower(B);
-#else
-  return A == B;
-#endif
-}
-
 std::vector
 DirectoryBasedGlobalCompilationDatabase::getDirectoryCaches(
 llvm::ArrayRef Dirs) const {
@@ -441,31 +439,42 @@
   assert(llvm::sys::path::is_absolute(Request.FileName) &&
  "path must be absolute");
 
+  std::string Storage;
+  std::vector SearchDirs;
+  if (Opts.CompileCommandsDir) // FIXME: unify this case with config.
+SearchDirs = {Opts.CompileCommandsDir.getValue()};
+  else {
+WithContext WithProvidedContext(Opts.ContextProvider(Request.FileName));
+const auto &Spec = Config::current().CompileFlags.CDBSearch;
+switch (Spec.Policy) {
+case Config::CDBSearchSpec::NoCDBSearch:
+  return llvm::None;
+case Config::CDBSearchSpec::FixedDir:
+  Storage = Spec.FixedCDBPath.getValue();
+  SearchDirs = {Storage};
+  break;
+case Config::CDBSearchSpec::Ancestors:
+  // Traverse the canonical version to prevent false positives. i.e.:
+  // src/build/../a.cc can detect a CDB in /src/build if not
+  // canonicalized.
+  Storage = removeDots(Request.FileName);
+  actOnAllParentDirectories(Storage, [&](llvm::StringRef Dir) {
+SearchDirs.push_back(Dir);
+return false;
+  });
+}
+  }
+
+  std::shared_ptr CDB = nullptr;
   bool ShouldBroadcast = false;
   DirectoryCache *DirCache = nullptr;
-  std::shared_ptr CDB = nullptr;
-  if (OnlyDirCache) {
-DirCache = OnlyDirCache.get();
-ShouldBroadcast = Request.ShouldBroadcast;
-CDB = DirCache->get(Opts.TFS, ShouldBroadcast, Request.FreshTime,
-Request.FreshTimeMissing);
-  } else {
-// Traverse the canonical version to prevent false positives. i.e.:
-// src/build/../a.cc can detect a CDB in /src/build if not canonicalized.
-std::string CanonicalPath = removeDots(Request.FileName);
-std::vector SearchDirs;
-actOnAllParentDirectories(CanonicalPath, [&](PathRef Path) {
-  SearchDirs.push_back(Path);
-  return false;
-});
-for (DirectoryCache *Candidate : getDirectoryCaches(SearchDirs)) {
-  bool CandidateShouldBroadcast = Request.ShouldBroadcast;
-  if ((CDB = Candidate->get(Opts.TFS, CandidateShouldBroadcast,
-Request.FreshTime, Request.FreshTimeMissing))) {
-DirCache = Candidate;
-ShouldBroadcast = CandidateShouldBroadcast;
-break;
-  }
+  for (DirectoryCache *Candidate : getDirec

[PATCH] D94786: [clang][ASTImporter] Add support for importing CXXFoldExpr.

2021-01-20 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik accepted this revision.
shafik added a comment.

LGTM, thank you for expanding the test!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94786

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


[PATCH] D95061: [OpenCL][Docs] Moved information about internals from UsersManual into OpenCLSupport

2021-01-20 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia created this revision.
Anastasia added a reviewer: svenvh.
Herald added subscribers: ebevhan, yaxunl.
Anastasia requested review of this revision.

Moved information detailing the implementation from UsersManual into 
OpenCLSupport page as it is not relevant to the user's of clang but primarily 
needed for the compiler developers.


https://reviews.llvm.org/D95061

Files:
  clang/docs/OpenCLSupport.rst
  clang/docs/UsersManual.rst

Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -2887,56 +2887,7 @@
 In this example it is assumed that the kernel code contains
 ``#include `` just as a regular C include.
 
-.. _opencl_cl_ext:
-
-.. option:: -cl-ext
-
-Disables support of OpenCL extensions. All OpenCL targets provide a list
-of extensions that they support. Clang allows to amend this using the ``-cl-ext``
-flag with a comma-separated list of extensions prefixed with ``'+'`` or ``'-'``.
-The syntax: ``-cl-ext=<(['-'|'+'][,])+>``,  where extensions
-can be either one of `the OpenCL published extensions
-`_
-or any vendor extension. Alternatively, ``'all'`` can be used to enable
-or disable all known extensions.
-
-Note that this is a frontend-only flag and therefore it requires the use of
-flags that forward options to the frontend e.g. ``-cc1`` or ``-Xclang``.
-
-Example disabling double support for the 64-bit SPIR target:
-
-   .. code-block:: console
-
- $ clang -cc1 -triple spir64-unknown-unknown -cl-ext=-cl_khr_fp64 test.cl
-
-Enabling all extensions except double support in R600 AMD GPU can be done using:
-
-   .. code-block:: console
-
- $ clang -cc1 -triple r600-unknown-unknown -cl-ext=-all,+cl_khr_fp16 test.cl
-
-.. _opencl_fake_address_space_map:
-
-.. option:: -ffake-address-space-map
-
-Overrides the target address space map with a fake map.
-This allows adding explicit address space IDs to the bitcode for non-segmented
-memory architectures that do not have separate IDs for each of the OpenCL
-logical address spaces by default. Passing ``-ffake-address-space-map`` will
-add/override address spaces of the target compiled for with the following values:
-``1-global``, ``2-constant``, ``3-local``, ``4-generic``. The private address
-space is represented by the absence of an address space attribute in the IR (see
-also :ref:`the section on the address space attribute `).
-
-   .. code-block:: console
-
- $ clang -cc1 -ffake-address-space-map test.cl
-
-Note that this is a frontend-only flag and therefore it requires the use of
-flags that forward options to the frontend e.g. ``-cc1`` or ``-Xclang``.
-
-Some other flags used for the compilation for C can also be passed while
-compiling for OpenCL, examples: ``-c``, ``-O<1-4|s>``, ``-o``, ``-emit-llvm``, etc.
+More options are documented in :doc:OpenCLSupport.
 
 OpenCL Targets
 --
@@ -3001,10 +2952,10 @@
 -
 
 By default Clang will not include standard headers and therefore OpenCL builtin
-functions and some types (i.e. vectors) are unknown. The default CL header is,
-however, provided in the Clang installation and can be enabled by passing the
-``-finclude-default-header`` flag (see :ref:`flags description `
-for more details).
+functions and some types (i.e. vectors) are unknown during compilation. The
+default CL header is, however, provided in the Clang installation and can be
+enabled by passing the ``-finclude-default-header`` flag (see :ref:`flags
+description ` for more details).
 
.. code-block:: console
 
@@ -3063,27 +3014,6 @@
 Extensions Documentation
 `_.
 
-OpenCL Metadata

-
-Clang uses metadata to provide additional OpenCL semantics in IR needed for
-backends and OpenCL runtime.
-
-Each kernel will have function metadata attached to it, specifying the arguments.
-Kernel argument metadata is used to provide source level information for querying
-at runtime, for example using the `clGetKernelArgInfo 
-`_
-call.
-
-Note that ``-cl-kernel-arg-info`` enables more information about the original CL
-code to be added e.g. kernel parameter names will appear in the OpenCL metadata
-along with other information. 
-
-The IDs used to encode the OpenCL's logical address spaces in the argument info
-metadata follows the SPIR address space mapping as defined in the SPIR
-specification `section 2.2
-`_
-
 OpenCL-Specific Attributes
 --
 
@@ -3185,48 +3115,6 @@
 ``noduplicate`` is kept for backwards compatibility only and it considered to be
 deprecated for future uses.
 
-.. _opencl_addrsp:
-
-address_space
-^
-
-Clang has arbitrary address space support using the ``address_s

[PATCH] D90173: [PowerPC] Exploit splat instruction xxsplti32dx in Power10

2021-01-20 Thread Albion Fung via Phabricator via cfe-commits
Conanap closed this revision.
Conanap added a comment.

Pushed; differential revision link accidentally had an extra `https://` so it 
did not automatically close.


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

https://reviews.llvm.org/D90173

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


[PATCH] D95016: [Clang][RISCV] Add custom TableGen backend for riscv-vector intrinsics.

2021-01-20 Thread Zakk Chen via Phabricator via cfe-commits
khchen added a comment.

Really thanks for @jrtc27 and @craig.topper 's review suggestions.
Before I upload the patch, I would want to discuss about the test generator, 
because if we don't want to upstream it, I don't need to fix some issues which 
are addressed by reivewers.

@asb @jrtc27 @craig.topper @evandro @HsiangKai : 
What's your opinion about the intrinsic test generator, should we really need 
to upstream it?
I'm just afraid when any community people want to contribute this part, they 
need to rewrite it again by themselves.
In the future we can remove test generator when all intrinsic are upstreamed.

However, I'm also ok to remove test generator if more people prefer on removing 
it.




Comment at: clang/include/clang/Basic/riscv_vector.td:56
+//
+//   e: type of "t" as is (identity)
+//   v: computes a vector type whose element type is "t" for the current LMUL

jrtc27 wrote:
> Do we really need to invent an esoteric DSL?
I think this is different design choose.
Current design is based on 
https://repo.hca.bsc.es/gitlab/rferrer/llvm-epi/-/blob/EPI/clang/include/clang/Basic/epi_builtins.td,
 personally I think it makes td file more simpler.

Of course we can make td file more complex little bit and list all legal type 
and combination like 
https://github.com/isrc-cas/rvv-llvm/blob/rvv-iscas/clang/include/clang/Basic/riscv_vector.td
 did.

In fact, I don't have a strong opinion on which one is better

ps. current approach is similar to arm_sve.td design, maybe they know the some 
critical reason.



Comment at: clang/include/clang/Basic/riscv_vector.td:66
+//  element type which is bool
+//   0: void type, ignores "t"
+//   z: size_t, ignores "t"

jrtc27 wrote:
> Then why aren't these just base types? We don't have to follow the brain-dead 
> nature of printf.
Basically builtin interface is instantiated by the "base type + LMUL" with type 
transformers. But in some intrinsic function we need a specific type regardless 
"base type + LMUL"
ex. `vuint32m2_t vssrl_vx_u32m2_vl (vuint32m2_t op1, uint8_t op2, size_t vl);`



Comment at: clang/utils/TestUtils/gen-riscv-v-tests.sh:22
+# op_list have marco name used in riscv_vector.td
+  local op_list="VADD VFADD"
+  local option="$1"

craig.topper wrote:
> It feels a little weird that this list is in the script and not derived from 
> the td file automatically somehow. Ideally we wouldn't have to update the 
> script every time a new set of intrinsics is added.
In tablegen interface `EmitRVVTest(RecordKeeper &Records, raw_ostream &OS)` can 
only emit one file. Currently I only found this stupid way to control 
`clang-tblgen` to generate one op in different files. 
Do you think it is acceptable to have a huge test file?
or maybe we can generate the same category op (ex. integer ops, floating ops) 
in the same file and predefined the all category first.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95016

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


[PATCH] D95016: [Clang][RISCV] Add custom TableGen backend for riscv-vector intrinsics.

2021-01-20 Thread Zakk Chen via Phabricator via cfe-commits
khchen updated this revision to Diff 317916.
khchen added a comment.

address reviewer's suggestion, do not include test generator related part.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95016

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/riscv_vector.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/test/CodeGen/RISCV/riscv-rvv-intrinsics-generic/vadd.c
  clang/test/CodeGen/RISCV/riscv-rvv-intrinsics-generic/vfadd.c
  clang/test/CodeGen/RISCV/riscv-rvv-intrinsics/vadd.c
  clang/test/CodeGen/RISCV/riscv-rvv-intrinsics/vfadd.c
  clang/test/CodeGen/RISCV/vadd.c
  clang/test/Headers/riscv-vector-header.c
  clang/utils/TableGen/CMakeLists.txt
  clang/utils/TableGen/RISCVVEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h
  clang/utils/TestUtils/gen-riscv-v-tests.sh
  llvm/docs/CommandGuide/tblgen.rst

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


[PATCH] D95063: AMDGPU: Use optimization remarks for register usage

2021-01-20 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm created this revision.
arsenm added reviewers: yaxunl, rampitec, scott.linder, t-tye, b-sumner.
Herald added subscribers: kerbowa, hiraditya, tpr, dstuttard, nhaehnle, 
jvesely, kzhuravl.
arsenm requested review of this revision.
Herald added a subscriber: wdng.
Herald added a project: LLVM.

I'm not really sure what the user experience should look like for
this. I don't think users should be looking for "asm-printer" remarks,
which also includes some generic remarks I don't think are
particularly useful.


https://reviews.llvm.org/D95063

Files:
  clang/test/Frontend/amdgcn-machine-analysis-remarks.cl
  llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp
  llvm/test/CodeGen/AMDGPU/resource-optimization-remarks.ll

Index: llvm/test/CodeGen/AMDGPU/resource-optimization-remarks.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AMDGPU/resource-optimization-remarks.ll
@@ -0,0 +1,121 @@
+; RUN: llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx908 -pass-remarks-output=%t -pass-remarks-analysis=asm-printer -filetype=obj -o /dev/null %s 2>&1 | FileCheck -check-prefix=STDERR %s
+; RUN: FileCheck -check-prefix=REMARK %s < %t
+
+; STDERR: remark: foo.cl:27:0: 6 instructions in function
+; STDERR-NEXT: remark: foo.cl:27:0: 28 SGPRs used in function
+; STDERR-NEXT: remark: foo.cl:27:0: 9 VGPRs used in function
+; STDERR-NEXT: remark: foo.cl:27:0: 43 AGPRs used in function
+; STDERR-NEXT: remark: foo.cl:27:0: 512 bytes LDS used in function
+; STDERR-NEXT: remark: :0:0: BasicBlock:
+; STDERR-NEXT: : 2
+
+; REMARK-LABEL: --- !Analysis
+; REMARK-NEXT: Pass: prologepilog
+; REMARK-NEXT: Name:StackSize
+; REMARK-NEXT: DebugLoc:{ File: foo.cl, Line: 27, Column: 0 }
+; REMARK-NEXT: Function:test_kernel
+; REMARK-NEXT: Args:
+; REMARK-NEXT: - NumStackBytes:   '0'
+; REMARK-NEXT: - String:  ' stack bytes in function'
+; REMARK-NEXT: ...
+
+; REMARK-LABEL: --- !Analysis
+; REMARK-NEXT: Pass:asm-printer
+; REMARK-NEXT: Name:InstructionMix
+; REMARK-NEXT: Function:test_kernel
+
+; REMARK-LABEL: --- !Analysis
+; REMARK-NEXT: Pass:asm-printer
+; REMARK-NEXT: Name:InstructionCount
+; REMARK-NEXT: DebugLoc:{ File: foo.cl, Line: 27, Column: 0 }
+; REMARK-NEXT: Function:test_kernel
+
+; REMARK-LABEL: --- !Analysis
+; REMARK-NEXT: Pass:asm-printer
+; REMARK-NEXT: Name:NumSGPR{{$}}
+; REMARK-NEXT: DebugLoc:{ File: foo.cl, Line: 27, Column: 0 }
+; REMARK-NEXT: Function:test_kernel
+; REMARK-NEXT: Args:
+; REMARK-NEXT:   - NumSGPR: '28'
+; REMARK-NEXT:   - String:  ' SGPRs used in function'
+; REMARK-NEXT: ...
+; REMARK-NEXT: --- !Analysis
+; REMARK-NEXT: Pass:asm-printer
+; REMARK-NEXT: Name:NumVGPR{{$}}
+; REMARK-NEXT: DebugLoc:{ File: foo.cl, Line: 27, Column: 0 }
+; REMARK-NEXT: Function:test_kernel
+; REMARK-NEXT: Args:
+; REMARK-NEXT:   - NumVGPR: '9'
+; REMARK-NEXT:   - String:  ' VGPRs used in function'
+; REMARK-NEXT: ...
+; REMARK-NEXT: --- !Analysis
+; REMARK-NEXT: Pass:asm-printer
+; REMARK-NEXT: Name:NumAGPR
+; REMARK-NEXT: DebugLoc:{ File: foo.cl, Line: 27, Column: 0 }
+; REMARK-NEXT: Function:test_kernel
+; REMARK-NEXT: Args:
+; REMARK-NEXT:   - NumAGPR: '43'
+; REMARK-NEXT:   - String:  ' AGPRs used in function'
+; REMARK-NEXT: ...
+; REMARK-NEXT: --- !Analysis
+; REMARK-NEXT: Pass:asm-printer
+; REMARK-NEXT: Name:BytesLDS
+; REMARK-NEXT: DebugLoc:{ File: foo.cl, Line: 27, Column: 0 }
+; REMARK-NEXT: Function:test_kernel
+; REMARK-NEXT: Args:
+; REMARK-NEXT:   - BytesLDS:'512'
+; REMARK-NEXT:   - String:  ' bytes LDS used in function'
+; REMARK-NEXT: ...
+@lds = internal unnamed_addr addrspace(3) global [128 x i32] undef, align 4
+
+define amdgpu_kernel void @test_kernel() !dbg !3 {
+  call void asm sideeffect "; clobber v8", "~{v8}"()
+  call void asm sideeffect "; clobber s23", "~{s23}"()
+  call void asm sideeffect "; clobber a42", "~{a42}"()
+  call void asm sideeffect "; use $0", "v"([128 x i32] addrspace(3)* @lds)
+  ret void
+}
+
+; STDERR: remark: foo.cl:42:0: 5 instructions in function
+; STDERR-NEXT: remark: foo.cl:42:0: 0 SGPRs used in function
+; STDERR-NEXT: remark: foo.cl:42:0: 0 VGPRs used in function
+; STDERR-NEXT: remark: foo.cl:42:0: 0 AGPRs used in function
+; STDERR-NOT: LDS used in function
+define void @test_func() !dbg !6 {
+  call void asm sideeffect "; clobber v17", "~{v17}"()
+  call void asm sideeffect "; clobber s11", "~{s11}"()
+  call void asm sideeffect "; clobber a9", "~{a9}"()
+  ret void
+}
+
+; STDERR: remark: foo.cl:8:0: 1 instructions in function
+; STDERR-NEXT: remark: foo.cl:8:0: 4 SGPRs used in function
+; STDERR-NEXT: remark: foo.cl:8:0: 0 VGPRs used in function
+; STDERR-NEXT: remark: foo.cl:8:0: 0 AGPRs used in

[PATCH] D94500: Rework Whitesmiths mode to use line-level values in UnwrappedLineParser

2021-01-20 Thread Tim Wojtulewicz via Phabricator via cfe-commits
timwoj updated this revision to Diff 317924.
timwoj added a comment.

Add tests for Whitesmiths with all of the NamespaceIndentation options


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94500

Files:
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/lib/Format/UnwrappedLineParser.h
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -13543,7 +13543,10 @@
WhitesmithsBraceStyle);
   */
 
+  WhitesmithsBraceStyle.NamespaceIndentation = FormatStyle::NI_None;
   verifyFormat("namespace a\n"
+   "  {\n"
+   "namespace b\n"
"  {\n"
"class A\n"
"  {\n"
@@ -13564,9 +13567,66 @@
"  {\n"
"  int x;\n"
"  };\n"
+   "  } // namespace b\n"
"  } // namespace a",
WhitesmithsBraceStyle);
 
+  WhitesmithsBraceStyle.NamespaceIndentation = FormatStyle::NI_Inner;
+  verifyFormat("namespace a\n"
+   "  {\n"
+   "namespace b\n"
+   "  {\n"
+   "  class A\n"
+   "{\n"
+   "void f()\n"
+   "  {\n"
+   "  if (true)\n"
+   "{\n"
+   "a();\n"
+   "b();\n"
+   "}\n"
+   "  }\n"
+   "void g()\n"
+   "  {\n"
+   "  return;\n"
+   "  }\n"
+   "};\n"
+   "  struct B\n"
+   "{\n"
+   "int x;\n"
+   "};\n"
+   "  } // namespace b\n"
+   "  } // namespace a",
+   WhitesmithsBraceStyle);
+
+  WhitesmithsBraceStyle.NamespaceIndentation = FormatStyle::NI_All;
+  verifyFormat("namespace a\n"
+   "  {\n"
+   "  namespace b\n"
+   "{\n"
+   "class A\n"
+   "  {\n"
+   "  void f()\n"
+   "{\n"
+   "if (true)\n"
+   "  {\n"
+   "  a();\n"
+   "  b();\n"
+   "  }\n"
+   "}\n"
+   "  void g()\n"
+   "{\n"
+   "return;\n"
+   "}\n"
+   "  };\n"
+   "struct B\n"
+   "  {\n"
+   "  int x;\n"
+   "  };\n"
+   "} // namespace b\n"
+   "  }   // namespace a",
+   WhitesmithsBraceStyle);
+
   verifyFormat("void f()\n"
"  {\n"
"  if (true)\n"
@@ -13601,7 +13661,7 @@
"  }\n",
WhitesmithsBraceStyle);
 
-  WhitesmithsBraceStyle.IndentCaseBlocks = true;
+  WhitesmithsBraceStyle.IndentCaseLabels = true;
   verifyFormat("void switchTest1(int a)\n"
"  {\n"
"  switch (a)\n"
@@ -13609,7 +13669,7 @@
"case 2:\n"
"  {\n"
"  }\n"
-   "break;\n"
+   "  break;\n"
"}\n"
"  }\n",
WhitesmithsBraceStyle);
@@ -13619,7 +13679,7 @@
"  switch (a)\n"
"{\n"
"case 0:\n"
-   "break;\n"
+   "  break;\n"
"case 1:\n"
"  {\n"
"  break;\n"
@@ -13627,9 +13687,9 @@
"case 2:\n"
"  {\n"
"  }\n"
-   "break;\n"
+   "  break;\n"
"default:\n"
-   "break;\n"
+   "  break;\n"
"}\n"
"  }\n",
WhitesmithsBraceStyle);
@@ -13642,17 +13702,17 @@
"  {\n"
"  foo(x);\n"
"  }\n"
-   "break;\n"
+   "  break;\n"
"default:\n"
"  {\n"
"  foo(1);\n"
"  }\n"
-   "break;\n"
+   "  break;\n"
"}\n"
"  }\n",
WhitesmithsBraceStyle);
 
-  WhitesmithsBraceStyle.IndentCaseBlocks = false;
+  WhitesmithsBraceStyle.IndentCaseLabels = false;
 
   verifyFormat("void switchTest4(int a)\n"
"  {\n"
Index: clang/lib/Format/UnwrappedLineParser.h

  1   2   >