[PATCH] D64608: [OpenCL] Make TableGen'd builtin tables and helper functions static

[Pierre GONDOIS via Phabricator via cfe-commits]

Pierre added a comment.

Hello Tom,
Thank you for adding me, the changes seem correct to me. 
There is a new version of the tablegen builtin functions that makes these 
tables static/const. It still needs some work, so I thing it's relevant to make 
this change in the meantime :
https://reviews.llvm.org/D63434


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64608



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

[PATCH] D64613: [clangd] Type hierarchy: don't resolve parents if the client only asked for children

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/XRefs.cpp:1238
   Optional Result =
-  getTypeAncestors(*CXXRD, AST.getASTContext(), RPSet);
+  getTypeAncestors(*CXXRD, AST.getASTContext(), RPSet, ResolveParents);
   if (!Result)

having a function named `getTypeAncestors` with a parameter `ResolveParents` 
doesn't make much sense. maybe move the check to caller side and simply don't 
call it if we are not interested in parents?

I think it makes sense to  make this part also similar to subtypes:
- let's generate the item in here with `Optional Result = 
declToTypeHierarchyItem(ASTCtx, CXXRD);`, which is used by both parents and 
children.
- bail out if we couldn't get the item.
- fill in parents if need be
- fill in children if need be

WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64613



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

[PATCH] D64537: [WebAssembly] Implement thread-local storage (local-exec model)

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

I wonder if `__tls_base` should be allocated by the embedder (or by the 
parent/creator thread).   Then it could be an *immutable* global import that is 
allocated up front.   I guess `__stack_pointer` should be treated in the same 
way (except mutable).

I don't want to block this change on this, but just putting the idea out there.




Comment at: lld/test/wasm/data-layout.ll:43
+; CHECK-NEXT:   - Index:   3
+; CHECK-NEXT: Type:I32
 ; CHECK-NEXT: Mutable: false

quantum wrote:
> tlively wrote:
> > These globals don't have enough information to tell the reader what they 
> > even are, and they don't have anything to do with the data layout, so how 
> > about skipping these in the test with a comment saying what is being 
> > skipped?
> Going to skip over `__tls_base` and `__tls_size`.
Is there any reason these symbols need to exist in non-threaded builds.  The 
cost of two extra globals is small but not nothing.

I'd also rather not skip over them here.  If TLS changes I'd like to see this 
test need updating.



Comment at: lld/test/wasm/data-segment-merging.ll:32
+; MERGE-NEXT:  - Index:   1
+; MERGE-NEXT:Name:__wasm_init_tls
 ; MERGE-NOT:   - Index:

Again, can we avoid creating this completely for non-threaded builds?



Comment at: lld/test/wasm/tls.ll:57
+;   memory.init 0, 0
+;   end
+

quantum wrote:
> tlively wrote:
> > quantum wrote:
> > > aheejin wrote:
> > > > Hmm, I think there might be a way to actually print disassembly 
> > > > results. There are '*.test' files in test directory, in which we have 
> > > > some examples. For example, [[ 
> > > > https://github.com/llvm/llvm-project/blob/master/lld/test/wasm/export-table.test
> > > >  | this test ]] has a sequence of commands you want to run, and you can 
> > > > put input files in a separate directory. That test uses `obj2yaml`, but 
> > > > can we possibly use `llvm-objdump` or something to disassemble?
> > > We already know that we can do something like
> > > 
> > > Run: obj2yaml %t.wasm | sed -n '/Body:/{s/^\s*Body:\s*//;s/../0x& 
> > > /gp}'  | llvm-mc -disassemble -triple=wasm32
> > > 
> > > to compare the actual assembly. As for `llvm-objdump`, it seems to be 
> > > unable to disassemble the WASM properly:
> > > 
> > > 
> > > ```
> > > .../tools/lld/test/wasm/Output/tls.ll.tmp.wasm:   file format WASM
> > > 
> > > 
> > > Disassembly of section CODE:
> > > 
> > >  CODE:
> > > # 4 functions in section.
> > >1: 02 00   block   invalid_type
> > >3: 0b  end
> > >4: 10 00   call0
> > >6: 20 00   local.get   0
> > >8: 24 01   global.set  1
> > >a: 20 00   local.get   0
> > >c: 41 00   i32.const   0
> > >e: 41 08   i32.const   8
> > >   10: fc 08 00 00 memory.init 0, 0
> > >   14: 0b  end
> > >   15: 0f  return
> > >   16: 00  llvm-objdump: 
> > > lib/Target/WebAssembly/WebAssemblyGenAsmWriter.inc:2032: void 
> > > llvm::WebAssemblyInstPrinter::printInstruction(const llvm::MCInst *, 
> > > llvm::raw_ostream &): Assertion `Bits != 0 && "Cannot print this 
> > > instruction."' failed.
> > > 
> > > ```
> > It might be worth filing an LLVM bug for this (or possibly fixing in a 
> > separate CL).
> Going to fix this at some point in the future.
This is known issue with the disassembler in that it doesn't know where the 
functions start and stop in executable output, only in object files.



Comment at: lld/wasm/Writer.cpp:629
+  // Merge .tbss into .tdata so that they share the same offsets.
+  if (name.startswith(".tbss."))
+return ".tdata";

Maybe write this as a single conditional so its clear even without this comment?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64537



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

[PATCH] D64537: [WebAssembly] Implement thread-local storage (local-exec model)

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

Its really great to see this change BTW!  Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64537



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

[PATCH] D64617: [clangd] Added highlighting for members and methods

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

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

Added highlighting for members and methods.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D64617

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/semantic-highlighting.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -37,7 +37,9 @@
   {HighlightingKind::Function, "Function"},
   {HighlightingKind::Class, "Class"},
   {HighlightingKind::Enum, "Enum"},
-  {HighlightingKind::Namespace, "Namespace"}};
+  {HighlightingKind::Namespace, "Namespace"},
+  {HighlightingKind::MemberVariable, "MemberVariable"},
+  {HighlightingKind::Method, "Method"}};
   std::vector ExpectedTokens;
   for (const auto &KindString : KindToString) {
 std::vector Toks = makeHighlightingTokens(
@@ -53,14 +55,14 @@
   const char *TestCases[] = {
 R"cpp(
   struct $Class[[AS]] {
-double SomeMember;
+double $MemberVariable[[SomeMember]];
   };
   struct {
   } $Variable[[S]];
   void $Function[[foo]](int $Variable[[A]], $Class[[AS]] $Variable[[As]]) {
 auto $Variable[[VeryLongVariableName]] = 12312;
 $Class[[AS]] $Variable[[AA]];
-auto $Variable[[L]] = $Variable[[AA]].SomeMember + $Variable[[A]];
+auto $Variable[[L]] = $Variable[[AA]].$MemberVariable[[SomeMember]] + $Variable[[A]];
 auto $Variable[[FN]] = [ $Variable[[AA]]](int $Variable[[A]]) -> void {};
 $Variable[[FN]](12312);
   }
@@ -72,19 +74,19 @@
 auto $Variable[[Bou]] = $Function[[Gah]];
   }
   struct $Class[[A]] {
-void $Function[[abc]]();
+void $Method[[abc]]();
   };
 )cpp",
 R"cpp(
   namespace $Namespace[[abc]] {
 template
 struct $Class[[A]] {
-  T t;
+  T $MemberVariable[[t]];
 };
   }
   template
   struct $Class[[C]] : $Namespace[[abc]]::A {
-typename T::A* D;
+typename T::A* $MemberVariable[[D]];
   };
   $Namespace[[abc]]::$Class[[A]] $Variable[[AA]];
   typedef $Namespace[[abc]]::$Class[[A]] AAA;
@@ -92,7 +94,7 @@
 $Class[[B]]();
 ~$Class[[B]]();
 void operator<<($Class[[B]]);
-$Class[[AAA]] AA;
+$Class[[AAA]] $MemberVariable[[AA]];
   };
   $Class[[B]]::$Class[[B]]() {}
   $Class[[B]]::~$Class[[B]]() {}
@@ -106,8 +108,8 @@
   enum class $Enum[[E]] {};
   enum $Enum[[EE]] {};
   struct $Class[[A]] {
-$Enum[[E]] EEE;
-$Enum[[EE]] ;
+$Enum[[E]] $MemberVariable[[EEE]];
+$Enum[[EE]] $MemberVariable[[]];
   };
 )cpp",
 R"cpp(
@@ -132,6 +134,27 @@
 $Namespace[[vwz]]::$Class[[A]]::$Enum[[B]]::Hi;
   ::$Namespace[[vwz]]::$Class[[A]] $Variable[[B]];
   ::$Namespace[[abc]]::$Namespace[[bcd]]::$Class[[A]] $Variable[[BB]];
+)cpp",
+R"cpp(
+  struct $Class[[D]] {
+double $MemberVariable[[C]];
+  };
+  struct $Class[[A]] {
+double $MemberVariable[[B]];
+$Class[[D]] $MemberVariable[[E]];
+void $Method[[foo]]() {
+  $MemberVariable[[B]] = 123;
+  this->$MemberVariable[[B]] = 156;
+  this->$Method[[foo]]();
+  $Method[[foo]]();
+}
+  };
+  void $Function[[foo]]() {
+$Class[[A]] $Variable[[AA]];
+$Variable[[AA]].$MemberVariable[[B]] += 2;
+$Variable[[AA]].$Method[[foo]]();
+$Variable[[AA]].$MemberVariable[[E]].$MemberVariable[[C]];
+  }
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
@@ -181,7 +204,7 @@
   toSemanticHighlightingInformation(Tokens);
   std::vector ExpectedResults = {
   {1, "AQAEAAA="},
-  {3, "CAAEAAAEAAMAAQ=="}};
+  {3, "CAAEAAAEAAMAAg=="}};
   EXPECT_EQ(ActualResults, ExpectedResults);
 }
 
Index: clang-tools-extra/clangd/test/semantic-highlighting.test
===
--- clang-tools-extra/clangd/test/semantic-highlighting.test
+++ clang-tools-extra/clangd/test/semantic-highlighting.test
@@ -5,12 +5,18 @@
 # CHECK:  "semanticHighlighting": {
 # CHECK-NEXT:"scopes": [
 # CHECK-NEXT:  [
-# CHECK-NEXT:"variable.cpp"
+# CHECK-NEXT:"variable.other.cpp"
+# CHECK-NEXT:  ],
+# CHECK-NEXT:  [
+# CHECK-NEXT:"variable.other.member.cpp"
 # CHECK-NEXT:  

[PATCH] D64565: [clangd] Don't run the prepare for tweaks that are disabled.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 209429.
hokein added a comment.

Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64565

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/refactor/Tweak.cpp
  clang-tools-extra/clangd/refactor/Tweak.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
@@ -472,7 +472,6 @@
   }
   Opts.StaticIndex = StaticIdx.get();
   Opts.AsyncThreadsCount = WorkerThreadsCount;
-  Opts.HiddenFeatures = HiddenFeatures;
 
   clangd::CodeCompleteOptions CCOpts;
   CCOpts.IncludeIneligibleResults = IncludeIneligibleResults;
@@ -531,11 +530,14 @@
   }
   Opts.SuggestMissingIncludes = SuggestMissingIncludes;
   Opts.QueryDriverGlobs = std::move(QueryDriverGlobs);
-  if (TweakList.getNumOccurrences())
-Opts.TweakFilter = [&](llvm::StringRef TweakToSearch) {
-  // return true if any tweak matches the TweakToSearch
-  return llvm::find(TweakList, TweakToSearch) != TweakList.end();
-};
+
+  Opts.TweakFilter = [&](const Tweak &T) {
+if (T.hidden() && !HiddenFeatures)
+  return false;
+if (TweakList.getNumOccurrences())
+  return llvm::is_contained(TweakList, T.id());
+return true;
+  };
   llvm::Optional OffsetEncodingFromFlag;
   if (ForceOffsetEncoding != OffsetEncoding::UnsupportedEncoding)
 OffsetEncodingFromFlag = ForceOffsetEncoding;
Index: clang-tools-extra/clangd/refactor/Tweak.h
===
--- clang-tools-extra/clangd/refactor/Tweak.h
+++ clang-tools-extra/clangd/refactor/Tweak.h
@@ -110,9 +110,11 @@
   TweakRegistrationFor##Subclass(#Subclass, /*Description=*/"");   \
   const char *Subclass::id() const { return #Subclass; }
 
-/// Calls prepare() on all tweaks, returning those that can run on the
-/// selection.
-std::vector> prepareTweaks(const Tweak::Selection &S);
+/// Calls prepare() on all tweaks that satisfy the filter, returning those that
+/// can run on the selection.
+std::vector>
+prepareTweaks(const Tweak::Selection &S,
+  llvm::function_ref Filter);
 
 // Calls prepare() on the tweak with a given ID.
 // If prepare() returns false, returns an error.
Index: clang-tools-extra/clangd/refactor/Tweak.cpp
===
--- clang-tools-extra/clangd/refactor/Tweak.cpp
+++ clang-tools-extra/clangd/refactor/Tweak.cpp
@@ -46,13 +46,15 @@
   Cursor = SM.getComposedLoc(SM.getMainFileID(), RangeBegin);
 }
 
-std::vector> prepareTweaks(const Tweak::Selection &S) {
+std::vector>
+prepareTweaks(const Tweak::Selection &S,
+  llvm::function_ref Filter) {
   validateRegistry();
 
   std::vector> Available;
   for (const auto &E : TweakRegistry::entries()) {
 std::unique_ptr T = E.instantiate();
-if (!T->prepare(S))
+if (!Filter(*T) || !T->prepare(S))
   continue;
 Available.push_back(std::move(T));
   }
Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -126,10 +126,6 @@
 
 bool SuggestMissingIncludes = false;
 
-/// Enable hidden features mostly useful to clangd developers.
-/// e.g. tweaks to dump the AST.
-bool HiddenFeatures = false;
-
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
@@ -137,9 +133,10 @@
 /// Enable semantic highlighting features.
 bool SemanticHighlighting = false;
 
-/// Returns true if the StringRef is a tweak that should be enabled
-std::function TweakFilter =
-[](llvm::StringRef TweakToSearch) { return true; };
+/// Returns true if the tweak should be enabled.
+std::function TweakFilter = [](const Tweak &T) {
+  return !T.hidden(); // only enable non-hidden tweaks.
+};
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -322,7 +319,7 @@
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
 
-  std::function TweakFilter;
+  std::function TweakFilter;
 
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -101,7 +101,7 @@
  : nullptr),
   GetClangTidyOptions(Opts.GetClangTidyOptions),
   SuggestMissingIncludes(Opts.SuggestMissingIncludes)

[clang-tools-extra] r365882 - [clangd] Don't run the prepare for tweaks that are disabled.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Fri Jul 12 01:50:20 2019
New Revision: 365882

URL: http://llvm.org/viewvc/llvm-project?rev=365882&view=rev
Log:
[clangd] Don't run the prepare for tweaks that are disabled.

Summary: Previously, we ran the prepare, even for the tweaks that are disabled.

Reviewers: sammccall

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

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/ClangdServer.cpp
clang-tools-extra/trunk/clangd/ClangdServer.h
clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
clang-tools-extra/trunk/clangd/refactor/Tweak.h
clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=365882&r1=365881&r2=365882&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Fri Jul 12 01:50:20 2019
@@ -101,7 +101,7 @@ ClangdServer::ClangdServer(const GlobalC
  : nullptr),
   GetClangTidyOptions(Opts.GetClangTidyOptions),
   SuggestMissingIncludes(Opts.SuggestMissingIncludes),
-  EnableHiddenFeatures(Opts.HiddenFeatures), TweakFilter(Opts.TweakFilter),
+  TweakFilter(Opts.TweakFilter),
   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
@@ -333,11 +333,9 @@ void ClangdServer::enumerateTweaks(PathR
 if (!Selection)
   return CB(Selection.takeError());
 std::vector Res;
-for (auto &T : prepareTweaks(*Selection)) {
-  if (!TweakFilter(T->id()) || (T->hidden() && !EnableHiddenFeatures))
-continue;
+for (auto &T : prepareTweaks(*Selection, TweakFilter))
   Res.push_back({T->id(), T->title(), T->intent()});
-}
+
 CB(std::move(Res));
   };
 

Modified: clang-tools-extra/trunk/clangd/ClangdServer.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.h?rev=365882&r1=365881&r2=365882&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.h (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.h Fri Jul 12 01:50:20 2019
@@ -126,10 +126,6 @@ public:
 
 bool SuggestMissingIncludes = false;
 
-/// Enable hidden features mostly useful to clangd developers.
-/// e.g. tweaks to dump the AST.
-bool HiddenFeatures = false;
-
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
@@ -137,9 +133,10 @@ public:
 /// Enable semantic highlighting features.
 bool SemanticHighlighting = false;
 
-/// Returns true if the StringRef is a tweak that should be enabled
-std::function TweakFilter =
-[](llvm::StringRef TweakToSearch) { return true; };
+/// Returns true if the tweak should be enabled.
+std::function TweakFilter = [](const Tweak &T) {
+  return !T.hidden(); // only enable non-hidden tweaks.
+};
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -322,7 +319,7 @@ private:
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
 
-  std::function TweakFilter;
+  std::function TweakFilter;
 
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>

Modified: clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/refactor/Tweak.cpp?rev=365882&r1=365881&r2=365882&view=diff
==
--- clang-tools-extra/trunk/clangd/refactor/Tweak.cpp (original)
+++ clang-tools-extra/trunk/clangd/refactor/Tweak.cpp Fri Jul 12 01:50:20 2019
@@ -46,13 +46,15 @@ Tweak::Selection::Selection(ParsedAST &A
   Cursor = SM.getComposedLoc(SM.getMainFileID(), RangeBegin);
 }
 
-std::vector> prepareTweaks(const Tweak::Selection &S) {
+std::vector>
+prepareTweaks(const Tweak::Selection &S,
+  llvm::function_ref Filter) {
   validateRegistry();
 
   std::vector> Available;
   for (const auto &E : TweakRegistry::entries()) {
 std::unique_ptr T = E.instantiate();
-if (!T->prepare(S))
+if (!Filter(*T) || !T->prepare(S))
   continue;
 Available.push_back(std::move(T));
   }

Modified: clang-tools-extra/trunk/clangd/refactor/Tweak.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/refactor/Tweak.h?rev=365882&r1=365881&r2=365882&view=diff
==
--- clang-tools-extra/trunk/clangd/refactor/Tweak.h (orig

[PATCH] D64565: [clangd] Don't run the prepare for tweaks that are disabled.

[Haojian Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL365882: [clangd] Don't run the prepare for tweaks that 
are disabled. (authored by hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64565?vs=209429&id=209430#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D64565

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

Index: clang-tools-extra/trunk/clangd/ClangdServer.cpp
===
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp
@@ -101,7 +101,7 @@
  : nullptr),
   GetClangTidyOptions(Opts.GetClangTidyOptions),
   SuggestMissingIncludes(Opts.SuggestMissingIncludes),
-  EnableHiddenFeatures(Opts.HiddenFeatures), TweakFilter(Opts.TweakFilter),
+  TweakFilter(Opts.TweakFilter),
   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
@@ -333,11 +333,9 @@
 if (!Selection)
   return CB(Selection.takeError());
 std::vector Res;
-for (auto &T : prepareTweaks(*Selection)) {
-  if (!TweakFilter(T->id()) || (T->hidden() && !EnableHiddenFeatures))
-continue;
+for (auto &T : prepareTweaks(*Selection, TweakFilter))
   Res.push_back({T->id(), T->title(), T->intent()});
-}
+
 CB(std::move(Res));
   };
 
Index: clang-tools-extra/trunk/clangd/refactor/Tweak.h
===
--- clang-tools-extra/trunk/clangd/refactor/Tweak.h
+++ clang-tools-extra/trunk/clangd/refactor/Tweak.h
@@ -110,9 +110,11 @@
   TweakRegistrationFor##Subclass(#Subclass, /*Description=*/"");   \
   const char *Subclass::id() const { return #Subclass; }
 
-/// Calls prepare() on all tweaks, returning those that can run on the
-/// selection.
-std::vector> prepareTweaks(const Tweak::Selection &S);
+/// Calls prepare() on all tweaks that satisfy the filter, returning those that
+/// can run on the selection.
+std::vector>
+prepareTweaks(const Tweak::Selection &S,
+  llvm::function_ref Filter);
 
 // Calls prepare() on the tweak with a given ID.
 // If prepare() returns false, returns an error.
Index: clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
===
--- clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
+++ clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
@@ -46,13 +46,15 @@
   Cursor = SM.getComposedLoc(SM.getMainFileID(), RangeBegin);
 }
 
-std::vector> prepareTweaks(const Tweak::Selection &S) {
+std::vector>
+prepareTweaks(const Tweak::Selection &S,
+  llvm::function_ref Filter) {
   validateRegistry();
 
   std::vector> Available;
   for (const auto &E : TweakRegistry::entries()) {
 std::unique_ptr T = E.instantiate();
-if (!T->prepare(S))
+if (!Filter(*T) || !T->prepare(S))
   continue;
 Available.push_back(std::move(T));
   }
Index: clang-tools-extra/trunk/clangd/ClangdServer.h
===
--- clang-tools-extra/trunk/clangd/ClangdServer.h
+++ clang-tools-extra/trunk/clangd/ClangdServer.h
@@ -126,10 +126,6 @@
 
 bool SuggestMissingIncludes = false;
 
-/// Enable hidden features mostly useful to clangd developers.
-/// e.g. tweaks to dump the AST.
-bool HiddenFeatures = false;
-
 /// Clangd will execute compiler drivers matching one of these globs to
 /// fetch system include path.
 std::vector QueryDriverGlobs;
@@ -137,9 +133,10 @@
 /// Enable semantic highlighting features.
 bool SemanticHighlighting = false;
 
-/// Returns true if the StringRef is a tweak that should be enabled
-std::function TweakFilter =
-[](llvm::StringRef TweakToSearch) { return true; };
+/// Returns true if the tweak should be enabled.
+std::function TweakFilter = [](const Tweak &T) {
+  return !T.hidden(); // only enable non-hidden tweaks.
+};
   };
   // Sensible default options for use in tests.
   // Features like indexing must be enabled if desired.
@@ -322,7 +319,7 @@
   bool SuggestMissingIncludes = false;
   bool EnableHiddenFeatures = false;
 
-  std::function TweakFilter;
+  std::function TweakFilter;
 
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
Index: clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/trunk/c

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Alex Bradbury via cfe-commits]

On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
 wrote:
>
> Author: smeenai
> Date: Thu Jul 11 14:20:38 2019
> New Revision: 365825
>
> URL: http://llvm.org/viewvc/llvm-project?rev=365825&view=rev
> Log:
> [clang-shlib] Fix clang-shlib for PRIVATE dependencies
>
> Any static library with a PRIVATE dependency ends up with a
> $ generator expression in its INTERFACE_LINK_LIBRARIES,
> which won't be evaluated by the $, so we end up
> with an unevaluated generator expression in the generated build file and
> Ninja chokes on the dollar sign. Just use the static library directly
> for its dependencies instead of trying to propagate dependencies
> manually.
>
> Differential Revision: https://reviews.llvm.org/D64579

This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
the point of linking lib/libclang_shared.so.9svn with errors like:
ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
>>> referenced by Attributes.cpp:34 
>>> (/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
>>>   
>>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule))

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
>>> referenced by TargetCXXABI.h:168 
>>> (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168)
>>>   
>>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft()
>>>  const)

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
>>> referenced by TargetCXXABI.h:149 
>>> (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149)
>>>   
>>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily()
>>>  const)

ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks
>>> referenced by Attributes.cpp
>>>   
>>> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64448: gsl::Owner/gsl::Pointer: Add implicit annotations for some std types

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr added a comment.

In D64448#1581866 , @mgehre wrote:

> I didn't know whether they would differ, but the test tells me that they 
> don't differ significantly (i.e. in introducing new techniques).


Okay -- I would prefer if you intentionally looked at the code before declaring 
a library as supported, or asked someone who knows about the differences, but 
it is your call.

> Would you like me to test with other standard libraries (besides MSVC, which 
> I already planned)?

It is your call which libraries you would like to support.

Another question -- in the latest iteration of the patch the inference code 
disappeared -- was it intentional?




Comment at: clang/include/clang/Basic/TokenKinds.def:486
+TYPE_TRAIT_1(__is_gsl_owner, IsGslOwner, KEYCXX)
+TYPE_TRAIT_1(__is_gsl_pointer, IsGslPointer, KEYCXX)
 KEYWORD(__underlying_type   , KEYCXX)

mgehre wrote:
> gribozavr wrote:
> > mgehre wrote:
> > > gribozavr wrote:
> > > > I'd suggest to split type trait implementations into a separate patch.
> > > > 
> > > > Are these type traits being exposed only for testing? I'm not sure it 
> > > > is a good idea to do that -- people will end up using them in 
> > > > production code -- is that a concern? If so, maybe it would be better 
> > > > to test through warnings.
> > > I copied that approach from https://reviews.llvm.org/D50119.
> > > If people do it in production code, then at least the two leading 
> > > underscores should tell them "I'm not supposed to use this".
> > > 
> > > I considered a test through warnings, but how would I trigger them? Add 
> > > `-Wlifetime-categories-debug` which emits notes whenever a 
> > > [[gsl::Owner/Pointer]] is implicitly/explicitly attached to class?
> > > If people do it in production code, then at least the two leading 
> > > underscores should tell them "I'm not supposed to use this".
> > 
> > That's not what two underscores mean. These custom type traits, being 
> > language extensions, must have a name that won't collide with any 
> > user-defined name, hence two underscores. Two underscores mean nothing 
> > about whether the user is allowed to use it or not. Sure the code might 
> > become non-portable to other compilers, but that's not what the concern is. 
> > My concern is that code that people write might become unportable to future 
> > versions of Clang, where we would have to change behavior of these type 
> > traits (or it would just subtly change in some corner case and we won't 
> > notice since we don't consider it a public API).
> > 
> > > I considered a test through warnings, but how would I trigger them?
> > 
> > I meant regular warnings, that are the objective of this analysis -- 
> > warnings about dereferencing dangling pointers. If we get those warnings 
> > for the types-under-test, then obviously they have the correct annotations 
> > from the compiler's point of view.
> I spent a lot of time debugging on the full lifetime analysis, and knowing 
> exactly which type has which Attribute (especially if inference is involved) 
> was quite important.
> I would say that adding additional code to trigger a real lifetime warning 
> - requires that we first add some lifetime warnings to clang (currently in a 
> different PR)
> - obscures the purpose of the check, i.e. checking the attributes and not the 
> warnings themselves
> - and makes debugging hard when the test fails (warnings involve at least one 
> Owner and one Pointer, so either of those could have made the test fail)
> I'd prefer if we can test the attributes directly.
I agree that being able to test these properties definitely simplifies testing. 
I am worried about adding language extension though, and would like someone 
like Richard Smith to LGTM this approach.



Comment at: clang/test/SemaCXX/attr-gsl-owner-pointer.cpp:86
 
-// Test builtin annotation for std types.
+// Test builtin attributes for std types.
 namespace std {

s/builtin attributes/Test attribute inference for types in the standard 
library./



Comment at: clang/test/SemaCXX/attr-gsl-owner-pointer.cpp:88
 namespace std {
-// Complete class
+// Attributes are added to a (complete) class.
 class any {

s/added to/inferred for/



Comment at: clang/test/SemaCXX/attr-gsl-owner-pointer.cpp:93
 
-// Complete template
+// Attributes are added to a instantiatons of a complete template.
 template 

Sorry, but what do you mean by a "concrete template"?

"Attributes are inferred on class template instantiations."



Comment at: clang/test/SemaCXX/attr-gsl-owner-pointer.cpp:102
 
+// If std::container::iterator is a using declaration, Attributes are added to
+// the underlying class

lowercase "attributes"



Comment at: clang/test/SemaCXX/attr-gsl-owner-pointer.cpp:114
 
+// If std::container::iterat

[PATCH] D64554: [CrossTU] Add a function to retrieve original source location.

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

> This patch can be treated as part of a bigger change that is needed to 
> improve macro expansion handliong at plist generation.

@balazske Could you please prepare the upcoming patch and put that on the 
Stack. I think that may ease the work of the reviewers if they could see how 
you want to use this function.


Repository:
  rC Clang

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

https://reviews.llvm.org/D64554



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

[PATCH] D64614: [clangd] Mark type hierarchy as a supported feature in the docs

[Sam McCall via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/docs/clangd/Features.rst:264
 +-++--+
-| Type hierarchy  | No |   No |
+| Type hierarchy  | No |   Yes|
 +-++--+

nridge wrote:
> Should I perhaps change type hierarchy's entry in the LSP column from "No" to 
> "Proposed"?
I'm not sure what "no" means, if it doesn't mean "proposed".

Changing the "no" links to say "proposal" and link to it would be useful, I 
think.
(And we could delete any rows that don't have a proposal)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64614



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

[PATCH] D64617: [clangd] Added highlighting for members and methods

[Sam McCall via Phabricator via cfe-commits]

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

LG from my side




Comment at: clang-tools-extra/clangd/SemanticHighlighting.h:28
   Variable = 0,
+  MemberVariable,
   Function,

nit: clang calls these Field which is terser and pretty understandable, I think.

(Formally, I think these are data members and "methods" are member functions, 
but I like the shorter names better)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64617



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

[clang-tools-extra] r365885 - [clangd] Move the expandAuto tweak from global namespace into annoymous namespace.

[Haojian Wu via cfe-commits]

Author: hokein
Date: Fri Jul 12 02:38:53 2019
New Revision: 365885

URL: http://llvm.org/viewvc/llvm-project?rev=365885&view=rev
Log:
[clangd] Move the expandAuto tweak from global namespace into annoymous 
namespace.

Modified:
clang-tools-extra/trunk/clangd/refactor/tweaks/ExpandAutoType.cpp
clang-tools-extra/trunk/clangd/test/code-action-request.test

Modified: clang-tools-extra/trunk/clangd/refactor/tweaks/ExpandAutoType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/refactor/tweaks/ExpandAutoType.cpp?rev=365885&r1=365884&r2=365885&view=diff
==
--- clang-tools-extra/trunk/clangd/refactor/tweaks/ExpandAutoType.cpp (original)
+++ clang-tools-extra/trunk/clangd/refactor/tweaks/ExpandAutoType.cpp Fri Jul 
12 02:38:53 2019
@@ -24,6 +24,7 @@
 
 namespace clang {
 namespace clangd {
+namespace {
 
 /// Expand the "auto" type to the derived type
 /// Before:
@@ -53,7 +54,7 @@ private:
 
 REGISTER_TWEAK(ExpandAutoType)
 
-std::string ExpandAutoType::title() const { return "expand auto type"; }
+std::string ExpandAutoType::title() const { return "Expand auto type"; }
 
 bool ExpandAutoType::prepare(const Selection& Inputs) {
   CachedLocation = llvm::None;
@@ -115,5 +116,6 @@ llvm::Error ExpandAutoType::createErrorM
  ErrorMessage.c_str());
 }
 
+} // namespace
 } // namespace clangd
 } // namespace clang

Modified: clang-tools-extra/trunk/clangd/test/code-action-request.test
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/test/code-action-request.test?rev=365885&r1=365884&r2=365885&view=diff
==
--- clang-tools-extra/trunk/clangd/test/code-action-request.test (original)
+++ clang-tools-extra/trunk/clangd/test/code-action-request.test Fri Jul 12 
02:38:53 2019
@@ -47,7 +47,7 @@
 # CHECK-NEXT:}
 # CHECK-NEXT:  ],
 # CHECK-NEXT:  "command": "clangd.applyTweak",
-# CHECK-NEXT:  "title": "expand auto type"
+# CHECK-NEXT:  "title": "Expand auto type"
 # CHECK-NEXT:}
 # CHECK-NEXT:  ]
 ---


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

[PATCH] D64617: [clangd] Added highlighting for members and methods

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:44
+  bool VisitMemberExpr(MemberExpr *ME) {
+if (const CXXMethodDecl *MD =
+dyn_cast(ME->getMemberDecl())) {

nit: this can be simplified like 

```
if (const auto* D = dyn_cast(ME->getMemberDecl())) {
  // When calling the destructor manually like: AAA::~A(); The ~ is a
  // MemberExpr.  
 return true;
}
```



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:53
+
+// The MemberDecl is VarDecl for static members, therefore getMemberDecl
+// does not work for all member variables.

It took me a while to understand how the comment associate with the code here, 
maybe add `and we use the MemberExpr` in the comment?



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:142
 }
+if(isa(D)) {
+  addToken(Loc, HighlightingKind::Method);

nit: clang-format.

As it is class-related, could you move it to Line 133 (immediately after the 
`Class` case), the same to the `FieldDecl`.



Comment at: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp:140
+  struct $Class[[D]] {
+double $MemberVariable[[C]];
+  };

could you add a test case for `static member`? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64617



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

[PATCH] D64624: [clangd] Added highlighting to enum constants.

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

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

VSCode does not have a scope for enum constants. So they were placed under 
"constant.other.enum" as that seems to be the most correct scope for enum 
constants. However, this makes theia color them blue (the same color it uses 
for keywords).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D64624

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/semantic-highlighting.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -37,7 +37,8 @@
   {HighlightingKind::Function, "Function"},
   {HighlightingKind::Class, "Class"},
   {HighlightingKind::Enum, "Enum"},
-  {HighlightingKind::Namespace, "Namespace"}};
+  {HighlightingKind::Namespace, "Namespace"},
+  {HighlightingKind::EnumConstant, "EnumConstant"}};
   std::vector ExpectedTokens;
   for (const auto &KindString : KindToString) {
 std::vector Toks = makeHighlightingTokens(
@@ -118,7 +119,7 @@
   namespace $Namespace[[cde]] {
 struct $Class[[A]] {
   enum class $Enum[[B]] {
-Hi,
+$EnumConstant[[Hi]],
   };
 };
   }
@@ -129,9 +130,20 @@
 $Namespace[[abc]]::$Namespace[[bcd]]::$Namespace[[cde]];
   $Namespace[[abc]]::$Namespace[[bcd]]::$Class[[A]] $Variable[[AA]];
   $Namespace[[vwz]]::$Class[[A]]::$Enum[[B]] $Variable[[AAA]] =
-$Namespace[[vwz]]::$Class[[A]]::$Enum[[B]]::Hi;
+$Namespace[[vwz]]::$Class[[A]]::$Enum[[B]]::$EnumConstant[[Hi]];
   ::$Namespace[[vwz]]::$Class[[A]] $Variable[[B]];
   ::$Namespace[[abc]]::$Namespace[[bcd]]::$Class[[A]] $Variable[[BB]];
+)cpp",
+R"cpp(
+  enum $Enum[[ABC]] {
+$EnumConstant[[Hi]],
+  };
+  int $Variable[[I]] = $EnumConstant[[Hi]];
+  enum class $Enum[[BC]] {
+$EnumConstant[[A]],
+$EnumConstant[[B]],
+  };
+  $Enum[[BC]] $Variable[[L]] = $Enum[[BC]]::$EnumConstant[[B]];
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
Index: clang-tools-extra/clangd/test/semantic-highlighting.test
===
--- clang-tools-extra/clangd/test/semantic-highlighting.test
+++ clang-tools-extra/clangd/test/semantic-highlighting.test
@@ -17,6 +17,9 @@
 # CHECK-NEXT:"entity.name.type.enum.cpp"
 # CHECK-NEXT:  ],
 # CHECK-NEXT:  [
+# CHECK-NEXT:"constant.other.enum.cpp"
+# CHECK-NEXT:  ],
+# CHECK-NEXT:  [
 # CHECK-NEXT:"entity.name.namespace.cpp"
 # CHECK-NEXT:  ]
 # CHECK-NEXT:]
Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -28,6 +28,7 @@
   Function,
   Class,
   Enum,
+  EnumConstant,
   Namespace,
 
   NumKinds,
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -119,6 +119,10 @@
   addToken(Loc, HighlightingKind::Enum);
   return;
 }
+if(isa(D)) {
+  addToken(Loc, HighlightingKind::EnumConstant);
+  return;
+}
 if (isa(D)) {
   addToken(Loc, HighlightingKind::Variable);
   return;
@@ -249,6 +253,8 @@
 return "entity.name.type.class.cpp";
   case HighlightingKind::Enum:
 return "entity.name.type.enum.cpp";
+  case HighlightingKind::EnumConstant:
+return "constant.other.enum.cpp";
   case HighlightingKind::Namespace:
 return "entity.name.namespace.cpp";
   case HighlightingKind::NumKinds:


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -37,7 +37,8 @@
   {HighlightingKind::Function, "Function"},
   {HighlightingKind::Class, "Class"},
   {HighlightingKind::Enum, "Enum"},
-  {HighlightingKind::Namespace, "Namespace"}};
+  {HighlightingKind::Namespace, "Namespace"},
+  {HighlightingKind::EnumConstant, "EnumConstant"}};
   std::vector ExpectedTokens;
   for (const a

[PATCH] D64624: [clangd] Added highlighting to enum constants.

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

mostly good.




Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:122
 }
+if(isa(D)) {
+  addToken(Loc, HighlightingKind::EnumConstant);

nit: clang-format.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:257
+  case HighlightingKind::EnumConstant:
+return "constant.other.enum.cpp";
   case HighlightingKind::Namespace:

could you check the tm scope on vscode? They seem to use 
`variable.other.enummember`.



Comment at: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp:107
 R"cpp(
   enum class $Enum[[E]] {};
   enum $Enum[[EE]] {};

since we have a dedicated testcase for `enum`, could you extend the testcase 
here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64624



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

[PATCH] D61333: [ASTImporter] Fix LLDB lookup in transparent ctx and with ext src

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

@shafik @jingham This is a polite Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61333



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

[PATCH] D64562: [clangd] Fixed toHalfOpenFileRange

[Sam McCall via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/SourceCode.cpp:261
+  if (!Lexer::getRawToken(Loc, TheTok, SM, LangOpts)) {
+if (TheTok.is(tok::greatergreater))
+  return 1;

sammccall wrote:
> `>>=` too? That's legal with variable templates.
> 
> (If you're deliberately choosing different behavior that definitely deserves 
> a comment)
nit: please don't just mark comments "done" if there's reason not to do them - 
a brief explanation in the review and/or the code is useful to keep track.

For the record, it turns out that it seems C++ doesn't actually allow `>>=` to 
be ambiguous - the user has to put a space before = if it's not a shift.



Comment at: clang-tools-extra/clangd/unittests/SourceCodeTests.cpp:410
+// Test for functions toHalfOpenFileRange and getHalfOpenFileRange
+// FIXME: Need better testing support to be able to check more than just Decls.
+TEST(SourceCodeTests, HalfOpenFileRange) {

SureYeaah wrote:
> sammccall wrote:
> > this is a function on ranges, so only using decls isn't a limitation per se.
> > 
> > Is there a type of range you're unable to test because you can't construct 
> > it as the source range of a decl? If so, please say which. If not I think 
> > we should just drop this comment.
> e.g. Nested template instantiation (TemplateSpecializationTypeLoc)
That's a type of decl, not a type of range.

This function inputs and outputs a range, so the type of decl used isn't 
relevant to its correctness.
Is there a particular type of range (e.g. certain macro expansion structure and 
pair of points) that you want to test but can't construct a decl to cover?



Comment at: clang-tools-extra/clangd/unittests/SourceCodeTests.cpp:421
+  $c[[FOO(b, c)]]; 
+  $d[[FOO(BAR(BAR(b)), d)]];
+}

SureYeaah wrote:
> sammccall wrote:
> > some tests where the expansion range is a macro arg? e.g.
> > ```
> > #define ECHO(X) X
> > ECHO($e[[ECHO(int) ECHO(e)]])
> > ```
> > 
> > (if I'm understanding right)
> In this case, the FileRange would be
> 
> ```
> ECHO(ECHO($e[[int) ECHO(e]]));
> ```
> 
> So the code works correctly. But it's not how we want it to behave right?
That looks OK to me. It's surprising, but I think defensible.

The most likely source of complaints is I guess if we use selection tree to 
implement structured selection expansion. Anyway, whatever the behavior is, 
thanks for adding the test :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64562



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

r365887 - [JSONCompilationDatabase] Strip distcc/ccache/gomacc wrappers from parsed commands.

[Sam McCall via cfe-commits]

Author: sammccall
Date: Fri Jul 12 03:11:40 2019
New Revision: 365887

URL: http://llvm.org/viewvc/llvm-project?rev=365887&view=rev
Log:
[JSONCompilationDatabase] Strip distcc/ccache/gomacc wrappers from parsed 
commands.

Summary:
It's common to use compiler wrappers by setting CC="gomacc clang++".
This results in both args appearing in compile_commands.json, and clang's driver
can't handle this.

This patch attempts to recognize this pattern (by looking for well-known
wrappers) and dropping argv0 in this case.

It conservatively ignores other cases for now:
 - wrappers with unknown names
 - wrappers that accept -flags
 - wrappers where the compiler to use is implied (usually cc or gcc)

This is done at the JSONCompilationDatabase level rather than somewhere more
fundamental, as (hopefully) this isn't a general conceptual problem, but a messy
aspect of the nature of the ecosystem around compile_commands.json.
i.e. compilation databases more tightly tied to the build system should not have
this problem.

Reviewers: phosek, klimek

Subscribers: llvm-commits

Tags: #llvm

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

Modified:
cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp
cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp

Modified: cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp?rev=365887&r1=365886&r2=365887&view=diff
==
--- cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp (original)
+++ cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp Fri Jul 12 03:11:40 2019
@@ -256,15 +256,57 @@ JSONCompilationDatabase::getAllCompileCo
   return Commands;
 }
 
+static llvm::StringRef stripExecutableExtension(llvm::StringRef Name) {
+  Name.consume_back(".exe");
+  return Name;
+}
+
+// There are compiler-wrappers (ccache, distcc, gomacc) that take the "real"
+// compiler as an argument, e.g. distcc gcc -O3 foo.c.
+// These end up in compile_commands.json when people set CC="distcc gcc".
+// Clang's driver doesn't understand this, so we need to unwrap.
+static bool unwrapCommand(std::vector &Args) {
+  if (Args.size() < 2)
+return false;
+  StringRef Wrapper =
+  stripExecutableExtension(llvm::sys::path::filename(Args.front()));
+  if (Wrapper == "distcc" || Wrapper == "gomacc" || Wrapper == "ccache") {
+// Most of these wrappers support being invoked 3 ways:
+// `distcc g++ file.c` This is the mode we're trying to match.
+// We need to drop `distcc`.
+// `distcc file.c` This acts like compiler is cc or similar.
+// Clang's driver can handle this, no change needed.
+// `g++ file.c`g++ is a symlink to distcc.
+// We don't even notice this case, and all is well.
+//
+// We need to distinguish between the first and second case.
+// The wrappers themselves don't take flags, so Args[1] is a compiler flag,
+// an input file, or a compiler. Inputs have extensions, compilers don't.
+bool HasCompiler =
+(Args[1][0] != '-') &&
+!llvm::sys::path::has_extension(stripExecutableExtension(Args[1]));
+if (HasCompiler) {
+  Args.erase(Args.begin());
+  return true;
+}
+// If !HasCompiler, wrappers act like GCC. Fine: so do we.
+  }
+  return false;
+}
+
 static std::vector
 nodeToCommandLine(JSONCommandLineSyntax Syntax,
   const std::vector &Nodes) {
   SmallString<1024> Storage;
-  if (Nodes.size() == 1)
-return unescapeCommandLine(Syntax, Nodes[0]->getValue(Storage));
   std::vector Arguments;
-  for (const auto *Node : Nodes)
-Arguments.push_back(Node->getValue(Storage));
+  if (Nodes.size() == 1)
+Arguments = unescapeCommandLine(Syntax, Nodes[0]->getValue(Storage));
+  else
+for (const auto *Node : Nodes)
+  Arguments.push_back(Node->getValue(Storage));
+  // There may be multiple wrappers: using distcc and ccache together is 
common.
+  while (unwrapCommand(Arguments))
+;
   return Arguments;
 }
 

Modified: cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp?rev=365887&r1=365886&r2=365887&view=diff
==
--- cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp Fri Jul 12 03:11:40 
2019
@@ -370,6 +370,30 @@ TEST(findCompileArgsInJsonDatabase, Find
   EXPECT_EQ("command4", FoundCommand.CommandLine[0]) << ErrorMessage;
 }
 
+TEST(findCompileArgsInJsonDatabase, ParsesCompilerWrappers) {
+  std::vector> Cases = {
+  {"distcc gcc foo.c", "gcc foo.c"},
+  {"gomacc clang++ foo.c", "clang++ foo.c"},
+  {"ccache gcc foo.c", "gcc foo.c"},
+  {"ccache.exe gcc foo.c", "gcc foo.c"},
+ 

[clang-tools-extra] r365888 - [clangd] Prioritize indexing of files that share a basename with the open file.

[Sam McCall via cfe-commits]

Author: sammccall
Date: Fri Jul 12 03:18:42 2019
New Revision: 365888

URL: http://llvm.org/viewvc/llvm-project?rev=365888&view=rev
Log:
[clangd] Prioritize indexing of files that share a basename with the open file.

Summary:
In practice, opening Foo.h will still often result in Foo.cpp making the
second index build instead of the first, as the rebuild policy doesn't
know to wait.

Reviewers: kadircet

Subscribers: ilya-biryukov, javed.absar, MaskRay, jkorous, arphaman, 
llvm-commits

Tags: #llvm

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

Modified:
clang-tools-extra/trunk/clangd/ClangdServer.cpp
clang-tools-extra/trunk/clangd/TUScheduler.cpp
clang-tools-extra/trunk/clangd/TUScheduler.h
clang-tools-extra/trunk/clangd/index/Background.cpp
clang-tools-extra/trunk/clangd/index/Background.h
clang-tools-extra/trunk/clangd/index/BackgroundQueue.cpp
clang-tools-extra/trunk/clangd/unittests/BackgroundIndexTests.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=365888&r1=365887&r2=365888&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Fri Jul 12 03:18:42 2019
@@ -151,7 +151,10 @@ void ClangdServer::addDocument(PathRef F
   Inputs.Contents = Contents;
   Inputs.Opts = std::move(Opts);
   Inputs.Index = Index;
-  WorkScheduler.update(File, Inputs, WantDiags);
+  bool NewFile = WorkScheduler.update(File, Inputs, WantDiags);
+  // If we loaded Foo.h, we want to make sure Foo.cpp is indexed.
+  if (NewFile && BackgroundIdx)
+BackgroundIdx->boostRelated(File);
 }
 
 void ClangdServer::removeDocument(PathRef File) { WorkScheduler.remove(File); }

Modified: clang-tools-extra/trunk/clangd/TUScheduler.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/TUScheduler.cpp?rev=365888&r1=365887&r2=365888&view=diff
==
--- clang-tools-extra/trunk/clangd/TUScheduler.cpp (original)
+++ clang-tools-extra/trunk/clangd/TUScheduler.cpp Fri Jul 12 03:18:42 2019
@@ -860,9 +860,10 @@ bool TUScheduler::blockUntilIdle(Deadlin
   return true;
 }
 
-void TUScheduler::update(PathRef File, ParseInputs Inputs,
+bool TUScheduler::update(PathRef File, ParseInputs Inputs,
  WantDiagnostics WantDiags) {
   std::unique_ptr &FD = Files[File];
+  bool NewFile = FD == nullptr;
   if (!FD) {
 // Create a new worker to process the AST-related tasks.
 ASTWorkerHandle Worker = ASTWorker::create(
@@ -875,6 +876,7 @@ void TUScheduler::update(PathRef File, P
 FD->Contents = Inputs.Contents;
   }
   FD->Worker->update(std::move(Inputs), WantDiags);
+  return NewFile;
 }
 
 void TUScheduler::remove(PathRef File) {

Modified: clang-tools-extra/trunk/clangd/TUScheduler.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/TUScheduler.h?rev=365888&r1=365887&r2=365888&view=diff
==
--- clang-tools-extra/trunk/clangd/TUScheduler.h (original)
+++ clang-tools-extra/trunk/clangd/TUScheduler.h Fri Jul 12 03:18:42 2019
@@ -142,13 +142,14 @@ public:
   /// contain files that currently run something over their AST.
   std::vector getFilesWithCachedAST() const;
 
-  /// Schedule an update for \p File. Adds \p File to a list of tracked files 
if
-  /// \p File was not part of it before. The compile command in \p Inputs is
-  /// ignored; worker queries CDB to get the actual compile command.
+  /// Schedule an update for \p File.
+  /// The compile command in \p Inputs is ignored; worker queries CDB to get
+  /// the actual compile command.
   /// If diagnostics are requested (Yes), and the context is cancelled
   /// before they are prepared, they may be skipped if eventual-consistency
   /// permits it (i.e. WantDiagnostics is downgraded to Auto).
-  void update(PathRef File, ParseInputs Inputs, WantDiagnostics WD);
+  /// Returns true if the file was not previously tracked.
+  bool update(PathRef File, ParseInputs Inputs, WantDiagnostics WD);
 
   /// Remove \p File from the list of tracked files and schedule removal of its
   /// resources. Pending diagnostics for closed files may not be delivered, 
even

Modified: clang-tools-extra/trunk/clangd/index/Background.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Background.cpp?rev=365888&r1=365887&r2=365888&view=diff
==
--- clang-tools-extra/trunk/clangd/index/Background.cpp (original)
+++ clang-tools-extra/trunk/clangd/index/Background.cpp Fri Jul 12 03:18:42 2019
@@ -27,6 +27,7 @@
 #include "index/SymbolCollector.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceM

[PATCH] D62888: [NewPM] Port Sancov

[Alex Brachet via Phabricator via cfe-commits]

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



Comment at: 
llvm/trunk/lib/Transforms/Instrumentation/SanitizerCoverage.cpp:1022-1026
+SanitizerCoverage::getSectionStart(const std::string &Section) const {
+  return getSectionStartImpl(TargetTriple, Section);
 }
 
+std::string SanitizerCoverage::getSectionEnd(const std::string &Section) const 
{

buildbots are complaining about warnings from these being unused.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62888



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

[PATCH] D64627: [clangd] Suppress unwritten scopes when expanding auto.

[Haojian Wu via Phabricator via cfe-commits]

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

otherwise the replacement will break the code.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D64627

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


Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -663,6 +663,20 @@
 const char * x = "test";
   )cpp";
   checkTransform(ID, Input, Output);
+
+  Input = R"cpp(
+  namespace {
+  class Foo {};
+  }
+  au^to f = Foo();
+  )cpp";
+  Output = R"cpp(
+  namespace {
+  class Foo {};
+  }
+  Foo f = Foo();
+  )cpp";
+  checkTransform(ID, Input, Output);
 }
 
 } // namespace
Index: clang-tools-extra/clangd/AST.h
===
--- clang-tools-extra/clangd/AST.h
+++ clang-tools-extra/clangd/AST.h
@@ -67,7 +67,8 @@
  const MacroInfo *MI,
  const SourceManager &SM);
 
-/// Returns a QualType as string.
+/// Returns a QualType as string. The result doesn't contain unwritten scopes
+/// like annoymous/inline namespace.
 std::string printType(const QualType QT, const DeclContext & Context);
 
 /// Try to shorten the OriginalName by removing namespaces from the left of
Index: clang-tools-extra/clangd/AST.cpp
===
--- clang-tools-extra/clangd/AST.cpp
+++ clang-tools-extra/clangd/AST.cpp
@@ -192,6 +192,7 @@
 
 std::string printType(const QualType QT, const DeclContext & Context){
   PrintingPolicy PP(Context.getParentASTContext().getPrintingPolicy());
+  PP.SuppressUnwrittenScope = 1;
   PP.SuppressTagKeyword = 1;
   return shortenNamespace(
   QT.getAsString(PP),


Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -663,6 +663,20 @@
 const char * x = "test";
   )cpp";
   checkTransform(ID, Input, Output);
+
+  Input = R"cpp(
+  namespace {
+  class Foo {};
+  }
+  au^to f = Foo();
+  )cpp";
+  Output = R"cpp(
+  namespace {
+  class Foo {};
+  }
+  Foo f = Foo();
+  )cpp";
+  checkTransform(ID, Input, Output);
 }
 
 } // namespace
Index: clang-tools-extra/clangd/AST.h
===
--- clang-tools-extra/clangd/AST.h
+++ clang-tools-extra/clangd/AST.h
@@ -67,7 +67,8 @@
  const MacroInfo *MI,
  const SourceManager &SM);
 
-/// Returns a QualType as string.
+/// Returns a QualType as string. The result doesn't contain unwritten scopes
+/// like annoymous/inline namespace.
 std::string printType(const QualType QT, const DeclContext & Context);
 
 /// Try to shorten the OriginalName by removing namespaces from the left of
Index: clang-tools-extra/clangd/AST.cpp
===
--- clang-tools-extra/clangd/AST.cpp
+++ clang-tools-extra/clangd/AST.cpp
@@ -192,6 +192,7 @@
 
 std::string printType(const QualType QT, const DeclContext & Context){
   PrintingPolicy PP(Context.getParentASTContext().getPrintingPolicy());
+  PP.SuppressUnwrittenScope = 1;
   PP.SuppressTagKeyword = 1;
   return shortenNamespace(
   QT.getAsString(PP),
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64628: [CrossTU] Test change only: improve ctu-main.c

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

balazske created this revision.
Herald added subscribers: cfe-commits, gamesh411, Szelethus, dkrupp.
Herald added a project: clang.

New lines are added to test ctu-main.c to make code execute when a
function with invalid source range is encountered on bug path
with NoStoreFuncVisitor.


Repository:
  rC Clang

https://reviews.llvm.org/D64628

Files:
  test/Analysis/ctu-main.c


Index: test/Analysis/ctu-main.c
===
--- test/Analysis/ctu-main.c
+++ test/Analysis/ctu-main.c
@@ -45,11 +45,18 @@
   g(0); // expected-warning@Inputs/ctu-other.c:29 {{Access to field 'a' 
results in a dereference of a null pointer (loaded from variable 'ctx')}}
 }
 
+void h(int);
+
 // The external function prototype is incomplete.
 // warning:implicit functions are prohibited by c99
 void testImplicit() {
-  int res = identImplicit(6);   // external implicit functions are not inlined
+  int res = identImplicit(6);
   clang_analyzer_eval(res == 6); // expected-warning{{TRUE}}
+
+  // Call something with uninitialized from the same function in which the 
implicit was called.
+  // This is necessary to reproduce a special bug in NoStoreFuncVisitor.
+  int uninitialized;
+  h(uninitialized); // expected-warning@ctu-main.c:59 {{1st function call 
argument is an uninitialized value}}
 }
 
 // Tests the import of functions that have a struct parameter


Index: test/Analysis/ctu-main.c
===
--- test/Analysis/ctu-main.c
+++ test/Analysis/ctu-main.c
@@ -45,11 +45,18 @@
   g(0); // expected-warning@Inputs/ctu-other.c:29 {{Access to field 'a' results in a dereference of a null pointer (loaded from variable 'ctx')}}
 }
 
+void h(int);
+
 // The external function prototype is incomplete.
 // warning:implicit functions are prohibited by c99
 void testImplicit() {
-  int res = identImplicit(6);   // external implicit functions are not inlined
+  int res = identImplicit(6);
   clang_analyzer_eval(res == 6); // expected-warning{{TRUE}}
+
+  // Call something with uninitialized from the same function in which the implicit was called.
+  // This is necessary to reproduce a special bug in NoStoreFuncVisitor.
+  int uninitialized;
+  h(uninitialized); // expected-warning@ctu-main.c:59 {{1st function call argument is an uninitialized value}}
 }
 
 // Tests the import of functions that have a struct parameter
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64083: [OpenCL][Sema] Improve address space support for blocks

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added inline comments.



Comment at: cfe/trunk/lib/Sema/SemaExprCXX.cpp:4229
+LangAS AddrSpaceR =
+RHSType->getAs()->getPointeeType().getAddressSpace();
+CastKind Kind =

rjmccall wrote:
> Anastasia wrote:
> > rjmccall wrote:
> > > Anastasia wrote:
> > > > rjmccall wrote:
> > > > > All of this can be much simpler:
> > > > > 
> > > > > ```
> > > > > LangAS AddrSpaceL = 
> > > > > ToType->castAs()->getPointeeType().getAddressSpace();
> > > > > LangAS AddrSpaceR = 
> > > > > FromType->castAs()->getPointeeType().getAddressSpace();
> > > > > ```
> > > > > 
> > > > > Is there something actually checking the validity of this 
> > > > > address-space cast somewhere?
> > > > > Is there something actually checking the validity of this 
> > > > > address-space cast somewhere?
> > > > 
> > > > The address spaces for blocks are currently added by clang implicitly. 
> > > > It doesn't seem possible to write kernel code qualifying blocks with 
> > > > address spaces. Although I have to say the error is not given properly 
> > > > because the parser gets confused at least for the examples I have 
> > > > tried. The OpenCL spec doesn't detail much regarding this use case. 
> > > > Potentially this is the area for improvement.
> > > > 
> > > > So for now we can add an assert to check the cast validity if you think 
> > > > it makes sense and maybe a FIXME in the  code to explain that address 
> > > > spaces aren't working with blocks
> > > > The address spaces for blocks are currently added by clang implicitly. 
> > > > It doesn't seem possible to write kernel code qualifying blocks with 
> > > > address spaces.
> > > 
> > > There's no way that just fell out from the existing implementation; it 
> > > was a change someone must have made for OpenCL.  Unless you care about 
> > > blocks existing in multiple address spaces — which, given that you depend 
> > > on eliminating them, I'm pretty sure you don't — the compiler just 
> > > shouldn't do that if it's causing you problems.
> > So the reasons why we add addr spaces to blocks is that if they are 
> > declared in program scope they will be inferred as `__global` AS and if 
> > they are declared in kernel scope they are inferred as `__private` AS.
> > 
> > When there is a common code i.e. we pass block into a function or invoke 
> > the block we use generic AS so that blocks in different addr spaces can be 
> > work correctly but we are adding addr space cast.
> > 
> > This is the review that added this logic for OpenCL C: 
> > https://reviews.llvm.org/D28814
> > 
> > However in C++ we follow slightly different program path and therefore addr 
> > space cast isn't performed correctly.
> Okay, so users can't write block pointer types with explicit address spaces.  
> What exactly do you mean by "declaring" a block?  Do you mean that block 
> pointer *types* are inferred to have different qualification based on where 
> they're written, or do you mean that block *literals* have different 
> qualification based on where they're written?  Because I'm not sure the 
> latter is actually distinguishable from a language model in which blocks are 
> always pointers into `__generic` and the compiler just immediately promotes 
> them when emitting the expression.
We add `__generic` addr space to pointee type of block pointer type for all 
block variables. However, we don't do the same for block literals. Hence we 
need to generate conversion from `LangAS::Default` to 
`LangAS::opencl_generic`... I think this just aligns with what we do for other 
similar cases in OpenCL.

We also add `__global`/`__private` to block pointer type in block variable 
declarations, but we do the same for all other objects. At IR generation we 
generate block literals with captures as local variables in `__private` addr 
space and block literals without captures as global variables in `__global` 
addr space.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D64083



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

[PATCH] D64083: [OpenCL][Sema] Improve address space support for blocks

[Marco Antognini via Phabricator via cfe-commits]

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



Comment at: cfe/trunk/lib/Sema/SemaExprCXX.cpp:4229
+LangAS AddrSpaceR =
+RHSType->getAs()->getPointeeType().getAddressSpace();
+CastKind Kind =

Anastasia wrote:
> rjmccall wrote:
> > Anastasia wrote:
> > > rjmccall wrote:
> > > > Anastasia wrote:
> > > > > rjmccall wrote:
> > > > > > All of this can be much simpler:
> > > > > > 
> > > > > > ```
> > > > > > LangAS AddrSpaceL = 
> > > > > > ToType->castAs()->getPointeeType().getAddressSpace();
> > > > > > LangAS AddrSpaceR = 
> > > > > > FromType->castAs()->getPointeeType().getAddressSpace();
> > > > > > ```
> > > > > > 
> > > > > > Is there something actually checking the validity of this 
> > > > > > address-space cast somewhere?
> > > > > > Is there something actually checking the validity of this 
> > > > > > address-space cast somewhere?
> > > > > 
> > > > > The address spaces for blocks are currently added by clang 
> > > > > implicitly. It doesn't seem possible to write kernel code qualifying 
> > > > > blocks with address spaces. Although I have to say the error is not 
> > > > > given properly because the parser gets confused at least for the 
> > > > > examples I have tried. The OpenCL spec doesn't detail much regarding 
> > > > > this use case. Potentially this is the area for improvement.
> > > > > 
> > > > > So for now we can add an assert to check the cast validity if you 
> > > > > think it makes sense and maybe a FIXME in the  code to explain that 
> > > > > address spaces aren't working with blocks
> > > > > The address spaces for blocks are currently added by clang 
> > > > > implicitly. It doesn't seem possible to write kernel code qualifying 
> > > > > blocks with address spaces.
> > > > 
> > > > There's no way that just fell out from the existing implementation; it 
> > > > was a change someone must have made for OpenCL.  Unless you care about 
> > > > blocks existing in multiple address spaces — which, given that you 
> > > > depend on eliminating them, I'm pretty sure you don't — the compiler 
> > > > just shouldn't do that if it's causing you problems.
> > > So the reasons why we add addr spaces to blocks is that if they are 
> > > declared in program scope they will be inferred as `__global` AS and if 
> > > they are declared in kernel scope they are inferred as `__private` AS.
> > > 
> > > When there is a common code i.e. we pass block into a function or invoke 
> > > the block we use generic AS so that blocks in different addr spaces can 
> > > be work correctly but we are adding addr space cast.
> > > 
> > > This is the review that added this logic for OpenCL C: 
> > > https://reviews.llvm.org/D28814
> > > 
> > > However in C++ we follow slightly different program path and therefore 
> > > addr space cast isn't performed correctly.
> > Okay, so users can't write block pointer types with explicit address 
> > spaces.  What exactly do you mean by "declaring" a block?  Do you mean that 
> > block pointer *types* are inferred to have different qualification based on 
> > where they're written, or do you mean that block *literals* have different 
> > qualification based on where they're written?  Because I'm not sure the 
> > latter is actually distinguishable from a language model in which blocks 
> > are always pointers into `__generic` and the compiler just immediately 
> > promotes them when emitting the expression.
> We add `__generic` addr space to pointee type of block pointer type for all 
> block variables. However, we don't do the same for block literals. Hence we 
> need to generate conversion from `LangAS::Default` to 
> `LangAS::opencl_generic`... I think this just aligns with what we do for 
> other similar cases in OpenCL.
> 
> We also add `__global`/`__private` to block pointer type in block variable 
> declarations, but we do the same for all other objects. At IR generation we 
> generate block literals with captures as local variables in `__private` addr 
> space and block literals without captures as global variables in `__global` 
> addr space.
I've been experimenting a bit more with blocks. Here is a snippet that helped 
me understand things further:

```
typedef int (^block_ty)(void);
__global block_ty block3 = ^{ return 0; };
__global int (^block4)(void) = ^{ return 0; }; // FIXME return type is not 
allowed to have AS qualifier

kernel void test(void) {
  block_ty __constant block0 = ^{ return 0; };
  int (^block1)(void) = ^(void){ return 0; };
  __private block_ty block2 = ^{ return 0; };
  // block2 = ^{ return 1; }; // invalid code in OpenCL; blocks cannot be 
re-assigned.

  int x = ((__local block_ty) block3)(); // FIXME The AS cast is missing from 
the AST, plus Clang crashes.
}
```

This piece of code shows two bugs:
* Address space qualifier on the return type of blocks should be rejected.
* Address space cast are missing from the AST when doing a C cast, and this 
regar

[clang-tools-extra] r365894 - [clangd] Fixed toHalfOpenFileRange

[Shaurya Gupta via cfe-commits]

Author: sureyeaah
Date: Fri Jul 12 04:42:31 2019
New Revision: 365894

URL: http://llvm.org/viewvc/llvm-project?rev=365894&view=rev
Log:
[clangd] Fixed toHalfOpenFileRange

Summary:
- Fixed toHalfOpenFileRange to work for macros as well as template
instantiations
- Added unit tests

Breaking test case for older version of toHalfOpenFileRange:
\# define FOO(X) X++
int a = 1;
int b = FOO(a);
toHalfOpenFileRange for the sourceRange of VarDecl for b returned the
wrong Range.

Reviewers: sammccall, kadircet

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

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/SourceCode.cpp
clang-tools-extra/trunk/clangd/SourceCode.h
clang-tools-extra/trunk/clangd/unittests/SourceCodeTests.cpp

Modified: clang-tools-extra/trunk/clangd/SourceCode.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/SourceCode.cpp?rev=365894&r1=365893&r2=365894&view=diff
==
--- clang-tools-extra/trunk/clangd/SourceCode.cpp (original)
+++ clang-tools-extra/trunk/clangd/SourceCode.cpp Fri Jul 12 04:42:31 2019
@@ -12,6 +12,8 @@
 #include "Logger.h"
 #include "Protocol.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Format/Format.h"
@@ -244,20 +246,106 @@ bool halfOpenRangeTouches(const SourceMa
   return L == R.getEnd() || halfOpenRangeContains(Mgr, R, L);
 }
 
-llvm::Optional toHalfOpenFileRange(const SourceManager &Mgr,
+static unsigned getTokenLengthAtLoc(SourceLocation Loc, const SourceManager 
&SM,
+const LangOptions &LangOpts) {
+  Token TheTok;
+  if (Lexer::getRawToken(Loc, TheTok, SM, LangOpts))
+return 0;
+  // FIXME: Here we check whether the token at the location is a greatergreater
+  // (>>) token and consider it as a single greater (>). This is to get it
+  // working for templates but it isn't correct for the right shift operator. 
We
+  // can avoid this by using half open char ranges in getFileRange() but 
getting
+  // token ending is not well supported in macroIDs.
+  if (TheTok.is(tok::greatergreater))
+return 1;
+  return TheTok.getLength();
+}
+
+// Returns location of the last character of the token at a given loc
+static SourceLocation getLocForTokenEnd(SourceLocation BeginLoc,
+const SourceManager &SM,
+const LangOptions &LangOpts) {
+  unsigned Len = getTokenLengthAtLoc(BeginLoc, SM, LangOpts);
+  return BeginLoc.getLocWithOffset(Len ? Len - 1 : 0);
+}
+
+// Returns location of the starting of the token at a given EndLoc
+static SourceLocation getLocForTokenBegin(SourceLocation EndLoc,
+  const SourceManager &SM,
+  const LangOptions &LangOpts) {
+  return EndLoc.getLocWithOffset(
+  -(signed)getTokenLengthAtLoc(EndLoc, SM, LangOpts));
+}
+
+// Converts a char source range to a token range.
+static SourceRange toTokenRange(CharSourceRange Range, const SourceManager &SM,
+const LangOptions &LangOpts) {
+  if (!Range.isTokenRange())
+Range.setEnd(getLocForTokenBegin(Range.getEnd(), SM, LangOpts));
+  return Range.getAsRange();
+}
+// Returns the union of two token ranges.
+// To find the maximum of the Ends of the ranges, we compare the location of 
the
+// last character of the token.
+static SourceRange unionTokenRange(SourceRange R1, SourceRange R2,
+   const SourceManager &SM,
+   const LangOptions &LangOpts) {
+  SourceLocation E1 = getLocForTokenEnd(R1.getEnd(), SM, LangOpts);
+  SourceLocation E2 = getLocForTokenEnd(R2.getEnd(), SM, LangOpts);
+  return SourceRange(std::min(R1.getBegin(), R2.getBegin()),
+ E1 < E2 ? R2.getEnd() : R1.getEnd());
+}
+
+// Returns the tokenFileRange for a given Location as a Token Range
+// This is quite similar to getFileLoc in SourceManager as both use
+// getImmediateExpansionRange and getImmediateSpellingLoc (for macro IDs).
+// However:
+// - We want to maintain the full range information as we move from one file to
+//   the next. getFileLoc only uses the BeginLoc of getImmediateExpansionRange.
+// - We want to split '>>' tokens as the lexer parses the '>>' in template
+//   instantiations as a '>>' instead of a '>'.
+// There is also getExpansionRange but it simply calls
+// getImmediateExpansionRange on the begin and ends separately which is wrong.
+static SourceRange getTokenFileRange(SourceLocation Loc,
+ const SourceManager &SM,
+ const LangOptions &LangOpts) {
+  SourceRange FileRange = Lo

[PATCH] D64562: [clangd] Fixed toHalfOpenFileRange

[Shaurya Gupta via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL365894: [clangd] Fixed toHalfOpenFileRange (authored by 
SureYeaah, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64562?vs=209363&id=209462#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D64562

Files:
  clang-tools-extra/trunk/clangd/SourceCode.cpp
  clang-tools-extra/trunk/clangd/SourceCode.h
  clang-tools-extra/trunk/clangd/unittests/SourceCodeTests.cpp

Index: clang-tools-extra/trunk/clangd/SourceCode.cpp
===
--- clang-tools-extra/trunk/clangd/SourceCode.cpp
+++ clang-tools-extra/trunk/clangd/SourceCode.cpp
@@ -12,6 +12,8 @@
 #include "Logger.h"
 #include "Protocol.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Format/Format.h"
@@ -244,20 +246,106 @@
   return L == R.getEnd() || halfOpenRangeContains(Mgr, R, L);
 }
 
-llvm::Optional toHalfOpenFileRange(const SourceManager &Mgr,
+static unsigned getTokenLengthAtLoc(SourceLocation Loc, const SourceManager &SM,
+const LangOptions &LangOpts) {
+  Token TheTok;
+  if (Lexer::getRawToken(Loc, TheTok, SM, LangOpts))
+return 0;
+  // FIXME: Here we check whether the token at the location is a greatergreater
+  // (>>) token and consider it as a single greater (>). This is to get it
+  // working for templates but it isn't correct for the right shift operator. We
+  // can avoid this by using half open char ranges in getFileRange() but getting
+  // token ending is not well supported in macroIDs.
+  if (TheTok.is(tok::greatergreater))
+return 1;
+  return TheTok.getLength();
+}
+
+// Returns location of the last character of the token at a given loc
+static SourceLocation getLocForTokenEnd(SourceLocation BeginLoc,
+const SourceManager &SM,
+const LangOptions &LangOpts) {
+  unsigned Len = getTokenLengthAtLoc(BeginLoc, SM, LangOpts);
+  return BeginLoc.getLocWithOffset(Len ? Len - 1 : 0);
+}
+
+// Returns location of the starting of the token at a given EndLoc
+static SourceLocation getLocForTokenBegin(SourceLocation EndLoc,
+  const SourceManager &SM,
+  const LangOptions &LangOpts) {
+  return EndLoc.getLocWithOffset(
+  -(signed)getTokenLengthAtLoc(EndLoc, SM, LangOpts));
+}
+
+// Converts a char source range to a token range.
+static SourceRange toTokenRange(CharSourceRange Range, const SourceManager &SM,
+const LangOptions &LangOpts) {
+  if (!Range.isTokenRange())
+Range.setEnd(getLocForTokenBegin(Range.getEnd(), SM, LangOpts));
+  return Range.getAsRange();
+}
+// Returns the union of two token ranges.
+// To find the maximum of the Ends of the ranges, we compare the location of the
+// last character of the token.
+static SourceRange unionTokenRange(SourceRange R1, SourceRange R2,
+   const SourceManager &SM,
+   const LangOptions &LangOpts) {
+  SourceLocation E1 = getLocForTokenEnd(R1.getEnd(), SM, LangOpts);
+  SourceLocation E2 = getLocForTokenEnd(R2.getEnd(), SM, LangOpts);
+  return SourceRange(std::min(R1.getBegin(), R2.getBegin()),
+ E1 < E2 ? R2.getEnd() : R1.getEnd());
+}
+
+// Returns the tokenFileRange for a given Location as a Token Range
+// This is quite similar to getFileLoc in SourceManager as both use
+// getImmediateExpansionRange and getImmediateSpellingLoc (for macro IDs).
+// However:
+// - We want to maintain the full range information as we move from one file to
+//   the next. getFileLoc only uses the BeginLoc of getImmediateExpansionRange.
+// - We want to split '>>' tokens as the lexer parses the '>>' in template
+//   instantiations as a '>>' instead of a '>'.
+// There is also getExpansionRange but it simply calls
+// getImmediateExpansionRange on the begin and ends separately which is wrong.
+static SourceRange getTokenFileRange(SourceLocation Loc,
+ const SourceManager &SM,
+ const LangOptions &LangOpts) {
+  SourceRange FileRange = Loc;
+  while (!FileRange.getBegin().isFileID()) {
+assert(!FileRange.getEnd().isFileID() &&
+   "Both Begin and End should be MacroIDs.");
+if (SM.isMacroArgExpansion(FileRange.getBegin())) {
+  FileRange.setBegin(SM.getImmediateSpellingLoc(FileRange.getBegin()));
+  FileRange.setEnd(SM.getImmediateSpellingLoc(FileRange.getEnd()));
+} else {
+  SourceRange ExpansionRangeForBegin = toTokenRang

[PATCH] D64569: [OpenCL] Improve destructor support in C++ for OpenCL

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added inline comments.



Comment at: clang/lib/CodeGen/CGExprCXX.cpp:117-118
+  llvm::Type *NewType = CGM.getTypes().ConvertType(DstTy);
+  This = getTargetHooks().performAddrSpaceCast(*this, This, SrcAS, DstAS,
+   NewType);
+}

mantognini wrote:
> This is effectively the fix for the third point mentioned in the description.
> 
> Alternatively, `This = Builder.CreatePointerBitCastOrAddrSpaceCast(This, 
> NewType);` seems to work equally well and does not require the extra new 
> parameter.
Yes, I agree just using `CreatePointerBitCastOrAddrSpaceCast` would be easier.

As far as I remember (@rjmccall can correct me if I am wrong) 
`performAddrSpaceCast` was added to workaround the fact that `nullptr` constant 
might not be value 0 for some address spaces. However, considering that it's 
not the first place where some big change has to be done in CodeGen to be able 
to use the new API I am wondering if it's worth looking at moving this logic to 
LLVM lowering phases that can map `nullptr` constant into some arbitrary value. 
I think the challenge is to find where LLVM assumes that `nullptr` is always 0. 
That might not be an easy task.

PS, I am not suggesting to do it for this patch but just an idea to investigate 
in the future. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64569



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

[PATCH] D62413: [OpenCL][PR41727] Prevent ICE on global dtors

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia updated this revision to Diff 209463.
Anastasia added a comment.

Generate NULL for pointer param of __cxa_atexit on mismatching addr spaces


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

https://reviews.llvm.org/D62413

Files:
  lib/CodeGen/CGDeclCXX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/CodeGen/TargetInfo.h
  test/CodeGenOpenCLCXX/atexit.cl

Index: test/CodeGenOpenCLCXX/atexit.cl
===
--- /dev/null
+++ test/CodeGenOpenCLCXX/atexit.cl
@@ -0,0 +1,11 @@
+//RUN: %clang_cc1 %s -triple spir -cl-std=c++ -emit-llvm -O0 -o - | FileCheck %s
+
+struct S {
+  ~S(){};
+};
+S s;
+
+//CHECK-LABEL: define internal void @__cxx_global_var_init()
+//CHECK: call i32 @__cxa_atexit(void (i8*)* bitcast (void (%struct.S addrspace(4)*)* @_ZNU3AS41SD1Ev to void (i8*)*), i8* null, i8 addrspace(1)* @__dso_handle)
+
+//CHECK: declare i32 @__cxa_atexit(void (i8*)*, i8*, i8 addrspace(1)*)
Index: lib/CodeGen/TargetInfo.h
===
--- lib/CodeGen/TargetInfo.h
+++ lib/CodeGen/TargetInfo.h
@@ -267,6 +267,11 @@
LangAS SrcAddr, LangAS DestAddr,
llvm::Type *DestTy) const;
 
+  /// Get address space of pointer parameter for __cxa_atexit.
+  virtual LangAS getAddrSpaceOfCxaAtexitPtrParam() const {
+return LangAS::Default;
+  }
+
   /// Get the syncscope used in LLVM IR.
   virtual llvm::SyncScope::ID getLLVMSyncScopeID(const LangOptions &LangOpts,
  SyncScope Scope,
Index: lib/CodeGen/ItaniumCXXABI.cpp
===
--- lib/CodeGen/ItaniumCXXABI.cpp
+++ lib/CodeGen/ItaniumCXXABI.cpp
@@ -2284,8 +2284,19 @@
   llvm::Type *dtorTy =
 llvm::FunctionType::get(CGF.VoidTy, CGF.Int8PtrTy, false)->getPointerTo();
 
+  // Preserve address space of addr.
+  auto AddrAS = addr ? addr->getType()->getPointerAddressSpace() : 0;
+  auto AddrInt8PtrTy =
+  AddrAS ? CGF.Int8Ty->getPointerTo(AddrAS) : CGF.Int8PtrTy;
+
+  // Create a variable that binds the atexit to this shared object.
+  llvm::Constant *handle =
+  CGF.CGM.CreateRuntimeVariable(CGF.Int8Ty, "__dso_handle");
+  auto *GV = cast(handle->stripPointerCasts());
+  GV->setVisibility(llvm::GlobalValue::HiddenVisibility);
+
   // extern "C" int __cxa_atexit(void (*f)(void *), void *p, void *d);
-  llvm::Type *paramTys[] = { dtorTy, CGF.Int8PtrTy, CGF.Int8PtrTy };
+  llvm::Type *paramTys[] = {dtorTy, AddrInt8PtrTy, handle->getType()};
   llvm::FunctionType *atexitTy =
 llvm::FunctionType::get(CGF.IntTy, paramTys, false);
 
@@ -2294,12 +2305,6 @@
   if (llvm::Function *fn = dyn_cast(atexit.getCallee()))
 fn->setDoesNotThrow();
 
-  // Create a variable that binds the atexit to this shared object.
-  llvm::Constant *handle =
-  CGF.CGM.CreateRuntimeVariable(CGF.Int8Ty, "__dso_handle");
-  auto *GV = cast(handle->stripPointerCasts());
-  GV->setVisibility(llvm::GlobalValue::HiddenVisibility);
-
   if (!addr)
 // addr is null when we are trying to register a dtor annotated with
 // __attribute__((destructor)) in a constructor function. Using null here is
@@ -2309,7 +2314,7 @@
 
   llvm::Value *args[] = {llvm::ConstantExpr::getBitCast(
  cast(dtor.getCallee()), dtorTy),
- llvm::ConstantExpr::getBitCast(addr, CGF.Int8PtrTy),
+ llvm::ConstantExpr::getBitCast(addr, AddrInt8PtrTy),
  handle};
   CGF.EmitNounwindRuntimeCall(atexit, args);
 }
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -3577,8 +3577,12 @@
 llvm::Constant *
 CodeGenModule::CreateRuntimeVariable(llvm::Type *Ty,
  StringRef Name) {
-  auto *Ret =
-  GetOrCreateLLVMGlobal(Name, llvm::PointerType::getUnqual(Ty), nullptr);
+  auto PtrTy =
+  getContext().getLangOpts().OpenCL
+  ? llvm::PointerType::get(
+Ty, getContext().getTargetAddressSpace(LangAS::opencl_global))
+  : llvm::PointerType::getUnqual(Ty);
+  auto *Ret = GetOrCreateLLVMGlobal(Name, PtrTy, nullptr);
   setDSOLocal(cast(Ret->stripPointerCasts()));
   return Ret;
 }
Index: lib/CodeGen/CGDeclCXX.cpp
===
--- lib/CodeGen/CGDeclCXX.cpp
+++ lib/CodeGen/CGDeclCXX.cpp
@@ -14,6 +14,7 @@
 #include "CGCXXABI.h"
 #include "CGObjCRuntime.h"
 #include "CGOpenMPRuntime.h"
+#include "TargetInfo.h"
 #include "clang/Basic/CodeGenOptions.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/IR/Intrinsics.h"
@@ -118,9 +119,22 @@
 CXXDestructorDecl *Dtor = Record->getDestructor();
 
 Func = CGM.getAddrAndTypeOfCXXStructor(Glo

[PATCH] D62413: [OpenCL][PR41727] Prevent ICE on global dtors

[Anastasia Stulova via Phabricator via cfe-commits]

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



Comment at: lib/CodeGen/CGDeclCXX.cpp:132
+  Argument = CGM.getTargetCodeGenInfo().performAddrSpaceCast(
+  CGM, Addr.getPointer(), SrcAS, LangAS::opencl_global, DestTy);
 

rjmccall wrote:
> Anastasia wrote:
> > rjmccall wrote:
> > > rjmccall wrote:
> > > > Anastasia wrote:
> > > > > rjmccall wrote:
> > > > > > Anastasia wrote:
> > > > > > > rjmccall wrote:
> > > > > > > > Should this code be conditional to OpenCL?  And why does 
> > > > > > > > `_cxa_atexit` take a `__global` pointer instead of, say, a 
> > > > > > > > `__generic` one?
> > > > > > > The only objects that are destructible globally in OpenCL are 
> > > > > > > `__global` and `__constant`. However `__constant` isn't 
> > > > > > > convertible to `__generic`. Therefore, I am adding `__global` 
> > > > > > > directly to avoid extra conversion. I am not yet sure how to 
> > > > > > > handle `__constant`though and how much destructing objects in 
> > > > > > > read-only memory segments would make sense anyway. I think I will 
> > > > > > > address this separately.
> > > > > > The pointer argument to `__cxa_atexit` is just an arbitrary bit of 
> > > > > > context and doesn't have to actually be the address of a global.  
> > > > > > It's *convenient* to use the address of a global sometimes; e.g. 
> > > > > > you can use the global as the pointer and its destructor as the 
> > > > > > function, and then `__cxa_atexit` will just call the destructor for 
> > > > > > you without any additional code.  But as far as the runtime is 
> > > > > > concerned, the pointer could be `malloc`'ed or something; we've 
> > > > > > never had a need to do that in the ABI, but it's good 
> > > > > > future-proofing to allow it.
> > > > > > 
> > > > > > So there are three ways to get a global destructor to destroy a 
> > > > > > variable in `__constant`:
> > > > > > - You can pass the pointer bitcast'ed as long as `sizeof(__constant 
> > > > > > void*) <= sizeof(__cxa_atexit_context_pointer)`.
> > > > > > - You can ignore the argument and just materialize the address 
> > > > > > separately within the destructor function.
> > > > > > - You can allocate memory for a context and then store the pointer 
> > > > > > in that.
> > > > > > 
> > > > > > Obviously you should go with the one of the first two, but you 
> > > > > > should make sure your ABI doesn't preclude doing the latter in case 
> > > > > > it's useful for some future language feature.  In other words, it 
> > > > > > doesn't really matter whether this argument is notionally in 
> > > > > > `__global` as long as that's wide enough to pass a more-or-less 
> > > > > > arbitrary pointer through.
> > > > > Ok, I see. I guess option 1 would be fine since we can't setup 
> > > > > pointer width per address space in clang currently. However, spec 
> > > > > doesn't provide any clarifications in this regard.
> > > > > 
> > > > > So I guess using either `__global` or `__generic` for the pointer 
> > > > > parameter would be fine... Or perhaps even leave it without any 
> > > > > address space (i.e. _`_private`) and just addrspacecast from either 
> > > > > `__global` or `__constant`. Do you have any preferences?
> > > > > 
> > > > > As for `malloc` I am not sure that will work for OpenCL since we 
> > > > > don't allow mem allocation on the device. Unless you mean the memory 
> > > > > is allocated on a host... then I am not sure how it should work.
> > > > > Ok, I see. I guess option 1 would be fine since we can't setup 
> > > > > pointer width per address space in clang currently.
> > > > 
> > > > Really?  What's missing there?  It looks to me like `getPointerSize` 
> > > > does take an address space.
> > > > 
> > > > > So I guess using either __global or __generic for the pointer 
> > > > > parameter would be fine... Or perhaps even leave it without any 
> > > > > address space (i.e. _`_private`) and just addrspacecast from either 
> > > > > __global or __constant. Do you have any preferences?
> > > > 
> > > > `__private` is likely to be a smaller address space, right?  I would 
> > > > recommend using the fattest pointer that you want to actually support 
> > > > at runtime — you shouldn't go all the way to `__generic` if the target 
> > > > relies on eliminating that statically.  If you want a target hook for 
> > > > the address space of the notional `__cxa_atexit_context_pointer` 
> > > > typedef, I think that would be reasonable.
> > > > 
> > > > > As for malloc I am not sure that will work for OpenCL since we don't 
> > > > > allow mem allocation on the device. Unless you mean the memory is 
> > > > > allocated on a host... then I am not sure how it should work.
> > > > 
> > > > Well, maybe not actually heap-allocated.  I just think you should 
> > > > design the ABI so that it's reasonably future-proof against taking any 
> > > > specific sort of reasonable pointer.
> > > This cast on

Re: [clang-tools-extra] r365867 - [clangd] Implement typeHierarchy/resolve for subtypes

[Russell Gallop via cfe-commits]

Hi Nathan,
This is causing a test failure on Windows:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26909

Please can you take a look?

Thanks
Russ

[ RUN  ] Subtypes.LazyResolution
Preamble for file C:\clangd-test\TestTU.cpp cannot be reused. Attempting to
rebuild it.
Built preamble of size 210988 for file C:\clangd-test\TestTU.cpp
Preamble for file C:\clangd-test\TestTU.cpp cannot be reused. Attempting to
rebuild it.
Built preamble of size 210988 for file C:\clangd-test\TestTU.cpp
index AST for C:\clangd-test\TestTU.cpp (main=false):
  symbol slab: 4 symbols, 5152 bytes
  ref slab: 0 symbols, 0 refs, 136 bytes
  relations slab: 3 relations, 84 bytes
index AST for C:\clangd-test\TestTU.cpp (main=true):
  symbol slab: 4 symbols, 5152 bytes
  ref slab: 0 symbols, 0 refs, 136 bytes
  relations slab: 3 relations, 84 bytes
Expected must be checked before access or destruction.
Unchecked Expected contained error:
Hint path doesn't start with test root: /clangd-test/TestTU.cpp
0x7FF7486D1B25 (0x0016 0x7FF7486D1B20
0x7FF70006 0x7FF748680AF4)
0x7FFF3F0EE19D (0x01CDE35AA701 0x01CD
0x01CDE35AA7B0 0x01CDE35AB111), raise() + 0x1DD bytes(s)
0x7FFF3F0EF071 (0x0003 0x00290003
0x01CDE35AB111 0x00294FD8E330), abort() + 0x31 bytes(s)
...

On Fri, 12 Jul 2019 at 04:26, Nathan Ridge via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: nridge
> Date: Thu Jul 11 20:26:32 2019
> New Revision: 365867
>
> URL: http://llvm.org/viewvc/llvm-project?rev=365867&view=rev
> Log:
> [clangd] Implement typeHierarchy/resolve for subtypes
>
> Summary:
> This allows the client to resolve subtypes one level at a time.
>
> For supertypes, this is not necessary, because we eagerly compute
> supertypes and return all levels.
>
> Reviewers: sammccall
>
> Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet,
> cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D64308
>
> Modified:
> clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
> clang-tools-extra/trunk/clangd/ClangdLSPServer.h
> clang-tools-extra/trunk/clangd/ClangdServer.cpp
> clang-tools-extra/trunk/clangd/ClangdServer.h
> clang-tools-extra/trunk/clangd/Protocol.cpp
> clang-tools-extra/trunk/clangd/Protocol.h
> clang-tools-extra/trunk/clangd/XRefs.cpp
> clang-tools-extra/trunk/clangd/XRefs.h
> clang-tools-extra/trunk/clangd/test/type-hierarchy.test
> clang-tools-extra/trunk/clangd/unittests/TypeHierarchyTests.cpp
>
> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=365867&r1=365866&r2=365867&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Thu Jul 11 20:26:32
> 2019
> @@ -926,6 +926,13 @@ void ClangdLSPServer::onTypeHierarchy(
>  Params.resolve, Params.direction,
> std::move(Reply));
>  }
>
> +void ClangdLSPServer::onResolveTypeHierarchy(
> +const ResolveTypeHierarchyItemParams &Params,
> +Callback> Reply) {
> +  Server->resolveTypeHierarchy(Params.item, Params.resolve,
> Params.direction,
> +   std::move(Reply));
> +}
> +
>  void ClangdLSPServer::applyConfiguration(
>  const ConfigurationSettings &Settings) {
>// Per-file update to the compilation database.
> @@ -1021,6 +1028,7 @@ ClangdLSPServer::ClangdLSPServer(
>MsgHandler->bind("workspace/didChangeConfiguration",
> &ClangdLSPServer::onChangeConfiguration);
>MsgHandler->bind("textDocument/symbolInfo",
> &ClangdLSPServer::onSymbolInfo);
>MsgHandler->bind("textDocument/typeHierarchy",
> &ClangdLSPServer::onTypeHierarchy);
> +  MsgHandler->bind("typeHierarchy/resolve",
> &ClangdLSPServer::onResolveTypeHierarchy);
>// clang-format on
>  }
>
>
> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.h
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.h?rev=365867&r1=365866&r2=365867&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.h (original)
> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.h Thu Jul 11 20:26:32
> 2019
> @@ -100,6 +100,8 @@ private:
> Callback>);
>void onTypeHierarchy(const TypeHierarchyParams &,
> Callback>);
> +  void onResolveTypeHierarchy(const ResolveTypeHierarchyItemParams &,
> +
> Callback>);
>void onChangeConfiguration(const DidChangeConfigurationParams &);
>void onSymbolInfo(const TextDocumentPositionParams &,
>  Callback>);
>
> Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
> URL:
> http://llvm.org/viewvc

[PATCH] D64563: Updated the signature for some stack related intrinsics (CLANG)

[Christudasan Devadasan via Phabricator via cfe-commits]

cdevadas updated this revision to Diff 209467.
cdevadas added a comment.

Added alloca address space.


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

https://reviews.llvm.org/D64563

Files:
  lib/CodeGen/CGBuiltin.cpp
  lib/CodeGen/CGException.cpp
  test/CodeGen/builtin-sponentry.c
  test/CodeGen/exceptions-seh.c
  test/CodeGen/integer-overflow.c
  test/CodeGen/ms-intrinsics.c
  test/CodeGen/ms-setjmp.c

Index: test/CodeGen/ms-setjmp.c
===
--- test/CodeGen/ms-setjmp.c
+++ test/CodeGen/ms-setjmp.c
@@ -20,12 +20,12 @@
   // I386-NEXT:  ret i32 %[[call]]
 
   // X64-LABEL: define dso_local i32 @test_setjmp
-  // X64:   %[[addr:.*]] = call i8* @llvm.frameaddress(i32 0)
+  // X64:   %[[addr:.*]] = call i8* @llvm.frameaddress.p0i8(i32 0)
   // X64:   %[[call:.*]] = call i32 @_setjmp(i8* getelementptr inbounds ([1 x i8], [1 x i8]* @jb, i64 0, i64 0), i8* %[[addr]])
   // X64-NEXT:  ret i32 %[[call]]
 
   // AARCH64-LABEL: define dso_local i32 @test_setjmp
-  // AARCH64:   %[[addr:.*]] = call i8* @llvm.sponentry()
+  // AARCH64:   %[[addr:.*]] = call i8* @llvm.sponentry.p0i8()
   // AARCH64:   %[[call:.*]] = call i32 @_setjmpex(i8* getelementptr inbounds ([1 x i8], [1 x i8]* @jb, i64 0, i64 0), i8* %[[addr]])
   // AARCH64-NEXT:  ret i32 %[[call]]
 }
@@ -33,12 +33,12 @@
 int test_setjmpex() {
   return _setjmpex(jb);
   // X64-LABEL: define dso_local i32 @test_setjmpex
-  // X64:   %[[addr:.*]] = call i8* @llvm.frameaddress(i32 0)
+  // X64:   %[[addr:.*]] = call i8* @llvm.frameaddress.p0i8(i32 0)
   // X64:   %[[call:.*]] = call i32 @_setjmpex(i8* getelementptr inbounds ([1 x i8], [1 x i8]* @jb, i64 0, i64 0), i8* %[[addr]])
   // X64-NEXT:  ret i32 %[[call]]
 
   // AARCH64-LABEL: define dso_local i32 @test_setjmpex
-  // AARCH64:   %[[addr:.*]] = call i8* @llvm.sponentry()
+  // AARCH64:   %[[addr:.*]] = call i8* @llvm.sponentry.p0i8()
   // AARCH64:   %[[call:.*]] = call i32 @_setjmpex(i8* getelementptr inbounds ([1 x i8], [1 x i8]* @jb, i64 0, i64 0), i8* %[[addr]])
   // AARCH64-NEXT:  ret i32 %[[call]]
 }
Index: test/CodeGen/ms-intrinsics.c
===
--- test/CodeGen/ms-intrinsics.c
+++ test/CodeGen/ms-intrinsics.c
@@ -142,7 +142,7 @@
   return _AddressOfReturnAddress();
 }
 // CHECK-INTEL-LABEL: define dso_local i8* @test_AddressOfReturnAddress()
-// CHECK-INTEL: = tail call i8* @llvm.addressofreturnaddress()
+// CHECK-INTEL: = tail call i8* @llvm.addressofreturnaddress.p0i8()
 // CHECK-INTEL: ret i8*
 #endif
 
Index: test/CodeGen/integer-overflow.c
===
--- test/CodeGen/integer-overflow.c
+++ test/CodeGen/integer-overflow.c
@@ -99,8 +99,8 @@
 
   // PR24256: don't instrument __builtin_frame_address.
   __builtin_frame_address(0 + 0);
-  // DEFAULT:  call i8* @llvm.frameaddress(i32 0)
-  // WRAPV:call i8* @llvm.frameaddress(i32 0)
-  // TRAPV:call i8* @llvm.frameaddress(i32 0)
-  // CATCH_UB: call i8* @llvm.frameaddress(i32 0)
+  // DEFAULT:  call i8* @llvm.frameaddress.p0i8(i32 0)
+  // WRAPV:call i8* @llvm.frameaddress.p0i8(i32 0)
+  // TRAPV:call i8* @llvm.frameaddress.p0i8(i32 0)
+  // CATCH_UB: call i8* @llvm.frameaddress.p0i8(i32 0)
 }
Index: test/CodeGen/exceptions-seh.c
===
--- test/CodeGen/exceptions-seh.c
+++ test/CodeGen/exceptions-seh.c
@@ -51,7 +51,7 @@
 // 32-bit SEH needs this filter to save the exception code.
 //
 // X86-LABEL: define internal i32 @"?filt$0@0@safe_div@@"()
-// X86: %[[ebp:[^ ]*]] = call i8* @llvm.frameaddress(i32 1)
+// X86: %[[ebp:[^ ]*]] = call i8* @llvm.frameaddress.p0i8(i32 1)
 // X86: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 (i32, i32, i32*)* @safe_div to i8*), i8* %[[ebp]])
 // X86: call i8* @llvm.localrecover(i8* bitcast (i32 (i32, i32, i32*)* @safe_div to i8*), i8* %[[fp]], i32 0)
 // X86: load i8*, i8**
@@ -103,7 +103,7 @@
 // ARM64: call i8* @llvm.localrecover(i8* bitcast (i32 ()* @filter_expr_capture to i8*), i8* %[[fp]], i32 0)
 //
 // X86-LABEL: define internal i32 @"?filt$0@0@filter_expr_capture@@"()
-// X86: %[[ebp:[^ ]*]] = call i8* @llvm.frameaddress(i32 1)
+// X86: %[[ebp:[^ ]*]] = call i8* @llvm.frameaddress.p0i8(i32 1)
 // X86: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 ()* @filter_expr_capture to i8*), i8* %[[ebp]])
 // X86: call i8* @llvm.localrecover(i8* bitcast (i32 ()* @filter_expr_capture to i8*), i8* %[[fp]], i32 0)
 //
Index: test/CodeGen/builtin-sponentry.c
===
--- test/CodeGen/builtin-sponentry.c
+++ test/CodeGen/builtin-sponentry.c
@@ -4,5 +4,5 @@
   return __builtin_sponentry();
 }
 // CHECK-LABEL: define dso_local i8* @test_sponentry()
-// CHECK: = tail call i8* @llvm.sponentry()
+// CHECK: = tail call i8* @llvm.s

[PATCH] D64062: Remove both -dumpversion and __VERSION__

[Sylvestre Ledru via Phabricator via cfe-commits]

sylvestre.ledru updated this revision to Diff 209473.
sylvestre.ledru added a comment.

Keep -dumpversion


Repository:
  rC Clang

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

https://reviews.llvm.org/D64062

Files:
  docs/ClangCommandLineReference.rst
  docs/LanguageExtensions.rst
  docs/ReleaseNotes.rst
  include/clang/Driver/Options.td
  lib/Basic/Version.cpp
  lib/Driver/Driver.cpp
  lib/Frontend/InitPreprocessor.cpp
  test/Driver/immediate-options.c
  test/Index/complete-exprs.c
  test/Preprocessor/init.c
  utils/builtin-defines.c

Index: utils/builtin-defines.c
===
--- utils/builtin-defines.c
+++ utils/builtin-defines.c
@@ -49,7 +49,6 @@
 #undef __INT8_TYPE__
 #undef __SSP__
 #undef __APPLE_CC__
-#undef __VERSION__
 #undef __clang__
 #undef __llvm__
 #undef __nocona
Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -101,7 +101,6 @@
 // COMMON:#define __ORDER_PDP_ENDIAN__ 3412
 // COMMON:#define __STDC_HOSTED__ 1
 // COMMON:#define __STDC__ 1
-// COMMON:#define __VERSION__ {{.*}}
 // COMMON:#define __clang__ 1
 // COMMON:#define __clang_major__ {{[0-9]+}}
 // COMMON:#define __clang_minor__ {{[0-9]+}}
@@ -8169,7 +8168,6 @@
 // SPARC:#define __UINT_LEAST8_MAX__ 255
 // SPARC:#define __UINT_LEAST8_TYPE__ unsigned char
 // SPARC:#define __USER_LABEL_PREFIX__
-// SPARC:#define __VERSION__ "4.2.1 Compatible{{.*}}
 // SPARC:#define __WCHAR_MAX__ 2147483647
 // SPARC:#define __WCHAR_TYPE__ int
 // SPARC:#define __WCHAR_WIDTH__ 32
@@ -9041,7 +9039,6 @@
 // X86_64-CLOUDABI:#define __UINT_LEAST8_MAX__ 255
 // X86_64-CLOUDABI:#define __UINT_LEAST8_TYPE__ unsigned char
 // X86_64-CLOUDABI:#define __USER_LABEL_PREFIX__
-// X86_64-CLOUDABI:#define __VERSION__ "4.2.1 Compatible{{.*}}
 // X86_64-CLOUDABI:#define __WCHAR_MAX__ 2147483647
 // X86_64-CLOUDABI:#define __WCHAR_TYPE__ int
 // X86_64-CLOUDABI:#define __WCHAR_WIDTH__ 32
@@ -10043,7 +10040,6 @@
 // WEBASSEMBLY-NEXT:#define __UINT_LEAST8_MAX__ 255
 // WEBASSEMBLY-NEXT:#define __UINT_LEAST8_TYPE__ unsigned char
 // WEBASSEMBLY-NEXT:#define __USER_LABEL_PREFIX__
-// WEBASSEMBLY-NEXT:#define __VERSION__ "{{.*}}"
 // WEBASSEMBLY-NEXT:#define __WCHAR_MAX__ 2147483647
 // WEBASSEMBLY-NEXT:#define __WCHAR_TYPE__ int
 // WEBASSEMBLY-NOT:#define __WCHAR_UNSIGNED__
Index: test/Index/complete-exprs.c
===
--- test/Index/complete-exprs.c
+++ test/Index/complete-exprs.c
@@ -27,7 +27,6 @@
 // RUN: c-index-test -code-completion-at=%s:7:10 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC1 %s
 // RUN: env CINDEXTEST_EDITING=1 CINDEXTEST_COMPLETION_CACHING=1 c-index-test -code-completion-at=%s:7:10 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC1 %s
 // CHECK-CC1: NotImplemented:{TypedText __PRETTY_FUNCTION__} (65)
-// CHECK-CC1: macro definition:{TypedText __VERSION__} (70)
 // CHECK-CC1: FunctionDecl:{ResultType int}{TypedText f}{LeftParen (}{Placeholder int}{RightParen )} (12) (unavailable)
 // CHECK-CC1-NOT: NotImplemented:{TypedText float} (65)
 // CHECK-CC1: ParmDecl:{ResultType int}{TypedText j} (8)
@@ -39,7 +38,6 @@
 // RUN: c-index-test -code-completion-at=%s:7:18 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC1 %s
 // RUN: c-index-test -code-completion-at=%s:7:22 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC1 %s
 // RUN: c-index-test -code-completion-at=%s:7:2 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC2 %s
-// CHECK-CC2: macro definition:{TypedText __VERSION__} (70)
 // CHECK-CC2: FunctionDecl:{ResultType int}{TypedText f}{LeftParen (}{Placeholder int}{RightParen )} (50)
 // CHECK-CC2: NotImplemented:{TypedText float} (50)
 // CHECK-CC2: ParmDecl:{ResultType int}{TypedText j} (34)
Index: test/Driver/immediate-options.c
===
--- test/Driver/immediate-options.c
+++ test/Driver/immediate-options.c
@@ -6,9 +6,6 @@
 // RUN: %clang --help-hidden | FileCheck %s -check-prefix=HELP-HIDDEN
 // HELP-HIDDEN: driver-mode
 
-// RUN: %clang -dumpversion | FileCheck %s -check-prefix=DUMPVERSION
-// DUMPVERSION: {{[0-9]+\.[0-9.]+}}
-
 // RUN: %clang -print-search-dirs | FileCheck %s -check-prefix=PRINT-SEARCH-DIRS
 // PRINT-SEARCH-DIRS: programs: ={{.*}}
 // PRINT-SEARCH-DIRS: libraries: ={{.*}}
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -604,12 +604,6 @@
   // Support for #pragma redefine_extname (Sun compatibility)
   Builder.defineMacro("__PRAGMA_REDEFINE_EXTNAME", "1");
 
-  // As sad as it is, enough software depends on the __VERSION__ for version
-  // checks that it is necessary to report 4.2.1 (

[PATCH] D64062: Remove both -dumpversion and __VERSION__

[Sylvestre Ledru via Phabricator via cfe-commits]

sylvestre.ledru updated this revision to Diff 209474.
sylvestre.ledru added a comment.

Actually remove it


Repository:
  rC Clang

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

https://reviews.llvm.org/D64062

Files:
  docs/LanguageExtensions.rst
  docs/ReleaseNotes.rst
  lib/Basic/Version.cpp
  lib/Frontend/InitPreprocessor.cpp
  test/Index/complete-exprs.c
  test/Preprocessor/init.c
  utils/builtin-defines.c

Index: utils/builtin-defines.c
===
--- utils/builtin-defines.c
+++ utils/builtin-defines.c
@@ -49,7 +49,6 @@
 #undef __INT8_TYPE__
 #undef __SSP__
 #undef __APPLE_CC__
-#undef __VERSION__
 #undef __clang__
 #undef __llvm__
 #undef __nocona
Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -101,7 +101,6 @@
 // COMMON:#define __ORDER_PDP_ENDIAN__ 3412
 // COMMON:#define __STDC_HOSTED__ 1
 // COMMON:#define __STDC__ 1
-// COMMON:#define __VERSION__ {{.*}}
 // COMMON:#define __clang__ 1
 // COMMON:#define __clang_major__ {{[0-9]+}}
 // COMMON:#define __clang_minor__ {{[0-9]+}}
@@ -8169,7 +8168,6 @@
 // SPARC:#define __UINT_LEAST8_MAX__ 255
 // SPARC:#define __UINT_LEAST8_TYPE__ unsigned char
 // SPARC:#define __USER_LABEL_PREFIX__
-// SPARC:#define __VERSION__ "4.2.1 Compatible{{.*}}
 // SPARC:#define __WCHAR_MAX__ 2147483647
 // SPARC:#define __WCHAR_TYPE__ int
 // SPARC:#define __WCHAR_WIDTH__ 32
@@ -9041,7 +9039,6 @@
 // X86_64-CLOUDABI:#define __UINT_LEAST8_MAX__ 255
 // X86_64-CLOUDABI:#define __UINT_LEAST8_TYPE__ unsigned char
 // X86_64-CLOUDABI:#define __USER_LABEL_PREFIX__
-// X86_64-CLOUDABI:#define __VERSION__ "4.2.1 Compatible{{.*}}
 // X86_64-CLOUDABI:#define __WCHAR_MAX__ 2147483647
 // X86_64-CLOUDABI:#define __WCHAR_TYPE__ int
 // X86_64-CLOUDABI:#define __WCHAR_WIDTH__ 32
@@ -10043,7 +10040,6 @@
 // WEBASSEMBLY-NEXT:#define __UINT_LEAST8_MAX__ 255
 // WEBASSEMBLY-NEXT:#define __UINT_LEAST8_TYPE__ unsigned char
 // WEBASSEMBLY-NEXT:#define __USER_LABEL_PREFIX__
-// WEBASSEMBLY-NEXT:#define __VERSION__ "{{.*}}"
 // WEBASSEMBLY-NEXT:#define __WCHAR_MAX__ 2147483647
 // WEBASSEMBLY-NEXT:#define __WCHAR_TYPE__ int
 // WEBASSEMBLY-NOT:#define __WCHAR_UNSIGNED__
Index: test/Index/complete-exprs.c
===
--- test/Index/complete-exprs.c
+++ test/Index/complete-exprs.c
@@ -27,7 +27,6 @@
 // RUN: c-index-test -code-completion-at=%s:7:10 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC1 %s
 // RUN: env CINDEXTEST_EDITING=1 CINDEXTEST_COMPLETION_CACHING=1 c-index-test -code-completion-at=%s:7:10 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC1 %s
 // CHECK-CC1: NotImplemented:{TypedText __PRETTY_FUNCTION__} (65)
-// CHECK-CC1: macro definition:{TypedText __VERSION__} (70)
 // CHECK-CC1: FunctionDecl:{ResultType int}{TypedText f}{LeftParen (}{Placeholder int}{RightParen )} (12) (unavailable)
 // CHECK-CC1-NOT: NotImplemented:{TypedText float} (65)
 // CHECK-CC1: ParmDecl:{ResultType int}{TypedText j} (8)
@@ -39,7 +38,6 @@
 // RUN: c-index-test -code-completion-at=%s:7:18 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC1 %s
 // RUN: c-index-test -code-completion-at=%s:7:22 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC1 %s
 // RUN: c-index-test -code-completion-at=%s:7:2 -Xclang -code-completion-patterns %s | FileCheck -check-prefix=CHECK-CC2 %s
-// CHECK-CC2: macro definition:{TypedText __VERSION__} (70)
 // CHECK-CC2: FunctionDecl:{ResultType int}{TypedText f}{LeftParen (}{Placeholder int}{RightParen )} (50)
 // CHECK-CC2: NotImplemented:{TypedText float} (50)
 // CHECK-CC2: ParmDecl:{ResultType int}{TypedText j} (34)
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -604,12 +604,6 @@
   // Support for #pragma redefine_extname (Sun compatibility)
   Builder.defineMacro("__PRAGMA_REDEFINE_EXTNAME", "1");
 
-  // As sad as it is, enough software depends on the __VERSION__ for version
-  // checks that it is necessary to report 4.2.1 (the base GCC version we claim
-  // compatibility with) first.
-  Builder.defineMacro("__VERSION__", "\"4.2.1 Compatible " +
-  Twine(getClangFullCPPVersion()) + "\"");
-
   // Initialize language-specific preprocessor defines.
 
   // Standard conforming mode?
Index: lib/Basic/Version.cpp
===
--- lib/Basic/Version.cpp
+++ lib/Basic/Version.cpp
@@ -136,8 +136,6 @@
 }
 
 std::string getClangFullCPPVersion() {
-  // The version string we report in __VERSION__ is just a compacted version of
-  // the one we report on the command line.
   std::string buf;
   llvm::raw_string_ostream OS(buf);
 #ifdef CLANG_VENDOR

r365898 - [Driver] Delete dead code

[Fangrui Song via cfe-commits]

Author: maskray
Date: Fri Jul 12 06:21:58 2019
New Revision: 365898

URL: http://llvm.org/viewvc/llvm-project?rev=365898&view=rev
Log:
[Driver] Delete dead code

Modified:
cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp?rev=365898&r1=365897&r2=365898&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/Mips.cpp Fri Jul 12 06:21:58 2019
@@ -246,7 +246,6 @@ void mips::getMIPSTargetFeatures(const D
   if (IsN64 && NonPIC && (!ABICallsArg || UseAbiCalls)) {
 D.Diag(diag::warn_drv_unsupported_pic_with_mabicalls)
 << LastPICArg->getAsString(Args) << (!ABICallsArg ? 0 : 1);
-NonPIC = false;
   }
 
   if (ABICallsArg && !UseAbiCalls && IsPIC) {

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=365898&r1=365897&r2=365898&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Fri Jul 12 06:21:58 2019
@@ -3448,19 +3448,14 @@ void Clang::ConstructJob(Compilation &C,
   }
 
   const llvm::Triple *AuxTriple = IsCuda ? TC.getAuxTriple() : nullptr;
-  bool IsWindowsGNU = RawTriple.isWindowsGNUEnvironment();
-  bool IsWindowsCygnus = RawTriple.isWindowsCygwinEnvironment();
   bool IsWindowsMSVC = RawTriple.isWindowsMSVCEnvironment();
   bool IsIAMCU = RawTriple.isOSIAMCU();
 
   // Adjust IsWindowsXYZ for CUDA/HIP compilations.  Even when compiling in
   // device mode (i.e., getToolchain().getTriple() is NVPTX/AMDGCN, not
   // Windows), we need to pass Windows-specific flags to cc1.
-  if (IsCuda || IsHIP) {
+  if (IsCuda || IsHIP)
 IsWindowsMSVC |= AuxTriple && AuxTriple->isWindowsMSVCEnvironment();
-IsWindowsGNU |= AuxTriple && AuxTriple->isWindowsGNUEnvironment();
-IsWindowsCygnus |= AuxTriple && AuxTriple->isWindowsCygwinEnvironment();
-  }
 
   // C++ is not supported for IAMCU.
   if (IsIAMCU && types::isCXX(Input.getType()))


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

[clang-tools-extra] r365899 - Revert "[clangd] Implement typeHierarchy/resolve for subtypes"

[Russell Gallop via cfe-commits]

Author: russell_gallop
Date: Fri Jul 12 06:35:58 2019
New Revision: 365899

URL: http://llvm.org/viewvc/llvm-project?rev=365899&view=rev
Log:
Revert "[clangd] Implement typeHierarchy/resolve for subtypes"

Causing test failure on Windows bot

This reverts commit 5b9484e559d44bd923fc290e335891b1dd2e17c4.

Modified:
clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
clang-tools-extra/trunk/clangd/ClangdLSPServer.h
clang-tools-extra/trunk/clangd/ClangdServer.cpp
clang-tools-extra/trunk/clangd/ClangdServer.h
clang-tools-extra/trunk/clangd/Protocol.cpp
clang-tools-extra/trunk/clangd/Protocol.h
clang-tools-extra/trunk/clangd/XRefs.cpp
clang-tools-extra/trunk/clangd/XRefs.h
clang-tools-extra/trunk/clangd/test/type-hierarchy.test
clang-tools-extra/trunk/clangd/unittests/TypeHierarchyTests.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=365899&r1=365898&r2=365899&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Fri Jul 12 06:35:58 2019
@@ -926,13 +926,6 @@ void ClangdLSPServer::onTypeHierarchy(
 Params.resolve, Params.direction, std::move(Reply));
 }
 
-void ClangdLSPServer::onResolveTypeHierarchy(
-const ResolveTypeHierarchyItemParams &Params,
-Callback> Reply) {
-  Server->resolveTypeHierarchy(Params.item, Params.resolve, Params.direction,
-   std::move(Reply));
-}
-
 void ClangdLSPServer::applyConfiguration(
 const ConfigurationSettings &Settings) {
   // Per-file update to the compilation database.
@@ -1028,7 +1021,6 @@ ClangdLSPServer::ClangdLSPServer(
   MsgHandler->bind("workspace/didChangeConfiguration", 
&ClangdLSPServer::onChangeConfiguration);
   MsgHandler->bind("textDocument/symbolInfo", &ClangdLSPServer::onSymbolInfo);
   MsgHandler->bind("textDocument/typeHierarchy", 
&ClangdLSPServer::onTypeHierarchy);
-  MsgHandler->bind("typeHierarchy/resolve", 
&ClangdLSPServer::onResolveTypeHierarchy);
   // clang-format on
 }
 

Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.h?rev=365899&r1=365898&r2=365899&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.h (original)
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.h Fri Jul 12 06:35:58 2019
@@ -100,8 +100,6 @@ private:
Callback>);
   void onTypeHierarchy(const TypeHierarchyParams &,
Callback>);
-  void onResolveTypeHierarchy(const ResolveTypeHierarchyItemParams &,
-  Callback>);
   void onChangeConfiguration(const DidChangeConfigurationParams &);
   void onSymbolInfo(const TextDocumentPositionParams &,
 Callback>);

Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=365899&r1=365898&r2=365899&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Fri Jul 12 06:35:58 2019
@@ -528,13 +528,6 @@ void ClangdServer::typeHierarchy(PathRef
   WorkScheduler.runWithAST("Type Hierarchy", File, Bind(Action, 
std::move(CB)));
 }
 
-void ClangdServer::resolveTypeHierarchy(
-TypeHierarchyItem Item, int Resolve, TypeHierarchyDirection Direction,
-Callback> CB) {
-  clangd::resolveTypeHierarchy(Item, Resolve, Direction, Index);
-  CB(Item);
-}
-
 void ClangdServer::onFileEvent(const DidChangeWatchedFilesParams &Params) {
   // FIXME: Do nothing for now. This will be used for indexing and potentially
   // invalidating other caches.

Modified: clang-tools-extra/trunk/clangd/ClangdServer.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.h?rev=365899&r1=365898&r2=365899&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.h (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.h Fri Jul 12 06:35:58 2019
@@ -210,11 +210,6 @@ public:
  TypeHierarchyDirection Direction,
  Callback> CB);
 
-  /// Resolve type hierarchy item in the given direction.
-  void resolveTypeHierarchy(TypeHierarchyItem Item, int Resolve,
-TypeHierarchyDirection Direction,
-Callback> CB);
-
   /// Retrieve the top symbols from the workspace matching a query.
   void workspaceSymbols(StringRef Query, int Limit,
 Callback> CB);

Modified: clang-tools-extra/trunk/clan

[PATCH] D56563: [clang-tidy] add options documentation to readability-identifier-naming checker

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.
Herald added a project: LLVM.

Is this doc supposed to be autogenerated somehow?
I believe `MacroDefinitionCase` (D21020 ) is 
missing from it, maybe others.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56563



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

[PATCH] D64062: Remove __VERSION__

[Sylvestre Ledru via Phabricator via cfe-commits]

sylvestre.ledru added a comment.

@rnk Should be good this time :)


Repository:
  rC Clang

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

https://reviews.llvm.org/D64062



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

[PATCH] D64632: [clang-format] Don't detect call to ObjC class method as C++11 attribute specifier

[Robbie Gibson via Phabricator via cfe-commits]

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D64632

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7027,6 +7027,10 @@
   // On the other hand, we still need to correctly find array subscripts.
   verifyFormat("int a = std::vector{1, 2, 3}[0];");
 
+  // Make sure that we do not mistake a call to the Objective-C method named
+  // "class" inside an array literal as attributes.
+  verifyFormat("@[ [NSArray class] ];");
+
   // Make sure we do not parse attributes as lambda introducers.
   FormatStyle MultiLineFunctions = getLLVMStyle();
   MultiLineFunctions.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -400,9 +400,11 @@
 while (AttrTok && !AttrTok->startsSequence(tok::r_square, tok::r_square)) {
   // ObjC message send. We assume nobody will use : in a C++11 attribute
   // specifier parameter, although this is technically valid:
-  // [[foo(:)]]
+  // [[foo(:)]]. 'class' is a common ObjC method selector, so allow it as
+  // well.
   if (AttrTok->is(tok::colon) ||
   AttrTok->startsSequence(tok::identifier, tok::identifier) ||
+  AttrTok->startsSequence(tok::identifier, tok::kw_class) ||
   AttrTok->startsSequence(tok::r_paren, tok::identifier))
 return false;
   if (AttrTok->is(tok::ellipsis))


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7027,6 +7027,10 @@
   // On the other hand, we still need to correctly find array subscripts.
   verifyFormat("int a = std::vector{1, 2, 3}[0];");
 
+  // Make sure that we do not mistake a call to the Objective-C method named
+  // "class" inside an array literal as attributes.
+  verifyFormat("@[ [NSArray class] ];");
+
   // Make sure we do not parse attributes as lambda introducers.
   FormatStyle MultiLineFunctions = getLLVMStyle();
   MultiLineFunctions.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -400,9 +400,11 @@
 while (AttrTok && !AttrTok->startsSequence(tok::r_square, tok::r_square)) {
   // ObjC message send. We assume nobody will use : in a C++11 attribute
   // specifier parameter, although this is technically valid:
-  // [[foo(:)]]
+  // [[foo(:)]]. 'class' is a common ObjC method selector, so allow it as
+  // well.
   if (AttrTok->is(tok::colon) ||
   AttrTok->startsSequence(tok::identifier, tok::identifier) ||
+  AttrTok->startsSequence(tok::identifier, tok::kw_class) ||
   AttrTok->startsSequence(tok::r_paren, tok::identifier))
 return false;
   if (AttrTok->is(tok::ellipsis))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r365901 - Delete dead stores

[Fangrui Song via cfe-commits]

Author: maskray
Date: Fri Jul 12 07:04:34 2019
New Revision: 365901

URL: http://llvm.org/viewvc/llvm-project?rev=365901&view=rev
Log:
Delete dead stores

Modified:
cfe/trunk/lib/CodeGen/CGCoroutine.cpp
cfe/trunk/lib/Lex/Lexer.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp

Modified: cfe/trunk/lib/CodeGen/CGCoroutine.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCoroutine.cpp?rev=365901&r1=365900&r2=365901&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCoroutine.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCoroutine.cpp Fri Jul 12 07:04:34 2019
@@ -204,7 +204,6 @@ static LValueOrRValue emitSuspendExpress
 BasicBlock *RealSuspendBlock =
 CGF.createBasicBlock(Prefix + Twine(".suspend.bool"));
 CGF.Builder.CreateCondBr(SuspendRet, RealSuspendBlock, ReadyBlock);
-SuspendBlock = RealSuspendBlock;
 CGF.EmitBlock(RealSuspendBlock);
   }
 

Modified: cfe/trunk/lib/Lex/Lexer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Lexer.cpp?rev=365901&r1=365900&r2=365901&view=diff
==
--- cfe/trunk/lib/Lex/Lexer.cpp (original)
+++ cfe/trunk/lib/Lex/Lexer.cpp Fri Jul 12 07:04:34 2019
@@ -687,7 +687,6 @@ PreambleBounds Lexer::ComputePreamble(St
   // We only end up here if we didn't recognize the preprocessor
   // directive or it was one that can't occur in the preamble at this
   // point. Roll back the current token to the location of the '#'.
-  InPreprocessorDirective = false;
   TheTok = HashTok;
 }
 
@@ -3232,7 +3231,7 @@ LexNextToken:
 
   case '\r':
 if (CurPtr[0] == '\n')
-  Char = getAndAdvanceChar(CurPtr, Result);
+  (void)getAndAdvanceChar(CurPtr, Result);
 LLVM_FALLTHROUGH;
   case '\n':
 // If we are inside a preprocessor directive and we see the end of line,

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=365901&r1=365900&r2=365901&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Jul 12 07:04:34 2019
@@ -3237,7 +3237,6 @@ bool Sema::MergeFunctionDecl(FunctionDec
 AdjustedType = Context.adjustFunctionType(AdjustedType, NewTypeInfo);
 New->setType(QualType(AdjustedType, 0));
 NewQType = Context.getCanonicalType(New->getType());
-NewType = cast(NewQType);
   }
 
   // If this redeclaration makes the function inline, we may need to add it to

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp?rev=365901&r1=365900&r2=365901&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp Fri Jul 12 
07:04:34 2019
@@ -753,10 +753,9 @@ void NonLocalizedStringChecker::reportLo
   if (isDebuggingContext(C))
 return;
 
-  ExplodedNode *ErrNode = C.getPredecessor();
   static CheckerProgramPointTag Tag("NonLocalizedStringChecker",
 "UnlocalizedString");
-  ErrNode = C.addTransition(C.getState(), C.getPredecessor(), &Tag);
+  ExplodedNode *ErrNode = C.addTransition(C.getState(), C.getPredecessor(), 
&Tag);
 
   if (!ErrNode)
 return;


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

[PATCH] D64634: [clangd] Fix duplicate highlighting tokens appearing in initializer lists

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

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

The RecursiveASTVisitor sometimes visits exprs in initializer lists twice. 
Added deduplication to prevent duplicate highlighting tokens from appearing. 
Done by sorting and a linear search.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D64634

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


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -132,6 +132,13 @@
 $Namespace[[vwz]]::$Class[[A]]::$Enum[[B]]::Hi;
   ::$Namespace[[vwz]]::$Class[[A]] $Variable[[B]];
   ::$Namespace[[abc]]::$Namespace[[bcd]]::$Class[[A]] $Variable[[BB]];
+)cpp",
+R"cpp(
+  struct $Class[[AA]] {
+int A;
+  }
+  int $Variable[[B]];
+  $Class[[AA]] $Variable[[A]]{$Variable[[B]]};
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -40,6 +40,7 @@
 };
 
 bool operator==(const HighlightingToken &Lhs, const HighlightingToken &Rhs);
+bool operator<(const HighlightingToken &Lhs, const HighlightingToken &Rhs);
 
 // Returns all HighlightingTokens from an AST. Only generates highlights for 
the
 // main AST.
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -31,6 +31,16 @@
   std::vector collectTokens() {
 Tokens.clear();
 TraverseAST(Ctx);
+// Initializer lists can give duplicates of tokens, therefore all tokens
+// must be deduplicated.
+std::sort(Tokens.begin(), Tokens.end());
+for (unsigned I = 1; I < Tokens.size(); ++I) {
+  if (Tokens[I] == Tokens[I - 1]) {
+Tokens.erase(Tokens.begin() + I);
+--I;
+  }
+}
+
 return Tokens;
   }
 
@@ -70,7 +80,6 @@
 DeclarationName::Identifier)
   // Only want to highlight identifiers.
   return true;
-
 addToken(Ref->getLocation(), Ref->getDecl());
 return true;
   }
@@ -201,6 +210,10 @@
   return Lhs.Kind == Rhs.Kind && Lhs.R == Rhs.R;
 }
 
+bool operator<(const HighlightingToken &Lhs, const HighlightingToken &Rhs) {
+  return Lhs.R.start < Rhs.R.start;
+}
+
 std::vector getSemanticHighlightings(ParsedAST &AST) {
   return HighlightingTokenCollector(AST).collectTokens();
 }


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -132,6 +132,13 @@
 $Namespace[[vwz]]::$Class[[A]]::$Enum[[B]]::Hi;
   ::$Namespace[[vwz]]::$Class[[A]] $Variable[[B]];
   ::$Namespace[[abc]]::$Namespace[[bcd]]::$Class[[A]] $Variable[[BB]];
+)cpp",
+R"cpp(
+  struct $Class[[AA]] {
+int A;
+  }
+  int $Variable[[B]];
+  $Class[[AA]] $Variable[[A]]{$Variable[[B]]};
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -40,6 +40,7 @@
 };
 
 bool operator==(const HighlightingToken &Lhs, const HighlightingToken &Rhs);
+bool operator<(const HighlightingToken &Lhs, const HighlightingToken &Rhs);
 
 // Returns all HighlightingTokens from an AST. Only generates highlights for the
 // main AST.
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -31,6 +31,16 @@
   std::vector collectTokens() {
 Tokens.clear();
 TraverseAST(Ctx);
+// Initializer lists can give duplicates of tokens, therefore all tokens
+// must be deduplicated.
+std::sort(Tokens.begin(), Tokens.end());
+for (unsigned I = 1; I < Tokens.size(); ++I) {
+  if (Tokens[I] == Tokens[I - 1]) {
+Tokens.erase(Tokens.begin() + I);
+--I;
+  }
+}
+
 retur

[PATCH] D64635: [CrossTU] Added CTU argument to diagnostic consumer create fn.

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

balazske created this revision.
Herald added subscribers: cfe-commits, gamesh411, Szelethus, dkrupp.
Herald added a project: clang.

The PListDiagnosticConsumer needs a new CTU parameter that is passed
through the create functions.


Repository:
  rC Clang

https://reviews.llvm.org/D64635

Files:
  include/clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h
  lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
  lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
  lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Index: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -64,19 +64,19 @@
 // Special PathDiagnosticConsumers.
 //===--===//
 
-void ento::createPlistHTMLDiagnosticConsumer(AnalyzerOptions &AnalyzerOpts,
- PathDiagnosticConsumers &C,
- const std::string &prefix,
- const Preprocessor &PP) {
+void ento::createPlistHTMLDiagnosticConsumer(
+AnalyzerOptions &AnalyzerOpts, PathDiagnosticConsumers &C,
+const std::string &prefix, const Preprocessor &PP,
+const cross_tu::CrossTranslationUnitContext &CTU) {
   createHTMLDiagnosticConsumer(AnalyzerOpts, C,
-   llvm::sys::path::parent_path(prefix), PP);
-  createPlistMultiFileDiagnosticConsumer(AnalyzerOpts, C, prefix, PP);
+   llvm::sys::path::parent_path(prefix), PP, CTU);
+  createPlistMultiFileDiagnosticConsumer(AnalyzerOpts, C, prefix, PP, CTU);
 }
 
-void ento::createTextPathDiagnosticConsumer(AnalyzerOptions &AnalyzerOpts,
-PathDiagnosticConsumers &C,
-const std::string &Prefix,
-const clang::Preprocessor &PP) {
+void ento::createTextPathDiagnosticConsumer(
+AnalyzerOptions &AnalyzerOpts, PathDiagnosticConsumers &C,
+const std::string &Prefix, const clang::Preprocessor &PP,
+const cross_tu::CrossTranslationUnitContext &CTU) {
   llvm_unreachable("'text' consumer should be enabled on ClangDiags");
 }
 
@@ -249,7 +249,7 @@
 default:
 #define ANALYSIS_DIAGNOSTICS(NAME, CMDFLAG, DESC, CREATEFN)\
   case PD_##NAME:  \
-CREATEFN(*Opts.get(), PathConsumers, OutDir, PP);   \
+CREATEFN(*Opts.get(), PathConsumers, OutDir, PP, CTU); \
 break;
 #include "clang/StaticAnalyzer/Core/Analyses.def"
 }
Index: lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
===
--- lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
+++ lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
@@ -43,10 +43,10 @@
 };
 } // end anonymous namespace
 
-void ento::createSarifDiagnosticConsumer(AnalyzerOptions &AnalyzerOpts,
- PathDiagnosticConsumers &C,
- const std::string &Output,
- const Preprocessor &) {
+void ento::createSarifDiagnosticConsumer(
+AnalyzerOptions &AnalyzerOpts, PathDiagnosticConsumers &C,
+const std::string &Output, const Preprocessor &,
+const cross_tu::CrossTranslationUnitContext &) {
   C.push_back(new SarifDiagnostics(AnalyzerOpts, Output));
 }
 
Index: lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
===
--- lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
+++ lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
@@ -14,6 +14,7 @@
 #include "clang/Basic/PlistSupport.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Version.h"
+#include "clang/CrossTU/CrossTranslationUnit.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Lex/TokenConcatenation.h"
 #include "clang/Rewrite/Core/HTMLRewrite.h"
@@ -21,9 +22,9 @@
 #include "clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h"
 #include "clang/StaticAnalyzer/Core/IssueHash.h"
 #include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
-#include "llvm/ADT/Statistic.h"
 #include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/Statistic.h"
 #include "llvm/Support/Casting.h"
 
 using namespace clang;
@@ -39,12 +40,13 @@
   class PlistDiagnostics : public PathDiagnosticConsumer {
 const std::string OutputFile;
 const Preprocessor &PP;
+const cross_tu::CrossTranslationUnitContext &CTU;
 AnalyzerOptions &AnOpts;
 const bool SupportsCrossFileDiagnostics;
   public:
-PlistDiagnostics(AnalyzerOptions &AnalyzerOpts,
- const std::string& prefix,
+PlistDiagno

r365902 - cmake: Add INSTALL_WITH_TOOLCHAIN option to add_*_library macros

[Tom Stellard via cfe-commits]

Author: tstellar
Date: Fri Jul 12 07:40:18 2019
New Revision: 365902

URL: http://llvm.org/viewvc/llvm-project?rev=365902&view=rev
Log:
cmake: Add INSTALL_WITH_TOOLCHAIN option to add_*_library macros

Summary:
This will simplify the macros by allowing us to remove the hard-coded
list of libraries that should be installed when
LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.

Reviewers: beanz, smeenai

Reviewed By: beanz

Subscribers: aheejin, mehdi_amini, mgorny, steven_wu, dexonsmith, cfe-commits, 
llvm-commits

Tags: #clang, #llvm

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

Modified:
cfe/trunk/cmake/modules/AddClang.cmake
cfe/trunk/tools/libclang/CMakeLists.txt

Modified: cfe/trunk/cmake/modules/AddClang.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/AddClang.cmake?rev=365902&r1=365901&r2=365902&view=diff
==
--- cfe/trunk/cmake/modules/AddClang.cmake (original)
+++ cfe/trunk/cmake/modules/AddClang.cmake Fri Jul 12 07:40:18 2019
@@ -44,7 +44,7 @@ endmacro()
 
 macro(add_clang_library name)
   cmake_parse_arguments(ARG
-"SHARED"
+"SHARED;INSTALL_WITH_TOOLCHAIN"
 ""
 "ADDITIONAL_HEADERS"
 ${ARGN})
@@ -97,7 +97,7 @@ macro(add_clang_library name)
   if(TARGET ${name})
 target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
 
-if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ${name} STREQUAL "libclang")
+if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
   set(export_to_clangtargets)
   if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
   "clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR

Modified: cfe/trunk/tools/libclang/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CMakeLists.txt?rev=365902&r1=365901&r2=365902&view=diff
==
--- cfe/trunk/tools/libclang/CMakeLists.txt (original)
+++ cfe/trunk/tools/libclang/CMakeLists.txt Fri Jul 12 07:40:18 2019
@@ -94,7 +94,7 @@ if (UNIX AND ${CMAKE_SYSTEM_NAME} MATCHE
 remove_definitions("-D_XOPEN_SOURCE=700")
 endif()
 
-add_clang_library(libclang ${ENABLE_SHARED} ${ENABLE_STATIC}
+add_clang_library(libclang ${ENABLE_SHARED} ${ENABLE_STATIC} 
INSTALL_WITH_TOOLCHAIN
   OUTPUT_NAME ${output_name}
   ${SOURCES}
   DEPENDS clang-resource-headers


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

[PATCH] D64580: cmake: Add INSTALL_WITH_TOOLCHAIN option to add_*_library macros

[Tom Stellard via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL365902: cmake: Add INSTALL_WITH_TOOLCHAIN option to 
add_*_library macros (authored by tstellar, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D64580?vs=209285&id=209482#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D64580

Files:
  cfe/trunk/cmake/modules/AddClang.cmake
  cfe/trunk/tools/libclang/CMakeLists.txt
  llvm/trunk/cmake/modules/AddLLVM.cmake
  llvm/trunk/tools/llvm-shlib/CMakeLists.txt
  llvm/trunk/tools/lto/CMakeLists.txt
  llvm/trunk/tools/remarks-shlib/CMakeLists.txt

Index: llvm/trunk/tools/remarks-shlib/CMakeLists.txt
===
--- llvm/trunk/tools/remarks-shlib/CMakeLists.txt
+++ llvm/trunk/tools/remarks-shlib/CMakeLists.txt
@@ -8,7 +8,7 @@
 
 set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/Remarks.exports)
 
-add_llvm_library(Remarks SHARED ${SOURCES})
+add_llvm_library(Remarks SHARED INSTALL_WITH_TOOLCHAIN ${SOURCES})
 
 install(FILES ${LLVM_MAIN_INCLUDE_DIR}/llvm-c/Remarks.h
   DESTINATION include/llvm-c
Index: llvm/trunk/tools/lto/CMakeLists.txt
===
--- llvm/trunk/tools/lto/CMakeLists.txt
+++ llvm/trunk/tools/lto/CMakeLists.txt
@@ -20,7 +20,7 @@
 
 set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/lto.exports)
 
-add_llvm_library(LTO SHARED ${SOURCES} DEPENDS intrinsics_gen)
+add_llvm_library(LTO SHARED INSTALL_WITH_TOOLCHAIN ${SOURCES} DEPENDS intrinsics_gen)
 
 install(FILES ${LLVM_MAIN_INCLUDE_DIR}/llvm-c/lto.h
   DESTINATION include/llvm-c
Index: llvm/trunk/tools/llvm-shlib/CMakeLists.txt
===
--- llvm/trunk/tools/llvm-shlib/CMakeLists.txt
+++ llvm/trunk/tools/llvm-shlib/CMakeLists.txt
@@ -39,7 +39,10 @@
 add_custom_target(libLLVMExports DEPENDS ${LLVM_EXPORTED_SYMBOL_FILE})
   endif()
 
-  add_llvm_library(LLVM SHARED DISABLE_LLVM_LINK_LLVM_DYLIB SONAME ${SOURCES})
+  if (LLVM_LINK_LLVM_DYLIB)
+set(INSTALL_WITH_TOOLCHAIN INSTALL_WITH_TOOLCHAIN)
+  endif()
+  add_llvm_library(LLVM SHARED DISABLE_LLVM_LINK_LLVM_DYLIB SONAME ${INSTALL_WITH_TOOLCHAIN} ${SOURCES})
 
   list(REMOVE_DUPLICATES LIB_NAMES)
   if(("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux") OR (MINGW) OR (HAIKU)
@@ -105,7 +108,7 @@
 
   add_custom_target(libLLVMCExports DEPENDS ${LLVM_EXPORTED_SYMBOL_FILE})
 
-  add_llvm_library(LLVM-C SHARED ${SOURCES})
+  add_llvm_library(LLVM-C SHARED ${SOURCES} INSTALL_WITH_TOOLCHAIN)
   
   target_link_libraries(LLVM-C PUBLIC LLVM)
   add_dependencies(LLVM-C libLLVMCExports)
Index: llvm/trunk/cmake/modules/AddLLVM.cmake
===
--- llvm/trunk/cmake/modules/AddLLVM.cmake
+++ llvm/trunk/cmake/modules/AddLLVM.cmake
@@ -657,7 +657,7 @@
 
 macro(add_llvm_library name)
   cmake_parse_arguments(ARG
-"SHARED;BUILDTREE_ONLY;MODULE"
+"SHARED;BUILDTREE_ONLY;MODULE;INSTALL_WITH_TOOLCHAIN"
 ""
 ""
 ${ARGN})
@@ -685,11 +685,7 @@
   elseif(ARG_BUILDTREE_ONLY)
 set_property(GLOBAL APPEND PROPERTY LLVM_EXPORTS_BUILDTREE_ONLY ${name})
   else()
-if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR
-${name} STREQUAL "LTO" OR
-${name} STREQUAL "LLVM-C" OR
-${name} STREQUAL "Remarks" OR
-(LLVM_LINK_LLVM_DYLIB AND ${name} STREQUAL "LLVM"))
+if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
 
   set(export_to_llvmexports)
   if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
Index: cfe/trunk/tools/libclang/CMakeLists.txt
===
--- cfe/trunk/tools/libclang/CMakeLists.txt
+++ cfe/trunk/tools/libclang/CMakeLists.txt
@@ -94,7 +94,7 @@
 remove_definitions("-D_XOPEN_SOURCE=700")
 endif()
 
-add_clang_library(libclang ${ENABLE_SHARED} ${ENABLE_STATIC}
+add_clang_library(libclang ${ENABLE_SHARED} ${ENABLE_STATIC} INSTALL_WITH_TOOLCHAIN
   OUTPUT_NAME ${output_name}
   ${SOURCES}
   DEPENDS clang-resource-headers
Index: cfe/trunk/cmake/modules/AddClang.cmake
===
--- cfe/trunk/cmake/modules/AddClang.cmake
+++ cfe/trunk/cmake/modules/AddClang.cmake
@@ -44,7 +44,7 @@
 
 macro(add_clang_library name)
   cmake_parse_arguments(ARG
-"SHARED"
+"SHARED;INSTALL_WITH_TOOLCHAIN"
 ""
 "ADDITIONAL_HEADERS"
 ${ARGN})
@@ -97,7 +97,7 @@
   if(TARGET ${name})
 target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
 
-if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ${name} STREQUAL "libclang")
+if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ARG_INSTALL_WITH_TOOLCHAIN)
   set(export_to_clangtargets)
   if(${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
   "clang-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
___

Re: [clang-tools-extra] r365867 - [clangd] Implement typeHierarchy/resolve for subtypes

[Russell Gallop via cfe-commits]

Hi Nathan,

I've reverted this to get the bot green(er).

Regards
Russ

On Fri, 12 Jul 2019 at 13:32, Russell Gallop 
wrote:

> Hi Nathan,
> This is causing a test failure on Windows:
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26909
>
> Please can you take a look?
>
> Thanks
> Russ
>
> [ RUN  ] Subtypes.LazyResolution
> Preamble for file C:\clangd-test\TestTU.cpp cannot be reused. Attempting
> to rebuild it.
> Built preamble of size 210988 for file C:\clangd-test\TestTU.cpp
> Preamble for file C:\clangd-test\TestTU.cpp cannot be reused. Attempting
> to rebuild it.
> Built preamble of size 210988 for file C:\clangd-test\TestTU.cpp
> index AST for C:\clangd-test\TestTU.cpp (main=false):
>   symbol slab: 4 symbols, 5152 bytes
>   ref slab: 0 symbols, 0 refs, 136 bytes
>   relations slab: 3 relations, 84 bytes
> index AST for C:\clangd-test\TestTU.cpp (main=true):
>   symbol slab: 4 symbols, 5152 bytes
>   ref slab: 0 symbols, 0 refs, 136 bytes
>   relations slab: 3 relations, 84 bytes
> Expected must be checked before access or destruction.
> Unchecked Expected contained error:
> Hint path doesn't start with test root: /clangd-test/TestTU.cpp
> 0x7FF7486D1B25 (0x0016 0x7FF7486D1B20
> 0x7FF70006 0x7FF748680AF4)
> 0x7FFF3F0EE19D (0x01CDE35AA701 0x01CD
> 0x01CDE35AA7B0 0x01CDE35AB111), raise() + 0x1DD bytes(s)
> 0x7FFF3F0EF071 (0x0003 0x00290003
> 0x01CDE35AB111 0x00294FD8E330), abort() + 0x31 bytes(s)
> ...
>
> On Fri, 12 Jul 2019 at 04:26, Nathan Ridge via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: nridge
>> Date: Thu Jul 11 20:26:32 2019
>> New Revision: 365867
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=365867&view=rev
>> Log:
>> [clangd] Implement typeHierarchy/resolve for subtypes
>>
>> Summary:
>> This allows the client to resolve subtypes one level at a time.
>>
>> For supertypes, this is not necessary, because we eagerly compute
>> supertypes and return all levels.
>>
>> Reviewers: sammccall
>>
>> Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet,
>> cfe-commits
>>
>> Tags: #clang
>>
>> Differential Revision: https://reviews.llvm.org/D64308
>>
>> Modified:
>> clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
>> clang-tools-extra/trunk/clangd/ClangdLSPServer.h
>> clang-tools-extra/trunk/clangd/ClangdServer.cpp
>> clang-tools-extra/trunk/clangd/ClangdServer.h
>> clang-tools-extra/trunk/clangd/Protocol.cpp
>> clang-tools-extra/trunk/clangd/Protocol.h
>> clang-tools-extra/trunk/clangd/XRefs.cpp
>> clang-tools-extra/trunk/clangd/XRefs.h
>> clang-tools-extra/trunk/clangd/test/type-hierarchy.test
>> clang-tools-extra/trunk/clangd/unittests/TypeHierarchyTests.cpp
>>
>> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=365867&r1=365866&r2=365867&view=diff
>>
>> ==
>> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
>> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Thu Jul 11
>> 20:26:32 2019
>> @@ -926,6 +926,13 @@ void ClangdLSPServer::onTypeHierarchy(
>>  Params.resolve, Params.direction,
>> std::move(Reply));
>>  }
>>
>> +void ClangdLSPServer::onResolveTypeHierarchy(
>> +const ResolveTypeHierarchyItemParams &Params,
>> +Callback> Reply) {
>> +  Server->resolveTypeHierarchy(Params.item, Params.resolve,
>> Params.direction,
>> +   std::move(Reply));
>> +}
>> +
>>  void ClangdLSPServer::applyConfiguration(
>>  const ConfigurationSettings &Settings) {
>>// Per-file update to the compilation database.
>> @@ -1021,6 +1028,7 @@ ClangdLSPServer::ClangdLSPServer(
>>MsgHandler->bind("workspace/didChangeConfiguration",
>> &ClangdLSPServer::onChangeConfiguration);
>>MsgHandler->bind("textDocument/symbolInfo",
>> &ClangdLSPServer::onSymbolInfo);
>>MsgHandler->bind("textDocument/typeHierarchy",
>> &ClangdLSPServer::onTypeHierarchy);
>> +  MsgHandler->bind("typeHierarchy/resolve",
>> &ClangdLSPServer::onResolveTypeHierarchy);
>>// clang-format on
>>  }
>>
>>
>> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.h?rev=365867&r1=365866&r2=365867&view=diff
>>
>> ==
>> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.h (original)
>> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.h Thu Jul 11 20:26:32
>> 2019
>> @@ -100,6 +100,8 @@ private:
>> Callback>);
>>void onTypeHierarchy(const TypeHierarchyParams &,
>> Callback>);
>> +  void onResolveTypeHierarchy(const ResolveTypeHierarchyItemPara

Re: r365887 - [JSONCompilationDatabase] Strip distcc/ccache/gomacc wrappers from parsed commands.

[Russell Gallop via cfe-commits]

Hi Sam,

This is hitting a test failure on a Windows bot:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26916

Please could you take a look?

Thanks
Russ

On Fri, 12 Jul 2019 at 11:11, Sam McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: sammccall
> Date: Fri Jul 12 03:11:40 2019
> New Revision: 365887
>
> URL: http://llvm.org/viewvc/llvm-project?rev=365887&view=rev
> Log:
> [JSONCompilationDatabase] Strip distcc/ccache/gomacc wrappers from parsed
> commands.
>
> Summary:
> It's common to use compiler wrappers by setting CC="gomacc clang++".
> This results in both args appearing in compile_commands.json, and clang's
> driver
> can't handle this.
>
> This patch attempts to recognize this pattern (by looking for well-known
> wrappers) and dropping argv0 in this case.
>
> It conservatively ignores other cases for now:
>  - wrappers with unknown names
>  - wrappers that accept -flags
>  - wrappers where the compiler to use is implied (usually cc or gcc)
>
> This is done at the JSONCompilationDatabase level rather than somewhere
> more
> fundamental, as (hopefully) this isn't a general conceptual problem, but a
> messy
> aspect of the nature of the ecosystem around compile_commands.json.
> i.e. compilation databases more tightly tied to the build system should
> not have
> this problem.
>
> Reviewers: phosek, klimek
>
> Subscribers: llvm-commits
>
> Tags: #llvm
>
> Differential Revision: https://reviews.llvm.org/D64297
>
> Modified:
> cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp
> cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp
>
> Modified: cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp?rev=365887&r1=365886&r2=365887&view=diff
>
> ==
> --- cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp (original)
> +++ cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp Fri Jul 12 03:11:40
> 2019
> @@ -256,15 +256,57 @@ JSONCompilationDatabase::getAllCompileCo
>return Commands;
>  }
>
> +static llvm::StringRef stripExecutableExtension(llvm::StringRef Name) {
> +  Name.consume_back(".exe");
> +  return Name;
> +}
> +
> +// There are compiler-wrappers (ccache, distcc, gomacc) that take the
> "real"
> +// compiler as an argument, e.g. distcc gcc -O3 foo.c.
> +// These end up in compile_commands.json when people set CC="distcc gcc".
> +// Clang's driver doesn't understand this, so we need to unwrap.
> +static bool unwrapCommand(std::vector &Args) {
> +  if (Args.size() < 2)
> +return false;
> +  StringRef Wrapper =
> +  stripExecutableExtension(llvm::sys::path::filename(Args.front()));
> +  if (Wrapper == "distcc" || Wrapper == "gomacc" || Wrapper == "ccache") {
> +// Most of these wrappers support being invoked 3 ways:
> +// `distcc g++ file.c` This is the mode we're trying to match.
> +// We need to drop `distcc`.
> +// `distcc file.c` This acts like compiler is cc or similar.
> +// Clang's driver can handle this, no change
> needed.
> +// `g++ file.c`g++ is a symlink to distcc.
> +// We don't even notice this case, and all is
> well.
> +//
> +// We need to distinguish between the first and second case.
> +// The wrappers themselves don't take flags, so Args[1] is a compiler
> flag,
> +// an input file, or a compiler. Inputs have extensions, compilers
> don't.
> +bool HasCompiler =
> +(Args[1][0] != '-') &&
> +
> !llvm::sys::path::has_extension(stripExecutableExtension(Args[1]));
> +if (HasCompiler) {
> +  Args.erase(Args.begin());
> +  return true;
> +}
> +// If !HasCompiler, wrappers act like GCC. Fine: so do we.
> +  }
> +  return false;
> +}
> +
>  static std::vector
>  nodeToCommandLine(JSONCommandLineSyntax Syntax,
>const std::vector &Nodes) {
>SmallString<1024> Storage;
> -  if (Nodes.size() == 1)
> -return unescapeCommandLine(Syntax, Nodes[0]->getValue(Storage));
>std::vector Arguments;
> -  for (const auto *Node : Nodes)
> -Arguments.push_back(Node->getValue(Storage));
> +  if (Nodes.size() == 1)
> +Arguments = unescapeCommandLine(Syntax, Nodes[0]->getValue(Storage));
> +  else
> +for (const auto *Node : Nodes)
> +  Arguments.push_back(Node->getValue(Storage));
> +  // There may be multiple wrappers: using distcc and ccache together is
> common.
> +  while (unwrapCommand(Arguments))
> +;
>return Arguments;
>  }
>
>
> Modified: cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp?rev=365887&r1=365886&r2=365887&view=diff
>
> ==
> --- cfe/trunk/unittests/Tooling/CompilationData

[PATCH] D56661: [clang-tidy] Fix incorrect array name generation in cppcoreguidelines-pro-bounds-constant-array-index

[Dmitry Venikov via Phabricator via cfe-commits]

Quolyk updated this revision to Diff 209485.
Quolyk added a comment.
Herald added a subscriber: wuzish.
Herald added a project: clang.

Update. Solution is not elegant, because DeclRef->BaseRange somehow has zero 
length.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56661

Files:
  clang-tidy/cppcoreguidelines/ProBoundsConstantArrayIndexCheck.cpp
  
test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index-gslheader.cpp
  test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
===
--- test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index.cpp
@@ -23,46 +23,46 @@
   return base + 3;
 }
 
-void f(std::array a, int pos) {
-  a [ pos / 2 /*comment*/] = 1;
+void f(std::array list, int pos) {
+  list [ pos / 2 /*comment*/] = 1;
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use array subscript when the index is not an integer constant expression; use gsl::at() instead [cppcoreguidelines-pro-bounds-constant-array-index]
-  int j = a[pos - 1];
+  int j = list[pos - 1];
   // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: do not use array subscript when the index is not an integer constant expression; use gsl::at() instead
 
-  a.at(pos-1) = 2; // OK, at() instead of []
-  gsl::at(a, pos-1) = 2; // OK, gsl::at() instead of []
+  list.at(pos-1) = 2; // OK, at() instead of []
+  gsl::at(list, pos-1) = 2; // OK, gsl::at() instead of []
 
-  a[-1] = 3;
+  list[-1] = 3;
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: std::array<> index -1 is negative [cppcoreguidelines-pro-bounds-constant-array-index]
-  a[10] = 4;
+  list[10] = 4;
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: std::array<> index 10 is past the end of the array (which contains 10 elements) [cppcoreguidelines-pro-bounds-constant-array-index]
 
-  a[const_index(7)] = 3;
+  list[const_index(7)] = 3;
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: std::array<> index 10 is past the end of the array (which contains 10 elements)
 
-  a[0] = 3; // OK, constant index and inside bounds
-  a[1] = 3; // OK, constant index and inside bounds
-  a[9] = 3; // OK, constant index and inside bounds
-  a[const_index(6)] = 3; // OK, constant index and inside bounds
+  list[0] = 3; // OK, constant index and inside bounds
+  list[1] = 3; // OK, constant index and inside bounds
+  list[9] = 3; // OK, constant index and inside bounds
+  list[const_index(6)] = 3; // OK, constant index and inside bounds
 }
 
 void g() {
-  int a[10];
+  int list[10];
   for (int i = 0; i < 10; ++i) {
-a[i] = i;
+list[i] = i;
 // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: do not use array subscript when the index is not an integer constant expression; use gsl::at() instead
-// CHECK-FIXES: gsl::at(a, i) = i;
-gsl::at(a, i) = i; // OK, gsl::at() instead of []
+// CHECK-FIXES: gsl::at(list, i) = i;
+gsl::at(list, i) = i; // OK, gsl::at() instead of []
   }
 
-  a[-1] = 3; // flagged by clang-diagnostic-array-bounds
-  a[10] = 4; // flagged by clang-diagnostic-array-bounds
-  a[const_index(7)] = 3; // flagged by clang-diagnostic-array-bounds
-
-  a[0] = 3; // OK, constant index and inside bounds
-  a[1] = 3; // OK, constant index and inside bounds
-  a[9] = 3; // OK, constant index and inside bounds
-  a[const_index(6)] = 3; // OK, constant index and inside bounds
+  list[-1] = 3; // flagged by clang-diagnostic-array-bounds
+  list[10] = 4; // flagged by clang-diagnostic-array-bounds
+  list[const_index(7)] = 3; // flagged by clang-diagnostic-array-bounds
+
+  list[0] = 3; // OK, constant index and inside bounds
+  list[1] = 3; // OK, constant index and inside bounds
+  list[9] = 3; // OK, constant index and inside bounds
+  list[const_index(6)] = 3; // OK, constant index and inside bounds
 }
 
 struct S {
Index: test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index-gslheader.cpp
===
--- test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index-gslheader.cpp
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-constant-array-index-gslheader.cpp
@@ -25,48 +25,48 @@
   return base + 3;
 }
 
-void f(std::array a, int pos) {
-  a [ pos / 2 /*comment*/] = 1;
+void f(std::array list, int pos) {
+  list [ pos / 2 /*comment*/] = 1;
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not use array subscript when the index is not an integer constant expression; use gsl::at() instead [cppcoreguidelines-pro-bounds-constant-array-index]
-  // CHECK-FIXES: gsl::at(a,  pos / 2 /*comment*/) = 1;
-  int j = a[pos - 1];
+  // CHECK-FIXES: gsl::at(list,  pos / 2 /*comment*/) = 1;
+  int j = list[pos - 1];
   // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: do not use array subscript when the

[PATCH] D64638: [CrossTU] Fix plist macro expansion if macro in other file.

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

balazske created this revision.
Herald added subscribers: cfe-commits, gamesh411, Szelethus, dkrupp.
Herald added a project: clang.

When cross TU analysis is used it is possible that a macro expansion
is generated for a macro that is defined (and used) in other than
the main translation unit. To get the expansion for it the source
location in the original source file and original preprocessor
is needed.


Repository:
  rC Clang

https://reviews.llvm.org/D64638

Files:
  lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  test/Analysis/Inputs/plist-macros-ctu.c
  test/Analysis/Inputs/plist-macros-ctu.h
  test/Analysis/Inputs/plist-macros-with-expansion-ctu.c.externalDefMap.txt
  test/Analysis/plist-macros-with-expansion-ctu.c

Index: test/Analysis/plist-macros-with-expansion-ctu.c
===
--- /dev/null
+++ test/Analysis/plist-macros-with-expansion-ctu.c
@@ -0,0 +1,80 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: mkdir -p %t/ctudir
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu \
+// RUN:   -emit-pch -o %t/ctudir/plist-macros-ctu.c.ast %S/Inputs/plist-macros-ctu.c
+// RUN: cp %S/Inputs/plist-macros-with-expansion-ctu.c.externalDefMap.txt %t/ctudir/externalDefMap.txt
+
+// RUN: %clang_analyze_cc1 -analyzer-checker=core \
+// RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
+// RUN:   -analyzer-config ctu-dir=%t/ctudir \
+// RUN:   -analyzer-config expand-macros=true \
+// RUN:   -analyzer-output=plist-multi-file -o %t.plist -verify %s
+
+// Check the macro expansions from the plist output here, to make the test more
+// understandable.
+//   RUN: FileCheck --input-file=%t.plist %s
+
+extern void F1(int **);
+extern void F2(int **);
+extern void F3(int **);
+extern void F_H(int **);
+
+void test0() {
+  int *X;
+  F3(&X);
+  *X = 1; // expected-warning{{Dereference of null pointer}}
+}
+// CHECK: nameM1
+// CHECK-NEXT: expansion*Z = (int *)0
+
+
+void test1() {
+  int *X;
+  F1(&X);
+  *X = 1; // expected-warning{{Dereference of null pointer}}
+}
+// CHECK: nameM
+// CHECK-NEXT: expansion*X = (int *)0
+
+void test2() {
+  int *X;
+  F2(&X);
+  *X = 1; // expected-warning{{Dereference of null pointer}}
+}
+// CHECK: nameM
+// CHECK-NEXT: expansion*Y = (int *)0
+
+#define M F1(&X)
+
+void test3() {
+  int *X;
+  M;
+  *X = 1; // expected-warning{{Dereference of null pointer}}
+}
+// CHECK: nameM
+// CHECK-NEXT: expansionF1(&X)
+// CHECK: nameM
+// CHECK-NEXT: expansion*X = (int *)0
+
+#undef M
+#define M F2(&X)
+
+void test4() {
+  int *X;
+  M;
+  *X = 1; // expected-warning{{Dereference of null pointer}}
+}
+
+// CHECK: nameM
+// CHECK-NEXT: expansionF2(&X)
+// CHECK: nameM
+// CHECK-NEXT: expansion*Y = (int *)0
+
+void test_h() {
+  int *X;
+  F_H(&X);
+  *X = 1; // expected-warning{{Dereference of null pointer}}
+}
+
+// CHECK: nameM_H
+// CHECK-NEXT: expansion*A = (int *)0
Index: test/Analysis/Inputs/plist-macros-with-expansion-ctu.c.externalDefMap.txt
===
--- /dev/null
+++ test/Analysis/Inputs/plist-macros-with-expansion-ctu.c.externalDefMap.txt
@@ -0,0 +1,4 @@
+c:@F@F1 plist-macros-ctu.c.ast
+c:@F@F2 plist-macros-ctu.c.ast
+c:@F@F3 plist-macros-ctu.c.ast
+c:@F@F_H plist-macros-ctu.c.ast
Index: test/Analysis/Inputs/plist-macros-ctu.h
===
--- /dev/null
+++ test/Analysis/Inputs/plist-macros-ctu.h
@@ -0,0 +1,4 @@
+#define M_H *A = (int *)0
+void F_H(int **A) {
+  M_H;
+}
Index: test/Analysis/Inputs/plist-macros-ctu.c
===
--- /dev/null
+++ test/Analysis/Inputs/plist-macros-ctu.c
@@ -0,0 +1,21 @@
+
+#include "plist-macros-ctu.h"
+
+#define M *X = (int *)0
+
+void F1(int **X) {
+  M;
+}
+
+#undef M
+#define M *Y = (int *)0
+
+void F2(int **Y) {
+  M;
+}
+
+#define M1 *Z = (int *)0
+
+void F3(int **Z) {
+  M1;
+}
Index: lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
===
--- lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
+++ lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
@@ -15,6 +15,7 @@
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Version.h"
 #include "clang/CrossTU/CrossTranslationUnit.h"
+#include "clang/Frontend/ASTUnit.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Lex/TokenConcatenation.h"
 #include "clang/Rewrite/Core/HTMLRewrite.h"
@@ -75,12 +76,14 @@
   const FIDMap& FM;
   AnalyzerOptions &AnOpts;
   const Preprocessor &PP;
+  const cross_tu::CrossTranslationUnitContext &CTU;
   llvm::SmallVector MacroPieces;
 
 public:
   PlistPrinter(const FIDMap& FM, AnalyzerOptions &AnOpts,
-   const Preprocessor &PP)
-: FM(FM), AnOpts(AnOpts), PP(PP) {
+   const Preprocessor &PP,
+   const cross_tu::CrossTranslationUnitContext &CTU)
+: FM(FM), AnOpts(AnOpts), PP(PP), CTU(CTU) {
   }
 
   void ReportDiag(raw_ostream &o, const 

[PATCH] D62584: [OpenCL][PR42033] Deducing addr space with template parameter types

[Anastasia Stulova via Phabricator via cfe-commits]

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



Comment at: lib/Sema/TreeTransform.h:5363
+if (ResultType.getAddressSpace() != LangAS::Default &&
+(ResultType.getAddressSpace() != LangAS::opencl_private)) {
   SemaRef.Diag(TL.getReturnLoc().getBeginLoc(),

rjmccall wrote:
> Anastasia wrote:
> > rjmccall wrote:
> > > Anastasia wrote:
> > > > Anastasia wrote:
> > > > > rjmccall wrote:
> > > > > > Anastasia wrote:
> > > > > > > I am trying to be a bit more helpful here although I am not sure 
> > > > > > > if we should instead require explicit template parameter and fail 
> > > > > > > the template deduction instead.
> > > > > > > 
> > > > > > > Basically, do we want the following code to always require 
> > > > > > > specifying template argument explicitly:
> > > > > > > 
> > > > > > > 
> > > > > > > ```
> > > > > > > template 
> > > > > > > T xxx(T *in) {
> > > > > > >   T *i = in;
> > > > > > >   return *i;
> > > > > > > }
> > > > > > > 
> > > > > > > __kernel void test() {
> > > > > > >   int foo[10];
> > > > > > >   xxx(&foo[0]); // if we deduce type from foo, it ends up 
> > > > > > > being qualified by __private that we currently diagnose. However 
> > > > > > > private is default (implicit) address space for return type so 
> > > > > > > technically there is no danger in just allowing xxx(&foo[0])
> > > > > > > }
> > > > > > > ```
> > > > > > Implicitly ignoring all address-space qualifiers on the return type 
> > > > > > seems like the right thing to do; I don't think it needs to be 
> > > > > > limited to `__private`.  That's probably also the right thing to do 
> > > > > > for locals, but I'm less certain about it.
> > > > > Just to clarify by "Implicitly ignoring" you mean ignoring if the 
> > > > > templ parameters were deduced?
> > > > > 
> > > > > Although I am a bit concerned about allowing other than `__private` 
> > > > > address spaces in return types as we reject them in return types of 
> > > > > functions generally. Would it not be somehow inconsistent?
> > > > Ok, I have removed the diagnostic completely. At least we don't seem to 
> > > > generate any incorrect IR.
> > > They should be diagnosed somehow when written explicitly on a return 
> > > type, but if you just do that on the parser path you don't have to worry 
> > > about it during template instantiation.  They should probably otherwise 
> > > be ignored no matter where they came from — if someone typedefs 
> > > `private_int_t` to `__private int`, you should just treat that as `int` 
> > > in a return type.  Stripping the qualifier from the type is probably the 
> > > right thing to do so that it doesn't further impact semantic analysis.
> > > 
> > > I definitely don't think you want a model where the qualifier actually 
> > > means that the return is somehow done via an object in that address space.
> > > They should be diagnosed somehow when written explicitly on a return 
> > > type, but if you just do that on the parser path you don't have to worry 
> > > about it during template instantiation.
> > 
> > Ok, this seems to be working currently. The following won't compile:
> > 
> > ```
> > template 
> > struct S {
> >   __global T f1(); // error: return value cannot be qualified with 
> > address space
> > };
> > 
> > ```
> > 
> > > They should probably otherwise be ignored no matter where they came from 
> > > — if someone typedefs private_int_t to __private int, you should just 
> > > treat that as int in a return type.
> > 
> > We produce diagnostic for this case currently. I can update this in a 
> > separate patch if you think it's more helpful behavior. Although I feel a 
> > bit worried about it. However it would align with what we are doing with 
> > templates here... so perhaps it's logical change... 
> > 
> > > Stripping the qualifier from the type is probably the right thing to do 
> > > so that it doesn't further impact semantic analysis.
> > 
> > I guess you mean stripping quals for the case of typedef or others where we 
> > will accept the code and ignore quals on the return type? I have tried to 
> > do this just for the template case but there are some assertions firing 
> > because we are expecting the original return type to be the same before and 
> > after template instantiation. So it feels like I would have to do it for 
> > everything together. Maybe it should rather go into separate review?
> > We produce diagnostic for this case currently. I can update this in a 
> > separate patch if you think it's more helpful behavior. Although I feel a 
> > bit worried about it. However it would align with what we are doing with 
> > templates here... so perhaps it's logical change...
> 
> Well, it's debatable.  C doesn't say that qualifiers are erased in function 
> return types in general.  On the other hand, qualifiers are semantically 
> meaningless there, and C has few rules that rely on exact type identity.  On 
> reflectio

r365905 - cmake: Fix install of libclang-cpp.so when LLVM_INSTALL_TOOLCHAIN_ONLY=ON

[Tom Stellard via cfe-commits]

Author: tstellar
Date: Fri Jul 12 08:11:28 2019
New Revision: 365905

URL: http://llvm.org/viewvc/llvm-project?rev=365905&view=rev
Log:
cmake: Fix install of libclang-cpp.so when LLVM_INSTALL_TOOLCHAIN_ONLY=ON

Summary:
If CLANG_LINK_CLANG_DYLIB is also enabled, then this library needs to be
installed.

Fixes PR42575.

Reviewers: beanz, smeenai

Subscribers: mgorny, cfe-commits

Tags: #clang

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

Conflicts:
clang/tools/clang-shlib/CMakeLists.txt

Modified:
cfe/trunk/tools/clang-shlib/CMakeLists.txt

Modified: cfe/trunk/tools/clang-shlib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-shlib/CMakeLists.txt?rev=365905&r1=365904&r2=365905&view=diff
==
--- cfe/trunk/tools/clang-shlib/CMakeLists.txt (original)
+++ cfe/trunk/tools/clang-shlib/CMakeLists.txt Fri Jul 12 08:11:28 2019
@@ -38,8 +38,13 @@ foreach (lib ${clang_libs})
   list(APPEND _DEPS ${lib})
 endforeach ()
 
+if (CLANG_LINK_CLANG_DYLIB)
+  set(INSTALL_WITH_TOOLCHAIN INSTALL_WITH_TOOLCHAIN)
+endif()
+
 add_clang_library(clang-cpp
   SHARED
+  ${INSTALL_WITH_TOOLCHAIN}
   clang-shlib.cpp
   ${_OBJECTS}
   LINK_LIBS


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

[PATCH] D64400: [OpenCL][PR42390] Deduce addr space for templ specialization

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D64400#1582142 , @rjmccall wrote:

> There are some code paths that I think are common between the parser and 
> template instantiation, like `BuildPointerType` and `BuildReferenceType`, but 
> if you want to do context-sensitive inference that might not be good enough.


Actually for pointee types we don't need context-sensitive inference. This is 
mainly for regular types, but in templates we have much less use cases and I 
haven't caught any issue with the current implementation although we still keep 
some inference logic for dependent types. But it's simple enough. Potentially 
we can assess the corner cases as we go along and discover them.


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

https://reviews.llvm.org/D64400



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

[PATCH] D64582: cmake: Fix install of libclang_shared.so when LLVM_INSTALL_TOOLCHAIN_ONLY=ON

[Tom Stellard via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL365905: cmake: Fix install of libclang-cpp.so when 
LLVM_INSTALL_TOOLCHAIN_ONLY=ON (authored by tstellar, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64582?vs=209295&id=209490#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D64582

Files:
  cfe/trunk/tools/clang-shlib/CMakeLists.txt


Index: cfe/trunk/tools/clang-shlib/CMakeLists.txt
===
--- cfe/trunk/tools/clang-shlib/CMakeLists.txt
+++ cfe/trunk/tools/clang-shlib/CMakeLists.txt
@@ -38,8 +38,13 @@
   list(APPEND _DEPS ${lib})
 endforeach ()
 
+if (CLANG_LINK_CLANG_DYLIB)
+  set(INSTALL_WITH_TOOLCHAIN INSTALL_WITH_TOOLCHAIN)
+endif()
+
 add_clang_library(clang-cpp
   SHARED
+  ${INSTALL_WITH_TOOLCHAIN}
   clang-shlib.cpp
   ${_OBJECTS}
   LINK_LIBS


Index: cfe/trunk/tools/clang-shlib/CMakeLists.txt
===
--- cfe/trunk/tools/clang-shlib/CMakeLists.txt
+++ cfe/trunk/tools/clang-shlib/CMakeLists.txt
@@ -38,8 +38,13 @@
   list(APPEND _DEPS ${lib})
 endforeach ()
 
+if (CLANG_LINK_CLANG_DYLIB)
+  set(INSTALL_WITH_TOOLCHAIN INSTALL_WITH_TOOLCHAIN)
+endif()
+
 add_clang_library(clang-cpp
   SHARED
+  ${INSTALL_WITH_TOOLCHAIN}
   clang-shlib.cpp
   ${_OBJECTS}
   LINK_LIBS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r365906 - Revert "[JSONCompilationDatabase] Strip distcc/ccache/gomacc wrappers from parsed commands."

[Russell Gallop via cfe-commits]

Author: russell_gallop
Date: Fri Jul 12 08:15:56 2019
New Revision: 365906

URL: http://llvm.org/viewvc/llvm-project?rev=365906&view=rev
Log:
Revert "[JSONCompilationDatabase] Strip distcc/ccache/gomacc wrappers from 
parsed commands."

New test is failing on Windows bot

This reverts commit 9c0391b36a76f8e3949588de3f44b7314c2318bf.

Modified:
cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp
cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp

Modified: cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp?rev=365906&r1=365905&r2=365906&view=diff
==
--- cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp (original)
+++ cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp Fri Jul 12 08:15:56 2019
@@ -256,57 +256,15 @@ JSONCompilationDatabase::getAllCompileCo
   return Commands;
 }
 
-static llvm::StringRef stripExecutableExtension(llvm::StringRef Name) {
-  Name.consume_back(".exe");
-  return Name;
-}
-
-// There are compiler-wrappers (ccache, distcc, gomacc) that take the "real"
-// compiler as an argument, e.g. distcc gcc -O3 foo.c.
-// These end up in compile_commands.json when people set CC="distcc gcc".
-// Clang's driver doesn't understand this, so we need to unwrap.
-static bool unwrapCommand(std::vector &Args) {
-  if (Args.size() < 2)
-return false;
-  StringRef Wrapper =
-  stripExecutableExtension(llvm::sys::path::filename(Args.front()));
-  if (Wrapper == "distcc" || Wrapper == "gomacc" || Wrapper == "ccache") {
-// Most of these wrappers support being invoked 3 ways:
-// `distcc g++ file.c` This is the mode we're trying to match.
-// We need to drop `distcc`.
-// `distcc file.c` This acts like compiler is cc or similar.
-// Clang's driver can handle this, no change needed.
-// `g++ file.c`g++ is a symlink to distcc.
-// We don't even notice this case, and all is well.
-//
-// We need to distinguish between the first and second case.
-// The wrappers themselves don't take flags, so Args[1] is a compiler flag,
-// an input file, or a compiler. Inputs have extensions, compilers don't.
-bool HasCompiler =
-(Args[1][0] != '-') &&
-!llvm::sys::path::has_extension(stripExecutableExtension(Args[1]));
-if (HasCompiler) {
-  Args.erase(Args.begin());
-  return true;
-}
-// If !HasCompiler, wrappers act like GCC. Fine: so do we.
-  }
-  return false;
-}
-
 static std::vector
 nodeToCommandLine(JSONCommandLineSyntax Syntax,
   const std::vector &Nodes) {
   SmallString<1024> Storage;
-  std::vector Arguments;
   if (Nodes.size() == 1)
-Arguments = unescapeCommandLine(Syntax, Nodes[0]->getValue(Storage));
-  else
-for (const auto *Node : Nodes)
-  Arguments.push_back(Node->getValue(Storage));
-  // There may be multiple wrappers: using distcc and ccache together is 
common.
-  while (unwrapCommand(Arguments))
-;
+return unescapeCommandLine(Syntax, Nodes[0]->getValue(Storage));
+  std::vector Arguments;
+  for (const auto *Node : Nodes)
+Arguments.push_back(Node->getValue(Storage));
   return Arguments;
 }
 

Modified: cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp?rev=365906&r1=365905&r2=365906&view=diff
==
--- cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp Fri Jul 12 08:15:56 
2019
@@ -370,30 +370,6 @@ TEST(findCompileArgsInJsonDatabase, Find
   EXPECT_EQ("command4", FoundCommand.CommandLine[0]) << ErrorMessage;
 }
 
-TEST(findCompileArgsInJsonDatabase, ParsesCompilerWrappers) {
-  std::vector> Cases = {
-  {"distcc gcc foo.c", "gcc foo.c"},
-  {"gomacc clang++ foo.c", "clang++ foo.c"},
-  {"ccache gcc foo.c", "gcc foo.c"},
-  {"ccache.exe gcc foo.c", "gcc foo.c"},
-  {"ccache g++.exe foo.c", "g++.exe foo.c"},
-  {"ccache distcc gcc foo.c", "gcc foo.c"},
-
-  {"distcc foo.c", "distcc foo.c"},
-  {"distcc -I/foo/bar foo.c", "distcc -I/foo/bar foo.c"},
-  };
-  std::string ErrorMessage;
-
-  for (const auto &Case : Cases) {
-std::string DB = R"([{"directory":".", "file":"/foo.c", "command":")" +
- Case.first + "\"}]";
-CompileCommand FoundCommand =
-findCompileArgsInJsonDatabase("/foo.c", DB, ErrorMessage);
-EXPECT_EQ(Case.second, llvm::join(FoundCommand.CommandLine, " "))
-<< Case.first;
-  }
-}
-
 static std::vector unescapeJsonCommandLine(StringRef Command) {
   std::string JsonDatabase =
 ("[{\"directory\":\"//net/root\", \"file\":\"test\", \"command\": \"" +


_

[PATCH] D64632: [clang-format] Don't detect call to ObjC class method as C++11 attribute specifier

[Ben Hamilton via Phabricator via cfe-commits]

benhamilton added a comment.

Thanks for the fix. One question: how does the real Clang parser deal with this 
case? Is it something that's actually ambiguous in the ObjC++ grammar, I wonder?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64632



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

[PATCH] D64632: [clang-format] Don't detect call to ObjC class method as C++11 attribute specifier

[Ben Hamilton via Phabricator via cfe-commits]

benhamilton added inline comments.



Comment at: clang/lib/Format/TokenAnnotator.cpp:400-413
 while (AttrTok && !AttrTok->startsSequence(tok::r_square, tok::r_square)) {
   // ObjC message send. We assume nobody will use : in a C++11 attribute
   // specifier parameter, although this is technically valid:
-  // [[foo(:)]]
+  // [[foo(:)]]. 'class' is a common ObjC method selector, so allow it as
+  // well.
   if (AttrTok->is(tok::colon) ||
   AttrTok->startsSequence(tok::identifier, tok::identifier) ||

Maybe we should check the token before AttrTok to see if it's `tok::at`, rather 
than checking for an identifier followed by `tok::kw_class`?

I don't think there's any valid C++11 attribute specifier sequence of `@[[]]`.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64632



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

[PATCH] D64635: [CrossTU] Added CTU argument to diagnostic consumer create fn.

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added reviewers: NoQ, Szelethus.
Szelethus accepted this revision.
Szelethus added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rC Clang

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

https://reviews.llvm.org/D64635



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

[PATCH] D64638: [CrossTU] Fix plist macro expansion if macro in other file.

[Kristóf Umann via Phabricator via cfe-commits]

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

LGTM! Thanks!


Repository:
  rC Clang

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

https://reviews.llvm.org/D64638



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

Re: r365887 - [JSONCompilationDatabase] Strip distcc/ccache/gomacc wrappers from parsed commands.

[Russell Gallop via cfe-commits]

Hi Sam,

I've reverted to get the bot green again.

Regards
Russ

On Fri, 12 Jul 2019 at 15:52, Russell Gallop 
wrote:

> Hi Sam,
>
> This is hitting a test failure on a Windows bot:
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26916
>
> Please could you take a look?
>
> Thanks
> Russ
>
> On Fri, 12 Jul 2019 at 11:11, Sam McCall via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: sammccall
>> Date: Fri Jul 12 03:11:40 2019
>> New Revision: 365887
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=365887&view=rev
>> Log:
>> [JSONCompilationDatabase] Strip distcc/ccache/gomacc wrappers from parsed
>> commands.
>>
>> Summary:
>> It's common to use compiler wrappers by setting CC="gomacc clang++".
>> This results in both args appearing in compile_commands.json, and clang's
>> driver
>> can't handle this.
>>
>> This patch attempts to recognize this pattern (by looking for well-known
>> wrappers) and dropping argv0 in this case.
>>
>> It conservatively ignores other cases for now:
>>  - wrappers with unknown names
>>  - wrappers that accept -flags
>>  - wrappers where the compiler to use is implied (usually cc or gcc)
>>
>> This is done at the JSONCompilationDatabase level rather than somewhere
>> more
>> fundamental, as (hopefully) this isn't a general conceptual problem, but
>> a messy
>> aspect of the nature of the ecosystem around compile_commands.json.
>> i.e. compilation databases more tightly tied to the build system should
>> not have
>> this problem.
>>
>> Reviewers: phosek, klimek
>>
>> Subscribers: llvm-commits
>>
>> Tags: #llvm
>>
>> Differential Revision: https://reviews.llvm.org/D64297
>>
>> Modified:
>> cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp
>> cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp
>>
>> Modified: cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp?rev=365887&r1=365886&r2=365887&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp (original)
>> +++ cfe/trunk/lib/Tooling/JSONCompilationDatabase.cpp Fri Jul 12 03:11:40
>> 2019
>> @@ -256,15 +256,57 @@ JSONCompilationDatabase::getAllCompileCo
>>return Commands;
>>  }
>>
>> +static llvm::StringRef stripExecutableExtension(llvm::StringRef Name) {
>> +  Name.consume_back(".exe");
>> +  return Name;
>> +}
>> +
>> +// There are compiler-wrappers (ccache, distcc, gomacc) that take the
>> "real"
>> +// compiler as an argument, e.g. distcc gcc -O3 foo.c.
>> +// These end up in compile_commands.json when people set CC="distcc gcc".
>> +// Clang's driver doesn't understand this, so we need to unwrap.
>> +static bool unwrapCommand(std::vector &Args) {
>> +  if (Args.size() < 2)
>> +return false;
>> +  StringRef Wrapper =
>> +  stripExecutableExtension(llvm::sys::path::filename(Args.front()));
>> +  if (Wrapper == "distcc" || Wrapper == "gomacc" || Wrapper == "ccache")
>> {
>> +// Most of these wrappers support being invoked 3 ways:
>> +// `distcc g++ file.c` This is the mode we're trying to match.
>> +// We need to drop `distcc`.
>> +// `distcc file.c` This acts like compiler is cc or similar.
>> +// Clang's driver can handle this, no change
>> needed.
>> +// `g++ file.c`g++ is a symlink to distcc.
>> +// We don't even notice this case, and all is
>> well.
>> +//
>> +// We need to distinguish between the first and second case.
>> +// The wrappers themselves don't take flags, so Args[1] is a
>> compiler flag,
>> +// an input file, or a compiler. Inputs have extensions, compilers
>> don't.
>> +bool HasCompiler =
>> +(Args[1][0] != '-') &&
>> +
>> !llvm::sys::path::has_extension(stripExecutableExtension(Args[1]));
>> +if (HasCompiler) {
>> +  Args.erase(Args.begin());
>> +  return true;
>> +}
>> +// If !HasCompiler, wrappers act like GCC. Fine: so do we.
>> +  }
>> +  return false;
>> +}
>> +
>>  static std::vector
>>  nodeToCommandLine(JSONCommandLineSyntax Syntax,
>>const std::vector &Nodes) {
>>SmallString<1024> Storage;
>> -  if (Nodes.size() == 1)
>> -return unescapeCommandLine(Syntax, Nodes[0]->getValue(Storage));
>>std::vector Arguments;
>> -  for (const auto *Node : Nodes)
>> -Arguments.push_back(Node->getValue(Storage));
>> +  if (Nodes.size() == 1)
>> +Arguments = unescapeCommandLine(Syntax, Nodes[0]->getValue(Storage));
>> +  else
>> +for (const auto *Node : Nodes)
>> +  Arguments.push_back(Node->getValue(Storage));
>> +  // There may be multiple wrappers: using distcc and ccache together is
>> common.
>> +  while (unwrapCommand(Arguments))
>> +;
>>return Arguments;
>>  }
>>
>>
>> Modified: cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp
>> URL:

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

Oops, sorry about the breakage.

Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
Should we disable building the latter if the former is set?

From: Alex Bradbury 
Date: Friday, July 12, 2019 at 2:02 AM
To: Shoaib Meenai 
Cc: cfe-commits 
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies

Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ&e=

This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
the point of linking lib/libclang_shared.so.9svn with errors like:
ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by Attributes.cpp:34 
(/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule))

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by TargetCXXABI.h:168 
(/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft()
 const)

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by TargetCXXABI.h:149 
(/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily()
 const)

ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks
referenced by Attributes.cpp
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks)

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

[PATCH] D64632: [clang-format] Don't detect call to ObjC class method as C++11 attribute specifier

[Robbie Gibson via Phabricator via cfe-commits]

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

In D64632#1582793 , @benhamilton wrote:

> Thanks for the fix. One question: how does the real Clang parser deal with 
> this case? Is it something that's actually ambiguous in the ObjC++ grammar, I 
> wonder?


I am not sure about real Clang. I actually don't know much about how it works. 
I just ran into this bug and wanted to see if it was fixable. My guess is the @ 
sign marks the bracket as an array literal. In clang-format, 
isCpp11AttributeSpecifier is checked before checking whether the previous token 
is @.




Comment at: clang/lib/Format/TokenAnnotator.cpp:400-413
 while (AttrTok && !AttrTok->startsSequence(tok::r_square, tok::r_square)) {
   // ObjC message send. We assume nobody will use : in a C++11 attribute
   // specifier parameter, although this is technically valid:
-  // [[foo(:)]]
+  // [[foo(:)]]. 'class' is a common ObjC method selector, so allow it as
+  // well.
   if (AttrTok->is(tok::colon) ||
   AttrTok->startsSequence(tok::identifier, tok::identifier) ||

benhamilton wrote:
> Maybe we should check the token before AttrTok to see if it's `tok::at`, 
> rather than checking for an identifier followed by `tok::kw_class`?
> 
> I don't think there's any valid C++11 attribute specifier sequence of `@[[]]`.
> 
Ok, sure. I considered that at first but I'm not familiar with C++11 enough to 
say. I thought it wasn't valid, but I wasn't sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64632



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

[PATCH] D64632: [clang-format] Don't detect call to ObjC class method as C++11 attribute specifier

[Robbie Gibson via Phabricator via cfe-commits]

rkgibson2 updated this revision to Diff 209496.
rkgibson2 added a comment.

Respond to comments and change detection method


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64632

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7027,6 +7027,10 @@
   // On the other hand, we still need to correctly find array subscripts.
   verifyFormat("int a = std::vector{1, 2, 3}[0];");
 
+  // Make sure that we do not mistake a call to the Objective-C method named
+  // "class" inside an array literal as attributes.
+  verifyFormat("@[ [NSArray class] ];");
+
   // Make sure we do not parse attributes as lambda introducers.
   FormatStyle MultiLineFunctions = getLLVMStyle();
   MultiLineFunctions.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -388,6 +388,10 @@
   bool isCpp11AttributeSpecifier(const FormatToken &Tok) {
 if (!Style.isCpp() || !Tok.startsSequence(tok::l_square, tok::l_square))
   return false;
+// Objective-C array literal and message send.
+if (Tok.Previous && Tok.Previous->is(tok::at)) {
+  return false;
+}
 const FormatToken *AttrTok = Tok.Next->Next;
 if (!AttrTok)
   return false;
@@ -400,7 +404,7 @@
 while (AttrTok && !AttrTok->startsSequence(tok::r_square, tok::r_square)) {
   // ObjC message send. We assume nobody will use : in a C++11 attribute
   // specifier parameter, although this is technically valid:
-  // [[foo(:)]]
+  // [[foo(:)]].
   if (AttrTok->is(tok::colon) ||
   AttrTok->startsSequence(tok::identifier, tok::identifier) ||
   AttrTok->startsSequence(tok::r_paren, tok::identifier))


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7027,6 +7027,10 @@
   // On the other hand, we still need to correctly find array subscripts.
   verifyFormat("int a = std::vector{1, 2, 3}[0];");
 
+  // Make sure that we do not mistake a call to the Objective-C method named
+  // "class" inside an array literal as attributes.
+  verifyFormat("@[ [NSArray class] ];");
+
   // Make sure we do not parse attributes as lambda introducers.
   FormatStyle MultiLineFunctions = getLLVMStyle();
   MultiLineFunctions.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -388,6 +388,10 @@
   bool isCpp11AttributeSpecifier(const FormatToken &Tok) {
 if (!Style.isCpp() || !Tok.startsSequence(tok::l_square, tok::l_square))
   return false;
+// Objective-C array literal and message send.
+if (Tok.Previous && Tok.Previous->is(tok::at)) {
+  return false;
+}
 const FormatToken *AttrTok = Tok.Next->Next;
 if (!AttrTok)
   return false;
@@ -400,7 +404,7 @@
 while (AttrTok && !AttrTok->startsSequence(tok::r_square, tok::r_square)) {
   // ObjC message send. We assume nobody will use : in a C++11 attribute
   // specifier parameter, although this is technically valid:
-  // [[foo(:)]]
+  // [[foo(:)]].
   if (AttrTok->is(tok::colon) ||
   AttrTok->startsSequence(tok::identifier, tok::identifier) ||
   AttrTok->startsSequence(tok::r_paren, tok::identifier))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64632: [clang-format] Don't detect call to ObjC class method as C++11 attribute specifier

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Format/TokenAnnotator.cpp:389
   bool isCpp11AttributeSpecifier(const FormatToken &Tok) {
 if (!Style.isCpp() || !Tok.startsSequence(tok::l_square, tok::l_square))
   return false;

Clang has a feature flag to enable support for double-square bracket attributes 
in more than just C++ mode, and this is enabled by default in C2x mode. This 
check for `isCpp()` makes me suspect we may be doing the wrong thing here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64632



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

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Chris Bieneman via cfe-commits]

One of the benefits of the object library approach for generating the clang 
dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues 
with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke 
it, so I was trying to make the clang dylib in a way that it could always be 
enabled.

Do we know where the nested generator expression was coming from?

-Chris

> On Jul 12, 2019, at 8:32 AM, Shoaib Meenai  wrote:
> 
> Oops, sorry about the breakage.
>  
> Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
> Should we disable building the latter if the former is set?
>  
> From: Alex Bradbury 
> Date: Friday, July 12, 2019 at 2:02 AM
> To: Shoaib Meenai 
> Cc: cfe-commits 
> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
>  
> On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
> mailto:cfe-commits@lists.llvm.org>> wrote:
>  
> Author: smeenai
> Date: Thu Jul 11 14:20:38 2019
> New Revision: 365825
>  
> URL: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
>  
> 
> Log:
> [clang-shlib] Fix clang-shlib for PRIVATE dependencies
>  
> Any static library with a PRIVATE dependency ends up with a
> $ generator expression in its INTERFACE_LINK_LIBRARIES,
> which won't be evaluated by the $, so we end up
> with an unevaluated generator expression in the generated build file and
> Ninja chokes on the dollar sign. Just use the static library directly
> for its dependencies instead of trying to propagate dependencies
> manually.
>  
> Differential Revision: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ&e=
>  
> 
>  
> This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
> the point of linking lib/libclang_shared.so.9svn with errors like:
> ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
> const*, char const*, unsigned int)
> referenced by Attributes.cpp:34 
> (/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
>
> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule))
>  
> ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
> const*, char const*, unsigned int)
> referenced by TargetCXXABI.h:168 
> (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168)
>
> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft()
>  const)
>  
> ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
> const*, char const*, unsigned int)
> referenced by TargetCXXABI.h:149 
> (/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149)
>
> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily()
>  const)
>  
> ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks
> referenced by Attributes.cpp
>
> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks)
>  

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

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

See https://reviews.llvm.org/D58418#1577670. More generally it would appear for 
any static library with a PRIVATE dependency though.

I guess an alternative would be to use the LINK_LIBRARIES property (which 
should be free of generator expressions, I believe) to propagate dependencies 
instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set 
an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies 
on a static library definitely seems more valuable than supporting INTERFACE 
dependencies.)

From:  on behalf of Chris Bieneman 
Date: Friday, July 12, 2019 at 8:49 AM
To: Shoaib Meenai 
Cc: Alex Bradbury , cfe-commits 
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

One of the benefits of the object library approach for generating the clang 
dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues 
with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke 
it, so I was trying to make the clang dylib in a way that it could always be 
enabled.

Do we know where the nested generator expression was coming from?

-Chris


On Jul 12, 2019, at 8:32 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Oops, sorry about the breakage.

Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
Should we disable building the latter if the former is set?

From: Alex Bradbury mailto:a...@lowrisc.org>>
Date: Friday, July 12, 2019 at 2:02 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies

Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ&e=

This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
the point of linking lib/libclang_shared.so.9svn with errors like:
ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by Attributes.cpp:34 
(/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule))

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by TargetCXXABI.h:168 
(/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:168)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isMicrosoft()
 const)

ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by TargetCXXABI.h:149 
(/home/asb/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:149)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::TargetCXXABI::isItaniumFamily()
 const)

ld.lld: error: undefined symbol: llvm::EnableABIBreakingChecks
referenced by Attributes.cpp
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(llvm::VerifyEnableABIBreakingChecks)


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

r365909 - [clang-format][tests] Explicitly specify style in some tests

[Rafael Stahl via cfe-commits]

Author: r.stahl
Date: Fri Jul 12 08:56:18 2019
New Revision: 365909

URL: http://llvm.org/viewvc/llvm-project?rev=365909&view=rev
Log:
[clang-format][tests] Explicitly specify style in some tests

Summary: This fixes broken tests when doing an out-of-source build that picks 
up a random .clang-format on the file system due to the default "file" style.

Reviewers: djasper, klimek, MyDeveloperDay, krasimir

Reviewed By: MyDeveloperDay

Subscribers: lebedev.ri, cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/test/Format/adjust-indent.cpp
cfe/trunk/test/Format/disable-include-sorting.cpp
cfe/trunk/test/Format/language-detection.cpp
cfe/trunk/test/Format/xmloutput.cpp

Modified: cfe/trunk/test/Format/adjust-indent.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Format/adjust-indent.cpp?rev=365909&r1=365908&r2=365909&view=diff
==
--- cfe/trunk/test/Format/adjust-indent.cpp (original)
+++ cfe/trunk/test/Format/adjust-indent.cpp Fri Jul 12 08:56:18 2019
@@ -1,4 +1,4 @@
-// RUN: grep -Ev "// *[A-Z-]+:" %s | clang-format -lines=2:2 \
+// RUN: grep -Ev "// *[A-Z-]+:" %s | clang-format -style=LLVM -lines=2:2 \
 // RUN:   | FileCheck -strict-whitespace %s
 
 void  f() {

Modified: cfe/trunk/test/Format/disable-include-sorting.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Format/disable-include-sorting.cpp?rev=365909&r1=365908&r2=365909&view=diff
==
--- cfe/trunk/test/Format/disable-include-sorting.cpp (original)
+++ cfe/trunk/test/Format/disable-include-sorting.cpp Fri Jul 12 08:56:18 2019
@@ -1,4 +1,4 @@
-// RUN: clang-format %s | FileCheck %s
+// RUN: clang-format %s -style=LLVM | FileCheck %s
 // RUN: clang-format %s -sort-includes -style="{SortIncludes: false}" | 
FileCheck %s
 // RUN: clang-format %s -sort-includes=false | FileCheck %s 
-check-prefix=NOT-SORTED
 

Modified: cfe/trunk/test/Format/language-detection.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Format/language-detection.cpp?rev=365909&r1=365908&r2=365909&view=diff
==
--- cfe/trunk/test/Format/language-detection.cpp (original)
+++ cfe/trunk/test/Format/language-detection.cpp Fri Jul 12 08:56:18 2019
@@ -1,8 +1,8 @@
 // RUN: grep -Ev "// *[A-Z0-9_]+:" %s \
-// RUN:   | clang-format -style=llvm -assume-filename=foo.js \
+// RUN:   | clang-format -style=LLVM -assume-filename=foo.js \
 // RUN:   | FileCheck -strict-whitespace -check-prefix=CHECK1 %s
 // RUN: grep -Ev "// *[A-Z0-9_]+:" %s \
-// RUN:   | clang-format -style=llvm -assume-filename=foo.cpp \
+// RUN:   | clang-format -style=LLVM -assume-filename=foo.cpp \
 // RUN:   | FileCheck -strict-whitespace -check-prefix=CHECK2 %s
 // CHECK1: {{^a >>>= b;$}}
 // CHECK2: {{^a >> >= b;$}}

Modified: cfe/trunk/test/Format/xmloutput.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Format/xmloutput.cpp?rev=365909&r1=365908&r2=365909&view=diff
==
--- cfe/trunk/test/Format/xmloutput.cpp (original)
+++ cfe/trunk/test/Format/xmloutput.cpp Fri Jul 12 08:56:18 2019
@@ -1,4 +1,4 @@
-// RUN: clang-format -output-replacements-xml -sort-includes %s \
+// RUN: clang-format -style=LLVM -output-replacements-xml -sort-includes %s \
 // RUN:   | FileCheck -strict-whitespace %s
 
 // CHECK: https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61001: [clang-format][tests] Explicitly specify style in some tests

[Rafael Stahl via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
r.stahl marked an inline comment as done.
Closed by commit rGf625a8a250b3: [clang-format][tests] Explicitly specify style 
in some tests (authored by r.stahl).

Changed prior to commit:
  https://reviews.llvm.org/D61001?vs=196212&id=209500#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61001

Files:
  clang/test/Format/adjust-indent.cpp
  clang/test/Format/disable-include-sorting.cpp
  clang/test/Format/language-detection.cpp
  clang/test/Format/xmloutput.cpp


Index: clang/test/Format/xmloutput.cpp
===
--- clang/test/Format/xmloutput.cpp
+++ clang/test/Format/xmloutput.cpp
@@ -1,4 +1,4 @@
-// RUN: clang-format -output-replacements-xml -sort-includes %s \
+// RUN: clang-format -style=LLVM -output-replacements-xml -sort-includes %s \
 // RUN:   | FileCheck -strict-whitespace %s
 
 // CHECK: >>= b;$}}
 // CHECK2: {{^a >> >= b;$}}
Index: clang/test/Format/disable-include-sorting.cpp
===
--- clang/test/Format/disable-include-sorting.cpp
+++ clang/test/Format/disable-include-sorting.cpp
@@ -1,4 +1,4 @@
-// RUN: clang-format %s | FileCheck %s
+// RUN: clang-format %s -style=LLVM | FileCheck %s
 // RUN: clang-format %s -sort-includes -style="{SortIncludes: false}" | 
FileCheck %s
 // RUN: clang-format %s -sort-includes=false | FileCheck %s 
-check-prefix=NOT-SORTED
 
Index: clang/test/Format/adjust-indent.cpp
===
--- clang/test/Format/adjust-indent.cpp
+++ clang/test/Format/adjust-indent.cpp
@@ -1,4 +1,4 @@
-// RUN: grep -Ev "// *[A-Z-]+:" %s | clang-format -lines=2:2 \
+// RUN: grep -Ev "// *[A-Z-]+:" %s | clang-format -style=LLVM -lines=2:2 \
 // RUN:   | FileCheck -strict-whitespace %s
 
 void  f() {


Index: clang/test/Format/xmloutput.cpp
===
--- clang/test/Format/xmloutput.cpp
+++ clang/test/Format/xmloutput.cpp
@@ -1,4 +1,4 @@
-// RUN: clang-format -output-replacements-xml -sort-includes %s \
+// RUN: clang-format -style=LLVM -output-replacements-xml -sort-includes %s \
 // RUN:   | FileCheck -strict-whitespace %s
 
 // CHECK: >>= b;$}}
 // CHECK2: {{^a >> >= b;$}}
Index: clang/test/Format/disable-include-sorting.cpp
===
--- clang/test/Format/disable-include-sorting.cpp
+++ clang/test/Format/disable-include-sorting.cpp
@@ -1,4 +1,4 @@
-// RUN: clang-format %s | FileCheck %s
+// RUN: clang-format %s -style=LLVM | FileCheck %s
 // RUN: clang-format %s -sort-includes -style="{SortIncludes: false}" | FileCheck %s
 // RUN: clang-format %s -sort-includes=false | FileCheck %s -check-prefix=NOT-SORTED
 
Index: clang/test/Format/adjust-indent.cpp
===
--- clang/test/Format/adjust-indent.cpp
+++ clang/test/Format/adjust-indent.cpp
@@ -1,4 +1,4 @@
-// RUN: grep -Ev "// *[A-Z-]+:" %s | clang-format -lines=2:2 \
+// RUN: grep -Ev "// *[A-Z-]+:" %s | clang-format -style=LLVM -lines=2:2 \
 // RUN:   | FileCheck -strict-whitespace %s
 
 void  f() {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64632: [clang-format] Don't detect call to ObjC class method as C++11 attribute specifier

[Robbie Gibson via Phabricator via cfe-commits]

rkgibson2 updated this revision to Diff 209504.
rkgibson2 added a comment.

Update comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64632

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7027,6 +7027,10 @@
   // On the other hand, we still need to correctly find array subscripts.
   verifyFormat("int a = std::vector{1, 2, 3}[0];");
 
+  // Make sure that we do not mistake a call to the Objective-C method named
+  // "class" inside an array literal as attributes.
+  verifyFormat("@[ [NSArray class] ];");
+
   // Make sure we do not parse attributes as lambda introducers.
   FormatStyle MultiLineFunctions = getLLVMStyle();
   MultiLineFunctions.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -388,6 +388,10 @@
   bool isCpp11AttributeSpecifier(const FormatToken &Tok) {
 if (!Style.isCpp() || !Tok.startsSequence(tok::l_square, tok::l_square))
   return false;
+// The first square bracket is part of an ObjC array literal
+if (Tok.Previous && Tok.Previous->is(tok::at)) {
+  return false;
+}
 const FormatToken *AttrTok = Tok.Next->Next;
 if (!AttrTok)
   return false;
@@ -400,7 +404,7 @@
 while (AttrTok && !AttrTok->startsSequence(tok::r_square, tok::r_square)) {
   // ObjC message send. We assume nobody will use : in a C++11 attribute
   // specifier parameter, although this is technically valid:
-  // [[foo(:)]]
+  // [[foo(:)]].
   if (AttrTok->is(tok::colon) ||
   AttrTok->startsSequence(tok::identifier, tok::identifier) ||
   AttrTok->startsSequence(tok::r_paren, tok::identifier))


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7027,6 +7027,10 @@
   // On the other hand, we still need to correctly find array subscripts.
   verifyFormat("int a = std::vector{1, 2, 3}[0];");
 
+  // Make sure that we do not mistake a call to the Objective-C method named
+  // "class" inside an array literal as attributes.
+  verifyFormat("@[ [NSArray class] ];");
+
   // Make sure we do not parse attributes as lambda introducers.
   FormatStyle MultiLineFunctions = getLLVMStyle();
   MultiLineFunctions.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -388,6 +388,10 @@
   bool isCpp11AttributeSpecifier(const FormatToken &Tok) {
 if (!Style.isCpp() || !Tok.startsSequence(tok::l_square, tok::l_square))
   return false;
+// The first square bracket is part of an ObjC array literal
+if (Tok.Previous && Tok.Previous->is(tok::at)) {
+  return false;
+}
 const FormatToken *AttrTok = Tok.Next->Next;
 if (!AttrTok)
   return false;
@@ -400,7 +404,7 @@
 while (AttrTok && !AttrTok->startsSequence(tok::r_square, tok::r_square)) {
   // ObjC message send. We assume nobody will use : in a C++11 attribute
   // specifier parameter, although this is technically valid:
-  // [[foo(:)]]
+  // [[foo(:)]].
   if (AttrTok->is(tok::colon) ||
   AttrTok->startsSequence(tok::identifier, tok::identifier) ||
   AttrTok->startsSequence(tok::r_paren, tok::identifier))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Chris Bieneman via cfe-commits]

Ah! I see what is going on here. This is kinda a silliness of CMake. `PRIVATE` 
linkage for a static archive is silly, and shouldn't be possible. All link 
dependencies for static archives are really `INTERFACE` dependencies, and it 
looks like CMake is doing something kinda silly instead of producing a 
reasonable error or warning like it probably should do.

For context, `PRIVATE` linkage in the context of that change would mean 
DirectoryWalker links something, but things that link DirectoryWalker don't. 
That just isn't possible with static archives, so they become interface 
dependencies (and CMake seems to insert a generator expression to make that 
work).

In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, and 
`INTERFACE` for static, which does the right thing.

Unless there is a better reason than a new patch coming in, I think the right 
fix is to revert this back and expect the new patch to correct its linkage 
behavior.

-Chris

> On Jul 12, 2019, at 8:53 AM, Shoaib Meenai  wrote:
> 
> See https://reviews.llvm.org/D58418#1577670 
> . More generally it would appear for 
> any static library with a PRIVATE dependency though.
>  
> I guess an alternative would be to use the LINK_LIBRARIES property (which 
> should be free of generator expressions, I believe) to propagate dependencies 
> instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set 
> an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies 
> on a static library definitely seems more valuable than supporting INTERFACE 
> dependencies.)
>  
> From:  on behalf of Chris Bieneman 
> Date: Friday, July 12, 2019 at 8:49 AM
> To: Shoaib Meenai 
> Cc: Alex Bradbury , cfe-commits 
> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
>  
> One of the benefits of the object library approach for generating the clang 
> dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues 
> with libLLVM where people using BUILD_SHARED_LIBS would make changes that 
> broke it, so I was trying to make the clang dylib in a way that it could 
> always be enabled.
>  
> Do we know where the nested generator expression was coming from?
>  
> -Chris
> 
> 
> On Jul 12, 2019, at 8:32 AM, Shoaib Meenai  > wrote:
>  
> Oops, sorry about the breakage.
>  
> Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
> Should we disable building the latter if the former is set?
>  
> From: Alex Bradbury mailto:a...@lowrisc.org>>
> Date: Friday, July 12, 2019 at 2:02 AM
> To: Shoaib Meenai mailto:smee...@fb.com>>
> Cc: cfe-commits  >
> Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies
>  
> On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
> mailto:cfe-commits@lists.llvm.org>> wrote:
>  
> Author: smeenai
> Date: Thu Jul 11 14:20:38 2019
> New Revision: 365825
>  
> URL: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
>  
> 
> Log:
> [clang-shlib] Fix clang-shlib for PRIVATE dependencies
>  
> Any static library with a PRIVATE dependency ends up with a
> $ generator expression in its INTERFACE_LINK_LIBRARIES,
> which won't be evaluated by the $, so we end up
> with an unevaluated generator expression in the generated build file and
> Ninja chokes on the dollar sign. Just use the static library directly
> for its dependencies instead of trying to propagate dependencies
> manually.
>  
> Differential Revision: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ&e=
>  
> 
>  
> This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
> the point of linking lib/libclang_shared.so.9svn with errors like:
> ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
> const*, char const*, unsigned int)
> referenced by Attributes.cpp:34 
> (/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
>
> tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleS

[PATCH] D64628: [CrossTU] Test change only: improve ctu-main.c

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

Hmmm, did this result in an assertion?


Repository:
  rC Clang

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

https://reviews.llvm.org/D64628



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

[PATCH] D64329: [Clangd] Fixed SelectionTree bug for macros

[Shaurya Gupta via Phabricator via cfe-commits]

SureYeaah updated this revision to Diff 209506.
SureYeaah added a comment.

Added a test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64329

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/unittests/SelectionTests.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -395,12 +395,23 @@
}
  })cpp"},*/
   // ensure InsertionPoint isn't inside a macro
-  {R"cpp(#define LOOP(x) {int a = x + 1;}
+  // FIXME: SelectionTree needs to be fixed for macros
+  /*{R"cpp(#define LOOP(x) while (1) {a = x;}
  void f(int a) {
if(1)
 LOOP(5 + ^3)
  })cpp",
-   R"cpp(#define LOOP(x) {int a = x + 1;}
+ R"cpp(#define LOOP(x) while (1) {a = x;}
+ void f(int a) {
+   auto dummy = 3; if(1)
+LOOP(5 + dummy)
+ })cpp"},*/
+  {R"cpp(#define LOOP(x) do {x;} while(1);
+ void f(int a) {
+   if(1)
+LOOP(5 + ^3)
+ })cpp",
+   R"cpp(#define LOOP(x) do {x;} while(1);
  void f(int a) {
auto dummy = 3; if(1)
 LOOP(5 + dummy)
@@ -421,9 +432,9 @@
  void f(int a) {
auto dummy = a; PLUS(dummy);
  })cpp"},*/
-  // FIXME: Doesn't work correctly for \[\[clang::uninitialized\]\] int b
-  // = 1; since the attr is inside the DeclStmt and the bounds of
-  // DeclStmt don't cover the attribute
+  // FIXME: Doesn't work correctly for this code since the attr is
+  // inside the DeclStmt and the bounds of DeclStmt don't cover the attr
+  // \[\[clang::uninitialized\]\] int b = 1;
   };
   for (const auto &IO : InputOutputs) {
 checkTransform(ID, IO.first, IO.second);
Index: clang-tools-extra/clangd/unittests/SelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SelectionTests.cpp
@@ -37,15 +37,15 @@
 Range nodeRange(const SelectionTree::Node *N, ParsedAST &AST) {
   if (!N)
 return Range{};
-  SourceManager &SM = AST.getSourceManager();
+  const SourceManager &SM = AST.getSourceManager();
+  const LangOptions &LangOpts = AST.getASTContext().getLangOpts();
   StringRef Buffer = SM.getBufferData(SM.getMainFileID());
-  SourceRange SR = N->ASTNode.getSourceRange();
-  SR.setBegin(SM.getFileLoc(SR.getBegin()));
-  SR.setEnd(SM.getFileLoc(SR.getEnd()));
-  CharSourceRange R =
-  Lexer::getAsCharRange(SR, SM, AST.getASTContext().getLangOpts());
-  return Range{offsetToPosition(Buffer, SM.getFileOffset(R.getBegin())),
-   offsetToPosition(Buffer, SM.getFileOffset(R.getEnd()))};
+  auto FileRange =
+  toHalfOpenFileRange(SM, LangOpts, N->ASTNode.getSourceRange());
+  assert(FileRange && "We should be able to get the File Range");
+  return Range{
+  offsetToPosition(Buffer, SM.getFileOffset(FileRange->getBegin())),
+  offsetToPosition(Buffer, SM.getFileOffset(FileRange->getEnd()))};
 }
 
 std::string nodeKind(const SelectionTree::Node *N) {
@@ -144,17 +144,17 @@
   R"cpp(
 void foo();
 #define CALL_FUNCTION(X) X()
-void bar() [[{ CALL_FUNC^TION(fo^o); }]]
+void bar() { [[CALL_FUNC^TION(fo^o)]]; }
   )cpp",
-  "CompoundStmt",
+  "CallExpr",
   },
   {
   R"cpp(
 void foo();
 #define CALL_FUNCTION(X) X()
-void bar() [[{ C^ALL_FUNC^TION(foo); }]]
+void bar() { [[C^ALL_FUNC^TION(foo)]]; }
   )cpp",
-  "CompoundStmt",
+  "CallExpr",
   },
   {
   R"cpp(
@@ -308,7 +308,12 @@
   R"cpp(
   template 
   struct unique_ptr {};
-  void foo(^$C[[unique_ptr>]]^ a) {}
+  void foo(^$C[[unique_ptr<$C[[unique_ptr<$C[[int]]>]]>]]^ a) {}
+  )cpp",
+  R"cpp(int a = [[5 >^> 1]];)cpp",
+  R"cpp(
+#define ECHO(X) X
+ECHO(EC^HO([[$C[[int]]) EC^HO(a]]));
   )cpp",
   };
   for (const char *C : Cases) {
Index: clang-tools-extra/clangd/Selection.cpp
===
--- clang-tools-extra/clangd/Selection.cpp
+++ clang-tools-extra/clangd/Selection.cpp
@@ -8,10 +8,13 @@
 
 #include "Selection.h"
 #include "ClangdUnit.h"
+#include "SourceCode.h"
 #include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/PrettyPrint

[PATCH] D64579: [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Brian Rzycki via Phabricator via cfe-commits]

brzycki added a comment.

Hello @smeenai , this commit causes LLVM to fail to build when set set `-D 
BUILD_SHARED_LIBS=ON`. Here is the failing CMake and Ninja invocation:

  /tools/build/cmake-3.14.5/bin/cmake \
  -G Ninja  \
  -D CMAKE_MAKE_PROGRAM=/tools/build/ninja-1.9.0/ninja \
  -D CMAKE_C_COMPILER=/usr/lib/llvm-7/bin/clang \
  -D CMAKE_CXX_COMPILER=/usr/lib/llvm-7/bin/clang++ \
  -D CMAKE_BUILD_TYPE=Release \
  -D CMAKE_INSTALL_PREFIX=/work/upstream/install \
  -D LLVM_TOOL_CLANG_BUILD=ON \
  -D LIBCXX_INCLUDE_BENCHMARKS=ON \
  -D BUILD_SHARED_LIBS=ON \
  -D LLVM_ENABLE_ASSERTIONS=ON \
  -D LLVM_TARGETS_TO_BUILD=X86 \
  /work/upstream/llvm-project/llvm
  
  /tools/build/ninja-1.9.0/ninja -v install

I am able to successfully build LLVM when I change to `-D 
BUILD_SHARED_LIBS=OFF`.

The outputted errors happen during link time of `lib/libclang_shared.so.9svn`:

  FAILED: lib/libclang_shared.so.9svn
  
  ...
  
  tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenModule.cpp.o: 
In function `llvm::cl::opt >::~opt()':
  
CodeGenModule.cpp:(.text._ZN4llvm2cl3optIbLb0ENS0_6parserIbEEED2Ev[_ZN4llvm2cl3optIbLb0ENS0_6parserIbEEED2Ev]+0x7):
 undefined reference to `vtable for llvm::cl::Option'
  tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenModule.cpp.o: 
In function `clang::CodeGen::CodeGenModule::CodeGenModule(clang::ASTContext&, 
clang::HeaderSearchOptions const&, clang::PreprocessorOptions const&, 
clang::CodeGenOptions const&, llvm::Module&, clang::DiagnosticsEngine&, 
clang::CoverageSourceInfo*)':
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x57a):
 undefined reference to `llvm::FoldingSetBase::FoldingSetBase(unsigned int)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5cc):
 undefined reference to `llvm::Type::getVoidTy(llvm::LLVMContext&)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5d7):
 undefined reference to `llvm::Type::getInt8Ty(llvm::LLVMContext&)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5e3):
 undefined reference to `llvm::Type::getInt16Ty(llvm::LLVMContext&)'
  
  ... (clipped thousands of similar errors)
  
  
WhitespaceManager.cpp:(.text._ZN5clang6formatL18AlignTokenSequenceIRZNS0_17WhitespaceManager28alignConsecutiveDeclarationsEvE3$_2EEvjjjOT_RN4llvm11SmallVectorINS2_6ChangeELj16EEE+0x129):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  
tools/clang/tools/clang-fuzzer/handle-cxx/CMakeFiles/obj.clangHandleCXX.dir/handle_cxx.cpp.o:
 In function `clang_fuzzer::HandleCXX(std::__cxx11::basic_string, std::allocator > const&, std::vector > const&)':
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x67):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x32b):
 undefined reference to `llvm::MemoryBuffer::getMemBuffer(llvm::StringRef, 
llvm::StringRef, bool)'
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x669):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  clang: error: linker command failed with exit code 1 (use -v to see 
invocation)


Repository:
  rL LLVM

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

https://reviews.llvm.org/D64579



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

[PATCH] D63975: Warn when ScopeDepthOrObjCQuals overflows

[Mark de Wever via Phabricator via cfe-commits]

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



Comment at: clang/lib/Parse/ParseDecl.cpp:6587
+return;
+  }
+

rjmccall wrote:
> Mordante wrote:
> > rjmccall wrote:
> > > Comment indentation.
> > > 
> > > Should we do this when starting to parse a function prototype instead of 
> > > when parsing a parameter?
> > Thanks I noticed I forgot to change the tabs to spaces.
> > 
> > I looked at your suggestion to move the code, but I think this is the 
> > proper place. Now it also validates whether lambdas exceed the limit, else 
> > we need to check at two places.
> > I'll also add a unit test to test for the lambda.
> I don't understand.  I'm just saying to put the check at the top of the 
> function instead of inside the loop.
I now understand what you mean. I'll upload a new patch.


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

https://reviews.llvm.org/D63975



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

[PATCH] D64617: [clangd] Added highlighting for members and methods

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

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

Removed addToken for Exprs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64617

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/semantic-highlighting.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -37,7 +37,9 @@
   {HighlightingKind::Function, "Function"},
   {HighlightingKind::Class, "Class"},
   {HighlightingKind::Enum, "Enum"},
-  {HighlightingKind::Namespace, "Namespace"}};
+  {HighlightingKind::Namespace, "Namespace"},
+  {HighlightingKind::Field, "Field"},
+  {HighlightingKind::Method, "Method"}};
   std::vector ExpectedTokens;
   for (const auto &KindString : KindToString) {
 std::vector Toks = makeHighlightingTokens(
@@ -53,14 +55,14 @@
   const char *TestCases[] = {
 R"cpp(
   struct $Class[[AS]] {
-double SomeMember;
+double $Field[[SomeMember]];
   };
   struct {
   } $Variable[[S]];
   void $Function[[foo]](int $Variable[[A]], $Class[[AS]] $Variable[[As]]) {
 auto $Variable[[VeryLongVariableName]] = 12312;
 $Class[[AS]] $Variable[[AA]];
-auto $Variable[[L]] = $Variable[[AA]].SomeMember + $Variable[[A]];
+auto $Variable[[L]] = $Variable[[AA]].$Field[[SomeMember]] + $Variable[[A]];
 auto $Variable[[FN]] = [ $Variable[[AA]]](int $Variable[[A]]) -> void {};
 $Variable[[FN]](12312);
   }
@@ -72,19 +74,19 @@
 auto $Variable[[Bou]] = $Function[[Gah]];
   }
   struct $Class[[A]] {
-void $Function[[abc]]();
+void $Method[[abc]]();
   };
 )cpp",
 R"cpp(
   namespace $Namespace[[abc]] {
 template
 struct $Class[[A]] {
-  T t;
+  T $Field[[t]];
 };
   }
   template
   struct $Class[[C]] : $Namespace[[abc]]::A {
-typename T::A* D;
+typename T::A* $Field[[D]];
   };
   $Namespace[[abc]]::$Class[[A]] $Variable[[AA]];
   typedef $Namespace[[abc]]::$Class[[A]] AAA;
@@ -92,7 +94,7 @@
 $Class[[B]]();
 ~$Class[[B]]();
 void operator<<($Class[[B]]);
-$Class[[AAA]] AA;
+$Class[[AAA]] $Field[[AA]];
   };
   $Class[[B]]::$Class[[B]]() {}
   $Class[[B]]::~$Class[[B]]() {}
@@ -106,8 +108,8 @@
   enum class $Enum[[E]] {};
   enum $Enum[[EE]] {};
   struct $Class[[A]] {
-$Enum[[E]] EEE;
-$Enum[[EE]] ;
+$Enum[[E]] $Field[[EEE]];
+$Enum[[EE]] $Field[[]];
   };
 )cpp",
 R"cpp(
@@ -132,6 +134,30 @@
 $Namespace[[vwz]]::$Class[[A]]::$Enum[[B]]::Hi;
   ::$Namespace[[vwz]]::$Class[[A]] $Variable[[B]];
   ::$Namespace[[abc]]::$Namespace[[bcd]]::$Class[[A]] $Variable[[BB]];
+)cpp",
+R"cpp(
+  struct $Class[[D]] {
+double $Field[[C]];
+  };
+  struct $Class[[A]] {
+double $Field[[B]];
+$Class[[D]] $Field[[E]];
+static double $Variable[[S]];
+void $Method[[foo]]() {
+  $Field[[B]] = 123;
+  this->$Field[[B]] = 156;
+  this->$Method[[foo]]();
+  $Method[[foo]]();
+  $Variable[[S]] = 90.1;
+}
+  };
+  void $Function[[foo]]() {
+$Class[[A]] $Variable[[AA]];
+$Variable[[AA]].$Field[[B]] += 2;
+$Variable[[AA]].$Method[[foo]]();
+$Variable[[AA]].$Field[[E]].$Field[[C]];
+$Class[[A]]::$Variable[[S]] = 90;
+  }
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
@@ -181,7 +207,7 @@
   toSemanticHighlightingInformation(Tokens);
   std::vector ExpectedResults = {
   {1, "AQAEAAA="},
-  {3, "CAAEAAAEAAMAAQ=="}};
+  {3, "CAAEAAAEAAMAAg=="}};
   EXPECT_EQ(ActualResults, ExpectedResults);
 }
 
Index: clang-tools-extra/clangd/test/semantic-highlighting.test
===
--- clang-tools-extra/clangd/test/semantic-highlighting.test
+++ clang-tools-extra/clangd/test/semantic-highlighting.test
@@ -5,12 +5,18 @@
 # CHECK:  "semanticHighlighting": {
 # CHECK-NEXT:"scopes": [
 # CHECK-NEXT:  [
-# CHECK-NEXT:"variable.cpp"
+# CHECK-NEXT:"variable.other.cpp"
+# CHECK-NEXT:  ],
+# CHECK-NEXT:  [
+# CHECK-NEXT:"variable.other.field.cpp"
 # CHECK-NEXT:  ],
 # CHECK-NEXT:  [
 # CHECK-NEXT:"entity.name.function.cpp"
 # CHECK-NEXT:  ]

[PATCH] D64617: [clangd] Added highlighting for members and methods

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

jvikstrom updated this revision to Diff 209509.
jvikstrom marked 6 inline comments as done.
jvikstrom added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64617

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/semantic-highlighting.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -37,7 +37,9 @@
   {HighlightingKind::Function, "Function"},
   {HighlightingKind::Class, "Class"},
   {HighlightingKind::Enum, "Enum"},
-  {HighlightingKind::Namespace, "Namespace"}};
+  {HighlightingKind::Namespace, "Namespace"},
+  {HighlightingKind::Field, "Field"},
+  {HighlightingKind::Method, "Method"}};
   std::vector ExpectedTokens;
   for (const auto &KindString : KindToString) {
 std::vector Toks = makeHighlightingTokens(
@@ -53,14 +55,14 @@
   const char *TestCases[] = {
 R"cpp(
   struct $Class[[AS]] {
-double SomeMember;
+double $Field[[SomeMember]];
   };
   struct {
   } $Variable[[S]];
   void $Function[[foo]](int $Variable[[A]], $Class[[AS]] $Variable[[As]]) {
 auto $Variable[[VeryLongVariableName]] = 12312;
 $Class[[AS]] $Variable[[AA]];
-auto $Variable[[L]] = $Variable[[AA]].SomeMember + $Variable[[A]];
+auto $Variable[[L]] = $Variable[[AA]].$Field[[SomeMember]] + $Variable[[A]];
 auto $Variable[[FN]] = [ $Variable[[AA]]](int $Variable[[A]]) -> void {};
 $Variable[[FN]](12312);
   }
@@ -72,19 +74,19 @@
 auto $Variable[[Bou]] = $Function[[Gah]];
   }
   struct $Class[[A]] {
-void $Function[[abc]]();
+void $Method[[abc]]();
   };
 )cpp",
 R"cpp(
   namespace $Namespace[[abc]] {
 template
 struct $Class[[A]] {
-  T t;
+  T $Field[[t]];
 };
   }
   template
   struct $Class[[C]] : $Namespace[[abc]]::A {
-typename T::A* D;
+typename T::A* $Field[[D]];
   };
   $Namespace[[abc]]::$Class[[A]] $Variable[[AA]];
   typedef $Namespace[[abc]]::$Class[[A]] AAA;
@@ -92,7 +94,7 @@
 $Class[[B]]();
 ~$Class[[B]]();
 void operator<<($Class[[B]]);
-$Class[[AAA]] AA;
+$Class[[AAA]] $Field[[AA]];
   };
   $Class[[B]]::$Class[[B]]() {}
   $Class[[B]]::~$Class[[B]]() {}
@@ -106,8 +108,8 @@
   enum class $Enum[[E]] {};
   enum $Enum[[EE]] {};
   struct $Class[[A]] {
-$Enum[[E]] EEE;
-$Enum[[EE]] ;
+$Enum[[E]] $Field[[EEE]];
+$Enum[[EE]] $Field[[]];
   };
 )cpp",
 R"cpp(
@@ -132,6 +134,30 @@
 $Namespace[[vwz]]::$Class[[A]]::$Enum[[B]]::Hi;
   ::$Namespace[[vwz]]::$Class[[A]] $Variable[[B]];
   ::$Namespace[[abc]]::$Namespace[[bcd]]::$Class[[A]] $Variable[[BB]];
+)cpp",
+R"cpp(
+  struct $Class[[D]] {
+double $Field[[C]];
+  };
+  struct $Class[[A]] {
+double $Field[[B]];
+$Class[[D]] $Field[[E]];
+static double $Variable[[S]];
+void $Method[[foo]]() {
+  $Field[[B]] = 123;
+  this->$Field[[B]] = 156;
+  this->$Method[[foo]]();
+  $Method[[foo]]();
+  $Variable[[S]] = 90.1;
+}
+  };
+  void $Function[[foo]]() {
+$Class[[A]] $Variable[[AA]];
+$Variable[[AA]].$Field[[B]] += 2;
+$Variable[[AA]].$Method[[foo]]();
+$Variable[[AA]].$Field[[E]].$Field[[C]];
+$Class[[A]]::$Variable[[S]] = 90;
+  }
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
@@ -181,7 +207,7 @@
   toSemanticHighlightingInformation(Tokens);
   std::vector ExpectedResults = {
   {1, "AQAEAAA="},
-  {3, "CAAEAAAEAAMAAQ=="}};
+  {3, "CAAEAAAEAAMAAg=="}};
   EXPECT_EQ(ActualResults, ExpectedResults);
 }
 
Index: clang-tools-extra/clangd/test/semantic-highlighting.test
===
--- clang-tools-extra/clangd/test/semantic-highlighting.test
+++ clang-tools-extra/clangd/test/semantic-highlighting.test
@@ -5,12 +5,18 @@
 # CHECK:  "semanticHighlighting": {
 # CHECK-NEXT:"scopes": [
 # CHECK-NEXT:  [
-# CHECK-NEXT:"variable.cpp"
+# CHECK-NEXT:"variable.other.cpp"
+# CHECK-NEXT:  ],
+# CHECK-NEXT:  [
+# CHECK-NEXT:"variable.other.field.cpp"
 # CHECK-NEXT:  ],
 # CHECK-NEXT:  [
 # CHECK-NEXT:"entity.name.fun

[PATCH] D63975: Warn when ScopeDepthOrObjCQuals overflows

[Mark de Wever via Phabricator via cfe-commits]

Mordante updated this revision to Diff 209513.
Mordante added a comment.

Moved the test out of the loop as suggested by rjmccall.


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

https://reviews.llvm.org/D63975

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/lib/Parse/ParseDecl.cpp
  clang/test/Parser/nested_function_prototype_overflow.cpp
  clang/test/Parser/nested_lambda_overflow.cpp


Index: clang/test/Parser/nested_lambda_overflow.cpp
===
--- /dev/null
+++ clang/test/Parser/nested_lambda_overflow.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 %s -fsyntax-only
+// RUN: not %clang_cc1 %s -fsyntax-only -DFAIL 2>&1 | FileCheck %s
+
+auto foo = [](void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(
+#ifdef FAIL
+void (*f)()
+#endif
+)
 {};
+// CHECK: fatal error: function scope depth exceeded maximum of 127
Index: clang/test/Parser/nested_function_prototype_overflow.cpp
===
--- /dev/null
+++ clang/test/Parser/nested_function_prototype_overflow.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 %s -fsyntax-only
+// RUN: not %clang_cc1 %s -fsyntax-only -DFAIL 2>&1 | FileCheck %s
+
+void foo(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void (*f)(void 
(*f)(void (*f)(
+#ifdef FAIL
+void (*f)()
+#endif
+);
+// CHECK: fatal error: function scope depth exceeded maximum of 127
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -6510,6 +6510,19 @@
ParsedAttributes &FirstArgAttrs,
SmallVectorImpl &ParamInfo,
SourceLocation &EllipsisLoc) {
+
+  // Avoid exceeding the maximum function scope depth.
+  // See https://bugs.llvm.org/show_bug.cgi?id=19607
+  // Note Sema::ActOnParamDeclarator calls ParmVarDecl::setScopeInfo with
+  // getFunctionPrototypeDepth() - 1.
+  if (getCurScope()->getFunctionPrototypeDepth() - 1 >
+  ParmVarDecl::getMaxFunctionScopeDepth()) {
+Diag(Tok.getLocation(), diag::err_function_scope_depth_exceeded)
+<< ParmVarDecl::getMaxFunctionScopeDepth();
+cutOffParsing();
+return;
+  }

[PATCH] D64624: [clangd] Added highlighting to enum constants.

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

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

Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64624

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/semantic-highlighting.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -37,7 +37,8 @@
   {HighlightingKind::Function, "Function"},
   {HighlightingKind::Class, "Class"},
   {HighlightingKind::Enum, "Enum"},
-  {HighlightingKind::Namespace, "Namespace"}};
+  {HighlightingKind::Namespace, "Namespace"},
+  {HighlightingKind::EnumConstant, "EnumConstant"}};
   std::vector ExpectedTokens;
   for (const auto &KindString : KindToString) {
 std::vector Toks = makeHighlightingTokens(
@@ -103,12 +104,19 @@
   }
 )cpp",
 R"cpp(
-  enum class $Enum[[E]] {};
-  enum $Enum[[EE]] {};
+  enum class $Enum[[E]] {
+$EnumConstant[[A]],
+$EnumConstant[[B]],
+  };
+  enum $Enum[[EE]] {
+$EnumConstant[[Hi]],
+  };
   struct $Class[[A]] {
 $Enum[[E]] EEE;
 $Enum[[EE]] ;
   };
+  int $Variable[[I]] = $EnumConstant[[Hi]];
+  $Enum[[E]] $Variable[[L]] = $Enum[[E]]::$EnumConstant[[B]];
 )cpp",
 R"cpp(
   namespace $Namespace[[abc]] {
@@ -118,7 +126,7 @@
   namespace $Namespace[[cde]] {
 struct $Class[[A]] {
   enum class $Enum[[B]] {
-Hi,
+$EnumConstant[[Hi]],
   };
 };
   }
@@ -129,7 +137,7 @@
 $Namespace[[abc]]::$Namespace[[bcd]]::$Namespace[[cde]];
   $Namespace[[abc]]::$Namespace[[bcd]]::$Class[[A]] $Variable[[AA]];
   $Namespace[[vwz]]::$Class[[A]]::$Enum[[B]] $Variable[[AAA]] =
-$Namespace[[vwz]]::$Class[[A]]::$Enum[[B]]::Hi;
+$Namespace[[vwz]]::$Class[[A]]::$Enum[[B]]::$EnumConstant[[Hi]];
   ::$Namespace[[vwz]]::$Class[[A]] $Variable[[B]];
   ::$Namespace[[abc]]::$Namespace[[bcd]]::$Class[[A]] $Variable[[BB]];
 )cpp"};
Index: clang-tools-extra/clangd/test/semantic-highlighting.test
===
--- clang-tools-extra/clangd/test/semantic-highlighting.test
+++ clang-tools-extra/clangd/test/semantic-highlighting.test
@@ -17,6 +17,9 @@
 # CHECK-NEXT:"entity.name.type.enum.cpp"
 # CHECK-NEXT:  ],
 # CHECK-NEXT:  [
+# CHECK-NEXT:"constant.other.enum.cpp"
+# CHECK-NEXT:  ],
+# CHECK-NEXT:  [
 # CHECK-NEXT:"entity.name.namespace.cpp"
 # CHECK-NEXT:  ]
 # CHECK-NEXT:]
Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -28,6 +28,7 @@
   Function,
   Class,
   Enum,
+  EnumConstant,
   Namespace,
 
   NumKinds,
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -119,6 +119,10 @@
   addToken(Loc, HighlightingKind::Enum);
   return;
 }
+if (isa(D)) {
+  addToken(Loc, HighlightingKind::EnumConstant);
+  return;
+}
 if (isa(D)) {
   addToken(Loc, HighlightingKind::Variable);
   return;
@@ -249,6 +253,8 @@
 return "entity.name.type.class.cpp";
   case HighlightingKind::Enum:
 return "entity.name.type.enum.cpp";
+  case HighlightingKind::EnumConstant:
+return "constant.other.enum.cpp";
   case HighlightingKind::Namespace:
 return "entity.name.namespace.cpp";
   case HighlightingKind::NumKinds:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64597: CodeGet: Init 32bit pointers with 0xFFFFFFFF

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added a comment.

In D64597#1581605 , @pcc wrote:

> The problem with `0x` on 32-bit is that it is likely to be a valid 
> address.
>
> When I discussed this with JF I proposed a pointer initialization of 
> `0x` which he agreed to. This value is very likely to trap when 
> accessed (due to accesses likely wrapping to zero) and also has the benefit 
> of being the same pattern as for floats.


The value is very likely not to trap on some systems (due to accesses likely 
wrapping to zero). I am not sure I have a better magic value to offer though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64597



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

[PATCH] D64597: CodeGet: Init 32bit pointers with 0xFFFFFFFF

[Peter Collingbourne via Phabricator via cfe-commits]

pcc added a comment.

In D64597#1582944 , 
@hubert.reinterpretcast wrote:

> In D64597#1581605 , @pcc wrote:
>
> > The problem with `0x` on 32-bit is that it is likely to be a valid 
> > address.
> >
> > When I discussed this with JF I proposed a pointer initialization of 
> > `0x` which he agreed to. This value is very likely to trap when 
> > accessed (due to accesses likely wrapping to zero) and also has the benefit 
> > of being the same pattern as for floats.
>
>
> The value is very likely not to trap on some systems (due to accesses likely 
> wrapping to zero). I am not sure I have a better magic value to offer though.


Right, though if your zero page is mapped then `0x` is probably as good 
as `0x00aa`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64597



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

[PATCH] D64597: CodeGet: Init 32bit pointers with 0xFFFFFFFF

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

In D64597#1582944 , 
@hubert.reinterpretcast wrote:

> In D64597#1581605 , @pcc wrote:
>
> > The problem with `0x` on 32-bit is that it is likely to be a valid 
> > address.
> >
> > When I discussed this with JF I proposed a pointer initialization of 
> > `0x` which he agreed to. This value is very likely to trap when 
> > accessed (due to accesses likely wrapping to zero) and also has the benefit 
> > of being the same pattern as for floats.
>
>
> The value is very likely not to trap on some systems (due to accesses likely 
> wrapping to zero). I am not sure I have a better magic value to offer though.


On 32-bit platforms the only region that's likely to trap is the zero page. 
This seems to be the best choice, but platforms with other regions should be 
able to tune this value (i.e. I'd accept platform checks here which change the 
value on such a target).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64597



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

[PATCH] D64644: Fixes a clang frontend assertion failure (bug 35682)

[Mark de Wever via Phabricator via cfe-commits]

Mordante created this revision.
Mordante added a reviewer: rsmith.
Mordante added a project: clang.

This fixes bug 35682.  I was not able to easily generate a test-case so I 
haven't been able to add unit tests. I'll update the bug in bugzilla with some 
additional information.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D64644

Files:
  clang/lib/Sema/SemaTemplate.cpp


Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -718,9 +718,15 @@
 SourceLocation TemplateKWLoc,
 const DeclarationNameInfo &NameInfo,
 const TemplateArgumentListInfo *TemplateArgs) {
-  return DependentScopeDeclRefExpr::Create(
-  Context, SS.getWithLocInContext(Context), TemplateKWLoc, NameInfo,
-  TemplateArgs);
+  // DependentScopeDeclRefExpr::Create requires a valid QualifierLoc
+  // See https://bugs.llvm.org/show_bug.cgi?id=35682
+  NestedNameSpecifierLoc QualifierLoc = SS.getWithLocInContext(Context);
+  if (!QualifierLoc)
+return ExprError();
+  else
+return DependentScopeDeclRefExpr::Create(Context, std::move(QualifierLoc),
+ TemplateKWLoc, NameInfo,
+ TemplateArgs);
 }
 
 


Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -718,9 +718,15 @@
 SourceLocation TemplateKWLoc,
 const DeclarationNameInfo &NameInfo,
 const TemplateArgumentListInfo *TemplateArgs) {
-  return DependentScopeDeclRefExpr::Create(
-  Context, SS.getWithLocInContext(Context), TemplateKWLoc, NameInfo,
-  TemplateArgs);
+  // DependentScopeDeclRefExpr::Create requires a valid QualifierLoc
+  // See https://bugs.llvm.org/show_bug.cgi?id=35682
+  NestedNameSpecifierLoc QualifierLoc = SS.getWithLocInContext(Context);
+  if (!QualifierLoc)
+return ExprError();
+  else
+return DependentScopeDeclRefExpr::Create(Context, std::move(QualifierLoc),
+ TemplateKWLoc, NameInfo,
+ TemplateArgs);
 }
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D64644: Fixes a clang frontend assertion failure (bug 35682)

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

Test?




Comment at: clang/lib/Sema/SemaTemplate.cpp:726
+return ExprError();
+  else
+return DependentScopeDeclRefExpr::Create(Context, std::move(QualifierLoc),

no else after return


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64644



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

r365919 - Dump actual line numbers when dumping the AST to JSON.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Fri Jul 12 09:53:57 2019
New Revision: 365919

URL: http://llvm.org/viewvc/llvm-project?rev=365919&view=rev
Log:
Dump actual line numbers when dumping the AST to JSON.

The "line" attribute is now the physical line within the source file for the 
location. A "presumedLine" attribute is printed when the presumed line number 
does not match the given source line number. We continue to not print repeated 
line information in subsequent source locations, but we track presumed and 
actual lines separately.

Modified:
cfe/trunk/include/clang/AST/JSONNodeDumper.h
cfe/trunk/lib/AST/JSONNodeDumper.cpp
cfe/trunk/test/AST/ast-dump-stmt-json.c

Modified: cfe/trunk/include/clang/AST/JSONNodeDumper.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/JSONNodeDumper.h?rev=365919&r1=365918&r2=365919&view=diff
==
--- cfe/trunk/include/clang/AST/JSONNodeDumper.h (original)
+++ cfe/trunk/include/clang/AST/JSONNodeDumper.h Fri Jul 12 09:53:57 2019
@@ -125,7 +125,7 @@ class JSONNodeDumper
   PrintingPolicy PrintPolicy;
   const comments::CommandTraits *Traits;
   StringRef LastLocFilename;
-  unsigned LastLocLine;
+  unsigned LastLocLine, LastLocPresumedLine;
 
   using InnerAttrVisitor = ConstAttrVisitor;
   using InnerCommentVisitor =
@@ -142,7 +142,7 @@ class JSONNodeDumper
   }
 
   // Writes the attributes of a SourceLocation object without.
-  void writeBareSourceLocation(SourceLocation Loc);
+  void writeBareSourceLocation(SourceLocation Loc, bool IsSpelling);
 
   // Writes the attributes of a SourceLocation to JSON based on its presumed
   // spelling location. If the given location represents a macro invocation,
@@ -181,7 +181,7 @@ public:
  const PrintingPolicy &PrintPolicy,
  const comments::CommandTraits *Traits)
   : NodeStreamer(OS), SM(SrcMgr), Ctx(Ctx), PrintPolicy(PrintPolicy),
-Traits(Traits), LastLocLine(0) {}
+Traits(Traits), LastLocLine(0), LastLocPresumedLine(0) {}
 
   void Visit(const Attr *A);
   void Visit(const Stmt *Node);

Modified: cfe/trunk/lib/AST/JSONNodeDumper.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/JSONNodeDumper.cpp?rev=365919&r1=365918&r2=365919&view=diff
==
--- cfe/trunk/lib/AST/JSONNodeDumper.cpp (original)
+++ cfe/trunk/lib/AST/JSONNodeDumper.cpp Fri Jul 12 09:53:57 2019
@@ -171,20 +171,28 @@ void JSONNodeDumper::Visit(const Generic
   attributeOnlyIfTrue("selected", A.isSelected());
 }
 
-void JSONNodeDumper::writeBareSourceLocation(SourceLocation Loc) {
+void JSONNodeDumper::writeBareSourceLocation(SourceLocation Loc,
+ bool IsSpelling) {
   PresumedLoc Presumed = SM.getPresumedLoc(Loc);
-
+  unsigned ActualLine = IsSpelling ? SM.getSpellingLineNumber(Loc)
+   : SM.getExpansionLineNumber(Loc);
   if (Presumed.isValid()) {
 if (LastLocFilename != Presumed.getFilename()) {
   JOS.attribute("file", Presumed.getFilename());
-  JOS.attribute("line", Presumed.getLine());
-} else if (LastLocLine != Presumed.getLine())
-  JOS.attribute("line", Presumed.getLine());
+  JOS.attribute("line", ActualLine);
+} else if (LastLocLine != ActualLine)
+  JOS.attribute("line", ActualLine);
+
+unsigned PresumedLine = Presumed.getLine();
+if (ActualLine != PresumedLine && LastLocPresumedLine != PresumedLine)
+  JOS.attribute("presumedLine", PresumedLine);
+
 JOS.attribute("col", Presumed.getColumn());
 JOS.attribute("tokLen",
   Lexer::MeasureTokenLength(Loc, SM, Ctx.getLangOpts()));
 LastLocFilename = Presumed.getFilename();
-LastLocLine = Presumed.getLine();
+LastLocPresumedLine = PresumedLine;
+LastLocLine = ActualLine;
   }
 }
 
@@ -195,17 +203,18 @@ void JSONNodeDumper::writeSourceLocation
   if (Expansion != Spelling) {
 // If the expansion and the spelling are different, output subobjects
 // describing both locations.
-JOS.attributeObject(
-"spellingLoc", [Spelling, this] { writeBareSourceLocation(Spelling); 
});
+JOS.attributeObject("spellingLoc", [Spelling, this] {
+  writeBareSourceLocation(Spelling, /*IsSpelling*/ true);
+});
 JOS.attributeObject("expansionLoc", [Expansion, Loc, this] {
-  writeBareSourceLocation(Expansion);
+  writeBareSourceLocation(Expansion, /*IsSpelling*/ false);
   // If there is a macro expansion, add extra information if the 
interesting
   // bit is the macro arg expansion.
   if (SM.isMacroArgExpansion(Loc))
 JOS.attribute("isMacroArgExpansion", true);
 });
   } else
-writeBareSourceLocation(Spelling);
+writeBareSourceLocation(Spelling, /*IsSpelling*/ true);
 }
 
 void JSONNodeDumper::writeSourceRange(SourceRange R) {

Modified: cfe/trunk/test/AST/ast-dump-

[PATCH] D64597: CodeGet: Init 32bit pointers with 0xFFFFFFFF

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added a comment.

In D64597#1582950 , @jfb wrote:

> On 32-bit platforms the only region that's likely to trap is the zero page. 
> This seems to be the best choice, but platforms with other regions should be 
> able to tune this value (i.e. I'd accept platform checks here which change 
> the value on such a target).


Sounds good. If I get more information from my internal inquiries, then we'll 
follow up in a later patch. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64597



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

[PATCH] D64644: Fixes a clang frontend assertion failure (bug 35682)

[Mark de Wever via Phabricator via cfe-commits]

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

Thanks for feedback. I'll whether I can find a way to generate a nice test case.




Comment at: clang/lib/Sema/SemaTemplate.cpp:726
+return ExprError();
+  else
+return DependentScopeDeclRefExpr::Create(Context, std::move(QualifierLoc),

lebedev.ri wrote:
> no else after return
Will do in the next update.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64644



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

[PATCH] D64646: [OPENMP]Add support for analysis of if clauses.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev created this revision.
ABataev added a reviewer: NoQ.
Herald added subscribers: jdoerfert, jfb, guansong.
Herald added a project: clang.

Added support for analysis of if clauses in the OpenMP directives to be
able to check for the use of uninitialized variables.


Repository:
  rC Clang

https://reviews.llvm.org/D64646

Files:
  include/clang/AST/OpenMPClause.h
  lib/AST/OpenMPClause.cpp
  test/Analysis/cfg-openmp.cpp
  test/OpenMP/cancel_if_messages.cpp
  test/OpenMP/distribute_parallel_for_if_messages.cpp
  test/OpenMP/distribute_parallel_for_simd_if_messages.cpp
  test/OpenMP/parallel_for_if_messages.cpp
  test/OpenMP/parallel_for_simd_if_messages.cpp
  test/OpenMP/parallel_if_messages.cpp
  test/OpenMP/parallel_sections_if_messages.cpp
  test/OpenMP/target_data_if_messages.cpp
  test/OpenMP/target_enter_data_if_messages.cpp
  test/OpenMP/target_exit_data_if_messages.cpp
  test/OpenMP/target_if_messages.cpp
  test/OpenMP/target_parallel_for_if_messages.cpp
  test/OpenMP/target_parallel_for_simd_if_messages.cpp
  test/OpenMP/target_parallel_if_messages.cpp
  test/OpenMP/target_simd_if_messages.cpp
  test/OpenMP/target_teams_distribute_if_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_if_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_if_messages.cpp
  test/OpenMP/target_teams_distribute_simd_if_messages.cpp
  test/OpenMP/target_teams_if_messages.cpp
  test/OpenMP/target_update_if_messages.cpp
  test/OpenMP/task_if_messages.cpp
  test/OpenMP/teams_distribute_parallel_for_if_messages.cpp
  test/OpenMP/teams_distribute_parallel_for_simd_if_messages.cpp

Index: test/OpenMP/teams_distribute_parallel_for_simd_if_messages.cpp
===
--- test/OpenMP/teams_distribute_parallel_for_simd_if_messages.cpp
+++ test/OpenMP/teams_distribute_parallel_for_simd_if_messages.cpp
@@ -9,6 +9,14 @@
   return argc;
 }
 
+void xxx(int argc) {
+  int cond; // expected-note {{initialize the variable 'cond' to silence this warning}}
+#pragma omp target
+#pragma omp teams distribute parallel for simd if(cond) // expected-warning {{variable 'cond' is uninitialized when used here}}
+  for (int i = 0; i < 10; ++i)
+;
+}
+
 struct S1; // expected-note {{declared here}}
 
 template  // expected-note {{declared here}}
Index: test/OpenMP/teams_distribute_parallel_for_if_messages.cpp
===
--- test/OpenMP/teams_distribute_parallel_for_if_messages.cpp
+++ test/OpenMP/teams_distribute_parallel_for_if_messages.cpp
@@ -9,6 +9,14 @@
   return argc;
 }
 
+void xxx(int argc) {
+  int cond; // expected-note {{initialize the variable 'cond' to silence this warning}}
+#pragma omp target
+#pragma omp teams distribute parallel for if(cond) // expected-warning {{variable 'cond' is uninitialized when used here}}
+  for (int i = 0; i < 10; ++i)
+;
+}
+
 struct S1; // expected-note {{declared here}}
 
 template  // expected-note {{declared here}}
Index: test/OpenMP/task_if_messages.cpp
===
--- test/OpenMP/task_if_messages.cpp
+++ test/OpenMP/task_if_messages.cpp
@@ -9,6 +9,13 @@
   return argc;
 }
 
+void xxx(int argc) {
+  int cond; // expected-note {{initialize the variable 'cond' to silence this warning}}
+#pragma omp task if(cond) // expected-warning {{variable 'cond' is uninitialized when used here}}
+  for (int i = 0; i < 10; ++i)
+;
+}
+
 struct S1; // expected-note {{declared here}}
 
 template  // expected-note {{declared here}}
Index: test/OpenMP/target_update_if_messages.cpp
===
--- test/OpenMP/target_update_if_messages.cpp
+++ test/OpenMP/target_update_if_messages.cpp
@@ -9,6 +9,13 @@
   return argc;
 }
 
+void xxx(int argc) {
+  int cond; // expected-note {{initialize the variable 'cond' to silence this warning}}
+#pragma omp target update to(argc) if(cond) // expected-warning {{variable 'cond' is uninitialized when used here}}
+  for (int i = 0; i < 10; ++i)
+;
+}
+
 struct S1; // expected-note {{declared here}}
 
 template  // expected-note {{declared here}}
Index: test/OpenMP/target_teams_if_messages.cpp
===
--- test/OpenMP/target_teams_if_messages.cpp
+++ test/OpenMP/target_teams_if_messages.cpp
@@ -9,6 +9,13 @@
   return argc;
 }
 
+void xxx(int argc) {
+  int cond; // expected-note {{initialize the variable 'cond' to silence this warning}}
+#pragma omp target teams if(cond) // expected-warning {{variable 'cond' is uninitialized when used here}}
+  for (int i = 0; i < 10; ++i)
+;
+}
+
 struct S1; // expected-note {{declared here}}
 
 template  // expected-note {{declared here}}
Index: test/OpenMP/target_teams_distribute_simd_if_messages.cpp
===
--- test/OpenMP/target_teams_distribute_simd_if_messages.cp

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

Hmm, I thought CMake did something more sensible with PRIVATE/INTERFACE/PUBLIC 
dependencies on static libraries, but now I’m not so sure…

I’m continuing to investigate more, but I’ll revert in the meantime.

From:  on behalf of Chris Bieneman 
Date: Friday, July 12, 2019 at 9:08 AM
To: Shoaib Meenai 
Cc: Alex Bradbury , cfe-commits 
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

Ah! I see what is going on here. This is kinda a silliness of CMake. `PRIVATE` 
linkage for a static archive is silly, and shouldn't be possible. All link 
dependencies for static archives are really `INTERFACE` dependencies, and it 
looks like CMake is doing something kinda silly instead of producing a 
reasonable error or warning like it probably should do.

For context, `PRIVATE` linkage in the context of that change would mean 
DirectoryWalker links something, but things that link DirectoryWalker don't. 
That just isn't possible with static archives, so they become interface 
dependencies (and CMake seems to insert a generator expression to make that 
work).

In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, and 
`INTERFACE` for static, which does the right thing.

Unless there is a better reason than a new patch coming in, I think the right 
fix is to revert this back and expect the new patch to correct its linkage 
behavior.

-Chris


On Jul 12, 2019, at 8:53 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

See 
https://reviews.llvm.org/D58418#1577670.
 More generally it would appear for any static library with a PRIVATE 
dependency though.

I guess an alternative would be to use the LINK_LIBRARIES property (which 
should be free of generator expressions, I believe) to propagate dependencies 
instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set 
an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies 
on a static library definitely seems more valuable than supporting INTERFACE 
dependencies.)

From: mailto:cbiene...@apple.com>> on behalf of Chris 
Bieneman mailto:be...@apple.com>>
Date: Friday, July 12, 2019 at 8:49 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: Alex Bradbury mailto:a...@lowrisc.org>>, cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

One of the benefits of the object library approach for generating the clang 
dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues 
with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke 
it, so I was trying to make the clang dylib in a way that it could always be 
enabled.

Do we know where the nested generator expression was coming from?

-Chris



On Jul 12, 2019, at 8:32 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Oops, sorry about the breakage.

Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
Should we disable building the latter if the former is set?

From: Alex Bradbury mailto:a...@lowrisc.org>>
Date: Friday, July 12, 2019 at 2:02 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies

Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ&e=

This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
the point of linking lib/libclang_shared.so.9svn with errors like:
ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by Attributes.cpp:34 
(/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
   

r365921 - CodeGet: Init 32bit pointers with 0xFFFFFFFF

[Vitaly Buka via cfe-commits]

Author: vitalybuka
Date: Fri Jul 12 10:21:55 2019
New Revision: 365921

URL: http://llvm.org/viewvc/llvm-project?rev=365921&view=rev
Log:
CodeGet: Init 32bit pointers with 0x

Summary:
Patch makes D63967 effective for 32bit platforms and improves pattern
initialization there. It cuts size of 32bit binary compiled with
-ftrivial-auto-var-init=pattern by 2% (3% with -Os).

Binary size change on CTMark, (with -fuse-ld=lld -Wl,--icf=all, similar results 
with default linker options)
```
   master   patch  diff
Os pattern   7.915580e+057.698424e+05 -0.028387
O3 pattern   9.953688e+059.752952e+05 -0.019325
```

Zero vs Pattern on master
```
   zero   pattern  diff
Os 7.689712e+05  7.915580e+05  0.031380
O3 9.744796e+05  9.953688e+05  0.021133
```

Zero vs Pattern with the patch
```
   zero   pattern  diff
Os 7.689712e+05  7.698424e+05  0.000789
O3 9.744796e+05  9.752952e+05  0.000742
```

Reviewers: pcc, eugenis, glider, jfb

Reviewed By: jfb

Subscribers: hubert.reinterpretcast, dexonsmith, cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/lib/CodeGen/PatternInit.cpp
cfe/trunk/test/CodeGenCXX/auto-var-init.cpp

Modified: cfe/trunk/lib/CodeGen/PatternInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/PatternInit.cpp?rev=365921&r1=365920&r2=365921&view=diff
==
--- cfe/trunk/lib/CodeGen/PatternInit.cpp (original)
+++ cfe/trunk/lib/CodeGen/PatternInit.cpp Fri Jul 12 10:21:55 2019
@@ -17,12 +17,13 @@ llvm::Constant *clang::CodeGen::initiali
   // repeated byte-pattern which makes it easier to synthesize. We use it for
   // pointers as well as integers so that aggregates are likely to be
   // initialized with this repeated value.
-  constexpr uint64_t LargeValue = 0xull;
   // For 32-bit platforms it's a bit trickier because, across systems, only the
-  // zero page can reasonably be expected to be unmapped, and even then we need
-  // a very low address. We use a smaller value, and that value sadly doesn't
-  // have a repeated byte-pattern. We don't use it for integers.
-  constexpr uint32_t SmallValue = 0x00AA;
+  // zero page can reasonably be expected to be unmapped. We use max 0x
+  // assuming that memory access will overlap into zero page.
+  const uint64_t IntValue =
+  CGM.getContext().getTargetInfo().getMaxPointerWidth() < 64
+  ? 0xull
+  : 0xull;
   // Floating-point values are initialized as NaNs because they propagate. 
Using
   // a repeated byte pattern means that it will be easier to initialize
   // all-floating-point aggregates and arrays with memset. Further, aggregates
@@ -36,27 +37,18 @@ llvm::Constant *clang::CodeGen::initiali
 Ty->isVectorTy() ? Ty->getVectorElementType() : Ty)
 ->getBitWidth();
 if (BitWidth <= 64)
-  return llvm::ConstantInt::get(Ty, LargeValue);
+  return llvm::ConstantInt::get(Ty, IntValue);
 return llvm::ConstantInt::get(
-Ty, llvm::APInt::getSplat(BitWidth, llvm::APInt(64, LargeValue)));
+Ty, llvm::APInt::getSplat(BitWidth, llvm::APInt(64, IntValue)));
   }
   if (Ty->isPtrOrPtrVectorTy()) {
 auto *PtrTy = cast(
 Ty->isVectorTy() ? Ty->getVectorElementType() : Ty);
 unsigned PtrWidth = CGM.getContext().getTargetInfo().getPointerWidth(
 PtrTy->getAddressSpace());
-llvm::Type *IntTy = llvm::IntegerType::get(CGM.getLLVMContext(), PtrWidth);
-uint64_t IntValue;
-switch (PtrWidth) {
-default:
+if (PtrWidth > 64)
   llvm_unreachable("pattern initialization of unsupported pointer width");
-case 64:
-  IntValue = LargeValue;
-  break;
-case 32:
-  IntValue = SmallValue;
-  break;
-}
+llvm::Type *IntTy = llvm::IntegerType::get(CGM.getLLVMContext(), PtrWidth);
 auto *Int = llvm::ConstantInt::get(IntTy, IntValue);
 return llvm::ConstantExpr::getIntToPtr(Int, PtrTy);
   }

Modified: cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/auto-var-init.cpp?rev=365921&r1=365920&r2=365921&view=diff
==
--- cfe/trunk/test/CodeGenCXX/auto-var-init.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/auto-var-init.cpp Fri Jul 12 10:21:55 2019
@@ -12,7 +12,7 @@
 #ifdef __x86_64__
 char inits[] = 
{"-86/-21846/-1431655766/i64/-6148914691236517206/-6148914691236517206/i128/-113427455640312821154458202477256070486/i64/-6148914691236517206/AA/"};
 #else
-char inits[] = 
{"-86/-21846/-1431655766/i32/-1431655766/-6148914691236517206/i32/-1431655766/i32/170/AA/"};
+char inits[] = {"-1/-1/-1/i32/-1/-1/i32/-1/i32/-1/FF/"};
 #define __int128 int;
 #endif
 // PATTERN: @in

[PATCH] D64597: CodeGet: Init 32bit pointers with 0xFFFFFFFF

[Vitaly Buka via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL365921: CodeGet: Init 32bit pointers with 0x 
(authored by vitalybuka, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64597?vs=209401&id=209522#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D64597

Files:
  cfe/trunk/lib/CodeGen/PatternInit.cpp
  cfe/trunk/test/CodeGenCXX/auto-var-init.cpp


Index: cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
===
--- cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
+++ cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
@@ -12,7 +12,7 @@
 #ifdef __x86_64__
 char inits[] = 
{"-86/-21846/-1431655766/i64/-6148914691236517206/-6148914691236517206/i128/-113427455640312821154458202477256070486/i64/-6148914691236517206/AA/"};
 #else
-char inits[] = 
{"-86/-21846/-1431655766/i32/-1431655766/-6148914691236517206/i32/-1431655766/i32/170/AA/"};
+char inits[] = {"-1/-1/-1/i32/-1/-1/i32/-1/i32/-1/FF/"};
 #define __int128 int;
 #endif
 // PATTERN: @inits = {{.*}} 
c"[[I8:[^/]+]]/[[I16:[^/]+]]/[[I32:[^/]+]]/[[ILONGT:[^/]+]]/[[ILONG:[^/]+]]/[[I64:[^/]+]]/[[I128T:[^/]+]]/[[I128:[^/]+]]/[[IPTRT:[^/]+]]/[[IPTR:[^/]+]]/[[IC:[^/]+]]/\00",
 align 1
Index: cfe/trunk/lib/CodeGen/PatternInit.cpp
===
--- cfe/trunk/lib/CodeGen/PatternInit.cpp
+++ cfe/trunk/lib/CodeGen/PatternInit.cpp
@@ -17,12 +17,13 @@
   // repeated byte-pattern which makes it easier to synthesize. We use it for
   // pointers as well as integers so that aggregates are likely to be
   // initialized with this repeated value.
-  constexpr uint64_t LargeValue = 0xull;
   // For 32-bit platforms it's a bit trickier because, across systems, only the
-  // zero page can reasonably be expected to be unmapped, and even then we need
-  // a very low address. We use a smaller value, and that value sadly doesn't
-  // have a repeated byte-pattern. We don't use it for integers.
-  constexpr uint32_t SmallValue = 0x00AA;
+  // zero page can reasonably be expected to be unmapped. We use max 0x
+  // assuming that memory access will overlap into zero page.
+  const uint64_t IntValue =
+  CGM.getContext().getTargetInfo().getMaxPointerWidth() < 64
+  ? 0xull
+  : 0xull;
   // Floating-point values are initialized as NaNs because they propagate. 
Using
   // a repeated byte pattern means that it will be easier to initialize
   // all-floating-point aggregates and arrays with memset. Further, aggregates
@@ -36,27 +37,18 @@
 Ty->isVectorTy() ? Ty->getVectorElementType() : Ty)
 ->getBitWidth();
 if (BitWidth <= 64)
-  return llvm::ConstantInt::get(Ty, LargeValue);
+  return llvm::ConstantInt::get(Ty, IntValue);
 return llvm::ConstantInt::get(
-Ty, llvm::APInt::getSplat(BitWidth, llvm::APInt(64, LargeValue)));
+Ty, llvm::APInt::getSplat(BitWidth, llvm::APInt(64, IntValue)));
   }
   if (Ty->isPtrOrPtrVectorTy()) {
 auto *PtrTy = cast(
 Ty->isVectorTy() ? Ty->getVectorElementType() : Ty);
 unsigned PtrWidth = CGM.getContext().getTargetInfo().getPointerWidth(
 PtrTy->getAddressSpace());
-llvm::Type *IntTy = llvm::IntegerType::get(CGM.getLLVMContext(), PtrWidth);
-uint64_t IntValue;
-switch (PtrWidth) {
-default:
+if (PtrWidth > 64)
   llvm_unreachable("pattern initialization of unsupported pointer width");
-case 64:
-  IntValue = LargeValue;
-  break;
-case 32:
-  IntValue = SmallValue;
-  break;
-}
+llvm::Type *IntTy = llvm::IntegerType::get(CGM.getLLVMContext(), PtrWidth);
 auto *Int = llvm::ConstantInt::get(IntTy, IntValue);
 return llvm::ConstantExpr::getIntToPtr(Int, PtrTy);
   }


Index: cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
===
--- cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
+++ cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
@@ -12,7 +12,7 @@
 #ifdef __x86_64__
 char inits[] = {"-86/-21846/-1431655766/i64/-6148914691236517206/-6148914691236517206/i128/-113427455640312821154458202477256070486/i64/-6148914691236517206/AA/"};
 #else
-char inits[] = {"-86/-21846/-1431655766/i32/-1431655766/-6148914691236517206/i32/-1431655766/i32/170/AA/"};
+char inits[] = {"-1/-1/-1/i32/-1/-1/i32/-1/i32/-1/FF/"};
 #define __int128 int;
 #endif
 // PATTERN: @inits = {{.*}} c"[[I8:[^/]+]]/[[I16:[^/]+]]/[[I32:[^/]+]]/[[ILONGT:[^/]+]]/[[ILONG:[^/]+]]/[[I64:[^/]+]]/[[I128T:[^/]+]]/[[I128:[^/]+]]/[[IPTRT:[^/]+]]/[[IPTR:[^/]+]]/[[IC:[^/]+]]/\00", align 1
Index: cfe/trunk/lib/CodeGen/PatternInit.cpp
===
--- cfe/trunk/li

[PATCH] D64607: [clang-tidy] Fix crash on end location inside macro

[Nathan Huckleberry via Phabricator via cfe-commits]

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

- Add test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64607

Files:
  clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
  clang-tools-extra/test/clang-tidy/bugprone-branch-clone-macro-crash.c


Index: clang-tools-extra/test/clang-tidy/bugprone-branch-clone-macro-crash.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/bugprone-branch-clone-macro-crash.c
@@ -0,0 +1,14 @@
+// RUN: %check_clang_tidy %s bugprone-branch-clone %t
+int x = 0;
+int y = 1;
+#define a(b, c) \
+  typeof(b) d;  \
+  if (b)\
+d = b;  \
+  else if (c)   \
+d = b;
+
+f() {
+  // CHECK-MESSAGES: warning: repeated branch in conditional chain 
[bugprone-branch-clone]
+  a(x, y)
+}
Index: clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
@@ -132,9 +132,12 @@
   // We report the first occurence only when we find the second one.
   diag(Branches[i]->getBeginLoc(),
"repeated branch in conditional chain");
-  diag(Lexer::getLocForEndOfToken(Branches[i]->getEndLoc(), 0,
-  *Result.SourceManager, 
getLangOpts()),
-   "end of the original", DiagnosticIDs::Note);
+  SourceLocation End =
+  Lexer::getLocForEndOfToken(Branches[i]->getEndLoc(), 0,
+ *Result.SourceManager, getLangOpts());
+  if (End.isValid()) {
+diag(End, "end of the original", DiagnosticIDs::Note);
+  }
 }
 
 diag(Branches[j]->getBeginLoc(), "clone %0 starts here",
@@ -208,10 +211,12 @@
 
 if (EndLoc.isMacroID())
   EndLoc = Context.getSourceManager().getExpansionLoc(EndLoc);
+EndLoc = Lexer::getLocForEndOfToken(EndLoc, 0, *Result.SourceManager,
+getLangOpts());
 
-diag(Lexer::getLocForEndOfToken(EndLoc, 0, *Result.SourceManager,
-getLangOpts()),
- "last of these clones ends here", DiagnosticIDs::Note);
+if (EndLoc.isValid()) {
+  diag(EndLoc, "last of these clones ends here", DiagnosticIDs::Note);
+}
   }
   BeginCurrent = EndCurrent;
 }


Index: clang-tools-extra/test/clang-tidy/bugprone-branch-clone-macro-crash.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/bugprone-branch-clone-macro-crash.c
@@ -0,0 +1,14 @@
+// RUN: %check_clang_tidy %s bugprone-branch-clone %t
+int x = 0;
+int y = 1;
+#define a(b, c) \
+  typeof(b) d;  \
+  if (b)\
+d = b;  \
+  else if (c)   \
+d = b;
+
+f() {
+  // CHECK-MESSAGES: warning: repeated branch in conditional chain [bugprone-branch-clone]
+  a(x, y)
+}
Index: clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
@@ -132,9 +132,12 @@
   // We report the first occurence only when we find the second one.
   diag(Branches[i]->getBeginLoc(),
"repeated branch in conditional chain");
-  diag(Lexer::getLocForEndOfToken(Branches[i]->getEndLoc(), 0,
-  *Result.SourceManager, getLangOpts()),
-   "end of the original", DiagnosticIDs::Note);
+  SourceLocation End =
+  Lexer::getLocForEndOfToken(Branches[i]->getEndLoc(), 0,
+ *Result.SourceManager, getLangOpts());
+  if (End.isValid()) {
+diag(End, "end of the original", DiagnosticIDs::Note);
+  }
 }
 
 diag(Branches[j]->getBeginLoc(), "clone %0 starts here",
@@ -208,10 +211,12 @@
 
 if (EndLoc.isMacroID())
   EndLoc = Context.getSourceManager().getExpansionLoc(EndLoc);
+EndLoc = Lexer::getLocForEndOfToken(EndLoc, 0, *Result.SourceManager,
+getLangOpts());
 
-diag(Lexer::getLocForEndOfToken(EndLoc, 0, *Result.SourceManager,
-getLangOpts()),
- "last of these clones ends here", DiagnosticIDs::Note);
+if (EndLoc.isValid()) {
+  diag(EndLoc, "last of these clones ends here", DiagnosticIDs::Note);
+}
   }
   BeginCurrent = EndCurrent;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li

Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

Reverted in r365922.

From:  on behalf of Chris Bieneman 
Date: Friday, July 12, 2019 at 9:08 AM
To: Shoaib Meenai 
Cc: Alex Bradbury , cfe-commits 
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

Ah! I see what is going on here. This is kinda a silliness of CMake. `PRIVATE` 
linkage for a static archive is silly, and shouldn't be possible. All link 
dependencies for static archives are really `INTERFACE` dependencies, and it 
looks like CMake is doing something kinda silly instead of producing a 
reasonable error or warning like it probably should do.

For context, `PRIVATE` linkage in the context of that change would mean 
DirectoryWalker links something, but things that link DirectoryWalker don't. 
That just isn't possible with static archives, so they become interface 
dependencies (and CMake seems to insert a generator expression to make that 
work).

In `llvm_add_library` we always use `PRIVATE` linkage for shared libraries, and 
`INTERFACE` for static, which does the right thing.

Unless there is a better reason than a new patch coming in, I think the right 
fix is to revert this back and expect the new patch to correct its linkage 
behavior.

-Chris


On Jul 12, 2019, at 8:53 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

See 
https://reviews.llvm.org/D58418#1577670.
 More generally it would appear for any static library with a PRIVATE 
dependency though.

I guess an alternative would be to use the LINK_LIBRARIES property (which 
should be free of generator expressions, I believe) to propagate dependencies 
instead of INTERFACE_LINK_LIBRARIES, and just assume that no one is gonna set 
an INTERFACE dependency on a static library. (Supporting PRIVATE dependencies 
on a static library definitely seems more valuable than supporting INTERFACE 
dependencies.)

From: mailto:cbiene...@apple.com>> on behalf of Chris 
Bieneman mailto:be...@apple.com>>
Date: Friday, July 12, 2019 at 8:49 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: Alex Bradbury mailto:a...@lowrisc.org>>, cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

One of the benefits of the object library approach for generating the clang 
dylib is that it was compatible with BUILD_SHARED_LIBS. We had lots of issues 
with libLLVM where people using BUILD_SHARED_LIBS would make changes that broke 
it, so I was trying to make the clang dylib in a way that it could always be 
enabled.

Do we know where the nested generator expression was coming from?

-Chris



On Jul 12, 2019, at 8:32 AM, Shoaib Meenai 
mailto:smee...@fb.com>> wrote:

Oops, sorry about the breakage.

Chris, aren't BUILD_SHARED_LIBS and the combined Clang dylib incompatible? 
Should we disable building the latter if the former is set?

From: Alex Bradbury mailto:a...@lowrisc.org>>
Date: Friday, July 12, 2019 at 2:02 AM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r365825 - [clang-shlib] Fix clang-shlib for PRIVATE dependencies

On Thu, 11 Jul 2019 at 22:20, Shoaib Meenai via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:

Author: smeenai
Date: Thu Jul 11 14:20:38 2019
New Revision: 365825

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D365825-26view-3Drev&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=R9NSZG1XQDVSiE0wJUgb1kMUrG6bJkG3v5GDcTdkpAk&e=
Log:
[clang-shlib] Fix clang-shlib for PRIVATE dependencies

Any static library with a PRIVATE dependency ends up with a
$ generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=ETCU2JhfBcjWz-nbe6LUVSRQR0T1f3wCzxLIhKlMmQo&s=mutN2zF1KixMEVFjNzG_Q7iVJzG5ECbrU4tX3AKWLVQ&e=

This seems to break a -DBUILD_SHARED_LIBS build for me. It fails at
the point of linking lib/libclang_shared.so.9svn with errors like:
ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int)
referenced by Attributes.cpp:34 
(/home/asb/llvm-project/clang/lib/Basic/Attributes.cpp:34)
   
tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Attributes.cpp.o:(clang::attr::getSubjectMatchRuleSpelling(clang::attr::SubjectMatchRule))

ld.lld: error: undefined symbol: llvm::llvm_

r365922 - Revert [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Fri Jul 12 10:23:35 2019
New Revision: 365922

URL: http://llvm.org/viewvc/llvm-project?rev=365922&view=rev
Log:
Revert [clang-shlib] Fix clang-shlib for PRIVATE dependencies

This reverts r365825 (git commit 3173c60f96c3ccfc17d403a192ae58e720153c23)

This is breaking BUILD_SHARED_LIBS=ON builds. Reverting while I rethink it.

Modified:
cfe/trunk/tools/clang-shlib/CMakeLists.txt

Modified: cfe/trunk/tools/clang-shlib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-shlib/CMakeLists.txt?rev=365922&r1=365921&r2=365922&view=diff
==
--- cfe/trunk/tools/clang-shlib/CMakeLists.txt (original)
+++ cfe/trunk/tools/clang-shlib/CMakeLists.txt Fri Jul 12 10:23:35 2019
@@ -7,35 +7,8 @@ get_property(clang_libs GLOBAL PROPERTY
 
 foreach (lib ${clang_libs})
   list(APPEND _OBJECTS $)
-  # Use the static library for its dependencies. The objects that constitute 
the
-  # static library will appear on the link line before the library, so it'll
-  # just be ignored, but the dependencies of the library will still be linked
-  # correctly.
-  #
-  # We could propagate the dependencies manually using the library's
-  # INTERFACE_LINK_LIBRARIES property, but that will contain $
-  # generator expressions if a static library has a private dependency, so we
-  # can't use a $ generator expression to get the property
-  # (since it wouldn't evaluate any generator expressions inside the property).
-  # We could use get_property and do string manipulation to manually evaluate
-  # the $, but that would miss any dependencies added after we
-  # evaluate the get_property. We could also use the LINK_LIBRARIES property
-  # instead, which should be free of any generator expressions, but that's
-  # technically incorrect (it'd most likely work fine in practice, but still).
-  #
-  # Another alternative would be to use --whole-archive or equivalent instead 
of
-  # using the object library at all. However, CMake reorders static libraries 
on
-  # the link line so that a library appears after all its dependents, which can
-  # reorder static libraries out of their --whole-archive --no-whole-archive
-  # sandwich. It's really hard to avoid that reordering while still propagating
-  # dependencies, which defeats the whole point.
-  #
-  # The ideal solution here is to bump our minimum CMake requirement to 3.12,
-  # which adds support for dependencies on object libraries. Until then, 
linking
-  # both the object and the static libraries seems like the least bad solution.
-  #
-  # TODO: Rework this when we bump our minimum CMake version to 3.12 or newer.
-  list(APPEND _DEPS ${lib})
+  list(APPEND _DEPS $)
+  list(APPEND _DEPS $)
 endforeach ()
 
 if (CLANG_LINK_CLANG_DYLIB)


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

[PATCH] D63975: Warn when ScopeDepthOrObjCQuals overflows

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Thanks.

It's good to have a lambda test, but that one isn't actually testing the lambda 
path — the place the diagnostic will trigger is just the normal 
function-prototype path, just originally within a lambda.  You can do something 
like this:

  template  int foo(T &&t);
  void bar(int x = foo(
  [](int x = foo(
  [](int x = foo(
  [](int x = foo(
  ...

It looks like you'll have to bump `-fbracket-level` to get a crash, but since 
that's configurable and this limit isn't, we should still be testing that.

Also I think the same problem can happen with the "blocks" extension — could 
you test that, too?  That would be something like (with `-fblocks`):

  void bar(int x = foo(
  ^(int x = foo(
  ^(int x = foo(
  ^(int x = foo(
  ...


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

https://reviews.llvm.org/D63975



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

Re: [PATCH] D64579: [clang-shlib] Fix clang-shlib for PRIVATE dependencies

[Shoaib Meenai via cfe-commits]

Sorry about the breakage. I reverted it in r365922.

On 7/12/19, 9:12 AM, "Brian Rzycki via Phabricator"  
wrote:

brzycki added a comment.

Hello @smeenai , this commit causes LLVM to fail to build when set set `-D 
BUILD_SHARED_LIBS=ON`. Here is the failing CMake and Ninja invocation:

  /tools/build/cmake-3.14.5/bin/cmake \
  -G Ninja  \
  -D CMAKE_MAKE_PROGRAM=/tools/build/ninja-1.9.0/ninja \
  -D CMAKE_C_COMPILER=/usr/lib/llvm-7/bin/clang \
  -D CMAKE_CXX_COMPILER=/usr/lib/llvm-7/bin/clang++ \
  -D CMAKE_BUILD_TYPE=Release \
  -D CMAKE_INSTALL_PREFIX=/work/upstream/install \
  -D LLVM_TOOL_CLANG_BUILD=ON \
  -D LIBCXX_INCLUDE_BENCHMARKS=ON \
  -D BUILD_SHARED_LIBS=ON \
  -D LLVM_ENABLE_ASSERTIONS=ON \
  -D LLVM_TARGETS_TO_BUILD=X86 \
  /work/upstream/llvm-project/llvm
  
  /tools/build/ninja-1.9.0/ninja -v install

I am able to successfully build LLVM when I change to `-D 
BUILD_SHARED_LIBS=OFF`.

The outputted errors happen during link time of 
`lib/libclang_shared.so.9svn`:

  FAILED: lib/libclang_shared.so.9svn
  
  ...
  
  
tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenModule.cpp.o: In 
function `llvm::cl::opt >::~opt()':
  
CodeGenModule.cpp:(.text._ZN4llvm2cl3optIbLb0ENS0_6parserIbEEED2Ev[_ZN4llvm2cl3optIbLb0ENS0_6parserIbEEED2Ev]+0x7):
 undefined reference to `vtable for llvm::cl::Option'
  
tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenModule.cpp.o: In 
function `clang::CodeGen::CodeGenModule::CodeGenModule(clang::ASTContext&, 
clang::HeaderSearchOptions const&, clang::PreprocessorOptions const&, 
clang::CodeGenOptions const&, llvm::Module&, clang::DiagnosticsEngine&, 
clang::CoverageSourceInfo*)':
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x57a):
 undefined reference to `llvm::FoldingSetBase::FoldingSetBase(unsigned int)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5cc):
 undefined reference to `llvm::Type::getVoidTy(llvm::LLVMContext&)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5d7):
 undefined reference to `llvm::Type::getInt8Ty(llvm::LLVMContext&)'
  
CodeGenModule.cpp:(.text._ZN5clang7CodeGen13CodeGenModuleC2ERNS_10ASTContextERKNS_19HeaderSearchOptionsERKNS_19PreprocessorOptionsERKNS_14CodeGenOptionsERN4llvm6ModuleERNS_17DiagnosticsEngineEPNS_18CoverageSourceInfoE+0x5e3):
 undefined reference to `llvm::Type::getInt16Ty(llvm::LLVMContext&)'
  
  ... (clipped thousands of similar errors)
  
  
WhitespaceManager.cpp:(.text._ZN5clang6formatL18AlignTokenSequenceIRZNS0_17WhitespaceManager28alignConsecutiveDeclarationsEvE3$_2EEvjjjOT_RN4llvm11SmallVectorINS2_6ChangeELj16EEE+0x129):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  
tools/clang/tools/clang-fuzzer/handle-cxx/CMakeFiles/obj.clangHandleCXX.dir/handle_cxx.cpp.o:
 In function `clang_fuzzer::HandleCXX(std::__cxx11::basic_string, std::allocator > const&, std::vector > const&)':
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x67):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x32b):
 undefined reference to `llvm::MemoryBuffer::getMemBuffer(llvm::StringRef, 
llvm::StringRef, bool)'
  
handle_cxx.cpp:(.text._ZN12clang_fuzzer9HandleCXXERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorIPKcSaISA_EE+0x669):
 undefined reference to `llvm::SmallVectorBase::grow_pod(void*, unsigned long, 
unsigned long)'
  clang: error: linker command failed with exit code 1 (use -v to see 
invocation)


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579_new_&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=cpyWE0YV319Dd3hlteUrLx-qVuVLtE5TuYEWHimU5pE&s=ewqtR4F272LGTH1CzQZcQALTX6_rJIABb5AgGqr2s4Q&e=
 


https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D64579&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=cpyWE0YV319Dd3hlteUrLx-qVuVLtE5TuYEWHimU5pE&s=oL7blc7PIIj9vcaNL2TKUMdmqc1iN_6Tv0ddCFde7as&e=
 

[PATCH] D63975: Warn when ScopeDepthOrObjCQuals overflows

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

(Blocks don't actually allow default arguments, but apparently we still parse 
them, so we should test that path.)


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

https://reviews.llvm.org/D63975



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

Re: [clang-tools-extra] r365867 - [clangd] Implement typeHierarchy/resolve for subtypes

[Nathan Ridge via cfe-commits]

Thanks. Is there a way to trigger a run of the bots on a patch prior to 
comitting it?

Nate


From: Russell Gallop 
Sent: July 12, 2019 2:46 PM
To: Nathan Ridge
Cc: cfe-commits
Subject: Re: [clang-tools-extra] r365867 - [clangd] Implement 
typeHierarchy/resolve for subtypes

Hi Nathan,

I've reverted this to get the bot green(er).

Regards
Russ

On Fri, 12 Jul 2019 at 13:32, Russell Gallop 
mailto:russell.gal...@gmail.com>> wrote:
Hi Nathan,
This is causing a test failure on Windows: 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26909

Please can you take a look?

Thanks
Russ

[ RUN  ] Subtypes.LazyResolution
Preamble for file C:\clangd-test\TestTU.cpp cannot be reused. Attempting to 
rebuild it.
Built preamble of size 210988 for file C:\clangd-test\TestTU.cpp
Preamble for file C:\clangd-test\TestTU.cpp cannot be reused. Attempting to 
rebuild it.
Built preamble of size 210988 for file C:\clangd-test\TestTU.cpp
index AST for C:\clangd-test\TestTU.cpp (main=false):
  symbol slab: 4 symbols, 5152 bytes
  ref slab: 0 symbols, 0 refs, 136 bytes
  relations slab: 3 relations, 84 bytes
index AST for C:\clangd-test\TestTU.cpp (main=true):
  symbol slab: 4 symbols, 5152 bytes
  ref slab: 0 symbols, 0 refs, 136 bytes
  relations slab: 3 relations, 84 bytes
Expected must be checked before access or destruction.
Unchecked Expected contained error:
Hint path doesn't start with test root: /clangd-test/TestTU.cpp
0x7FF7486D1B25 (0x0016 0x7FF7486D1B20 0x7FF70006 
0x7FF748680AF4)
0x7FFF3F0EE19D (0x01CDE35AA701 0x01CD 0x01CDE35AA7B0 
0x01CDE35AB111), raise() + 0x1DD bytes(s)
0x7FFF3F0EF071 (0x0003 0x00290003 0x01CDE35AB111 
0x00294FD8E330), abort() + 0x31 bytes(s)
...

On Fri, 12 Jul 2019 at 04:26, Nathan Ridge via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: nridge
Date: Thu Jul 11 20:26:32 2019
New Revision: 365867

URL: http://llvm.org/viewvc/llvm-project?rev=365867&view=rev
Log:
[clangd] Implement typeHierarchy/resolve for subtypes

Summary:
This allows the client to resolve subtypes one level at a time.

For supertypes, this is not necessary, because we eagerly compute
supertypes and return all levels.

Reviewers: sammccall

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

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
clang-tools-extra/trunk/clangd/ClangdLSPServer.h
clang-tools-extra/trunk/clangd/ClangdServer.cpp
clang-tools-extra/trunk/clangd/ClangdServer.h
clang-tools-extra/trunk/clangd/Protocol.cpp
clang-tools-extra/trunk/clangd/Protocol.h
clang-tools-extra/trunk/clangd/XRefs.cpp
clang-tools-extra/trunk/clangd/XRefs.h
clang-tools-extra/trunk/clangd/test/type-hierarchy.test
clang-tools-extra/trunk/clangd/unittests/TypeHierarchyTests.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=365867&r1=365866&r2=365867&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Thu Jul 11 20:26:32 2019
@@ -926,6 +926,13 @@ void ClangdLSPServer::onTypeHierarchy(
 Params.resolve, Params.direction, std::move(Reply));
 }

+void ClangdLSPServer::onResolveTypeHierarchy(
+const ResolveTypeHierarchyItemParams &Params,
+Callback> Reply) {
+  Server->resolveTypeHierarchy(Params.item, Params.resolve, Params.direction,
+   std::move(Reply));
+}
+
 void ClangdLSPServer::applyConfiguration(
 const ConfigurationSettings &Settings) {
   // Per-file update to the compilation database.
@@ -1021,6 +1028,7 @@ ClangdLSPServer::ClangdLSPServer(
   MsgHandler->bind("workspace/didChangeConfiguration", 
&ClangdLSPServer::onChangeConfiguration);
   MsgHandler->bind("textDocument/symbolInfo", &ClangdLSPServer::onSymbolInfo);
   MsgHandler->bind("textDocument/typeHierarchy", 
&ClangdLSPServer::onTypeHierarchy);
+  MsgHandler->bind("typeHierarchy/resolve", 
&ClangdLSPServer::onResolveTypeHierarchy);
   // clang-format on
 }


Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.h?rev=365867&r1=365866&r2=365867&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.h (original)
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.h Thu Jul 11 20:26:32 2019
@@ -100,6 +100,8 @@ private:
Callback>);
   void onTypeHierarchy(const TypeHierarchyParams &,
Callback>);
+  void onRe

[PATCH] D64308: [clangd] Implement typeHierarchy/resolve for subtypes

[Nathan Ridge via Phabricator via cfe-commits]

nridge reopened this revision.
nridge marked an inline comment as done.
nridge added a comment.
This revision is now accepted and ready to land.

This was backed out due to a Windows test failure. Seems to be related to the 
hint path having a different format on Windows. I guess I should not hard-code 
it, but get it from the TestTU.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D64308



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

[PATCH] D62413: [OpenCL][PR41727] Prevent ICE on global dtors

[John McCall via Phabricator via cfe-commits]

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

Current patch LGTM


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

https://reviews.llvm.org/D62413



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

[PATCH] D62413: [OpenCL][PR41727] Prevent ICE on global dtors

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

If you're interested in working on this, great.  I actually think there's zero 
reason to emit a non-null argument here on any target unless we're going to use 
the destructor as the function pointer — but we can do that on every Itanium 
target, so we should.  So where we want to be is probably:

- use the complete-object destructor and the object pointer as its argument 
when destroying a (non-array) object of C++ class type
- otherwise use a custom function that materializes the object pointer on its 
own and uses a null pointer as the argument

And then the address-spaces tweak to that is that we use the second option when 
we either (1) the destructor isn't in the `__cxa_atexit` address space or (2) 
the object pointer can't be converted to that address space.


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

https://reviews.llvm.org/D62413



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

[PATCH] D64632: [clang-format] Don't detect call to ObjC class method as C++11 attribute specifier

[Ben Hamilton via Phabricator via cfe-commits]

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

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64632



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