[PATCH] D58880: [WIP] [clangd] Type hierarchy subtypes

[Nathan Ridge via Phabricator via cfe-commits]

nridge updated this revision to Diff 203073.
nridge added a comment.

Rebased onto D62839  and predecessors


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D58880

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

Index: clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
===
--- clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
+++ clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
@@ -450,6 +450,170 @@
   SelectionRangeIs(Source.range("SDef")), Parents();
 }
 
+SymbolID findSymbolIDByName(llvm::StringRef Name, SymbolIndex *Index) {
+  SymbolID Result;
+  FuzzyFindRequest Request;
+  Request.Query = Name;
+  Request.AnyScope = true;
+  Request.Limit = 1;
+  int ResultCount = 0;
+  Index->fuzzyFind(Request, [&](const Symbol ) {
+Result = S.ID;
+++ResultCount;
+  });
+  EXPECT_EQ(1, ResultCount);
+  return Result;
+}
+
+std::vector collectSubtypes(SymbolID Type, SymbolIndex *Index) {
+  std::vector Result;
+  Index->relations(Type, index::SymbolRole::RelationBaseOf,
+   [](const SymbolID ) { Result.push_back(ID); });
+  return Result;
+}
+
+TEST(Subtypes, SimpleInheritance) {
+  Annotations Source(R"cpp(
+struct Parent {
+  int a;
+};
+
+struct Child1 : Parent {
+  int b;
+};
+
+struct Child2 : Child1 {
+  int c;
+};
+)cpp");
+
+  TestTU TU = TestTU::withCode(Source.code());
+  auto Index = TU.index();
+
+  SymbolID Parent = findSymbolIDByName("Parent", Index.get());
+  SymbolID Child1 = findSymbolIDByName("Child1", Index.get());
+  SymbolID Child2 = findSymbolIDByName("Child2", Index.get());
+
+  EXPECT_THAT(collectSubtypes(Parent, Index.get()), ElementsAre(Child1));
+  EXPECT_THAT(collectSubtypes(Child1, Index.get()), ElementsAre(Child2));
+}
+
+TEST(Subtypes, MultipleInheritance) {
+  Annotations Source(R"cpp(
+struct Parent1 {
+  int a;
+};
+
+struct Parent2 {
+  int b;
+};
+
+struct Parent3 : Parent2 {
+  int c;
+};
+
+struct Child : Parent1, Parent3 {
+  int d;
+};
+)cpp");
+
+  TestTU TU = TestTU::withCode(Source.code());
+  auto Index = TU.index();
+
+  SymbolID Parent1 = findSymbolIDByName("Parent1", Index.get());
+  SymbolID Parent2 = findSymbolIDByName("Parent2", Index.get());
+  SymbolID Parent3 = findSymbolIDByName("Parent3", Index.get());
+  SymbolID Child = findSymbolIDByName("Child", Index.get());
+
+  EXPECT_THAT(collectSubtypes(Parent1, Index.get()), ElementsAre(Child));
+  EXPECT_THAT(collectSubtypes(Parent2, Index.get()), ElementsAre(Parent3));
+  EXPECT_THAT(collectSubtypes(Parent3, Index.get()), ElementsAre(Child));
+}
+
+TEST(Subtypes, ClassTemplate) {
+  Annotations Source(R"cpp(
+struct Parent {};
+
+template 
+struct Child : Parent {};
+)cpp");
+
+  TestTU TU = TestTU::withCode(Source.code());
+  auto Index = TU.index();
+
+  SymbolID Parent = findSymbolIDByName("Parent", Index.get());
+  SymbolID Child = findSymbolIDByName("Child", Index.get());
+
+  EXPECT_THAT(collectSubtypes(Parent, Index.get()), ElementsAre(Child));
+}
+
+// FIXME(nridge): I was expecting https://reviews.llvm.org/D59354 to make this
+// pass.
+TEST(Subtypes, DISABLED_TemplateSpec1) {
+  Annotations Source(R"cpp(
+template 
+struct Parent {};
+
+template <>
+struct Parent {};
+
+struct Child1 : Parent {};
+
+struct Child2 : Parent {};
+)cpp");
+
+  TestTU TU = TestTU::withCode(Source.code());
+  auto Index = TU.index();
+
+  SymbolID Parent = findSymbolIDByName("Parent", Index.get());
+  SymbolID ParentSpec = findSymbolIDByName("Parent", Index.get());
+  SymbolID Child1 = findSymbolIDByName("Child1", Index.get());
+  SymbolID Child2 = findSymbolIDByName("Child2", Index.get());
+
+  EXPECT_THAT(collectSubtypes(Parent, Index.get()), ElementsAre(Child1));
+  EXPECT_THAT(collectSubtypes(ParentSpec, Index.get()), ElementsAre(Child2));
+}
+
+// FIXME(nridge): I was expecting https://reviews.llvm.org/D59354 to make this
+// pass.
+TEST(Subtypes, DISABLED_TemplateSpec2) {
+  Annotations Source(R"cpp(
+struct Parent {};
+
+template 
+struct Child {};
+
+template <>
+struct Child : Parent {};
+)cpp");
+
+  TestTU TU = TestTU::withCode(Source.code());
+  auto Index = TU.index();
+
+  SymbolID Parent = findSymbolIDByName("Parent", Index.get());
+  SymbolID ChildSpec = findSymbolIDByName("Child", Index.get());
+
+  EXPECT_THAT(collectSubtypes(Parent, Index.get()), ElementsAre(ChildSpec));
+}
+
+TEST(Subtypes, DependentBase) {
+  Annotations Source(R"cpp(
+template 
+struct Parent {};
+
+template 
+struct Child : Parent {};
+)cpp");
+
+  TestTU TU = TestTU::withCode(Source.code());
+  auto Index = TU.index();
+
+  SymbolID Parent = findSymbolIDByName("Parent", Index.get());
+  SymbolID Child = findSymbolIDByName("Child", Index.get());
+
+  

[PATCH] D62839: [clangd] Index API and implementations for relations

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

Ok, this is probably ready for a first round of review now.

I know I should add new test cases to at least DexTests and 
BackgroundIndexTests, I'll do this in the next version of the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62839



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

[PATCH] D62839: [WIP] [clangd] Index API and implementations for relations

[Nathan Ridge via Phabricator via cfe-commits]

nridge updated this revision to Diff 203072.
nridge added a comment.

Fill in BackgroundIndex and Dex implementations


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62839

Files:
  clang-tools-extra/clangd/index/Background.cpp
  clang-tools-extra/clangd/index/FileIndex.cpp
  clang-tools-extra/clangd/index/FileIndex.h
  clang-tools-extra/clangd/index/Index.cpp
  clang-tools-extra/clangd/index/Index.h
  clang-tools-extra/clangd/index/IndexAction.cpp
  clang-tools-extra/clangd/index/IndexAction.h
  clang-tools-extra/clangd/index/MemIndex.cpp
  clang-tools-extra/clangd/index/MemIndex.h
  clang-tools-extra/clangd/index/Merge.cpp
  clang-tools-extra/clangd/index/Merge.h
  clang-tools-extra/clangd/index/Serialization.cpp
  clang-tools-extra/clangd/index/dex/Dex.cpp
  clang-tools-extra/clangd/index/dex/Dex.h
  clang-tools-extra/clangd/indexer/IndexerMain.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/DexTests.cpp
  clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
  clang-tools-extra/clangd/unittests/FileIndexTests.cpp
  clang-tools-extra/clangd/unittests/IndexActionTests.cpp
  clang-tools-extra/clangd/unittests/IndexTests.cpp

Index: clang-tools-extra/clangd/unittests/IndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/IndexTests.cpp
+++ clang-tools-extra/clangd/unittests/IndexTests.cpp
@@ -119,8 +119,9 @@
   auto Token = std::make_shared();
   std::weak_ptr WeakToken = Token;
 
-  SwapIndex S(llvm::make_unique(
-  SymbolSlab(), RefSlab(), std::move(Token), /*BackingDataSize=*/0));
+  SwapIndex S(llvm::make_unique(SymbolSlab(), RefSlab(),
+  RelationSlab(), std::move(Token),
+  /*BackingDataSize=*/0));
   EXPECT_FALSE(WeakToken.expired());  // Current MemIndex keeps it alive.
   S.reset(llvm::make_unique()); // Now the MemIndex is destroyed.
   EXPECT_TRUE(WeakToken.expired());   // So the token is too.
@@ -132,12 +133,13 @@
   FuzzyFindRequest Req;
   Req.Query = "2";
   Req.AnyScope = true;
-  MemIndex I(Symbols, RefSlab());
+  MemIndex I(Symbols, RefSlab(), RelationSlab());
   EXPECT_THAT(match(I, Req), ElementsAre("2"));
 }
 
 TEST(MemIndexTest, MemIndexLimitedNumMatches) {
-  auto I = MemIndex::build(generateNumSymbols(0, 100), RefSlab());
+  auto I =
+  MemIndex::build(generateNumSymbols(0, 100), RefSlab(), RelationSlab());
   FuzzyFindRequest Req;
   Req.Query = "5";
   Req.AnyScope = true;
@@ -152,7 +154,7 @@
 TEST(MemIndexTest, FuzzyMatch) {
   auto I = MemIndex::build(
   generateSymbols({"LaughingOutLoud", "LionPopulation", "LittleOldLady"}),
-  RefSlab());
+  RefSlab(), RelationSlab());
   FuzzyFindRequest Req;
   Req.Query = "lol";
   Req.AnyScope = true;
@@ -162,8 +164,8 @@
 }
 
 TEST(MemIndexTest, MatchQualifiedNamesWithoutSpecificScope) {
-  auto I =
-  MemIndex::build(generateSymbols({"a::y1", "b::y2", "y3"}), RefSlab());
+  auto I = MemIndex::build(generateSymbols({"a::y1", "b::y2", "y3"}), RefSlab(),
+   RelationSlab());
   FuzzyFindRequest Req;
   Req.Query = "y";
   Req.AnyScope = true;
@@ -171,8 +173,8 @@
 }
 
 TEST(MemIndexTest, MatchQualifiedNamesWithGlobalScope) {
-  auto I =
-  MemIndex::build(generateSymbols({"a::y1", "b::y2", "y3"}), RefSlab());
+  auto I = MemIndex::build(generateSymbols({"a::y1", "b::y2", "y3"}), RefSlab(),
+   RelationSlab());
   FuzzyFindRequest Req;
   Req.Query = "y";
   Req.Scopes = {""};
@@ -181,7 +183,8 @@
 
 TEST(MemIndexTest, MatchQualifiedNamesWithOneScope) {
   auto I = MemIndex::build(
-  generateSymbols({"a::y1", "a::y2", "a::x", "b::y2", "y3"}), RefSlab());
+  generateSymbols({"a::y1", "a::y2", "a::x", "b::y2", "y3"}), RefSlab(),
+  RelationSlab());
   FuzzyFindRequest Req;
   Req.Query = "y";
   Req.Scopes = {"a::"};
@@ -190,7 +193,8 @@
 
 TEST(MemIndexTest, MatchQualifiedNamesWithMultipleScopes) {
   auto I = MemIndex::build(
-  generateSymbols({"a::y1", "a::y2", "a::x", "b::y3", "y3"}), RefSlab());
+  generateSymbols({"a::y1", "a::y2", "a::x", "b::y3", "y3"}), RefSlab(),
+  RelationSlab());
   FuzzyFindRequest Req;
   Req.Query = "y";
   Req.Scopes = {"a::", "b::"};
@@ -198,7 +202,8 @@
 }
 
 TEST(MemIndexTest, NoMatchNestedScopes) {
-  auto I = MemIndex::build(generateSymbols({"a::y1", "a::b::y2"}), RefSlab());
+  auto I = MemIndex::build(generateSymbols({"a::y1", "a::b::y2"}), RefSlab(),
+   RelationSlab());
   FuzzyFindRequest Req;
   Req.Query = "y";
   Req.Scopes = {"a::"};
@@ -206,7 +211,8 @@
 }
 
 TEST(MemIndexTest, IgnoreCases) {
-  auto I = MemIndex::build(generateSymbols({"ns::ABC", "ns::abc"}), RefSlab());
+  auto I = MemIndex::build(generateSymbols({"ns::ABC", "ns::abc"}), RefSlab(),
+   

Network issues in LLVM Lab

[Galina Kistanova via cfe-commits]

Hello everyone,

Many of you may noticed yesterday issues with the production LLVM buildbot,
and yesterday and today issues with the staging LLVM buildbot. The problems
were because of problems with the outside connection.

All the problems have been resolved. The production buildbot woks normally
as of yesterday. The staging buildbot works normally as of today.

Please let me know if you still see any issues.

Thank you for the patience.

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

[PATCH] D60583: [AArch64] Implement Vector Funtion ABI name mangling.

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D60583#1529937 , @fpetrogalli wrote:

> In D60583#1529878 , @jdoerfert wrote:
>
> > Why/Where did we decide to clobber the attribute list with "non-existent 
> > function names"?
>
>
> The existence of those symbols is guaranteed by the "contract" stipulated via 
> the Vector Function ABI. They cannot be added explicitly by the front-end as 
> `define`s because they would be removed before reaching the vectorizer.


That is not a good argument. Afaik, there are multiple ways designed to keep 
symbols alive, e.g., `@llvm.used`.

>> I don't think an attribute list like this:
>>  `attributes #1 = { "_ZGVsM2v_foo" "_ZGVsM32v_foo" "_ZGVsM4v_foo" 
>> "_ZGVsM6v_foo" "_ZGVsM8v_foo" "_ZGVsMxv_foo" ... `
>>  is helpful in any way, e.g., this would require us to search through all 
>> attributes and interpret them one by one.
> 
> Agree. This is what was agreed : 
> http://lists.llvm.org/pipermail/cfe-dev/2016-March/047732.html
> 
> The new RFC will get rid of this list of string attributes. It will become 
> something like:
> 
>   attribute #0 = { 
> declare-variant="comma,separated,list,of,vector,function,ABI,mangled,names" }.
> 
> 
> 
> 
>> This seems to me like an ad-hoc implementation of the RFC that is currently 
>> discussed but committed before the discussion is finished.
> 
> I can assure you that's not the case.
> 
> The code in this patch is what it is because it is based on previous 
> (accepted) RFC originally proposed by other people and used by VecClone: 
> https://reviews.llvm.org/D22792
> 
> As you can see in the unit tests of the VecClone pass, the variant attribute 
> is added as follows:
> 
>   attributes #0 = { nounwind uwtable 
> "vector-variants"="_ZGVbM4_foo1,_ZGVbN4_foo1,_ZGVcM8_foo1,_ZGVcN8_foo1,_ZGVdM8_foo1,_ZGVdN8_foo1,_ZGVeM16_foo1,_ZGVeN16_foo1"
>    }

I get that it was discussed three years ago and I get that it was accepted then.
My confusing stems from the fact that it was committed just now, three years 
later, but shortly before the new RFC basically proposed a different encoding.

> Nothing in LLVM is using those attributes at the moment, that might be the 
> reason why the string attribute have not yet been moved to a single attribute.

That means we can easily change the encoding, and I strongly believe we should.

Given that you want a different encoding, I don't know if I have to list 
reasons why I dislike this one (direct names as attributes). Though, I can do 
so if we want to discuss it.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60583



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

r362581 - Add __FILE_NAME__ to ReleaseNotes. NFC

[Kristina Brooks via cfe-commits]

Author: kristina
Date: Tue Jun  4 20:47:02 2019
New Revision: 362581

URL: http://llvm.org/viewvc/llvm-project?rev=362581=rev
Log:
Add __FILE_NAME__ to ReleaseNotes. NFC

Added it under C language changes as a nonstandard
extension for the time being.


Modified:
cfe/trunk/docs/ReleaseNotes.rst

Modified: cfe/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=362581=362580=362581=diff
==
--- cfe/trunk/docs/ReleaseNotes.rst (original)
+++ cfe/trunk/docs/ReleaseNotes.rst Tue Jun  4 20:47:02 2019
@@ -101,9 +101,11 @@ Windows Support
 C Language Changes in Clang
 ---
 
-- ...
+- ``__FILE_NAME__`` macro has been added as a Clang specific extension 
supported
+  in all C-family languages. This macro is similar to ``__FILE__`` except it
+  will always provide the last path component when possible.
 
-...
+- ...
 
 C11 Feature Support
 ^^^


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

[Diffusion] rL358949: [PowerPC] [Clang] Port MMX intrinsics and basic test cases to Power

[Zixuan Wu via Phabricator via cfe-commits]

wuzish added inline comments.

/cfe/trunk/lib/Driver/ToolChains/PPCLinux.cpp:26 @hubert.reinterpretcast 
Thanks for your advice. I think the name `ppc_wrappers` is accurate to describe 
its meaning that wrapping the headers under standard library path or standard 
header search path. (Headers in lib/Headers is clang standard search path) It's 
truly that `ppc_wrappers` can be used for all platforms of powerpc no matter 
what's OS or bit mode or endian because there are only little num of files and 
no need for too many level directory. And we can distinguish OS, endian or mode 
by macros in wrapped headers, combining with `#include_next` as what you said, 
which I also prefer to use because it's easier to maintain headers instead of 
modifying cpp code about toolchain class such as `PPCLinuxToolChain `.

We will use better way described above to guard those headers only in 64-bit 
mode soon after other headers have been upstreamed.

https://reviews.llvm.org/rL358949



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

[PATCH] D58375: [Clang] Disable new PM for tests that use optimization level -O1, -O2 and -O3

[Petr Hosek via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL362580: [Clang] Disable new PM for tests that use 
optimization level -O1, -O2 and -O3 (authored by phosek, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D58375?vs=200784=203067#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D58375

Files:
  cfe/trunk/test/CodeGen/callback_annotated.c
  cfe/trunk/test/CodeGen/cfi-icall-cross-dso.c
  cfe/trunk/test/CodeGen/complex-math.c
  cfe/trunk/test/CodeGen/dllimport.c
  cfe/trunk/test/CodeGen/inline2.c
  cfe/trunk/test/CodeGen/lifetime.c
  cfe/trunk/test/CodeGen/sanitize-address-field-padding.cpp
  cfe/trunk/test/CodeGen/tbaa-for-vptr.cpp
  cfe/trunk/test/CodeGenCXX/atomicinit.cpp
  cfe/trunk/test/CodeGenCXX/cfi-speculative-vtable.cpp
  cfe/trunk/test/CodeGenCXX/debug-info-class-optzns.cpp
  cfe/trunk/test/CodeGenCXX/dllimport-members.cpp
  cfe/trunk/test/CodeGenCXX/dllimport.cpp
  cfe/trunk/test/CodeGenCXX/dso-local-executable.cpp
  cfe/trunk/test/CodeGenCXX/init-invariant.cpp
  cfe/trunk/test/CodeGenCXX/merge-functions.cpp
  cfe/trunk/test/CodeGenCXX/nrvo.cpp
  cfe/trunk/test/CodeGenCXX/sanitize-dtor-nontrivial-virtual-base.cpp
  cfe/trunk/test/CodeGenCXX/visibility-hidden-extern-templates.cpp
  cfe/trunk/test/CodeGenObjCXX/nrvo.mm
  cfe/trunk/test/Driver/asan.c
  cfe/trunk/test/Driver/msan.c
  cfe/trunk/test/Driver/tsan.c

Index: cfe/trunk/test/CodeGenCXX/cfi-speculative-vtable.cpp
===
--- cfe/trunk/test/CodeGenCXX/cfi-speculative-vtable.cpp
+++ cfe/trunk/test/CodeGenCXX/cfi-speculative-vtable.cpp
@@ -1,7 +1,7 @@
 // Test that we don't emit a bit set entry for a speculative (available_externally) vtable.
 // This does not happen in the Microsoft ABI.
-// RUN: %clang_cc1 -triple x86_64-unknown-linux -O1 -fsanitize=cfi-vcall -fsanitize-trap=cfi-vcall -emit-llvm -o - %s | FileCheck  %s
-// RUN: %clang_cc1 -triple x86_64-unknown-linux -O1 -fsanitize=cfi-vcall -fsanitize-trap=cfi-vcall -fsanitize-cfi-cross-dso -emit-llvm -o - %s | FileCheck  %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -O1 -fno-experimental-new-pass-manager -fsanitize=cfi-vcall -fsanitize-trap=cfi-vcall -emit-llvm -o - %s | FileCheck  %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -O1 -fno-experimental-new-pass-manager -fsanitize=cfi-vcall -fsanitize-trap=cfi-vcall -fsanitize-cfi-cross-dso -emit-llvm -o - %s | FileCheck  %s
 
 class A {
  public:
Index: cfe/trunk/test/CodeGenCXX/dllimport.cpp
===
--- cfe/trunk/test/CodeGenCXX/dllimport.cpp
+++ cfe/trunk/test/CodeGenCXX/dllimport.cpp
@@ -4,7 +4,7 @@
 // RUN: %clang_cc1 -triple x86_64-windows-gnu  -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -w | FileCheck --check-prefix=GNU --check-prefix=G64 %s
 // RUN: %clang_cc1 -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -fms-compatibility-version=18.00 -emit-llvm -std=c++1y -O1 -disable-llvm-passes -o - %s -DMSABI -w | FileCheck --check-prefix=MO1 --check-prefix=M18 %s
 // RUN: %clang_cc1 -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -fms-compatibility-version=19.00 -emit-llvm -std=c++1y -O1 -disable-llvm-passes -o - %s -DMSABI -w | FileCheck --check-prefix=MO1 --check-prefix=M19 %s
-// RUN: %clang_cc1 -triple i686-windows-gnu-fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O1 -o - %s -w | FileCheck --check-prefix=GO1 %s
+// RUN: %clang_cc1 -triple i686-windows-gnu-fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O1 -fno-experimental-new-pass-manager -o - %s -w | FileCheck --check-prefix=GO1 %s
 
 // CHECK-NOT doesn't play nice with CHECK-DAG, so use separate run lines.
 // RUN: %clang_cc1 -triple i686-windows-msvc   -fno-rtti -fno-threadsafe-statics -fms-extensions -emit-llvm -std=c++1y -O0 -o - %s -DMSABI -w | FileCheck --check-prefix=MSC2 %s
Index: cfe/trunk/test/CodeGenCXX/dso-local-executable.cpp
===
--- cfe/trunk/test/CodeGenCXX/dso-local-executable.cpp
+++ cfe/trunk/test/CodeGenCXX/dso-local-executable.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-pc-linux -mrelocation-model static -O1 -emit-llvm %s -o - | FileCheck --check-prefix=STATIC %s
-// RUN: %clang_cc1 -triple x86_64-pc-linux -mrelocation-model static -fno-plt -O1 -emit-llvm %s -o - | FileCheck --check-prefix=NOPLT %s
-// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -O1 -emit-llvm %s -o - | FileCheck --check-prefix=MINGW %s
+// RUN: %clang_cc1 -triple x86_64-pc-linux -mrelocation-model static -O1 

r362580 - [Clang] Disable new PM for tests that use optimization level -O1, -O2 and -O3

[Petr Hosek via cfe-commits]

Author: phosek
Date: Tue Jun  4 20:17:11 2019
New Revision: 362580

URL: http://llvm.org/viewvc/llvm-project?rev=362580=rev
Log:
[Clang] Disable new PM for tests that use optimization level -O1, -O2 and -O3

Tests that use -O1, -O2 and -O3 would often produce different results
with the new pass manager which makes these tests fail. Disable new PM
explicitly for these tests.

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

Modified:
cfe/trunk/test/CodeGen/callback_annotated.c
cfe/trunk/test/CodeGen/cfi-icall-cross-dso.c
cfe/trunk/test/CodeGen/complex-math.c
cfe/trunk/test/CodeGen/dllimport.c
cfe/trunk/test/CodeGen/inline2.c
cfe/trunk/test/CodeGen/lifetime.c
cfe/trunk/test/CodeGen/sanitize-address-field-padding.cpp
cfe/trunk/test/CodeGen/tbaa-for-vptr.cpp
cfe/trunk/test/CodeGenCXX/atomicinit.cpp
cfe/trunk/test/CodeGenCXX/cfi-speculative-vtable.cpp
cfe/trunk/test/CodeGenCXX/debug-info-class-optzns.cpp
cfe/trunk/test/CodeGenCXX/dllimport-members.cpp
cfe/trunk/test/CodeGenCXX/dllimport.cpp
cfe/trunk/test/CodeGenCXX/dso-local-executable.cpp
cfe/trunk/test/CodeGenCXX/init-invariant.cpp
cfe/trunk/test/CodeGenCXX/merge-functions.cpp
cfe/trunk/test/CodeGenCXX/nrvo.cpp
cfe/trunk/test/CodeGenCXX/sanitize-dtor-nontrivial-virtual-base.cpp
cfe/trunk/test/CodeGenCXX/visibility-hidden-extern-templates.cpp
cfe/trunk/test/CodeGenObjCXX/nrvo.mm
cfe/trunk/test/Driver/asan.c
cfe/trunk/test/Driver/msan.c
cfe/trunk/test/Driver/tsan.c

Modified: cfe/trunk/test/CodeGen/callback_annotated.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/callback_annotated.c?rev=362580=362579=362580=diff
==
--- cfe/trunk/test/CodeGen/callback_annotated.c (original)
+++ cfe/trunk/test/CodeGen/callback_annotated.c Tue Jun  4 20:17:11 2019
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple i386-unknown-unknown -fopenmp -O1 %s -emit-llvm -o 
- | FileCheck %s --check-prefix=RUN1
-// RUN: %clang_cc1 -triple i386-unknown-unknown -fopenmp -O1 %s -emit-llvm -o 
- | FileCheck %s --check-prefix=RUN2
-// RUN: %clang_cc1 -triple i386-unknown-unknown -fopenmp -O1 %s -emit-llvm -o 
- | opt -ipconstprop -S | FileCheck --check-prefix=IPCP %s
+// RUN: %clang_cc1 -triple i386-unknown-unknown -fopenmp -O1 
-fno-experimental-new-pass-manager %s -emit-llvm -o - | FileCheck %s 
--check-prefix=RUN1
+// RUN: %clang_cc1 -triple i386-unknown-unknown -fopenmp -O1 
-fno-experimental-new-pass-manager %s -emit-llvm -o - | FileCheck %s 
--check-prefix=RUN2
+// RUN: %clang_cc1 -triple i386-unknown-unknown -fopenmp -O1 
-fno-experimental-new-pass-manager %s -emit-llvm -o - | opt -ipconstprop -S | 
FileCheck --check-prefix=IPCP %s
 
 // RUN1-DAG: @broker0({{[^#]*#[0-9]+}} !callback ![[cid0:[0-9]+]]
 __attribute__((callback(1, 2))) void *broker0(void *(*callee)(void *), void 
*payload) {

Modified: cfe/trunk/test/CodeGen/cfi-icall-cross-dso.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/cfi-icall-cross-dso.c?rev=362580=362579=362580=diff
==
--- cfe/trunk/test/CodeGen/cfi-icall-cross-dso.c (original)
+++ cfe/trunk/test/CodeGen/cfi-icall-cross-dso.c Tue Jun  4 20:17:11 2019
@@ -1,25 +1,25 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-linux -O1 \
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -O1 
-fno-experimental-new-pass-manager \
 // RUN:   -fsanitize=cfi-icall -fsanitize-cfi-cross-dso \
 // RUN:   -emit-llvm -o - %s | FileCheck \
 // RUN:   --check-prefix=CHECK --check-prefix=CHECK-DIAG \
 // RUN:   --check-prefix=ITANIUM --check-prefix=ITANIUM-DIAG \
 // RUN:   %s
 
-// RUN: %clang_cc1 -triple x86_64-unknown-linux -O1 \
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -O1 
-fno-experimental-new-pass-manager \
 // RUN:   -fsanitize=cfi-icall -fsanitize-cfi-cross-dso 
-fsanitize-trap=cfi-icall \
 // RUN:   -emit-llvm -o - %s | FileCheck \
 // RUN:   --check-prefix=CHECK \
 // RUN:   --check-prefix=ITANIUM --check-prefix=ITANIUM-TRAP \
 // RUN:   %s
 
-// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -O1 \
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -O1 
-fno-experimental-new-pass-manager \
 // RUN:   -fsanitize=cfi-icall -fsanitize-cfi-cross-dso \
 // RUN:   -emit-llvm -o - %s | FileCheck \
 // RUN:   --check-prefix=CHECK --check-prefix=CHECK-DIAG \
 // RUN:   --check-prefix=MS --check-prefix=MS-DIAG \
 // RUN:   %s
 
-// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -O1 \
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -O1 
-fno-experimental-new-pass-manager \
 // RUN:   -fsanitize=cfi-icall -fsanitize-cfi-cross-dso 
-fsanitize-trap=cfi-icall \
 // RUN:   -emit-llvm -o - %s | FileCheck \
 // RUN:   --check-prefix=CHECK \

Modified: cfe/trunk/test/CodeGen/complex-math.c
URL: 

[PATCH] D62883: [analyzer] Track conditions of terminator statements on which the reported node depends on

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Yay, this thing really works!

> Now, whether this change is any good is practically impossible to tell 
> without evaluation on production code, so I'll get back with that once I 
> gather some data.

Yes. This patch deserves some data on how much have reports grown in length 
(i.e., how many have grown in length and how much did they do so). Ideally we 
should also have a look at how many of the new notes were truly useful. Eg., 
you can start with the old report, understand it (or fail to do so), then take 
the new report. If you get this feeling that's like "ugh, if i've seen this 
note before i would have figured this out much sooner!", then it's a good note. 
If the bug report was obvious to begin with and the note didn't add much, it's 
probably not a good note. But it's not necessarily bad as long as the report 
remains readable.

Additionally, it's likely that some reports will in fact get suppressed due to 
inline defensive checks suppressions kicking in over condition values. That'd 
be a lot of fun to see as well.




Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1863-1864
+
+case Stmt::ObjCForCollectionStmtClass:
+  return cast(S)->getCollection();
+

Szelethus wrote:
> @NoQ Any feelings on this?
This makes some sense in the long run but i think you should give up here for 
now. Unlike `CXXForRangeStmt`, its Objective-C counterpart doesn't mock up the 
AST that would have made it look like a regular for-loop, so there just isn't 
an AST node that would represent the part of it that corresponds to "`__begin 
!= __end`".

Even in the C++ case, i'm not sure your current behavior would make much sense. 
We should probably delegate this work to a checker that knows how collections 
work and what makes them empty or have a certain size, something similar to 
what the `IteratorChecker` seems to be becoming :)

Should we give mark the report as invalid when we give up here? I've no idea, i 
guess i'll have to gather more empirical evidence on that.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1894-1897
+  // If N is originaring from a different function than the node of interest,
+  // we can't reason about control dependencies.
+  if (>getCFG() != >getCFG())
+return nullptr;

What if they're in the same function but in different stack frames, i.e. due to 
recursion? I think you should just compare stack frame contexts here.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1899-1901
+  CFGBlock *NB = GetRelevantBlock(N);
+  if (!VisitedBlocks.insert(NB).second)
+return nullptr;

I didn't really understand this part.



Comment at: clang/test/Analysis/diagnostics/no-store-func-path-notes.m:26
+// expected-note@-1{{Returning from 
'initVar:param:'}}
+// expected-note@-2{{Passing the value 0 
via 2nd parameter 'param'}}
+// expected-note@-3{{'out' initialized to 
1}}

I suspect we'll have to play with the wording a little bit. The current 
`trackExpressionValue()` was worded for the scenario in which there's only one 
value that we're tracking. So it keeps saying things like "THE VALUE" as if 
we're focused on one value. In reality, however, "the value 0" isn't the same 
value as the "undefined or garbage value" that the report is about.

I think we should discriminate between these values somehow. Eg., "Passing the 
//condition// value 0 via 2nd parameter 'param'". We have this information when 
we're attaching the visitor, so we can keep passing it around.



Comment at: clang/test/Analysis/track-control-dependency-conditions.cpp:34
+
+  foo(); // TODO: Add nodes here about flag's value being invalidated.
+  if (flag) // expected-note   {{Taking false branch}}

Why?


Repository:
  rC Clang

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

https://reviews.llvm.org/D62883



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

[PATCH] D62888: [NewPM] Port Sancov

[Leonard Chan via Phabricator via cfe-commits]

leonardchan created this revision.
leonardchan added reviewers: fedor.sergeev, philip.pfaffe, chandlerc.
leonardchan added a project: clang.
Herald added subscribers: hiraditya, eraman.
Herald added a project: LLVM.

This patch contains a port of SanitizerCoverage to the new pass manager. This 
one's a bit hefty.

Changes:

- Split `SanitizerCoverageModule` into 2 `SanitizerCoverage` for passing over 
functions and `ModuleSanitizerCoverage` for passing over modules.
- `ModuleSanitizerCoverage` exists for adding 2 module level calls to 
initialization functions but only if there's a function that was instrumented 
by sancov. This uses `SanitizerCoverageFunctionCheck[Legacy]Pass`, a function 
analysis that just checks if there's a function that can be instrumented.
  - An alternative to this analysis could just be to iterate over the functions 
in `ModuleSanitizerCoverage`, but I'm not sure if that's more correct than 
another function analysis.
- Added legacy and new PM wrapper classes that own instances of the 2 new 
classes.
- Update llvm tests and add clang tests,


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D62888

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/sancov-new-pm.c
  llvm/include/llvm/InitializePasses.h
  llvm/include/llvm/Transforms/Instrumentation.h
  llvm/include/llvm/Transforms/Instrumentation/SanitizerCoverage.h
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Passes/PassRegistry.def
  llvm/lib/Transforms/Instrumentation/Instrumentation.cpp
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
  llvm/test/Instrumentation/SanitizerCoverage/abort-in-entry-block.ll
  llvm/test/Instrumentation/SanitizerCoverage/backedge-pruning.ll
  llvm/test/Instrumentation/SanitizerCoverage/chains.ll
  llvm/test/Instrumentation/SanitizerCoverage/cmp-tracing-api-x86_32.ll
  llvm/test/Instrumentation/SanitizerCoverage/cmp-tracing-api-x86_64.ll
  llvm/test/Instrumentation/SanitizerCoverage/cmp-tracing.ll
  llvm/test/Instrumentation/SanitizerCoverage/coff-comdat.ll
  
llvm/test/Instrumentation/SanitizerCoverage/coff-pc-table-inline-8bit-counters.ll
  llvm/test/Instrumentation/SanitizerCoverage/coff-used-ctor.ll
  llvm/test/Instrumentation/SanitizerCoverage/const-cmp-tracing.ll
  llvm/test/Instrumentation/SanitizerCoverage/coverage-dbg.ll
  llvm/test/Instrumentation/SanitizerCoverage/coverage.ll
  llvm/test/Instrumentation/SanitizerCoverage/coverage2-dbg.ll
  llvm/test/Instrumentation/SanitizerCoverage/div-tracing.ll
  llvm/test/Instrumentation/SanitizerCoverage/gep-tracing.ll
  llvm/test/Instrumentation/SanitizerCoverage/inline-8bit-counters.ll
  llvm/test/Instrumentation/SanitizerCoverage/interposable-symbol-nocomdat.ll
  llvm/test/Instrumentation/SanitizerCoverage/no-func.ll
  llvm/test/Instrumentation/SanitizerCoverage/pc-table.ll
  llvm/test/Instrumentation/SanitizerCoverage/postdominator_check.ll
  llvm/test/Instrumentation/SanitizerCoverage/seh.ll
  
llvm/test/Instrumentation/SanitizerCoverage/stack-depth-variable-declared-by-user.ll
  llvm/test/Instrumentation/SanitizerCoverage/stack-depth.ll
  llvm/test/Instrumentation/SanitizerCoverage/switch-tracing.ll
  llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-comdat.ll
  
llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-inline-8bit-counters.ll
  llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-nocomdat.ll
  llvm/test/Instrumentation/SanitizerCoverage/tracing-comdat.ll
  llvm/test/Instrumentation/SanitizerCoverage/tracing.ll
  llvm/test/Instrumentation/SanitizerCoverage/unreachable-critedge.ll
  llvm/test/Instrumentation/SanitizerCoverage/wineh.ll

Index: llvm/test/Instrumentation/SanitizerCoverage/wineh.ll
===
--- llvm/test/Instrumentation/SanitizerCoverage/wineh.ll
+++ llvm/test/Instrumentation/SanitizerCoverage/wineh.ll
@@ -1,4 +1,5 @@
 ; RUN: opt < %s -sancov -sanitizer-coverage-level=3 -sanitizer-coverage-trace-pc -S | FileCheck %s --check-prefix=CHECK
+; RUN: opt < %s -passes='module(sancov-module),function(require,sancov-func)' -sanitizer-coverage-level=3 -sanitizer-coverage-trace-pc -S | FileCheck %s --check-prefix=CHECK
 
 ; Generated from this C++ source:
 ; $ clang -O2 t.cpp -S -emit-llvm
Index: llvm/test/Instrumentation/SanitizerCoverage/unreachable-critedge.ll
===
--- llvm/test/Instrumentation/SanitizerCoverage/unreachable-critedge.ll
+++ llvm/test/Instrumentation/SanitizerCoverage/unreachable-critedge.ll
@@ -1,4 +1,5 @@
 ; RUN: opt < %s -S -sancov -sanitizer-coverage-level=3 | FileCheck %s
+; RUN: opt < %s -S -passes='module(sancov-module),function(require,sancov-func)' -sanitizer-coverage-level=3 | FileCheck %s
 
 ; The critical edges to unreachable_bb should not be split.
 define i32 @foo(i32 %c, i32 %d) {
Index: llvm/test/Instrumentation/SanitizerCoverage/tracing.ll
===
--- 

[PATCH] D62638: [analyzer] A Python script to prettify the ExplodedGraph dumps.

[Artem Dergachev via Phabricator via cfe-commits]

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

In D62638#1529170 , @krytarowski wrote:

> This commit breaks the NetBSD buildbot node.


rC362574 .




Comment at: cfe/trunk/utils/analyzer/exploded-graph-rewriter.py:1
+#!/usr/bin/env python
+

Charusso wrote:
> ```
> # something else then
> #
> #==- exploded-graph-rewriter.py - Simplifies the ExplodedGraph -*- python 
> -*-==#
> #
> # Part of the LLVM Project, under the Apache License v2.0 with LLVM 
> Exceptions.
> # See https://llvm.org/LICENSE.txt for license information.
> # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
> #
> #======#
> ```
> Whoops!
rC362575.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62638



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

r362575 - [analyzer] exploded-graph-rewriter: Add the missing license header!

[Artem Dergachev via cfe-commits]

Author: dergachev
Date: Tue Jun  4 19:09:49 2019
New Revision: 362575

URL: http://llvm.org/viewvc/llvm-project?rev=362575=rev
Log:
[analyzer] exploded-graph-rewriter: Add the missing license header!

Modified:
cfe/trunk/utils/analyzer/exploded-graph-rewriter.py

Modified: cfe/trunk/utils/analyzer/exploded-graph-rewriter.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/analyzer/exploded-graph-rewriter.py?rev=362575=362574=362575=diff
==
--- cfe/trunk/utils/analyzer/exploded-graph-rewriter.py (original)
+++ cfe/trunk/utils/analyzer/exploded-graph-rewriter.py Tue Jun  4 19:09:49 2019
@@ -1,4 +1,13 @@
 #!/usr/bin/env python
+#
+#===- exploded-graph-rewriter.py - ExplodedGraph dump tool -*- python -*--#
+#
+# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+# See https://llvm.org/LICENSE.txt for license information.
+# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+#
+#===---===#
+
 
 from __future__ import print_function
 


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

r362574 - [analyzer] exploded-graph-rewriter: Pick up python from cmake in tests.

[Artem Dergachev via cfe-commits]

Author: dergachev
Date: Tue Jun  4 19:09:29 2019
New Revision: 362574

URL: http://llvm.org/viewvc/llvm-project?rev=362574=rev
Log:
[analyzer] exploded-graph-rewriter: Pick up python from cmake in tests.

This should fix NetBSD buildbots.

Modified:
cfe/trunk/test/Analysis/exploded-graph-rewriter/lit.local.cfg

Modified: cfe/trunk/test/Analysis/exploded-graph-rewriter/lit.local.cfg
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/exploded-graph-rewriter/lit.local.cfg?rev=362574=362573=362574=diff
==
--- cfe/trunk/test/Analysis/exploded-graph-rewriter/lit.local.cfg (original)
+++ cfe/trunk/test/Analysis/exploded-graph-rewriter/lit.local.cfg Tue Jun  4 
19:09:29 2019
@@ -1,3 +1,5 @@
+# -*- Python -*-
+
 import lit.util
 import lit.formats
 import os
@@ -6,8 +8,11 @@ use_lit_shell = os.environ.get("LIT_USE_
 config.test_format = lit.formats.ShTest(use_lit_shell == "0")
 
 config.substitutions.append(('%exploded_graph_rewriter',
- lit.util.which('exploded-graph-rewriter.py',
-os.path.join(config.clang_src_dir,
- 'utils', 
'analyzer'
+ '\'%s\' %s' % (
+ config.python_executable,
+ lit.util.which('exploded-graph-rewriter.py',
+os.path.join(
+config.clang_src_dir,
+'utils', 'analyzer')
 
 config.suffixes = ['.dot']


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

r362571 - Initial support for vectorization using MASSV (IBM MASS vector library)

[Nemanja Ivanovic via cfe-commits]

Author: nemanjai
Date: Tue Jun  4 18:57:57 2019
New Revision: 362571

URL: http://llvm.org/viewvc/llvm-project?rev=362571=rev
Log:
Initial support for vectorization using MASSV (IBM MASS vector library)

Part 2 (the Clang portion) of D59881.

This patch (first of two patches) enables the vectorizer to recognize the
IBM MASS vector library routines. This patch specifically adds support for
recognizing the -vector-library=MASSV option, and defines mappings from IEEE
standard scalar math functions to generic PowerPC MASS vector counterparts.
For instance, the generic PowerPC MASS vector entry for double-precision
cbrt function is __cbrtd2_massv.

The second patch will further lower the generic PowerPC vector entries to
PowerPC subtarget-specific entries.
For instance, the PowerPC generic entry cbrtd2_massv is lowered to
cbrtd2_P9 for Power9 subtarget.

The overall support for MASS vector library is presented as such in two patches
for ease of review.

Patch by Jeeva Paudel.

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

Modified:
cfe/trunk/include/clang/Basic/CodeGenOptions.h
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/autocomplete.c
cfe/trunk/test/Driver/fveclib.c

Modified: cfe/trunk/include/clang/Basic/CodeGenOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/CodeGenOptions.h?rev=362571=362570=362571=diff
==
--- cfe/trunk/include/clang/Basic/CodeGenOptions.h (original)
+++ cfe/trunk/include/clang/Basic/CodeGenOptions.h Tue Jun  4 18:57:57 2019
@@ -53,6 +53,7 @@ public:
   enum VectorLibrary {
 NoLibrary,  // Don't use any vector library.
 Accelerate, // Use the Accelerate framework.
+MASSV,  // IBM MASS vector library.
 SVML// Intel short vector math library.
   };
 

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=362571=362570=362571=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Tue Jun  4 18:57:57 2019
@@ -1418,7 +1418,7 @@ def fno_experimental_new_pass_manager :
   Group, Flags<[CC1Option]>,
   HelpText<"Disables an experimental new pass manager in LLVM.">;
 def fveclib : Joined<["-"], "fveclib=">, Group, Flags<[CC1Option]>,
-HelpText<"Use the given vector functions library">, 
Values<"Accelerate,SVML,none">;
+HelpText<"Use the given vector functions library">, 
Values<"Accelerate,MASSV,SVML,none">;
 def fno_lax_vector_conversions : Flag<["-"], "fno-lax-vector-conversions">, 
Group,
   HelpText<"Disallow implicit conversions between vectors with a different 
number of elements or different element types">, Flags<[CC1Option]>;
 def fno_merge_all_constants : Flag<["-"], "fno-merge-all-constants">, 
Group,

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=362571=362570=362571=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Tue Jun  4 18:57:57 2019
@@ -340,6 +340,9 @@ static TargetLibraryInfoImpl *createTLII
   case CodeGenOptions::Accelerate:
 
TLII->addVectorizableFunctionsFromVecLib(TargetLibraryInfoImpl::Accelerate);
 break;
+  case CodeGenOptions::MASSV:
+TLII->addVectorizableFunctionsFromVecLib(TargetLibraryInfoImpl::MASSV);
+break;
   case CodeGenOptions::SVML:
 TLII->addVectorizableFunctionsFromVecLib(TargetLibraryInfoImpl::SVML);
 break;

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=362571=362570=362571=diff
==
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Tue Jun  4 18:57:57 2019
@@ -682,6 +682,8 @@ static bool ParseCodeGenArgs(CodeGenOpti
 StringRef Name = A->getValue();
 if (Name == "Accelerate")
   Opts.setVecLib(CodeGenOptions::Accelerate);
+else if (Name == "MASSV")
+  Opts.setVecLib(CodeGenOptions::MASSV);
 else if (Name == "SVML")
   Opts.setVecLib(CodeGenOptions::SVML);
 else if (Name == "none")

Modified: cfe/trunk/test/Driver/autocomplete.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/autocomplete.c?rev=362571=362570=362571=diff
==
--- cfe/trunk/test/Driver/autocomplete.c (original)
+++ cfe/trunk/test/Driver/autocomplete.c Tue Jun  4 18:57:57 2019
@@ -68,6 +68,7 @@
 // 

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

[Don Hinton via Phabricator via cfe-commits]

hintonda added a comment.

In D62873#1530197 , @Szelethus wrote:

> I seem to have missed out on previous commits that moved analyzer plugins 
> around -- would you mind adding `[analyzer]` to the revision names that 
> affect the Static Analyzer? Many of us are automatically subscribed to such 
> patches.
>
> In any case, LGTM!


Sorry about that.  I was mainly trying to fix broken llvm plugins that were no 
longer available with the previous changes to LLVM_ENABLE_PLUGIN.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62873



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

[PATCH] D62885: [analyzer] Add werror flag for analyzer warnings

[Keno Fischer via Phabricator via cfe-commits]

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

> So, you'd like to make this a frontend flag in order not to expose it to 
> "regular" end users? Or was it because, well, every other flag we have is a 
> frontend flag?

Little bit of both? We already need to pass a bunch of `Xanalyzer` and `Xclang` 
features in order to set things up correctly and it seemed like a more 
prominent flag would cause more debate and delay in getting this in ;).

> For a project whose entire foundation is based on an estimation (I mean to 
> refer to false positives), I fear that this flag would be impractical for 
> most users. I certainly wouldn't like to receive an error on a false 
> positive, but I can see that for your specific use, while on specific 
> checkers are enabled, this would be fine. But again, do we really do this 
> flag justice by "simply" making it a frontend flag?

Yeah, we're a bit of a special case here in that we consider false positives 
for our analysis a bug (in the analysis), so Werror makes more sense for us 
(since the analysis is also in the repo being CI'd).

> At the end of the day, the idea sounds great, and I'm not opposed to landing 
> this before resolve this paradox.






Comment at: test/Analysis/override-werror.c:10
+  return p; // expected-warning{{incompatible pointer types}} \
+   werror-warning{{incompatible pointer types}}
 }

Szelethus wrote:
> Why isn't this `werror-error`?
Unlike the other error (which is generated by the analyzer), this is a semantic 
error (i.e. would get emitted even in the absence of the analyzer). The 
`-analyzer-werror` flag only touches those warnings generated by the analyzer, 
so this is the desired behavior.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62885



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

[PATCH] D62557: [analyzer] Modernize CStringChecker to use CallDescriptions.

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

Szelethus accepted this revision.
Szelethus added a comment.

That's beautiful *-*


Repository:
  rC Clang

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

https://reviews.llvm.org/D62557



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

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

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

Szelethus added a comment.

I like the idea, but will need more time to get familiar with `CallEvent` to 
formally accept.

> When matching C standard library functions in the checker, it's easy to 
> forget that they are often implemented as macros that are expanded to 
> compiler builtins. Such builtins would have a different name, so matching the 
> callee identifier would fail, or may sometimes have more arguments than 
> expected (so matching the exact number of arguments would fail, but this is 
> fine as long as we have all the arguments that we need in their respective 
> places.

Just a name an issue that came up recently, in the case of D59812 
, we probably shouldn't need to strip 
`"__builtin_"` off.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62556



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

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

[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.

This is why I love unit tests so much, you get the learn a lot about how things 
work! Thanks!

The idea for the patch is great, can't wait to get rid of the mess we have in 
`MallocChecker`.


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

https://reviews.llvm.org/D62441



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

[PATCH] D62885: [analyzer] Add werror flag for analyzer warnings

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

Szelethus added a comment.

Interesting. Let's also have a link to your cfe-dev letter: 
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062495.html

So, you'd like to make this a frontend flag in order not to expose it to 
"regular" end users? Or was it because, well, every other flag we have is a 
frontend flag?

We've recently had a lot of discussion about what features should the user 
access -- now, we currently discourage anyone from using the analyzer from the 
command line (as seen by the fact that every configuration flag we have only 
exposed through the frontend), which at the same time forces anyone who'd like 
to custom-configure it to be exposed to every frontend flag we have.

This is, in my opinion, somewhat counter intuitive: we use the frontend to hide 
developer-only flags, yet the expectation that nobody will visit them is 
unreasonable if we don't provide a subset of end-user facing flags through the 
driver. This has resulted (or so I've been told) in numerous bugreports from 
users using experimental features that were known to be not stable.

For a project whose entire foundation is based on an estimation (I mean to 
refer to false positives), I fear that this flag would be impractical for most 
users. I certainly wouldn't like to receive an error on a false positive, but I 
can see that for your specific use, while on specific checkers are enabled, 
this would be fine. But again, do we really do this flag justice by "simply" 
making it a frontend flag?

At the end of the day, the idea sounds great, and I'm not opposed to landing 
this before resolve this paradox.




Comment at: test/Analysis/override-werror.c:10
+  return p; // expected-warning{{incompatible pointer types}} \
+   werror-warning{{incompatible pointer types}}
 }

Why isn't this `werror-error`?


Repository:
  rC Clang

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

https://reviews.llvm.org/D62885



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

[PATCH] D61467: [Rewrite] Extend to further accept CharSourceRange

[Joel E. Denny via Phabricator via cfe-commits]

jdenny added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61467



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

[PATCH] D62049: [clang-tidy] Add a close-on-exec check on pipe2() in Android module.

[Jian Cai via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/test/clang-tidy/android-cloexec-pipe2.cpp:17
+
+void warning1() {
+  int pipefd[2];

gribozavr wrote:
> `warning1`, `warning2` is better than `a` and `b`, but we can do even better.
> 
> `warningForPipeCall`
> `warningForPipeCallInMacroArgument`
> 
> Similarly in the rest of the patch.
Sounds good. I have updated the function names, although I feel the 
"ForPipeCall" part is already implied in the test so I did not include it to 
keep the names shorter. Let me know if you think it is better to have it 
included.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62049



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

[PATCH] D62049: [clang-tidy] Add a close-on-exec check on pipe2() in Android module.

[Jian Cai via Phabricator via cfe-commits]

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

Update test function names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62049

Files:
  clang-tools-extra/clang-tidy/android/AndroidTidyModule.cpp
  clang-tools-extra/clang-tidy/android/CMakeLists.txt
  clang-tools-extra/clang-tidy/android/CloexecPipe2Check.cpp
  clang-tools-extra/clang-tidy/android/CloexecPipe2Check.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/android-cloexec-pipe2.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/android-cloexec-pipe2.cpp

Index: clang-tools-extra/test/clang-tidy/android-cloexec-pipe2.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/android-cloexec-pipe2.cpp
@@ -0,0 +1,68 @@
+// RUN: %check_clang_tidy %s android-cloexec-pipe2 %t
+
+#define O_NONBLOCK 1
+#define __O_CLOEXEC 3
+#define O_CLOEXEC __O_CLOEXEC
+#define TEMP_FAILURE_RETRY(exp) \
+  ({\
+int _rc;\
+do {\
+  _rc = (exp);  \
+} while (_rc == -1);\
+  })
+#define NULL 0
+
+extern "C" int pipe2(int pipefd[2], int flags);
+
+void warning() {
+  int pipefd[2];
+  pipe2(pipefd, O_NONBLOCK);
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: 'pipe2'
+  // CHECK-FIXES: pipe2(pipefd, O_NONBLOCK | O_CLOEXEC);
+  TEMP_FAILURE_RETRY(pipe2(pipefd, O_NONBLOCK));
+  // CHECK-MESSAGES: :[[@LINE-1]]:46: warning: 'pipe2'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(pipe2(pipefd, O_NONBLOCK | O_CLOEXEC));
+}
+
+void warningInMacroArugment() {
+  int pipefd[2];
+  pipe2(pipefd, 3);
+  // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: 'pipe2'
+  // CHECK-FIXES: pipe2(pipefd, 3 | O_CLOEXEC);
+  TEMP_FAILURE_RETRY(pipe2(pipefd, 3));
+  // CHECK-MESSAGES: :[[@LINE-1]]:37: warning: 'pipe2'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(pipe2(pipefd, 3 | O_CLOEXEC));
+
+  int flag = O_NONBLOCK;
+  pipe2(pipefd, flag);
+  TEMP_FAILURE_RETRY(pipe2(pipefd, flag));
+}
+
+namespace i {
+int pipe2(int pipefd[2], int flags);
+
+void noWarning() {
+  int pipefd[2];
+  pipe2(pipefd, O_NONBLOCK);
+  TEMP_FAILURE_RETRY(pipe2(pipefd, O_NONBLOCK));
+}
+
+} // namespace i
+
+void noWarning() {
+  int pipefd[2];
+  pipe2(pipefd, O_CLOEXEC);
+  TEMP_FAILURE_RETRY(pipe2(pipefd, O_CLOEXEC));
+  pipe2(pipefd, O_NONBLOCK | O_CLOEXEC);
+  TEMP_FAILURE_RETRY(pipe2(pipefd, O_NONBLOCK | O_CLOEXEC));
+}
+
+class G {
+public:
+  int pipe2(int pipefd[2], int flags);
+  void noWarning() {
+int pipefd[2];
+pipe2(pipefd, O_NONBLOCK);
+TEMP_FAILURE_RETRY(pipe2(pipefd, O_NONBLOCK));
+  }
+};
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -32,6 +32,7 @@
android-cloexec-inotify-init1
android-cloexec-memfd-create
android-cloexec-open
+   android-cloexec-pipe2
android-cloexec-socket
android-comparison-in-temp-failure-retry
boost-use-to-string
Index: clang-tools-extra/docs/clang-tidy/checks/android-cloexec-pipe2.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/android-cloexec-pipe2.rst
@@ -0,0 +1,21 @@
+.. title:: clang-tidy - android-cloexec-pipe2
+
+android-cloexec-pipe2
+=
+
+This checks ensures that pipe2() is called with the O_CLOEXEC flag. The check also
+adds the O_CLOEXEC flag that marks the file descriptor to be closed in child processes.
+Without this flag a sensitive file descriptor can be leaked to a child process,
+potentially into a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  pipe2(pipefd, O_NONBLOCK);
+
+Suggested replacement:
+
+.. code-block:: c++
+
+  pipe2(pipefd, O_NONBLOCK | O_CLOEXEC);
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -101,6 +101,11 @@
   Finds and fixes ``absl::Time`` subtraction expressions to do subtraction
   in the Time domain instead of the numeric domain.
 
+- New :doc:`android-cloexec-pipe
+  ` check.
+
+  This checks ensures that ``pipe2()`` is called with the O_CLOEXEC flag.
+
 - New :doc:`bugprone-unhandled-self-assignment
   ` check.
 
Index: clang-tools-extra/clang-tidy/android/CloexecPipe2Check.h
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/android/CloexecPipe2Check.h
@@ -0,0 +1,34 @@
+//===--- CloexecPipe2Check.h - clang-tidy*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// 

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

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

Szelethus accepted this revision.
Szelethus added a comment.

I seem to have missed out on previous commits that moved analyzer plugins 
around -- would you mind adding `[analyzer]` to the revision names that affect 
the Static Analyzer? Many of us are automatically subscribed to such patches.

In any case, LGTM!




Comment at: lib/Analysis/plugins/CMakeLists.txt:1
-if(LLVM_ENABLE_PLUGINS)
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
   add_subdirectory(SampleAnalyzer)

hintonda wrote:
> Szelethus wrote:
> > Is this file a thing? `lib/Analysis/plugins/CMakeLists.txt`? I can't seem 
> > to find it anywhere.
> commit a33eaad00cca99ca0b5d2b0cc6dec33be6d7ee7f (origin/master, origin/HEAD, 
> master)
> Author: Don Hinton 
> Date:   Tue Jun 4 22:07:40 2019 +
> 
> [Analysis] Only build Analysis plugins when CLANG_ENABLE_STATIC_ANALYZER 
> is enabled.
> 
> Fixes bug introduced in r362328.
> 
> Thanks to Nathan Chancellor for reporting this!
> 
> llvm-svn: 362555
> 
> $ git diff  06c801e153347d24ec7ce93f6ffbbc58b64a89ba 
> a33eaad00cca99ca0b5d2b0cc6dec33be6d7ee7f
> diff --git a/clang/lib/Analysis/plugins/CMakeLists.txt 
> b/clang/lib/Analysis/plugins/CMakeLists.txt
> index f7dbc936952..bd7314a871f 100644
> --- a/clang/lib/Analysis/plugins/CMakeLists.txt
> +++ b/clang/lib/Analysis/plugins/CMakeLists.txt
> @@ -1,4 +1,4 @@
> -if(LLVM_ENABLE_PLUGINS)
> +if(CLANG_ENABLE_STATIC_ANALYZER AND LLVM_ENABLE_PLUGINS)
>add_subdirectory(SampleAnalyzer)
>add_subdirectory(CheckerDependencyHandling)
>add_subdirectory(CheckerOptionHandling)
Oops, my apologies, was on the wrong branch.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62873



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

r362563 - Factor out duplicated code building a MemberExpr and marking it

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Jun  4 17:21:47 2019
New Revision: 362563

URL: http://llvm.org/viewvc/llvm-project?rev=362563=rev
Log:
Factor out duplicated code building a MemberExpr and marking it
referenced.

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaExprMember.cpp
cfe/trunk/lib/Sema/SemaOverload.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=362563=362562=362563=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Jun  4 17:21:47 2019
@@ -4510,6 +4510,23 @@ public:
UnqualifiedId ,
Decl *ObjCImpDecl);
 
+  MemberExpr *
+  BuildMemberExpr(Expr *Base, bool IsArrow, SourceLocation OpLoc,
+  const CXXScopeSpec *SS, SourceLocation TemplateKWLoc,
+  ValueDecl *Member, DeclAccessPair FoundDecl,
+  bool HadMultipleCandidates,
+  const DeclarationNameInfo , QualType Ty,
+  ExprValueKind VK, ExprObjectKind OK,
+  const TemplateArgumentListInfo *TemplateArgs = nullptr);
+  MemberExpr *
+  BuildMemberExpr(Expr *Base, bool IsArrow, SourceLocation OpLoc,
+  NestedNameSpecifierLoc NNS, SourceLocation TemplateKWLoc,
+  ValueDecl *Member, DeclAccessPair FoundDecl,
+  bool HadMultipleCandidates,
+  const DeclarationNameInfo , QualType Ty,
+  ExprValueKind VK, ExprObjectKind OK,
+  const TemplateArgumentListInfo *TemplateArgs = nullptr);
+
   void ActOnDefaultCtorInitializers(Decl *CDtorDecl);
   bool ConvertArgumentsForCall(CallExpr *Call, Expr *Fn,
FunctionDecl *FDecl,

Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprCXX.cpp?rev=362563=362562=362563=diff
==
--- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Tue Jun  4 17:21:47 2019
@@ -7189,15 +7189,12 @@ ExprResult Sema::BuildCXXMemberCallExpr(
 }
   }
 
-  MemberExpr *ME = MemberExpr::Create(
-  Context, Exp.get(), /*IsArrow=*/false, SourceLocation(),
-  NestedNameSpecifierLoc(), SourceLocation(), Method,
-  DeclAccessPair::make(FoundDecl, FoundDecl->getAccess()),
-  DeclarationNameInfo(), /*TemplateArgs=*/nullptr, Context.BoundMemberTy,
-  VK_RValue, OK_Ordinary);
-  if (HadMultipleCandidates)
-ME->setHadMultipleCandidates(true);
-  MarkMemberReferenced(ME);
+  MemberExpr *ME =
+  BuildMemberExpr(Exp.get(), /*IsArrow=*/false, SourceLocation(),
+  NestedNameSpecifierLoc(), SourceLocation(), Method,
+  DeclAccessPair::make(FoundDecl, FoundDecl->getAccess()),
+  HadMultipleCandidates, DeclarationNameInfo(),
+  Context.BoundMemberTy, VK_RValue, OK_Ordinary);
 
   QualType ResultType = Method->getReturnType();
   ExprValueKind VK = Expr::getValueKindForType(ResultType);

Modified: cfe/trunk/lib/Sema/SemaExprMember.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprMember.cpp?rev=362563=362562=362563=diff
==
--- cfe/trunk/lib/Sema/SemaExprMember.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprMember.cpp Tue Jun  4 17:21:47 2019
@@ -893,18 +893,31 @@ BuildMSPropertyRefExpr(Sema , Expr *Ba
NameInfo.getLoc());
 }
 
-/// Build a MemberExpr AST node.
-static MemberExpr *BuildMemberExpr(
-Sema , ASTContext , Expr *Base, bool isArrow,
-SourceLocation OpLoc, const CXXScopeSpec , SourceLocation TemplateKWLoc,
-ValueDecl *Member, DeclAccessPair FoundDecl,
-const DeclarationNameInfo , QualType Ty, ExprValueKind VK,
-ExprObjectKind OK, const TemplateArgumentListInfo *TemplateArgs = nullptr) 
{
-  assert((!isArrow || Base->isRValue()) && "-> base must be a pointer rvalue");
-  MemberExpr *E = MemberExpr::Create(
-  C, Base, isArrow, OpLoc, SS.getWithLocInContext(C), TemplateKWLoc, 
Member,
-  FoundDecl, MemberNameInfo, TemplateArgs, Ty, VK, OK);
-  SemaRef.MarkMemberReferenced(E);
+MemberExpr *Sema::BuildMemberExpr(
+Expr *Base, bool IsArrow, SourceLocation OpLoc, const CXXScopeSpec *SS,
+SourceLocation TemplateKWLoc, ValueDecl *Member, DeclAccessPair FoundDecl,
+bool HadMultipleCandidates, const DeclarationNameInfo ,
+QualType Ty, ExprValueKind VK, ExprObjectKind OK,
+const TemplateArgumentListInfo *TemplateArgs) {
+  NestedNameSpecifierLoc NNS =
+  SS ? SS->getWithLocInContext(Context) : NestedNameSpecifierLoc();
+  return 

[PATCH] D62883: [analyzer] Track conditions of terminator statements on which the reported node depends on

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

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

For the test files where plist files have changed: (note to self: there has 
**got to be** a better way to show this off)

F9062068: track_cond_undef_value_param_before.html 

F9062011: track_cond_undef_value_param_after.html 


F9062176: track_cond_unix_fns_before.html 
F9062279: track_cond_unix_fns_after.html 

F9062777: track_cond_retain_release_m_objc_1_before.html 

F9062772: track_cond_retain_release_m_objc_1_after.html 


(same for the .*objcpp file)
F9062784: track_cond_retain_release_m_objc_2_before.html 

F9062797: track_cond_retain_release_m_objc_2_after.html 


F9062927: track_cond_edges_new_before.html 
F9062929: track_cond_edges_new_after.html 

F9063089: track_cond_cxx_for_range_before.html 

F9063092: track_cond_cxx_for_range_after.html 





Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1863-1864
+
+case Stmt::ObjCForCollectionStmtClass:
+  return cast(S)->getCollection();
+

@NoQ Any feelings on this?


Repository:
  rC Clang

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

https://reviews.llvm.org/D62883



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

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

[Don Hinton via Phabricator via cfe-commits]

hintonda added inline comments.



Comment at: lib/Analysis/plugins/CMakeLists.txt:1
-if(LLVM_ENABLE_PLUGINS)
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
   add_subdirectory(SampleAnalyzer)

Szelethus wrote:
> Is this file a thing? `lib/Analysis/plugins/CMakeLists.txt`? I can't seem to 
> find it anywhere.
commit a33eaad00cca99ca0b5d2b0cc6dec33be6d7ee7f (origin/master, origin/HEAD, 
master)
Author: Don Hinton 
Date:   Tue Jun 4 22:07:40 2019 +

[Analysis] Only build Analysis plugins when CLANG_ENABLE_STATIC_ANALYZER is 
enabled.

Fixes bug introduced in r362328.

Thanks to Nathan Chancellor for reporting this!

llvm-svn: 362555

$ git diff  06c801e153347d24ec7ce93f6ffbbc58b64a89ba 
a33eaad00cca99ca0b5d2b0cc6dec33be6d7ee7f
diff --git a/clang/lib/Analysis/plugins/CMakeLists.txt 
b/clang/lib/Analysis/plugins/CMakeLists.txt
index f7dbc936952..bd7314a871f 100644
--- a/clang/lib/Analysis/plugins/CMakeLists.txt
+++ b/clang/lib/Analysis/plugins/CMakeLists.txt
@@ -1,4 +1,4 @@
-if(LLVM_ENABLE_PLUGINS)
+if(CLANG_ENABLE_STATIC_ANALYZER AND LLVM_ENABLE_PLUGINS)
   add_subdirectory(SampleAnalyzer)
   add_subdirectory(CheckerDependencyHandling)
   add_subdirectory(CheckerOptionHandling)


Repository:
  rC Clang

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

https://reviews.llvm.org/D62873



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

r362562 - PR42111: Use guarded initialization for thread-local variables with

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Jun  4 17:04:33 2019
New Revision: 362562

URL: http://llvm.org/viewvc/llvm-project?rev=362562=rev
Log:
PR42111: Use guarded initialization for thread-local variables with
unordered initialization and internal linkage.

We'll run their initializers once on each reference, so we need a guard
variable even though they only have a single definition.

Modified:
cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
cfe/trunk/test/CodeGenCXX/cxx1y-variable-template.cpp

Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=362562=362561=362562=diff
==
--- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Tue Jun  4 17:04:33 2019
@@ -630,7 +630,13 @@ void CodeGenFunction::GenerateCXXGlobalV
   // Use guarded initialization if the global variable is weak. This
   // occurs for, e.g., instantiated static data members and
   // definitions explicitly marked weak.
-  if (Addr->hasWeakLinkage() || Addr->hasLinkOnceLinkage()) {
+  //
+  // Also use guarded initialization for a variable with dynamic TLS and
+  // unordered initialization. (If the initialization is ordered, the ABI
+  // layer will guard the whole-TU initialization for us.)
+  if (Addr->hasWeakLinkage() || Addr->hasLinkOnceLinkage() ||
+  (D->getTLSKind() == VarDecl::TLS_Dynamic &&
+   isTemplateInstantiation(D->getTemplateSpecializationKind( {
 EmitCXXGuardedInit(*D, Addr, PerformInit);
   } else {
 EmitCXXGlobalVarDeclInit(*D, Addr, PerformInit);

Modified: cfe/trunk/test/CodeGenCXX/cxx1y-variable-template.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/cxx1y-variable-template.cpp?rev=362562=362561=362562=diff
==
--- cfe/trunk/test/CodeGenCXX/cxx1y-variable-template.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/cxx1y-variable-template.cpp Tue Jun  4 17:04:33 
2019
@@ -27,4 +27,21 @@ int *p = <0>;
 // CHECK: @_ZN5OuterIA100_cE5InnerIA20_cE3arrIA3_cEE = linkonce_odr global 
[123 x i32] zeroinitializer
 // CHECK: @_ZGVN5OuterIA100_cE5InnerIA20_cE3arrIA3_cEE = linkonce_odr global
 
+// CHECK: @_ZTHN7PR422_GLOBAL__N_11nILi0EEE = internal alias {{.*}} 
@[[PR42111_CTOR:.*]]
+
 // CHECK: call {{.*}}@_Z8init_arrv
+
+// Ensure that we use guarded initialization for an instantiated thread_local
+// variable with internal linkage.
+namespace PR42111 {
+  int f();
+  namespace { template  thread_local int n = f(); }
+  // CHECK: define {{.*}}@[[PR42111_CTOR]](
+  // CHECK: load {{.*}} @_ZGVN7PR422_GLOBAL__N_11nILi0EEE
+  // CHECK: icmp eq i8 {{.*}}, 0
+  // CHECK: br i1
+  // CHECK: call i32 @_ZN7PR42fEv(
+  // CHECK: store i32 {{.*}}, i32* @_ZN7PR422_GLOBAL__N_11nILi0EEE
+  // CHECK: store i8 1, i8* @_ZGVN7PR422_GLOBAL__N_11nILi0EEE
+  int g() { return n<> + n<>; }
+}


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

[PATCH] D62885: [analyzer] Add werror flag for analyzer warnings

[Keno Fischer via Phabricator via cfe-commits]

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

We're using the clang static analyzer together with a number of
custom analyses in our CI system to ensure that certain invariants
are statiesfied for by the code every commit. Unfortunately, there
currently doesn't seem to be a good way to determine whether any
analyzer warnings were emitted, other than parsing clang's output
(or using scan-build, which then in turn parses clang's output).
As a simpler mechanism, simply add a `-analyzer-werror` flag to CC1
that causes the analyzer to emit its warnings as errors instead.
I briefly tried to have this be `Werror=analyzer` and make it go
through that machinery instead, but that seemed more trouble than
it was worth in terms of conflicting with options to the actual build
and special cases that would be required to circumvent the analyzers
usual attempts to quiet non-analyzer warnings. This is simple and it
works well.


Repository:
  rC Clang

https://reviews.llvm.org/D62885

Files:
  include/clang/Driver/CC1Options.td
  include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  lib/Frontend/CompilerInvocation.cpp
  lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
  test/Analysis/override-werror.c

Index: test/Analysis/override-werror.c
===
--- test/Analysis/override-werror.c
+++ test/Analysis/override-werror.c
@@ -1,14 +1,17 @@
 // RUN: %clang_analyze_cc1 -analyzer-checker=core,alpha.core -Werror %s -analyzer-store=region -verify
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,alpha.core -Werror %s -analyzer-store=region -analyzer-werror -verify=werror
 
 // This test case illustrates that using '-analyze' overrides the effect of
 // -Werror.  This allows basic warnings not to interfere with producing
 // analyzer results.
 
-char* f(int *p) { 
-  return p; // expected-warning{{incompatible pointer types}}
+char* f(int *p) {
+  return p; // expected-warning{{incompatible pointer types}} \
+   werror-warning{{incompatible pointer types}}
 }
 
 void g(int *p) {
-  if (!p) *p = 0; // expected-warning{{null}}  
+  if (!p) *p = 0; // expected-warning{{null}} \
+ werror-error{{null}}
 }
 
Index: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -83,10 +83,11 @@
 namespace {
 class ClangDiagPathDiagConsumer : public PathDiagnosticConsumer {
   DiagnosticsEngine 
-  bool IncludePath;
+  bool IncludePath, Werror;
+
 public:
   ClangDiagPathDiagConsumer(DiagnosticsEngine )
-: Diag(Diag), IncludePath(false) {}
+  : Diag(Diag), IncludePath(false), Werror(false) {}
   ~ClangDiagPathDiagConsumer() override {}
   StringRef getName() const override { return "ClangDiags"; }
 
@@ -101,9 +102,13 @@
 IncludePath = true;
   }
 
+  void enableWerror() { Werror = true; }
+
   void FlushDiagnosticsImpl(std::vector ,
 FilesMade *filesMade) override {
-unsigned WarnID = Diag.getCustomDiagID(DiagnosticsEngine::Warning, "%0");
+unsigned WarnID =
+Werror ? Diag.getCustomDiagID(DiagnosticsEngine::Error, "%0")
+   : Diag.getCustomDiagID(DiagnosticsEngine::Warning, "%0");
 unsigned NoteID = Diag.getCustomDiagID(DiagnosticsEngine::Note, "%0");
 
 for (std::vector::iterator I = Diags.begin(),
@@ -225,6 +230,9 @@
   new ClangDiagPathDiagConsumer(PP.getDiagnostics());
   PathConsumers.push_back(clangDiags);
 
+  if (Opts->AnalyzerWerror)
+clangDiags->enableWerror();
+
   if (Opts->AnalysisDiagOpt == PD_TEXT) {
 clangDiags->enablePaths();
 
@@ -255,7 +263,7 @@
 #define ANALYSIS_CONSTRAINTS(NAME, CMDFLAG, DESC, CREATEFN) \
   case NAME##Model: CreateConstraintMgr = CREATEFN; break;
 #include "clang/StaticAnalyzer/Core/Analyses.def"
-}
+};
   }
 
   void DisplayFunction(const Decl *D, AnalysisMode Mode,
@@ -357,9 +365,8 @@
 if (VD->getAnyInitializer())
   return true;
 
-llvm::Expected CTUDeclOrError =
-  CTU.getCrossTUDefinition(VD, Opts->CTUDir, Opts->CTUIndexName, 
-   Opts->DisplayCTUProgress);
+llvm::Expected CTUDeclOrError = CTU.getCrossTUDefinition(
+VD, Opts->CTUDir, Opts->CTUIndexName, Opts->DisplayCTUProgress);
 
 if (!CTUDeclOrError) {
   handleAllErrors(CTUDeclOrError.takeError(),
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -309,6 +309,7 @@
 Args.hasArg(OPT_analyzer_viz_egraph_graphviz);
   Opts.DumpExplodedGraphTo = 

[PATCH] D59744: Fix i386 ABI "__m64" type bug

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D59744#1529218 , @mgorny wrote:

> In D59744#1529182 , @krytarowski 
> wrote:
>
> > In D59744#1527412 , @wxiao3 wrote:
> >
> > > Consider other Systems (e.g Darwin, PS4 and FreeBSD) don't want to spend 
> > > any effort dealing with the ramifications of ABI breaks (as discussed in 
> > > https://reviews.llvm.org/D60748) at present, I only fix the bug for 
> > > Linux. If other system wants the fix, the only thing needed is to add a 
> > > flag (like "IsLinuxABI" ) to enable it.
> >
> >
> > CC @mgorny and @joerg - do we want this for NetBSD?
>
>
> Probably yes. FWICS, gcc uses `%mm0` and `%mm1` on NetBSD while clang doesn't.


Unless Joerg will protest, @wxiao3 please enable it on NetBSD as well.. but 
personally I would enable it unconditionally for all sysv ABIs.


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

https://reviews.llvm.org/D59744



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

[PATCH] D62780: msabi: Fix exponential mangling time for even more contrived inputs

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL362560: msabi: Fix exponential mangling time for even more 
contrived inputs (authored by nico, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D62780?vs=202561=203044#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D62780

Files:
  cfe/trunk/lib/AST/MicrosoftMangle.cpp
  cfe/trunk/test/CodeGenCXX/mangle-ms-back-references-pr13207.cpp

Index: cfe/trunk/test/CodeGenCXX/mangle-ms-back-references-pr13207.cpp
===
--- cfe/trunk/test/CodeGenCXX/mangle-ms-back-references-pr13207.cpp
+++ cfe/trunk/test/CodeGenCXX/mangle-ms-back-references-pr13207.cpp
@@ -232,3 +232,25 @@
 void f(B6 a) {}
 
 // CHECK: "?f@@YAXU?$Food@U?$Food@U?$Food@U?$Food@U?$Food@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U2@U2@U2@U2@U2@U2@U2@U2@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U3@U3@U3@U3@U3@U3@U3@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U2@U2@U2@U2@U2@U2@U2@U2@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U4@U4@U4@U4@U4@U4@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U2@U2@U2@U2@U2@U2@U2@U2@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U3@U3@U3@U3@U3@U3@U3@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U2@U2@U2@U2@U2@U2@U2@U2@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U5@U5@U5@U5@U5@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@U?$Food@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U2@U2@U2@U2@U2@U2@U2@U2@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U3@U3@U3@U3@U3@U3@U3@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U2@U2@U2@U2@U2@U2@U2@U2@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U4@U4@U4@U4@U4@U4@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U2@U2@U2@U2@U2@U2@U2@U2@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U3@U3@U3@U3@U3@U3@U3@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U2@U2@U2@U2@U2@U2@U2@U2@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@U?$Food@@@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1@@@U?$Food@@@U6@U6@U6@U6@U1@U1@U1@U1@U1@U1@U1@U1@U1@U1Z"
+
+
+// Similar to the previous case, except that the later arguments aren't
+// present in the earlier ones and hence aren't in the backref cache.
+template 
+struct Fooe {};
+
+using C0 = Fooe;
+using C1 = Fooe;
+using C2 = Fooe;
+using C3 = Fooe;
+using C4 = Fooe;
+using C5 = Fooe;
+using C6 = Fooe;
+using C7 = Fooe;
+
+// This too should take milliseconds, not minutes.
+void f(C7 a) {}
+// CHECK: "??@f23afdfb44276eaa53a5575352cf0ebc@"
Index: cfe/trunk/lib/AST/MicrosoftMangle.cpp
===
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp
@@ -31,6 +31,7 @@
 #include "llvm/Support/xxhash.h"
 #include "llvm/Support/MD5.h"
 #include "llvm/Support/MathExtras.h"
+#include "llvm/Support/StringSaver.h"
 
 using namespace clang;
 
@@ -268,6 +269,11 @@
   ArgBackRefMap FunArgBackReferences;
   ArgBackRefMap TemplateArgBackReferences;
 
+  typedef llvm::DenseMap TemplateArgStringMap;
+  TemplateArgStringMap TemplateArgStrings;
+  llvm::StringSaver 

r362560 - msabi: Fix exponential mangling time for even more contrived inputs

[Nico Weber via cfe-commits]

Author: nico
Date: Tue Jun  4 16:27:40 2019
New Revision: 362560

URL: http://llvm.org/viewvc/llvm-project?rev=362560=rev
Log:
msabi: Fix exponential mangling time for even more contrived inputs

This is a follow-up to r362293 which fixed exponential time needed
for mangling certain templates. This fixes the same issue if that
template pattern happens in template arguments > 10: The first
ten template arguments can use back references, and r362293 added
caching for back references. For latter arguments, we have to add
a cache for the mangling itself instead.

Fixes PR42091 even more.

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

Modified:
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/test/CodeGenCXX/mangle-ms-back-references-pr13207.cpp

Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=362560=362559=362560=diff
==
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Tue Jun  4 16:27:40 2019
@@ -31,6 +31,7 @@
 #include "llvm/Support/xxhash.h"
 #include "llvm/Support/MD5.h"
 #include "llvm/Support/MathExtras.h"
+#include "llvm/Support/StringSaver.h"
 
 using namespace clang;
 
@@ -268,6 +269,11 @@ class MicrosoftCXXNameMangler {
   ArgBackRefMap FunArgBackReferences;
   ArgBackRefMap TemplateArgBackReferences;
 
+  typedef llvm::DenseMap TemplateArgStringMap;
+  TemplateArgStringMap TemplateArgStrings;
+  llvm::StringSaver TemplateArgStringStorage;
+  llvm::BumpPtrAllocator TemplateArgStringStorageAlloc;
+
   typedef std::set> PassObjectSizeArgsSet;
   PassObjectSizeArgsSet PassObjectSizeArgs;
 
@@ -282,18 +288,21 @@ public:
 
   MicrosoftCXXNameMangler(MicrosoftMangleContextImpl , raw_ostream _)
   : Context(C), Out(Out_), Structor(nullptr), StructorType(-1),
+TemplateArgStringStorage(TemplateArgStringStorageAlloc),
 PointersAre64Bit(C.getASTContext().getTargetInfo().getPointerWidth(0) 
==
  64) {}
 
   MicrosoftCXXNameMangler(MicrosoftMangleContextImpl , raw_ostream _,
   const CXXConstructorDecl *D, CXXCtorType Type)
   : Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
+TemplateArgStringStorage(TemplateArgStringStorageAlloc),
 PointersAre64Bit(C.getASTContext().getTargetInfo().getPointerWidth(0) 
==
  64) {}
 
   MicrosoftCXXNameMangler(MicrosoftMangleContextImpl , raw_ostream _,
   const CXXDestructorDecl *D, CXXDtorType Type)
   : Context(C), Out(Out_), Structor(getStructor(D)), StructorType(Type),
+TemplateArgStringStorage(TemplateArgStringStorageAlloc),
 PointersAre64Bit(C.getASTContext().getTargetInfo().getPointerWidth(0) 
==
  64) {}
 
@@ -809,24 +818,34 @@ void MicrosoftCXXNameMangler::mangleUnqu
 // TD / TemplateArg pairs.
 ArgBackRefMap::iterator Found = TemplateArgBackReferences.find(ND);
 if (Found == TemplateArgBackReferences.end()) {
-  // Mangle full template name into temporary buffer.
-  llvm::SmallString<64> TemplateMangling;
-  llvm::raw_svector_ostream Stream(TemplateMangling);
-  MicrosoftCXXNameMangler Extra(Context, Stream);
-  Extra.mangleTemplateInstantiationName(TD, *TemplateArgs);
-
-  // Use the string backref vector to possibly get a back reference.
-  mangleSourceName(TemplateMangling);
-
-  // Memoize back reference for this type.
-  BackRefVec::iterator StringFound =
-  llvm::find(NameBackReferences, TemplateMangling);
-  if (StringFound != NameBackReferences.end()) {
-TemplateArgBackReferences[ND] =
-StringFound - NameBackReferences.begin();
+
+  TemplateArgStringMap::iterator Found = TemplateArgStrings.find(ND);
+  if (Found == TemplateArgStrings.end()) {
+// Mangle full template name into temporary buffer.
+llvm::SmallString<64> TemplateMangling;
+llvm::raw_svector_ostream Stream(TemplateMangling);
+MicrosoftCXXNameMangler Extra(Context, Stream);
+Extra.mangleTemplateInstantiationName(TD, *TemplateArgs);
+
+// Use the string backref vector to possibly get a back reference.
+mangleSourceName(TemplateMangling);
+
+// Memoize back reference for this type if one exist, else memoize
+// the mangling itself.
+BackRefVec::iterator StringFound =
+llvm::find(NameBackReferences, TemplateMangling);
+if (StringFound != NameBackReferences.end()) {
+  TemplateArgBackReferences[ND] =
+  StringFound - NameBackReferences.begin();
+} else {
+  TemplateArgStrings[ND] =
+  TemplateArgStringStorage.save(TemplateMangling.str());
+}
+  } else {
+Out << Found->second; // Outputs a StringRef.
   }
 } else {
-  Out << 

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

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

Szelethus added inline comments.



Comment at: lib/Analysis/plugins/CMakeLists.txt:1
-if(LLVM_ENABLE_PLUGINS)
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
   add_subdirectory(SampleAnalyzer)

Is this file a thing? `lib/Analysis/plugins/CMakeLists.txt`? I can't seem to 
find it anywhere.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62873



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

[PATCH] D62780: msabi: Fix exponential mangling time for even more contrived inputs

[Reid Kleckner via Phabricator via cfe-commits]

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

lgtm




Comment at: clang/lib/AST/MicrosoftMangle.cpp:819-823
 ArgBackRefMap::iterator Found = TemplateArgBackReferences.find(ND);
 if (Found == TemplateArgBackReferences.end()) {
-  // Mangle full template name into temporary buffer.
-  llvm::SmallString<64> TemplateMangling;
-  llvm::raw_svector_ostream Stream(TemplateMangling);
-  MicrosoftCXXNameMangler Extra(Context, Stream);
-  Extra.mangleTemplateInstantiationName(TD, *TemplateArgs);
-
-  // Use the string backref vector to possibly get a back reference.
-  mangleSourceName(TemplateMangling);
-
-  // Memoize back reference for this type.
-  BackRefVec::iterator StringFound =
-  llvm::find(NameBackReferences, TemplateMangling);
-  if (StringFound != NameBackReferences.end()) {
-TemplateArgBackReferences[ND] =
-StringFound - NameBackReferences.begin();
+
+  TemplateArgStringMap::iterator Found = TemplateArgStrings.find(ND);
+  if (Found == TemplateArgStrings.end()) {

thakis wrote:
> rnk wrote:
> > Here's a thought: could we get by with one map? I think we can be certain 
> > that nothing mangles to integer literals between 0 and 9, since otherwise 
> > the demangler couldn't distinguish those from back references. So, can we 
> > keep the string map, and insert the string "0", "1", etc for back 
> > referenced things?
> I had wondered too. In the end, I figured the int map needs less memory and 
> is almost always enough, so I went with this approach.
I think I'm coming at this more from the perspective of less code complexity, 
fewer ifs, fewer data structures to name and have to understand. We could get 
the memory wins by storing numbers in the map, and then having a side vector of 
numbered strings, indexed by `BackrefId-10`. Then that data structure would be 
seldom used. Anyway, it's all code golf, not really important.


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

https://reviews.llvm.org/D62780



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

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

[Don Hinton via Phabricator via cfe-commits]

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

LGTM...




Comment at: test/CMakeLists.txt:122
 
-if (CLANG_ENABLE_STATIC_ANALYZER)
-  if (LLVM_ENABLE_PLUGINS)
-list(APPEND CLANG_TEST_DEPS
-  SampleAnalyzerPlugin
-  CheckerDependencyHandlingAnalyzerPlugin
-  CheckerOptionHandlingAnalyzerPlugin
-  )
-  endif()
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
+  list(APPEND CLANG_TEST_DEPS

I didn't fix this one, but makes sense. 


Repository:
  rC Clang

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

https://reviews.llvm.org/D62873



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

[PATCH] D62883: [analyzer] Track conditions of terminator statements on which the reported node depends on

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

Szelethus created this revision.
Szelethus added reviewers: NoQ, dcoughlin, a.sidorin, baloghadamsoftware, 
xazax.hun, Charusso, rnkovacs.
Szelethus added a project: clang.
Herald added subscribers: cfe-commits, gamesh411, dkrupp, donat.nagy, 
mikhail.ramalho, szepet, whisperity.
Szelethus added a parent revision: D62619: [analyzer][Dominators] Add a control 
dependency tree builder + a new debug checker.

This patch implements the idea discussed on the mailing list 
, in fact, the 
included testfile contains the functions `example_1` and `example_2` exactly 
how it's described there.

The idea is to, as the title says, to track the value of the condition of the 
terminator statement on which the reported node depends on:

  01 int flag;
  02 bool coin();
  03 
  04 void foo() {
  05   flag = coin(); // no note
  06 }
  07 
  08 int main() {
  09   int *x = 0; // x initialized to 0
  10   flag = 1;
  11   foo();
  12   if (flag) // assumed false
  13 x = new int;
  14   foo();
  15 
  16   if (flag) // assumed true
  17 *x = 5; // warn
  18 }

We emit a warning at statement 17. The new BugReporter visitor figures out that 
statement 16 is in fact a control dependency if the reported node, and uses 
`trackExpressionValue()` to track it's condition, in this case, `flag`, 
resulting in new notes being placed at for the call to `foo()` on line 14 and a 
note about `flag` being invalidated on line 5.

Now, whether this change is any good is practically impossible to tell without 
evaluation on production code, so I'll get back with that once I gather some 
data.


Repository:
  rC Clang

https://reviews.llvm.org/D62883

Files:
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  clang/test/Analysis/Inputs/expected-plists/cxx-for-range.cpp.plist
  clang/test/Analysis/Inputs/expected-plists/edges-new.mm.plist
  clang/test/Analysis/Inputs/expected-plists/retain-release.m.objc.plist
  clang/test/Analysis/Inputs/expected-plists/retain-release.m.objcpp.plist
  clang/test/Analysis/Inputs/expected-plists/unix-fns.c.plist
  
clang/test/Analysis/diagnostics/Inputs/expected-plists/undef-value-param.m.plist
  clang/test/Analysis/diagnostics/no-store-func-path-notes.m
  clang/test/Analysis/diagnostics/undef-value-param.m
  clang/test/Analysis/track-control-dependency-conditions.cpp

Index: clang/test/Analysis/track-control-dependency-conditions.cpp
===
--- /dev/null
+++ clang/test/Analysis/track-control-dependency-conditions.cpp
@@ -0,0 +1,48 @@
+// RUN: %clang_analyze_cc1 %s -verify \
+// RUN:   -analyzer-output=text \
+// RUN:   -analyzer-checker=core
+
+int flag;
+bool coin();
+
+void foo() {
+  flag = coin(); // expected-note 2{{Value assigned to 'flag'}}
+}
+
+void example_1() {
+  int *x = 0; // expected-note{{'x' initialized to a null pointer value}}
+  flag = 1;
+
+  foo(); // TODO: Add nodes here about flag's value being invalidated.
+  if (flag) // expected-note   {{Taking false branch}}
+// expected-note@-1{{Assuming 'flag' is 0}}
+x = new int;
+
+  foo(); // expected-note   {{Calling 'foo'}}
+ // expected-note@-1{{Returning from 'foo'}}
+
+  if (flag) // expected-note   {{Taking true branch}}
+// expected-note@-1{{Assuming 'flag' is not equal to 0}}
+*x = 5; // expected-warning{{Dereference of null pointer}}
+// expected-note@-1{{Dereference of null pointer}}
+}
+
+void example_2() {
+  int *x = 0;
+  flag = 1;
+
+  foo(); // TODO: Add nodes here about flag's value being invalidated.
+  if (flag) // expected-note   {{Taking false branch}}
+// expected-note@-1{{Assuming 'flag' is 0}}
+x = new int;
+
+  x = 0; // expected-note{{Null pointer value stored to 'x'}}
+
+  foo(); // expected-note   {{Calling 'foo'}}
+ // expected-note@-1{{Returning from 'foo'}}
+
+  if (flag) // expected-note   {{Taking true branch}}
+// expected-note@-1{{Assuming 'flag' is not equal to 0}}
+*x = 5; // expected-warning{{Dereference of null pointer}}
+// expected-note@-1{{Dereference of null pointer}}
+}
Index: clang/test/Analysis/diagnostics/undef-value-param.m
===
--- clang/test/Analysis/diagnostics/undef-value-param.m
+++ clang/test/Analysis/diagnostics/undef-value-param.m
@@ -52,7 +52,7 @@
 
 static void CreateRef(SCDynamicStoreRef *storeRef, unsigned x) {
 unsigned err = 0;
-SCDynamicStoreRef ref = anotherCreateRef(, x);
+SCDynamicStoreRef ref = anotherCreateRef(, x); // expected-note{{Value assigned to 'err'}}
 if (err) { 
//expected-note@-1{{Assuming 'err' is not equal to 0}}
//expected-note@-2{{Taking true branch}}
Index: clang/test/Analysis/diagnostics/no-store-func-path-notes.m

[PATCH] D62623: Reduce memory consumption of coverage dumps

[Vedant Kumar via Phabricator via cfe-commits]

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

LGTM.




Comment at: clang/lib/CodeGen/CoverageMappingGen.cpp:1393
+  size_t CoverageMappingSize = 0;
+  for (auto  : CoverageMappings) {
+CoverageMappingSize += S.size();

serge-sans-paille wrote:
> vsk wrote:
> > It doesn't look like the CoverageMappings std::vector is needed at all. 
> > Consider moving `FilenamesAndCoverageMappings` into 
> > CoverageMappingModuleGen?
> > 
> > That should reduce the memory requirements a bit more.
> It's not possible to directly store into `FilenamesAndCoverageMappings` 
> because filenames need to be stored before all mappings. It's possible to use 
> a `std::string` instead of a `std::vector` but it means that at some point, 
> memory usage will be `| CoverageMappings| x 2` while if we empty the vector 
> elements as we push them to the stream, we should keep `|CoverageMappings|`. 
> I've updated the diff to enforce this stream behavior.
Ah, thanks for explaining.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62623



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

[Diffusion] rL358949: [PowerPC] [Clang] Port MMX intrinsics and basic test cases to Power

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.

/cfe/trunk/lib/Driver/ToolChains/PPCLinux.cpp:26 I'm not particularly concerned 
about the scoping of the work; however, the `ppc_wrappers` directory is not at 
all indicative of that scoping. It neither indicates the scope in terms of 
purpose (providing x86 vector intrinsics) nor does it indicate the scope in 
terms of applicability (64-bit Linux). I would suggest that the header belongs 
as part of a deeper structure that can be used for other purposes as well 
`ppc_wrappers/ppc64common/linux/`. If the header becomes applicable to more 
platforms, we can move it with the possibility of additionally placing headers 
that use `#include_next` as appropriate.

https://reviews.llvm.org/rL358949



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

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

[Don Hinton via Phabricator via cfe-commits]

hintonda added a comment.

In D62873#1529800 , @nathanchance 
wrote:

> Thanks for the quick fix, looks good to me!


Ah, sorry, just saw this.  I just committed r362555 that addresses this.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62873



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

[PATCH] D62445: [test] Fix plugin tests

[Don Hinton via Phabricator via cfe-commits]

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



Comment at: cfe/trunk/lib/Analysis/plugins/CMakeLists.txt:1
+if(LLVM_ENABLE_PLUGINS)
+  add_subdirectory(SampleAnalyzer)

hintonda wrote:
> nathanchance wrote:
> > I think this should have a dependency on `CLANG_ENABLE_STATIC_ANALYZER` 
> > like in `clang/test/CMakeLists.txt`, otherwise my build (which disables 
> > `CLANG_ENABLE_STATIC_ANALYZER`) fails because these plugins are being added 
> > to the build.
> > 
> > ```
> > [2058/2605] Linking CXX shared module 
> > lib/CheckerOptionHandlingAnalyzerPlugin.so
> > FAILED: lib/CheckerOptionHandlingAnalyzerPlugin.so 
> > : && /usr/bin/g++ -fPIC -O2 -march=native -mtune=native -fPIC 
> > -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -w 
> > -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common 
> > -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG  -Wl,-z,nodelete 
> > -fuse-ld=gold   -Wl,-O3 -Wl,--gc-sections  
> > -Wl,--version-script,"/tc-build2/build/llvm/stage1/tools/clang/lib/Analysis/plugins/CheckerOptionHandling/CheckerOptionHandlingAnalyzerPlugin.exports"
> >  -shared  -o lib/CheckerOptionHandlingAnalyzerPlugin.so 
> > tools/clang/lib/Analysis/plugins/CheckerOptionHandling/CMakeFiles/CheckerOptionHandlingAnalyzerPlugin.dir/CheckerOptionHandling.cpp.o
> >   -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a lib/libclangAnalysis.a 
> > lib/libclangAST.a -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend 
> > lib/libLLVMSupport.a lib/libclangASTMatchers.a lib/libclangAST.a 
> > lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a 
> > lib/libLLVMRemarks.a lib/libLLVMMC.a lib/libLLVMBinaryFormat.a 
> > lib/libLLVMDebugInfoCodeView.a lib/libLLVMDebugInfoMSF.a 
> > lib/libLLVMSupport.a -lz -lrt -ldl -lpthread -lm lib/libLLVMDemangle.a && :
> > /usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerCore
> > /usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerFrontend
> > collect2: error: ld returned 1 exit status
> > [2059/2605] Building CXX object 
> > tools/clang/tools/clang-refactor/CMakeFiles/clang-refactor.dir/TestSupport.cpp.o
> > [2060/2605] Linking CXX shared module 
> > lib/CheckerDependencyHandlingAnalyzerPlugin.so
> > FAILED: lib/CheckerDependencyHandlingAnalyzerPlugin.so 
> > : && /usr/bin/g++ -fPIC -O2 -march=native -mtune=native -fPIC 
> > -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -w 
> > -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common 
> > -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG  -Wl,-z,nodelete 
> > -fuse-ld=gold   -Wl,-O3 -Wl,--gc-sections  
> > -Wl,--version-script,"/tc-build2/build/llvm/stage1/tools/clang/lib/Analysis/plugins/CheckerDependencyHandling/CheckerDependencyHandlingAnalyzerPlugin.exports"
> >  -shared  -o lib/CheckerDependencyHandlingAnalyzerPlugin.so 
> > tools/clang/lib/Analysis/plugins/CheckerDependencyHandling/CMakeFiles/CheckerDependencyHandlingAnalyzerPlugin.dir/CheckerDependencyHandling.cpp.o
> >   -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a lib/libclangAnalysis.a 
> > lib/libclangAST.a -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend 
> > lib/libLLVMSupport.a lib/libclangASTMatchers.a lib/libclangAST.a 
> > lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a 
> > lib/libLLVMRemarks.a lib/libLLVMMC.a lib/libLLVMBinaryFormat.a 
> > lib/libLLVMDebugInfoCodeView.a lib/libLLVMDebugInfoMSF.a 
> > lib/libLLVMSupport.a -lz -lrt -ldl -lpthread -lm lib/libLLVMDemangle.a && :
> > /usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerCore
> > /usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerFrontend
> > collect2: error: ld returned 1 exit status
> > [2061/2605] Building CXX object 
> > tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/CompilationDatabase.cpp.o
> > [2062/2605] Linking CXX shared module lib/SampleAnalyzerPlugin.so
> > FAILED: lib/SampleAnalyzerPlugin.so 
> > : && /usr/bin/g++ -fPIC -O2 -march=native -mtune=native -fPIC 
> > -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -w 
> > -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common 
> > -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG  -Wl,-z,nodelete 
> > -fuse-ld=gold   -Wl,-O3 -Wl,--gc-sections  
> > -Wl,--version-script,"/tc-build2/build/llvm/stage1/tools/clang/lib/Analysis/plugins/SampleAnalyzer/SampleAnalyzerPlugin.exports"
> >  -shared  -o lib/SampleAnalyzerPlugin.so 
> > tools/clang/lib/Analysis/plugins/SampleAnalyzer/CMakeFiles/SampleAnalyzerPlugin.dir/MainCallChecker.cpp.o
> >   -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a lib/libclangAnalysis.a 
> > lib/libclangAST.a -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend 
> > lib/libLLVMSupport.a lib/libclangASTMatchers.a lib/libclangAST.a 
> > lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a 
> > lib/libLLVMRemarks.a lib/libLLVMMC.a lib/libLLVMBinaryFormat.a 
> > lib/libLLVMDebugInfoCodeView.a lib/libLLVMDebugInfoMSF.a 
> > 

r362555 - [Analysis] Only build Analysis plugins when CLANG_ENABLE_STATIC_ANALYZER is enabled.

[Don Hinton via cfe-commits]

Author: dhinton
Date: Tue Jun  4 15:07:40 2019
New Revision: 362555

URL: http://llvm.org/viewvc/llvm-project?rev=362555=rev
Log:
[Analysis] Only build Analysis plugins when CLANG_ENABLE_STATIC_ANALYZER is 
enabled.

Fixes bug introduced in r362328.

Thanks to Nathan Chancellor for reporting this!

Modified:
cfe/trunk/lib/Analysis/plugins/CMakeLists.txt

Modified: cfe/trunk/lib/Analysis/plugins/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/plugins/CMakeLists.txt?rev=362555=362554=362555=diff
==
--- cfe/trunk/lib/Analysis/plugins/CMakeLists.txt (original)
+++ cfe/trunk/lib/Analysis/plugins/CMakeLists.txt Tue Jun  4 15:07:40 2019
@@ -1,4 +1,4 @@
-if(LLVM_ENABLE_PLUGINS)
+if(CLANG_ENABLE_STATIC_ANALYZER AND LLVM_ENABLE_PLUGINS)
   add_subdirectory(SampleAnalyzer)
   add_subdirectory(CheckerDependencyHandling)
   add_subdirectory(CheckerOptionHandling)


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

[PATCH] D62049: [clang-tidy] Add a close-on-exec check on pipe2() in Android module.

[Dmitri Gribenko via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/test/clang-tidy/android-cloexec-pipe2.cpp:20
+  pipe2(pipefd, O_NONBLOCK);
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: 'pipe2' should use O_CLOEXEC 
where possible [android-cloexec-pipe2]
+  // CHECK-FIXES: pipe2(pipefd, O_NONBLOCK | O_CLOEXEC);

jcai19 wrote:
> gribozavr wrote:
> > jcai19 wrote:
> > > gribozavr wrote:
> > > > Same comment about the message as in D61967 -- the message should 
> > > > briefly explain why the user should make this change. Users tend to 
> > > > ignore warnings they don't understand.
> > > > 
> > > > "pipe2 should be called with O_CLOEXEC to avoid leaking file 
> > > > descriptors to child processes"
> > > It appeared to me that there was no easy way to change the warning 
> > > message due to the way insertMacroFlag is implemented (called in  
> > > CloexecPipe2Check::check(...) to add O_CLOEXEC flag when necessary). The 
> > > function always issue a warning in the format of "%0 should use %1 where 
> > > possible". So unless we parameterize the warning string (which could be 
> > > solved by a different code change), we might end up implementing a 
> > > similar function with different warning message, which creates extra work 
> > > if we need to modify insertMacroFlag in the future. I am new to Clang so 
> > > please let me know if there is a better way to udpate the warning message.
> > I don't see an issue with parameterizing insertMacroFlag -- the current 
> > message that it produces is not descriptive enough anyway, users tend to 
> > ignore such messages.
> I agree. But my point is insertMacroFlag is used by several other checks. 
> Shouldn't we parameterize the warning message and update these checks 
> together in a separate change?
SGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62049



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

[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 203029.
serge-sans-paille added a comment.

- make it possible for client code to speicify the registration function for 
new PM, thanks @philip.pfaffe for the hint. @Meinersbur this should be ok now.


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

https://reviews.llvm.org/D61446

Files:
  clang/tools/driver/CMakeLists.txt
  clang/tools/driver/cc1_main.cpp
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/docs/WritingAnLLVMPass.rst
  llvm/include/llvm/Config/llvm-config.h.cmake
  llvm/tools/CMakeLists.txt
  llvm/tools/bugpoint/CMakeLists.txt
  llvm/tools/bugpoint/bugpoint.cpp
  llvm/tools/opt/CMakeLists.txt
  llvm/tools/opt/NewPMDriver.cpp
  llvm/tools/opt/opt.cpp
  llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
  polly/CMakeLists.txt
  polly/lib/CMakeLists.txt
  polly/lib/Support/RegisterPasses.cpp
  polly/test/Unit/lit.site.cfg.in
  polly/test/lit.site.cfg.in
  polly/test/update_check.py

Index: polly/test/update_check.py
===
--- polly/test/update_check.py
+++ polly/test/update_check.py
@@ -15,7 +15,7 @@
 polly_lib_dir = '''@POLLY_LIB_DIR@'''
 shlibext = '''@LLVM_SHLIBEXT@'''
 llvm_tools_dir = '''@LLVM_TOOLS_DIR@'''
-link_polly_into_tools = not '''@LINK_POLLY_INTO_TOOLS@'''.lower() in {'','0','n','no','off','false','notfound','link_polly_into_tools-notfound'}
+llvm_polly_link_into_tools = not '''@LLVM_POLLY_LINK_INTO_TOOLS@'''.lower() in {'','0','n','no','off','false','notfound','llvm_polly_link_into_tools-notfound'}
 
 runre = re.compile(r'\s*\;\s*RUN\s*\:(?P.*)')
 filecheckre = re.compile(r'\s*(?P.*)\|\s*(?PFileCheck\s[^|]*)')
@@ -298,7 +298,7 @@
 toolarg = toolarg.replace('%s', filename)
 toolarg = toolarg.replace('%S', os.path.dirname(filename))
 if toolarg == '%loadPolly':
-if not link_polly_into_tools:
+if not llvm_polly_link_into_tools:
 newtool += ['-load',os.path.join(polly_lib_dir,'LLVMPolly' + shlibext)]
 newtool.append('-polly-process-unprofitable')
 newtool.append('-polly-remarks-minimal')
Index: polly/test/lit.site.cfg.in
===
--- polly/test/lit.site.cfg.in
+++ polly/test/lit.site.cfg.in
@@ -8,7 +8,7 @@
 config.polly_lib_dir = "@POLLY_LIB_DIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
-config.link_polly_into_tools = "@LINK_POLLY_INTO_TOOLS@"
+config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.targets_to_build = "@TARGETS_TO_BUILD@"
 config.extra_paths = "@POLLY_TEST_EXTRA_PATHS@".split(";")
 
@@ -36,14 +36,14 @@
 # directories.
 config.excludes = ['Inputs']
 
-if config.link_polly_into_tools == '' or \
-   config.link_polly_into_tools.lower() == '0' or \
-   config.link_polly_into_tools.lower() == 'n' or \
-   config.link_polly_into_tools.lower() == 'no' or \
-   config.link_polly_into_tools.lower() == 'off' or \
-   config.link_polly_into_tools.lower() == 'false' or \
-   config.link_polly_into_tools.lower() == 'notfound' or \
-   config.link_polly_into_tools.lower() == 'link_polly_into_tools-notfound':
+if config.llvm_polly_link_into_tools == '' or \
+   config.llvm_polly_link_into_tools.lower() == '0' or \
+   config.llvm_polly_link_into_tools.lower() == 'n' or \
+   config.llvm_polly_link_into_tools.lower() == 'no' or \
+   config.llvm_polly_link_into_tools.lower() == 'off' or \
+   config.llvm_polly_link_into_tools.lower() == 'false' or \
+   config.llvm_polly_link_into_tools.lower() == 'notfound' or \
+   config.llvm_polly_link_into_tools.lower() == 'llvm_polly_link_into_tools-notfound':
 config.substitutions.append(('%loadPolly', '-load '
  + config.polly_lib_dir + '/LLVMPolly@LLVM_SHLIBEXT@'
  + ' -load-pass-plugin '
Index: polly/test/Unit/lit.site.cfg.in
===
--- polly/test/Unit/lit.site.cfg.in
+++ polly/test/Unit/lit.site.cfg.in
@@ -13,7 +13,7 @@
 config.shlibdir = "@SHLIBDIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
-config.link_polly_into_tools = "@LINK_POLLY_INTO_TOOLS@"
+config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.has_unittests = @POLLY_GTEST_AVAIL@
 
 # Support substitution of the tools_dir, libs_dirs, and build_mode with user
Index: polly/lib/Support/RegisterPasses.cpp
===
--- polly/lib/Support/RegisterPasses.cpp
+++ polly/lib/Support/RegisterPasses.cpp
@@ -234,7 +234,6 @@
 cl::desc("Bail out on unprofitable SCoPs before rescheduling"), cl::Hidden,
 cl::init(true), cl::cat(PollyCategory));
 
-namespace polly {
 void initializePollyPasses(PassRegistry ) {
   

[PATCH] D62623: Reduce memory consumption of coverage dumps

[serge via Phabricator via cfe-commits]

serge-sans-paille added inline comments.



Comment at: clang/lib/CodeGen/CoverageMappingGen.cpp:1393
+  size_t CoverageMappingSize = 0;
+  for (auto  : CoverageMappings) {
+CoverageMappingSize += S.size();

vsk wrote:
> It doesn't look like the CoverageMappings std::vector is needed at all. 
> Consider moving `FilenamesAndCoverageMappings` into CoverageMappingModuleGen?
> 
> That should reduce the memory requirements a bit more.
It's not possible to directly store into `FilenamesAndCoverageMappings` because 
filenames need to be stored before all mappings. It's possible to use a 
`std::string` instead of a `std::vector` but it means that at some point, 
memory usage will be `| CoverageMappings| x 2` while if we empty the vector 
elements as we push them to the stream, we should keep `|CoverageMappings|`. 
I've updated the diff to enforce this stream behavior.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62623



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

r362551 - Convert MemberExpr creation and serialization to work the same way as

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Jun  4 14:29:28 2019
New Revision: 362551

URL: http://llvm.org/viewvc/llvm-project?rev=362551=rev
Log:
Convert MemberExpr creation and serialization to work the same way as
most / all other Expr subclasses.

Modified:
cfe/trunk/include/clang/AST/Expr.h
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/lib/AST/DeclBase.cpp
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp
cfe/trunk/lib/Frontend/Rewrite/RewriteObjC.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
cfe/trunk/lib/Serialization/ASTWriterStmt.cpp

Modified: cfe/trunk/include/clang/AST/Expr.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Expr.h?rev=362551=362550=362551=diff
==
--- cfe/trunk/include/clang/AST/Expr.h (original)
+++ cfe/trunk/include/clang/AST/Expr.h Tue Jun  4 14:29:28 2019
@@ -2735,6 +2735,7 @@ class MemberExpr final
 ASTTemplateKWAndArgsInfo,
 TemplateArgumentLoc> {
   friend class ASTReader;
+  friend class ASTStmtReader;
   friend class ASTStmtWriter;
   friend TrailingObjects;
 
@@ -2769,49 +2770,38 @@ class MemberExpr final
 return MemberExprBits.HasTemplateKWAndArgsInfo;
   }
 
-public:
-  MemberExpr(Expr *base, bool isarrow, SourceLocation operatorloc,
- ValueDecl *memberdecl, const DeclarationNameInfo ,
- QualType ty, ExprValueKind VK, ExprObjectKind OK)
-  : Expr(MemberExprClass, ty, VK, OK, base->isTypeDependent(),
- base->isValueDependent(), base->isInstantiationDependent(),
- base->containsUnexpandedParameterPack()),
-Base(base), MemberDecl(memberdecl), MemberDNLoc(NameInfo.getInfo()),
-MemberLoc(NameInfo.getLoc()) {
-assert(memberdecl->getDeclName() == NameInfo.getName());
-MemberExprBits.IsArrow = isarrow;
-MemberExprBits.HasQualifierOrFoundDecl = false;
-MemberExprBits.HasTemplateKWAndArgsInfo = false;
-MemberExprBits.HadMultipleCandidates = false;
-MemberExprBits.OperatorLoc = operatorloc;
-  }
-
-  // NOTE: this constructor should be used only when it is known that
-  // the member name can not provide additional syntactic info
-  // (i.e., source locations for C++ operator names or type source info
-  // for constructors, destructors and conversion operators).
-  MemberExpr(Expr *base, bool isarrow, SourceLocation operatorloc,
- ValueDecl *memberdecl, SourceLocation l, QualType ty,
- ExprValueKind VK, ExprObjectKind OK)
-  : Expr(MemberExprClass, ty, VK, OK, base->isTypeDependent(),
- base->isValueDependent(), base->isInstantiationDependent(),
- base->containsUnexpandedParameterPack()),
-Base(base), MemberDecl(memberdecl), MemberDNLoc(), MemberLoc(l) {
-MemberExprBits.IsArrow = isarrow;
-MemberExprBits.HasQualifierOrFoundDecl = false;
-MemberExprBits.HasTemplateKWAndArgsInfo = false;
-MemberExprBits.HadMultipleCandidates = false;
-MemberExprBits.OperatorLoc = operatorloc;
-  }
+  MemberExpr(Expr *Base, bool IsArrow, SourceLocation OperatorLoc,
+ ValueDecl *MemberDecl, const DeclarationNameInfo ,
+ QualType T, ExprValueKind VK, ExprObjectKind OK);
+  MemberExpr(EmptyShell Empty)
+  : Expr(MemberExprClass, Empty), Base(), MemberDecl() {}
 
-  static MemberExpr *Create(const ASTContext , Expr *base, bool isarrow,
+public:
+  static MemberExpr *Create(const ASTContext , Expr *Base, bool IsArrow,
 SourceLocation OperatorLoc,
 NestedNameSpecifierLoc QualifierLoc,
-SourceLocation TemplateKWLoc, ValueDecl 
*memberdecl,
-DeclAccessPair founddecl,
+SourceLocation TemplateKWLoc, ValueDecl 
*MemberDecl,
+DeclAccessPair FoundDecl,
 DeclarationNameInfo MemberNameInfo,
-const TemplateArgumentListInfo *targs, QualType ty,
-ExprValueKind VK, ExprObjectKind OK);
+const TemplateArgumentListInfo *TemplateArgs,
+QualType T, ExprValueKind VK, ExprObjectKind OK);
+
+  /// Create an implicit MemberExpr, with no location, qualifier, template
+  /// arguments, and so on.
+  static MemberExpr *CreateImplicit(const ASTContext , Expr *Base,
+bool IsArrow, ValueDecl *MemberDecl,
+QualType T, ExprValueKind VK,
+ExprObjectKind OK) {
+return Create(C, Base, IsArrow, SourceLocation(), NestedNameSpecifierLoc(),
+  SourceLocation(), MemberDecl,
+  DeclAccessPair::make(MemberDecl, MemberDecl->getAccess()),
+  

[PATCH] D60583: [AArch64] Implement Vector Funtion ABI name mangling.

[Francesco Petrogalli via Phabricator via cfe-commits]

fpetrogalli added a comment.

In D60583#1529878 , @jdoerfert wrote:

> Why/Where did we decide to clobber the attribute list with "non-existent 
> function names"?
>  I don't think an attribute list like this:
>  `attributes #1 = { "_ZGVsM2v_foo" "_ZGVsM32v_foo" "_ZGVsM4v_foo" 
> "_ZGVsM6v_foo" "_ZGVsM8v_foo" "_ZGVsMxv_foo" ... `
>  is helpful in any way, e.g., this would require us to search through all 
> attributes and interpret them one by one.


Agree. This is what was agreed : 
http://lists.llvm.org/pipermail/cfe-dev/2016-March/047732.html

The new RFC will get rid of this list of string attributes. It will become 
something like:

  attribute #0 = { 
declare-variant="comma,separated,list,of,vector,function,ABI,mangled,names" }.



> This seems to me like an ad-hoc implementation of the RFC that is currently 
> discussed but committed before the discussion is finished.

I can assure you that's not the case.

The code in this patch is what it is because it is based on previous (accepted) 
RFC originally proposed by other people and used by VecClone: 
https://reviews.llvm.org/D22792

As you can see in the unit tests of the VecClone pass, the variant attribute is 
added as follows:

  attributes #0 = { nounwind uwtable 
"vector-variants"="_ZGVbM4_foo1,_ZGVbN4_foo1,_ZGVcM8_foo1,_ZGVcN8_foo1,_ZGVdM8_foo1,_ZGVdN8_foo1,_ZGVeM16_foo1,_ZGVeN16_foo1"
   }

Nothing in LLVM is using those attributes at the moment, that might be the 
reason why the string attribute have not yet been moved to a single attribute.

Kind regards,

Francesco


Repository:
  rC Clang

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

https://reviews.llvm.org/D60583



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

[PATCH] D60583: [AArch64] Implement Vector Funtion ABI name mangling.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D60583#1529885 , @jdoerfert wrote:

> In D60583#1529882 , @ABataev wrote:
>
> > In D60583#1529878 , @jdoerfert 
> > wrote:
> >
> > > Why/Where did we decide to clobber the attribute list with "non-existent 
> > > function names"?
> > >
> > > This seems to me like an ad-hoc implementation of the RFC that is 
> > > currently discussed but committed before the discussion is finished.
> >
> >
> > It has nothing to do with the RFC for a variant. It is a standard interface 
> > to communicate with the backend to generate vectorized versions of the 
> > functions. It relies on Vector ABI, provided by Intel and ARM, it follows 
> > the way it is implemented in GCC. There was an RFC for this long time ago 
> > which was accepted by the community and later implemented.
>
>
> The RFC states, in a nutshell, let us add one attribute to identify all 
> vector variants. This patch adds all vector variants as attributes. Clearly, 
> these things are related.


This new RFC just follows the scheme that was already accepted and implemented. 
As I understand, Francesco just wants to reuse the existing solution for SIMD 
isa of the pragma omp variant (or attribute clang variant)


Repository:
  rC Clang

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

https://reviews.llvm.org/D60583



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

[PATCH] D60583: [AArch64] Implement Vector Funtion ABI name mangling.

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D60583#1529882 , @ABataev wrote:

> In D60583#1529878 , @jdoerfert wrote:
>
> > Why/Where did we decide to clobber the attribute list with "non-existent 
> > function names"?
> >
> > This seems to me like an ad-hoc implementation of the RFC that is currently 
> > discussed but committed before the discussion is finished.
>
>
> It has nothing to do with the RFC for a variant. It is a standard interface 
> to communicate with the backend to generate vectorized versions of the 
> functions. It relies on Vector ABI, provided by Intel and ARM, it follows the 
> way it is implemented in GCC. There was an RFC for this long time ago which 
> was accepted by the community and later implemented.


The RFC states, in a nutshell, let us add one attribute to identify all vector 
variants. This patch adds all vector variants as attributes. Clearly, these 
things are related.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60583



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

[PATCH] D60583: [AArch64] Implement Vector Funtion ABI name mangling.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D60583#1529878 , @jdoerfert wrote:

> Why/Where did we decide to clobber the attribute list with "non-existent 
> function names"?
>
> This seems to me like an ad-hoc implementation of the RFC that is currently 
> discussed but committed before the discussion is finished.


It has nothing to do with the RFC for a variant. It is a standard interface to 
communicate with the backend to generate vectorized versions of the functions. 
It relies on Vector ABI, provided by Intel and ARM, it follows the way it is 
implemented in GCC. There was an RFC for this long time ago which was accepted 
by the community and later implemented.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60583



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

[PATCH] D60583: [AArch64] Implement Vector Funtion ABI name mangling.

[Johannes Doerfert via Phabricator via cfe-commits]

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

Why/Where did we decide to clobber the attribute list with "non-existent 
function names"?

This seems to me like an ad-hoc implementation of the RFC that is currently 
discussed but committed before the discussion is finished.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60583



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

[PATCH] D62830: [WebAssembly] Support Leak Sanitizer on Emscripten

[Guanzhong Chen via Phabricator via cfe-commits]

quantum added a comment.

It's not urgent, so I am willing to wait a day or two for commit access. If I 
still can't get access by then, I'll ask someone else to commit this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62830



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

[PATCH] D62830: [WebAssembly] Support Leak Sanitizer on Emscripten

[Heejin Ahn via Phabricator via cfe-commits]

aheejin added a comment.

I see. Do you want me to commit this, or you are gonna get a commit access?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62830



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

[PATCH] D60233: [clang-scan-deps] initial outline of the tool that runs preprocessor to find dependencies over a JSON compilation database

[Alex Lorenz via Phabricator via cfe-commits]

arphaman updated this revision to Diff 203012.
arphaman marked 7 inline comments as done.
arphaman added a comment.

Address review comments.


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

https://reviews.llvm.org/D60233

Files:
  clang/test/ClangScanDeps/Inputs/regular_cdb.json
  clang/test/ClangScanDeps/regular_cdb.cpp
  clang/tools/CMakeLists.txt
  clang/tools/clang-scan-deps/CMakeLists.txt
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- /dev/null
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -0,0 +1,216 @@
+//===-- ClangScanDeps.cpp - Implementation of clang-scan-deps -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/CompilerInvocation.h"
+#include "clang/Frontend/FrontendActions.h"
+#include "clang/Frontend/PCHContainerOperations.h"
+#include "clang/FrontendTool/Utils.h"
+#include "clang/Tooling/CommonOptionsParser.h"
+#include "clang/Tooling/JSONCompilationDatabase.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/JSON.h"
+#include "llvm/Support/Options.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Program.h"
+#include "llvm/Support/Signals.h"
+#include "llvm/Support/Threading.h"
+#include 
+
+using namespace clang;
+
+namespace {
+
+/// A clang tool that runs the preprocessor only for the given compiler
+/// invocation.
+class PreprocessorOnlyTool : public tooling::ToolAction {
+public:
+  PreprocessorOnlyTool(StringRef WorkingDirectory)
+  : WorkingDirectory(WorkingDirectory) {}
+
+  bool runInvocation(std::shared_ptr Invocation,
+ FileManager *FileMgr,
+ std::shared_ptr PCHContainerOps,
+ DiagnosticConsumer *DiagConsumer) override {
+// Create a compiler instance to handle the actual work.
+CompilerInstance Compiler(std::move(PCHContainerOps));
+Compiler.setInvocation(std::move(Invocation));
+FileMgr->getFileSystemOpts().WorkingDir = WorkingDirectory;
+Compiler.setFileManager(FileMgr);
+
+// Create the compiler's actual diagnostics engine.
+Compiler.createDiagnostics(DiagConsumer, /*ShouldOwnClient=*/false);
+if (!Compiler.hasDiagnostics())
+  return false;
+
+Compiler.createSourceManager(*FileMgr);
+
+auto Action = llvm::make_unique();
+const bool Result = Compiler.ExecuteAction(*Action);
+FileMgr->clearStatCache();
+return Result;
+  }
+
+private:
+  StringRef WorkingDirectory;
+};
+
+/// A proxy file system that doesn't call `chdir` when changing the working
+/// directory of a clang tool.
+class ProxyFileSystemWithoutChdir : public llvm::vfs::ProxyFileSystem {
+public:
+  ProxyFileSystemWithoutChdir(
+  llvm::IntrusiveRefCntPtr FS)
+  : ProxyFileSystem(std::move(FS)) {}
+
+  llvm::ErrorOr getCurrentWorkingDirectory() const override {
+assert(!CWD.empty() && "empty CWD");
+return CWD;
+  }
+
+  std::error_code setCurrentWorkingDirectory(const Twine ) override {
+CWD = Path.str();
+return {};
+  }
+
+private:
+  std::string CWD;
+};
+
+/// The high-level implementation of the dependency discovery tool that runs on
+/// an individual worker thread.
+class DependencyScanningTool {
+public:
+  /// Construct a dependency scanning tool.
+  ///
+  /// \param Compilations The reference to the compilation database that's
+  /// used by the clang tool.
+  DependencyScanningTool(const tooling::CompilationDatabase )
+  : Compilations(Compilations) {
+PCHContainerOps = std::make_shared();
+BaseFS = new ProxyFileSystemWithoutChdir(llvm::vfs::getRealFileSystem());
+  }
+
+  /// Computes the dependencies for the given file.
+  ///
+  /// \returns True on error.
+  bool runOnFile(const std::string , StringRef CWD) {
+BaseFS->setCurrentWorkingDirectory(CWD);
+tooling::ClangTool Tool(Compilations, Input, PCHContainerOps, BaseFS);
+Tool.clearArgumentsAdjusters();
+Tool.setRestoreWorkingDir(false);
+PreprocessorOnlyTool Action(CWD);
+return Tool.run();
+  }
+
+private:
+  const tooling::CompilationDatabase 
+  std::shared_ptr PCHContainerOps;
+  /// The real filesystem used as a base for all the operations performed by the
+  /// tool.
+  llvm::IntrusiveRefCntPtr BaseFS;
+};
+
+llvm::cl::opt Help("h", llvm::cl::desc("Alias for -help"),
+ llvm::cl::Hidden);
+
+llvm::cl::OptionCategory DependencyScannerCategory("Tool options");
+
+llvm::cl::opt
+NumThreads("j", llvm::cl::Optional,
+   llvm::cl::desc("Number of worker threads to use (default: use "
+  

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

[David Goldman via Phabricator via cfe-commits]

dgoldman updated this revision to Diff 203011.
dgoldman added a comment.

- Move if empty check back


Repository:
  rC Clang

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

https://reviews.llvm.org/D62648

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

Index: test/Sema/typo-correction-recursive.cpp
===
--- /dev/null
+++ test/Sema/typo-correction-recursive.cpp
@@ -0,0 +1,71 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Check the following typo correction behavior:
+// - multiple typos in a single member call chain are all diagnosed
+// - no typos are diagnosed for multiple typos in an expression when not all
+//   typos can be corrected
+
+class DeepClass
+{
+public:
+  void trigger() const;  // expected-note {{'trigger' declared here}}
+};
+
+class Y
+{
+public:
+  const DeepClass& getX() const { return m_deepInstance; } // expected-note {{'getX' declared here}}
+  int getN() const { return m_n; }
+private:
+  DeepClass m_deepInstance;
+  int m_n;
+};
+
+class Z
+{
+public:
+  const Y& getY0() const { return m_y0; } // expected-note {{'getY0' declared here}}
+  const Y& getY1() const { return m_y1; }
+  const Y& getActiveY() const { return m_y0; }
+
+private:
+  Y m_y0;
+  Y m_y1;
+};
+
+Z z_obj;
+
+void testMultipleCorrections()
+{
+  z_obj.getY2(). // expected-error {{no member named 'getY2' in 'Z'; did you mean 'getY0'}}
+getM().  // expected-error {{no member named 'getM' in 'Y'; did you mean 'getX'}}
+triggee();   // expected-error {{no member named 'triggee' in 'DeepClass'; did you mean 'trigger'}}
+}
+
+void testNoCorrections()
+{
+  z_obj.getY2(). // expected-error {{no member named 'getY2' in 'Z'}}
+getM().
+thisDoesntSeemToMakeSense();
+}
+
+struct C {};
+struct D { int value; };
+struct A {
+  C get_me_a_C();
+};
+struct B {
+  D get_me_a_D(); // expected-note {{'get_me_a_D' declared here}}
+};
+class Scope {
+public:
+  A make_an_A();
+  B make_a_B(); // expected-note {{'make_a_B' declared here}}
+};
+
+Scope scope_obj;
+
+int testDiscardedCorrections() {
+  return scope_obj.make_an_E(). // expected-error {{no member named 'make_an_E' in 'Scope'; did you mean 'make_a_B'}}
+get_me_a_Z().value; // expected-error {{no member named 'get_me_a_Z' in 'B'; did you mean 'get_me_a_D'}}
+}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -7680,6 +7680,61 @@
 return ExprFilter(Res.get());
   }
 
+  // Try to transform the given expression, looping through the correction
+  // candidates with `CheckAndAdvanceTypoExprCorrectionStreams`.
+  //
+  // Since correcting typos may intoduce new TypoExprs, this function
+  // checks for new TypoExprs and recurses if it finds any. Note that it will
+  // only succeed if it is able to correct all typos in the given expression.
+  ExprResult RecursiveTransformLoop(Expr *E) {
+ExprResult Res;
+while (true) {
+  Res = TryTransform(E);
+
+  // The transform was valid: check if there any new TypoExprs were created.
+  // If so, we need to recurse to check their validity.
+  if (!Res.isInvalid()) {
+Expr *FixedExpr = Res.get();
+auto SavedTypoExprs = TypoExprs;
+llvm::SmallSetVector RecursiveTypoExprs;
+TypoExprs = RecursiveTypoExprs;
+FindTypoExprs(TypoExprs).TraverseStmt(FixedExpr);
+
+if (!TypoExprs.empty()) {
+  // Recurse to handle newly created TypoExprs. If we're not able to
+  // handle them, discard these TypoExprs.
+  ExprResult RecurResult = RecursiveTransformLoop(FixedExpr);
+  if (RecurResult.isInvalid()) {
+Res = ExprError();
+// Recursive corrections didn't work, wipe them away and don't add
+// them to the TypoExprs set.
+for (auto TE : TypoExprs) {
+  TransformCache.erase(TE);
+  SemaRef.clearDelayedTypo(TE);
+}
+  } else {
+// TypoExpr is valid: add newly created TypoExprs since we were
+// able to correct them.
+Res = RecurResult;
+SavedTypoExprs.set_union(TypoExprs);
+  }
+}
+
+TypoExprs = SavedTypoExprs;
+  }
+  // If the transform is still valid after checking for any new typos,
+  // it's good to go.
+  if (!Res.isInvalid())
+break;
+
+  // The transform was invalid, see if we have any TypoExprs with untried
+  // correction candidates.
+  if (!CheckAndAdvanceTypoExprCorrectionStreams())
+break;
+}
+return Res;
+  }
+
 public:
   TransformTypos(Sema , VarDecl *InitDecl, llvm::function_ref Filter)
   : BaseTransform(SemaRef), InitDecl(InitDecl), ExprFilter(Filter) {}
@@ -7707,16 +7762,7 @@
   ExprResult TransformBlockExpr(BlockExpr *E) { return Owned(E); }
 
   

r362545 - Introduce Value::stripPointerCastsSameRepresentation

[Johannes Doerfert via cfe-commits]

Author: jdoerfert
Date: Tue Jun  4 13:21:46 2019
New Revision: 362545

URL: http://llvm.org/viewvc/llvm-project?rev=362545=rev
Log:
Introduce Value::stripPointerCastsSameRepresentation

This patch allows current users of Value::stripPointerCasts() to force
the result of the function to have the same representation as the value
it was called on. This is useful in various cases, e.g., (non-)null
checks.

In this patch only a single call site was adjusted to fix an existing
misuse that would cause nonnull where they may be wrong. Uses in
attribute deduction and other areas, e.g., D60047, are to be expected.

For a discussion on this topic, please see [0].

[0] http://lists.llvm.org/pipermail/llvm-dev/2018-December/128423.html

Reviewers: hfinkel, arsenm, reames

Subscribers: wdng, hiraditya, bollu, llvm-commits

Tags: #llvm

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

Modified:
cfe/trunk/test/CodeGenOpenCLCXX/addrspace-references.cl

Modified: cfe/trunk/test/CodeGenOpenCLCXX/addrspace-references.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCLCXX/addrspace-references.cl?rev=362545=362544=362545=diff
==
--- cfe/trunk/test/CodeGenOpenCLCXX/addrspace-references.cl (original)
+++ cfe/trunk/test/CodeGenOpenCLCXX/addrspace-references.cl Tue Jun  4 13:21:46 
2019
@@ -9,6 +9,6 @@ void foo() {
   // CHECK: [[REF:%.*]] = alloca i32
   // CHECK: store i32 1, i32* [[REF]]
   // CHECK: [[REG:%[0-9]+]] = addrspacecast i32* [[REF]] to i32 addrspace(4)*
-  // CHECK: call spir_func i32 @_Z3barRU3AS4Kj(i32 addrspace(4)* nonnull 
dereferenceable(4) [[REG]])
+  // CHECK: call spir_func i32 @_Z3barRU3AS4Kj(i32 addrspace(4)* 
dereferenceable(4) [[REG]])
   bar(1);
 }


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

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

[Nathan Chancellor via Phabricator via cfe-commits]

nathanchance added a comment.

Thanks for the quick fix, looks good to me!


Repository:
  rC Clang

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

https://reviews.llvm.org/D62873



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

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

[Kristina Brooks via Phabricator via cfe-commits]

kristina added a comment.

Experienced the same, updated my test build configuration to always force 
`CLANG_ENABLE_STATIC_ANALYZER` to On when building with tests. Maybe it's worth 
adding a warning about when Clang tests are being built?


Repository:
  rC Clang

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

https://reviews.llvm.org/D62873



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

[PATCH] D48680: Add missing visibility annotation for __base

[Peter Collingbourne via Phabricator via cfe-commits]

pcc added a comment.

Here's a standalone reproducer for the problem:

  $ cat exe.cpp
  #include 
  
  std::function f();
  
  int main() {
f()();
  }
  $ cat dso.cpp
  #include 
  
  __attribute__((visibility("default"))) std::function f() {
return [](){};
  }
  $ ~/l3/ra-cmake/bin/clang++ -fsanitize=cfi -fvisibility=hidden dso.cpp 
-shared -flto -fuse-ld=lld -Wl,-soname,dso.so -o dso.so -stdlib=libc++ 
-fno-rtti -fno-exceptions
  $ ~/l3/ra-cmake/bin/clang++ -fsanitize=cfi -fvisibility=hidden exe.cpp  -flto 
-fuse-ld=lld dso.so -stdlib=libc++
  $ LD_LIBRARY_PATH=.:$HOME/l3/ra-cmake/lib ./a.out 
  Illegal instruction

With this patch:

  $ LD_LIBRARY_PATH=.:$HOME/l3/ra-cmake/lib ./a.out 
  [no output]


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D48680



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

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

[Dimitry Andric via Phabricator via cfe-commits]

dim created this revision.
dim added reviewers: hintonda, dcoughlin, NoQ.
Herald added subscribers: dkrupp, donat.nagy, Szelethus, a.sidorin, 
baloghadamsoftware, mgorny.
Herald added a project: clang.

Attempting to build clang with CLANG_ENABLE_STATIC_ANALYZER=OFF fails
after rC362328 , because the new plugins 
under lib/Analysis/plugins are
dependent on the static analyzer libraries.

Add checks to disable building these if CLANG_ENABLE_STATIC_ANALYZER is
OFF.


Repository:
  rC Clang

https://reviews.llvm.org/D62873

Files:
  lib/Analysis/plugins/CMakeLists.txt
  test/CMakeLists.txt


Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -119,14 +119,12 @@
   endif()
 endif()
 
-if (CLANG_ENABLE_STATIC_ANALYZER)
-  if (LLVM_ENABLE_PLUGINS)
-list(APPEND CLANG_TEST_DEPS
-  SampleAnalyzerPlugin
-  CheckerDependencyHandlingAnalyzerPlugin
-  CheckerOptionHandlingAnalyzerPlugin
-  )
-  endif()
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
+  list(APPEND CLANG_TEST_DEPS
+SampleAnalyzerPlugin
+CheckerDependencyHandlingAnalyzerPlugin
+CheckerOptionHandlingAnalyzerPlugin
+)
 endif()
 
 add_custom_target(clang-test-depends DEPENDS ${CLANG_TEST_DEPS})
Index: lib/Analysis/plugins/CMakeLists.txt
===
--- lib/Analysis/plugins/CMakeLists.txt
+++ lib/Analysis/plugins/CMakeLists.txt
@@ -1,4 +1,4 @@
-if(LLVM_ENABLE_PLUGINS)
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
   add_subdirectory(SampleAnalyzer)
   add_subdirectory(CheckerDependencyHandling)
   add_subdirectory(CheckerOptionHandling)


Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -119,14 +119,12 @@
   endif()
 endif()
 
-if (CLANG_ENABLE_STATIC_ANALYZER)
-  if (LLVM_ENABLE_PLUGINS)
-list(APPEND CLANG_TEST_DEPS
-  SampleAnalyzerPlugin
-  CheckerDependencyHandlingAnalyzerPlugin
-  CheckerOptionHandlingAnalyzerPlugin
-  )
-  endif()
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
+  list(APPEND CLANG_TEST_DEPS
+SampleAnalyzerPlugin
+CheckerDependencyHandlingAnalyzerPlugin
+CheckerOptionHandlingAnalyzerPlugin
+)
 endif()
 
 add_custom_target(clang-test-depends DEPENDS ${CLANG_TEST_DEPS})
Index: lib/Analysis/plugins/CMakeLists.txt
===
--- lib/Analysis/plugins/CMakeLists.txt
+++ lib/Analysis/plugins/CMakeLists.txt
@@ -1,4 +1,4 @@
-if(LLVM_ENABLE_PLUGINS)
+if(LLVM_ENABLE_PLUGINS AND CLANG_ENABLE_STATIC_ANALYZER)
   add_subdirectory(SampleAnalyzer)
   add_subdirectory(CheckerDependencyHandling)
   add_subdirectory(CheckerOptionHandling)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62445: [test] Fix plugin tests

[Don Hinton via Phabricator via cfe-commits]

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



Comment at: cfe/trunk/lib/Analysis/plugins/CMakeLists.txt:1
+if(LLVM_ENABLE_PLUGINS)
+  add_subdirectory(SampleAnalyzer)

nathanchance wrote:
> I think this should have a dependency on `CLANG_ENABLE_STATIC_ANALYZER` like 
> in `clang/test/CMakeLists.txt`, otherwise my build (which disables 
> `CLANG_ENABLE_STATIC_ANALYZER`) fails because these plugins are being added 
> to the build.
> 
> ```
> [2058/2605] Linking CXX shared module 
> lib/CheckerOptionHandlingAnalyzerPlugin.so
> FAILED: lib/CheckerOptionHandlingAnalyzerPlugin.so 
> : && /usr/bin/g++ -fPIC -O2 -march=native -mtune=native -fPIC 
> -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -w 
> -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common 
> -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG  -Wl,-z,nodelete 
> -fuse-ld=gold   -Wl,-O3 -Wl,--gc-sections  
> -Wl,--version-script,"/tc-build2/build/llvm/stage1/tools/clang/lib/Analysis/plugins/CheckerOptionHandling/CheckerOptionHandlingAnalyzerPlugin.exports"
>  -shared  -o lib/CheckerOptionHandlingAnalyzerPlugin.so 
> tools/clang/lib/Analysis/plugins/CheckerOptionHandling/CMakeFiles/CheckerOptionHandlingAnalyzerPlugin.dir/CheckerOptionHandling.cpp.o
>   -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a lib/libclangAnalysis.a 
> lib/libclangAST.a -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend 
> lib/libLLVMSupport.a lib/libclangASTMatchers.a lib/libclangAST.a 
> lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a lib/libLLVMRemarks.a 
> lib/libLLVMMC.a lib/libLLVMBinaryFormat.a lib/libLLVMDebugInfoCodeView.a 
> lib/libLLVMDebugInfoMSF.a lib/libLLVMSupport.a -lz -lrt -ldl -lpthread -lm 
> lib/libLLVMDemangle.a && :
> /usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerCore
> /usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerFrontend
> collect2: error: ld returned 1 exit status
> [2059/2605] Building CXX object 
> tools/clang/tools/clang-refactor/CMakeFiles/clang-refactor.dir/TestSupport.cpp.o
> [2060/2605] Linking CXX shared module 
> lib/CheckerDependencyHandlingAnalyzerPlugin.so
> FAILED: lib/CheckerDependencyHandlingAnalyzerPlugin.so 
> : && /usr/bin/g++ -fPIC -O2 -march=native -mtune=native -fPIC 
> -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -w 
> -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common 
> -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG  -Wl,-z,nodelete 
> -fuse-ld=gold   -Wl,-O3 -Wl,--gc-sections  
> -Wl,--version-script,"/tc-build2/build/llvm/stage1/tools/clang/lib/Analysis/plugins/CheckerDependencyHandling/CheckerDependencyHandlingAnalyzerPlugin.exports"
>  -shared  -o lib/CheckerDependencyHandlingAnalyzerPlugin.so 
> tools/clang/lib/Analysis/plugins/CheckerDependencyHandling/CMakeFiles/CheckerDependencyHandlingAnalyzerPlugin.dir/CheckerDependencyHandling.cpp.o
>   -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a lib/libclangAnalysis.a 
> lib/libclangAST.a -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend 
> lib/libLLVMSupport.a lib/libclangASTMatchers.a lib/libclangAST.a 
> lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a lib/libLLVMRemarks.a 
> lib/libLLVMMC.a lib/libLLVMBinaryFormat.a lib/libLLVMDebugInfoCodeView.a 
> lib/libLLVMDebugInfoMSF.a lib/libLLVMSupport.a -lz -lrt -ldl -lpthread -lm 
> lib/libLLVMDemangle.a && :
> /usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerCore
> /usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerFrontend
> collect2: error: ld returned 1 exit status
> [2061/2605] Building CXX object 
> tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/CompilationDatabase.cpp.o
> [2062/2605] Linking CXX shared module lib/SampleAnalyzerPlugin.so
> FAILED: lib/SampleAnalyzerPlugin.so 
> : && /usr/bin/g++ -fPIC -O2 -march=native -mtune=native -fPIC 
> -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -w 
> -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common 
> -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG  -Wl,-z,nodelete 
> -fuse-ld=gold   -Wl,-O3 -Wl,--gc-sections  
> -Wl,--version-script,"/tc-build2/build/llvm/stage1/tools/clang/lib/Analysis/plugins/SampleAnalyzer/SampleAnalyzerPlugin.exports"
>  -shared  -o lib/SampleAnalyzerPlugin.so 
> tools/clang/lib/Analysis/plugins/SampleAnalyzer/CMakeFiles/SampleAnalyzerPlugin.dir/MainCallChecker.cpp.o
>   -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a lib/libclangAnalysis.a 
> lib/libclangAST.a -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend 
> lib/libLLVMSupport.a lib/libclangASTMatchers.a lib/libclangAST.a 
> lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a lib/libLLVMRemarks.a 
> lib/libLLVMMC.a lib/libLLVMBinaryFormat.a lib/libLLVMDebugInfoCodeView.a 
> lib/libLLVMDebugInfoMSF.a lib/libLLVMSupport.a -lz -lrt -ldl -lpthread -lm 
> lib/libLLVMDemangle.a && :
> /usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerCore
> 

[PATCH] D62445: [test] Fix plugin tests

[Nathan Chancellor via Phabricator via cfe-commits]

nathanchance added inline comments.



Comment at: cfe/trunk/lib/Analysis/plugins/CMakeLists.txt:1
+if(LLVM_ENABLE_PLUGINS)
+  add_subdirectory(SampleAnalyzer)

I think this should have a dependency on `CLANG_ENABLE_STATIC_ANALYZER` like in 
`clang/test/CMakeLists.txt`, otherwise my build (which disables 
`CLANG_ENABLE_STATIC_ANALYZER`) fails because these plugins are being added to 
the build.

```
[2058/2605] Linking CXX shared module lib/CheckerOptionHandlingAnalyzerPlugin.so
FAILED: lib/CheckerOptionHandlingAnalyzerPlugin.so 
: && /usr/bin/g++ -fPIC -O2 -march=native -mtune=native -fPIC 
-fvisibility-inlines-hidden -Werror=date-time -std=c++11 -w -fdiagnostics-color 
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual 
-fno-strict-aliasing -O3 -DNDEBUG  -Wl,-z,nodelete -fuse-ld=gold   -Wl,-O3 
-Wl,--gc-sections  
-Wl,--version-script,"/tc-build2/build/llvm/stage1/tools/clang/lib/Analysis/plugins/CheckerOptionHandling/CheckerOptionHandlingAnalyzerPlugin.exports"
 -shared  -o lib/CheckerOptionHandlingAnalyzerPlugin.so 
tools/clang/lib/Analysis/plugins/CheckerOptionHandling/CMakeFiles/CheckerOptionHandlingAnalyzerPlugin.dir/CheckerOptionHandling.cpp.o
  -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a lib/libclangAnalysis.a 
lib/libclangAST.a -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend 
lib/libLLVMSupport.a lib/libclangASTMatchers.a lib/libclangAST.a 
lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a lib/libLLVMRemarks.a 
lib/libLLVMMC.a lib/libLLVMBinaryFormat.a lib/libLLVMDebugInfoCodeView.a 
lib/libLLVMDebugInfoMSF.a lib/libLLVMSupport.a -lz -lrt -ldl -lpthread -lm 
lib/libLLVMDemangle.a && :
/usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerCore
/usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerFrontend
collect2: error: ld returned 1 exit status
[2059/2605] Building CXX object 
tools/clang/tools/clang-refactor/CMakeFiles/clang-refactor.dir/TestSupport.cpp.o
[2060/2605] Linking CXX shared module 
lib/CheckerDependencyHandlingAnalyzerPlugin.so
FAILED: lib/CheckerDependencyHandlingAnalyzerPlugin.so 
: && /usr/bin/g++ -fPIC -O2 -march=native -mtune=native -fPIC 
-fvisibility-inlines-hidden -Werror=date-time -std=c++11 -w -fdiagnostics-color 
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual 
-fno-strict-aliasing -O3 -DNDEBUG  -Wl,-z,nodelete -fuse-ld=gold   -Wl,-O3 
-Wl,--gc-sections  
-Wl,--version-script,"/tc-build2/build/llvm/stage1/tools/clang/lib/Analysis/plugins/CheckerDependencyHandling/CheckerDependencyHandlingAnalyzerPlugin.exports"
 -shared  -o lib/CheckerDependencyHandlingAnalyzerPlugin.so 
tools/clang/lib/Analysis/plugins/CheckerDependencyHandling/CMakeFiles/CheckerDependencyHandlingAnalyzerPlugin.dir/CheckerDependencyHandling.cpp.o
  -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a lib/libclangAnalysis.a 
lib/libclangAST.a -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend 
lib/libLLVMSupport.a lib/libclangASTMatchers.a lib/libclangAST.a 
lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a lib/libLLVMRemarks.a 
lib/libLLVMMC.a lib/libLLVMBinaryFormat.a lib/libLLVMDebugInfoCodeView.a 
lib/libLLVMDebugInfoMSF.a lib/libLLVMSupport.a -lz -lrt -ldl -lpthread -lm 
lib/libLLVMDemangle.a && :
/usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerCore
/usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerFrontend
collect2: error: ld returned 1 exit status
[2061/2605] Building CXX object 
tools/clang/lib/Tooling/CMakeFiles/obj.clangTooling.dir/CompilationDatabase.cpp.o
[2062/2605] Linking CXX shared module lib/SampleAnalyzerPlugin.so
FAILED: lib/SampleAnalyzerPlugin.so 
: && /usr/bin/g++ -fPIC -O2 -march=native -mtune=native -fPIC 
-fvisibility-inlines-hidden -Werror=date-time -std=c++11 -w -fdiagnostics-color 
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual 
-fno-strict-aliasing -O3 -DNDEBUG  -Wl,-z,nodelete -fuse-ld=gold   -Wl,-O3 
-Wl,--gc-sections  
-Wl,--version-script,"/tc-build2/build/llvm/stage1/tools/clang/lib/Analysis/plugins/SampleAnalyzer/SampleAnalyzerPlugin.exports"
 -shared  -o lib/SampleAnalyzerPlugin.so 
tools/clang/lib/Analysis/plugins/SampleAnalyzer/CMakeFiles/SampleAnalyzerPlugin.dir/MainCallChecker.cpp.o
  -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a lib/libclangAnalysis.a 
lib/libclangAST.a -lclangStaticAnalyzerCore -lclangStaticAnalyzerFrontend 
lib/libLLVMSupport.a lib/libclangASTMatchers.a lib/libclangAST.a 
lib/libclangLex.a lib/libclangBasic.a lib/libLLVMCore.a lib/libLLVMRemarks.a 
lib/libLLVMMC.a lib/libLLVMBinaryFormat.a lib/libLLVMDebugInfoCodeView.a 
lib/libLLVMDebugInfoMSF.a lib/libLLVMSupport.a -lz -lrt -ldl -lpthread -lm 
lib/libLLVMDemangle.a && :
/usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerCore
/usr/bin/ld.gold: error: cannot find -lclangStaticAnalyzerFrontend
collect2: error: ld returned 1 exit status
```


Repository:
  rL LLVM

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

[PATCH] D62621: [LibTooling] Add insert/remove convenience functions for creating `ASTEdit`s.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

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

Thanks for the review.

In D62621#1528714 , @ilya-biryukov 
wrote:

> Are there any corner cases with handling whitespace that we might want to 
> handle or document them if we don't handle them?
>  E.g. if the range ends up being a name of an expanded macro , it's probably 
> very easy to glue the macro name with whatever you're inserting.
>
>   #define FOO 1+2;
>   #define BAR 2+3;
>  
>   [[FOO]] // [[ ]] marks the selected range
>
>
> would `insertBefore([[FOO]], "BAR")` end up being `BARFOO` or `BAR FOO`?




In D62621#1528716 , @ilya-biryukov 
wrote:

> I guess the question also applies to `change`, although it did not occur to 
> me before.


Good questions.  The answer to both is that it depends on the `RangeSelector` 
used.  `change` itself takes exactly the range given it and modifies the source 
at that range.  Since these APIs are acting at the character level, I think it 
could be confusing to add token-level reasoning.  That said, we could add 
`RangeSelector`s and/or `TextGenerator`s that are smarter about this and 
ensure/add spaces around text as needed.  Since all changes should (in my 
opinion) be run through clang-format afterwards, there's no risk in adding 
extra whitespace.  For example, we could change `text()` to add whitespace on 
both sides of the argument, or add a new combinator `pad` which does that (and 
leave `text()` alone). So, for this example, the user would write 
`insertBefore([[FOO]], pad("BAR"))` and get `BAR FOO`.

We could similarly update `Stencil` to pad its output by default or somesuch.

WDYT?




Comment at: clang/include/clang/Tooling/Refactoring/Transformer.h:202
+
+/// Inserts \p Replacement after \p S, automatically calculating the end
+/// location of \p S.

ilya-biryukov wrote:
> Could you elaborate on what `calculating the end location of \p S` means?
> Is the fact that the end location is calculated specific to this function, 
> rather than `RangeSelector` in general?
> 
> The comment is very different from `insertBefore`, suggesting the function 
> behaves differently in practice.
> 
> 
I'm glad you bring this up, since I struggled with how best to express this.  
The point is that it handles the difference between CharRange and TokenRange 
and does the "right" thing. This kind of thing has bitten me and others in the 
past -- it's a pretty typical newbie error to mishandle the `SourceRange` of a 
node. 

That said, it is *not* doing anything more than `RangeSelector` already does, 
since `RangeSelector` is already built on `CharSourceRange` rather than 
`SourceRange`.  So, I'd be fine dropping this mention entirely, since it's 
really a property of the whole system.  That is, I could replace with
"Inserts \p Replacement after \p S, leaving the source selected by \S 
unchanged."

WDYT?

As for insertBefore -- since the beginning of a range is unambiguous, there's 
no need to say anything interesting there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62621



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

[PATCH] D62830: [WebAssembly] Support Leak Sanitizer on Emscripten

[Guanzhong Chen via Phabricator via cfe-commits]

quantum added a comment.

LSan is supposed to be linked in to replace some C library functions, and does 
not change the generated LLVM IR code, so there is nothing to actually test in 
LLVM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62830



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

r362537 - Factor out repeated code to build a DeclRefExpr and mark it referenced.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Jun  4 11:30:46 2019
New Revision: 362537

URL: http://llvm.org/viewvc/llvm-project?rev=362537=rev
Log:
Factor out repeated code to build a DeclRefExpr and mark it referenced.

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaOverload.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=362537=362536=362537=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Jun  4 11:30:46 2019
@@ -4305,16 +4305,24 @@ public:
 bool isAddressOfOperand,
 const TemplateArgumentListInfo *TemplateArgs);
 
-  ExprResult BuildDeclRefExpr(ValueDecl *D, QualType Ty,
-  ExprValueKind VK,
-  SourceLocation Loc,
-  const CXXScopeSpec *SS = nullptr);
-  ExprResult
+  DeclRefExpr *BuildDeclRefExpr(ValueDecl *D, QualType Ty, ExprValueKind VK,
+SourceLocation Loc,
+const CXXScopeSpec *SS = nullptr);
+  DeclRefExpr *
   BuildDeclRefExpr(ValueDecl *D, QualType Ty, ExprValueKind VK,
const DeclarationNameInfo ,
const CXXScopeSpec *SS = nullptr,
NamedDecl *FoundD = nullptr,
+   SourceLocation TemplateKWLoc = SourceLocation(),
+   const TemplateArgumentListInfo *TemplateArgs = nullptr);
+  DeclRefExpr *
+  BuildDeclRefExpr(ValueDecl *D, QualType Ty, ExprValueKind VK,
+   const DeclarationNameInfo ,
+   NestedNameSpecifierLoc NNS,
+   NamedDecl *FoundD = nullptr,
+   SourceLocation TemplateKWLoc = SourceLocation(),
const TemplateArgumentListInfo *TemplateArgs = nullptr);
+
   ExprResult
   BuildAnonymousStructUnionMemberReference(
   const CXXScopeSpec ,

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=362537=362536=362537=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Tue Jun  4 11:30:46 2019
@@ -11475,7 +11475,7 @@ class RefBuilder: public ExprBuilder {
 
 public:
   Expr *build(Sema , SourceLocation Loc) const override {
-return assertNotNull(S.BuildDeclRefExpr(Var, VarType, VK_LValue, 
Loc).get());
+return assertNotNull(S.BuildDeclRefExpr(Var, VarType, VK_LValue, Loc));
   }
 
   RefBuilder(VarDecl *Var, QualType VarType)
@@ -12877,7 +12877,7 @@ void Sema::DefineImplicitLambdaToFunctio
 
   // Construct the body of the conversion function { return __invoke; }.
   Expr *FunctionRef = BuildDeclRefExpr(Invoker, Invoker->getType(),
-   VK_LValue, Conv->getLocation()).get();
+   VK_LValue, Conv->getLocation());
   assert(FunctionRef && "Can't refer to __invoke function?");
   Stmt *Return = BuildReturnStmt(Conv->getLocation(), FunctionRef).get();
   Conv->setBody(CompoundStmt::Create(Context, Return, Conv->getLocation(),

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=362537=362536=362537=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Tue Jun  4 11:30:46 2019
@@ -1762,7 +1762,7 @@ Sema::ActOnStringLiteral(ArrayRef
   llvm_unreachable("unexpected literal operator lookup result");
 }
 
-ExprResult
+DeclRefExpr *
 Sema::BuildDeclRefExpr(ValueDecl *D, QualType Ty, ExprValueKind VK,
SourceLocation Loc,
const CXXScopeSpec *SS) {
@@ -1770,36 +1770,33 @@ Sema::BuildDeclRefExpr(ValueDecl *D, Qua
   return BuildDeclRefExpr(D, Ty, VK, NameInfo, SS);
 }
 
+DeclRefExpr *
+Sema::BuildDeclRefExpr(ValueDecl *D, QualType Ty, ExprValueKind VK,
+   const DeclarationNameInfo ,
+   const CXXScopeSpec *SS, NamedDecl *FoundD,
+   SourceLocation TemplateKWLoc,
+   const TemplateArgumentListInfo *TemplateArgs) {
+  NestedNameSpecifierLoc NNS =
+  SS ? SS->getWithLocInContext(Context) : NestedNameSpecifierLoc();
+  return BuildDeclRefExpr(D, Ty, VK, NameInfo, NNS, FoundD, TemplateKWLoc,
+  TemplateArgs);
+}
+
 /// BuildDeclRefExpr - Build an expression that references a
 /// declaration that does not require a closure capture.
-ExprResult
+DeclRefExpr *
 Sema::BuildDeclRefExpr(ValueDecl *D, 

[PATCH] D62363: [X86] Enable intrinsics that convert float and bf16 data to each other

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon accepted this revision.
RKSimon added a comment.

Yup, doxygen LGTM - cheers




Comment at: lib/Headers/avx512bf16intrin.h:33
+
+/// Convert One BF16 Data to One Single Data.
+///

Single Float Data


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

https://reviews.llvm.org/D62363



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

[PATCH] D62363: [X86] Enable intrinsics that convert float and bf16 data to each other

[Craig Topper via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D62363



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

[PATCH] D53157: Teach the IRBuilder about constrained fadd and friends

[Kevin P. Neal via Phabricator via cfe-commits]

kpn updated this revision to Diff 202987.
kpn added a comment.

Address the rest of the review comments, hopefully.

I've lifted from mibintc's D62730  the enums 
for the exception behavior and rounding modes. The rest of that set of changes 
is better left to a separate ticket after all.

Since I now have those requested enums I've changed the relevant public 
functions to take them instead of an MDNode*.

There is no standalone or comprehensive IRBuilder documentation that I could 
find. I hope the references in comments back to the LangRef are good enough. I 
used the exact language from it to make it easier to reference said doc.


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

https://reviews.llvm.org/D53157

Files:
  include/llvm/IR/IRBuilder.h
  unittests/IR/IRBuilderTest.cpp

Index: unittests/IR/IRBuilderTest.cpp
===
--- unittests/IR/IRBuilderTest.cpp
+++ unittests/IR/IRBuilderTest.cpp
@@ -122,6 +122,70 @@
   EXPECT_FALSE(II->hasNoNaNs());
 }
 
+TEST_F(IRBuilderTest, ConstrainedFP) {
+  IRBuilder<> Builder(BB);
+  Value *V;
+  CallInst *Call;
+  IntrinsicInst *II;
+
+  V = Builder.CreateLoad(GV);
+
+  // See if we get constrained intrinsics instead of non-constrained
+  // instructions.
+  Builder.setIsFPConstrained(true);
+
+  V = Builder.CreateFAdd(V, V);
+  ASSERT_TRUE(isa(V));
+  II = cast(V);
+  EXPECT_EQ(II->getIntrinsicID(), Intrinsic::experimental_constrained_fadd);
+
+  V = Builder.CreateFSub(V, V);
+  ASSERT_TRUE(isa(V));
+  II = cast(V);
+  EXPECT_EQ(II->getIntrinsicID(), Intrinsic::experimental_constrained_fsub);
+
+  V = Builder.CreateFMul(V, V);
+  ASSERT_TRUE(isa(V));
+  II = cast(V);
+  EXPECT_EQ(II->getIntrinsicID(), Intrinsic::experimental_constrained_fmul);
+  
+  V = Builder.CreateFDiv(V, V);
+  ASSERT_TRUE(isa(V));
+  II = cast(V);
+  EXPECT_EQ(II->getIntrinsicID(), Intrinsic::experimental_constrained_fdiv);
+  
+  V = Builder.CreateFRem(V, V);
+  ASSERT_TRUE(isa(V));
+  II = cast(V);
+  EXPECT_EQ(II->getIntrinsicID(), Intrinsic::experimental_constrained_frem);
+
+  // Verify the codepaths for setting and overriding the default metadata.
+  V = Builder.CreateFAdd(V, V);
+  ASSERT_TRUE(isa(V));
+  auto *CII = cast(V);
+  ASSERT_TRUE(CII->getExceptionBehavior() == ConstrainedFPIntrinsic::ebStrict);
+  ASSERT_TRUE(CII->getRoundingMode() == ConstrainedFPIntrinsic::rmDynamic);
+
+  Builder.setDefaultConstrainedExcept(IRBuilderBase::CE_Ignore);
+  Builder.setDefaultConstrainedRounding(IRBuilderBase::CR_Upward);
+  V = Builder.CreateFAdd(V, V);
+  CII = cast(V);
+  ASSERT_TRUE(CII->getExceptionBehavior() == ConstrainedFPIntrinsic::ebIgnore);
+  ASSERT_TRUE(CII->getRoundingMode() == ConstrainedFPIntrinsic::rmUpward);
+
+  // Now override the defaults.
+  Call = Builder.CreateConstrainedFPBinOp(
+Intrinsic::experimental_constrained_fadd, V, V, nullptr, "",
+IRBuilderBase::CR_Dynamic, IRBuilderBase::CE_Strict);
+  CII = cast(Call);
+  EXPECT_EQ(CII->getIntrinsicID(), Intrinsic::experimental_constrained_fadd);
+  ASSERT_TRUE(CII->getExceptionBehavior() == ConstrainedFPIntrinsic::ebStrict);
+  ASSERT_TRUE(CII->getRoundingMode() == ConstrainedFPIntrinsic::rmDynamic);
+
+  Builder.CreateRetVoid();
+  EXPECT_FALSE(verifyModule(*M));
+}
+
 TEST_F(IRBuilderTest, Lifetime) {
   IRBuilder<> Builder(BB);
   AllocaInst *Var1 = Builder.CreateAlloca(Builder.getInt8Ty());
Index: include/llvm/IR/IRBuilder.h
===
--- include/llvm/IR/IRBuilder.h
+++ include/llvm/IR/IRBuilder.h
@@ -88,6 +88,30 @@
 class IRBuilderBase {
   DebugLoc CurDbgLocation;
 
+public:
+  /// Specifies the required exception behavior. This is only used when
+  /// when constrained floating point is enabled. See the LLVM Language
+  /// Reference Manual for details.
+  enum ConstrainedExceptKind {
+CE_Unspecified, ///< Use as a placeholder to not affect exception
+///< behavior.
+CE_Strict,  ///< This corresponds to "fpexcept.strict".
+CE_Ignore,  ///< This corresponds to "fpexcept.ignore".
+CE_MayTrap  ///< This corresponds to "fpexcept.maytrap".
+  };
+  /// Specifies the rounding mode to be assumed. This is only used when
+  /// when constrained floating point is enabled. See the LLVM Language
+  /// Reference Manual for details.
+  enum ConstrainedRoundingKind {
+CR_Unspecified, ///< Use as a placeholder to not affect rounding
+///< behavior.
+CR_Dynamic, ///< This corresponds to "fpround.dynamic".
+CR_ToNearest,   ///< This corresponds to "fpround.tonearest".
+CR_Downward,///< This corresponds to "fpround.downward".
+CR_Upward,  ///< This corresponds to "fpround.upward".
+CR_ToZero   ///< This corresponds to "fpround.tozero".
+  };
+
 protected:
   BasicBlock *BB;
   BasicBlock::iterator InsertPt;
@@ -96,12 +120,18 @@
   MDNode 

[PATCH] D62638: [analyzer] A Python script to prettify the ExplodedGraph dumps.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Thanks!! Will fix as soon as i get to my desktop.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62638



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

[PATCH] D62850: [X86] Fix builtins-x86.c test where it wasn't using immediates. NFC

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D62850#1529588 , @russell.gallop 
wrote:

> > We support non immediate on these because gcc does.
>
> Thanks. Your comment crossed in mid-air. Okay, so is this test worth 
> changing, or should it have both versions (immediate and non-immediate)?


Both, i guess, with a comment as to why they are the way they are.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62850



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

[PATCH] D61967: [clang-tidy] Add a close-on-exec check on pipe() in Android module.

[Jian Cai via Phabricator via cfe-commits]

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

Update test function names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61967

Files:
  clang-tools-extra/clang-tidy/android/AndroidTidyModule.cpp
  clang-tools-extra/clang-tidy/android/CMakeLists.txt
  clang-tools-extra/clang-tidy/android/CloexecPipeCheck.cpp
  clang-tools-extra/clang-tidy/android/CloexecPipeCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/android-cloexec-pipe.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/android-cloexec-pipe.cpp

Index: clang-tools-extra/test/clang-tidy/android-cloexec-pipe.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/android-cloexec-pipe.cpp
@@ -0,0 +1,27 @@
+// RUN: %check_clang_tidy %s android-cloexec-pipe %t
+
+extern "C" int pipe(int pipefd[2]);
+
+void warning() {
+  int pipefd[2];
+  pipe(pipefd);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer pipe2() with O_CLOEXEC to avoid leaking file descriptors to child processes [android-cloexec-pipe]
+  // CHECK-FIXES: pipe2(pipefd, O_CLOEXEC);
+}
+
+namespace i {
+int pipe(int pipefd[2]);
+void noWarningInNamespace() {
+  int pipefd[2];
+  pipe(pipefd);
+}
+} // namespace i
+
+class C {
+public:
+  int pipe(int pipefd[2]);
+  void noWarningForMemberFunction() {
+int pipefd[2];
+pipe(pipefd);
+  }
+};
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -32,6 +32,7 @@
android-cloexec-inotify-init1
android-cloexec-memfd-create
android-cloexec-open
+   android-cloexec-pipe
android-cloexec-socket
android-comparison-in-temp-failure-retry
boost-use-to-string
Index: clang-tools-extra/docs/clang-tidy/checks/android-cloexec-pipe.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/android-cloexec-pipe.rst
@@ -0,0 +1,20 @@
+.. title:: clang-tidy - android-cloexec-pipe
+
+android-cloexec-pipe
+
+
+This check detects usage of ``pipe()``. Using ``pipe()`` is not recommended, ``pipe2()`` is the
+suggested replacement. The check also adds the O_CLOEXEC flag that marks the file descriptor to
+be closed in child processes. Without this flag a sensitive file descriptor can be leaked to a
+child process, potentially into a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  pipe(pipefd);
+
+Suggested replacement:
+
+.. code-block:: c++
+  pipe2(pipefd, O_CLOEXEC);
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -101,6 +101,11 @@
   Finds and fixes ``absl::Time`` subtraction expressions to do subtraction
   in the Time domain instead of the numeric domain.
 
+- New :doc:`android-cloexec-pipe
+  ` check.
+
+  This check detects usage of ``pipe()``.
+
 - New :doc:`bugprone-unhandled-self-assignment
   ` check.
 
Index: clang-tools-extra/clang-tidy/android/CloexecPipeCheck.h
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/android/CloexecPipeCheck.h
@@ -0,0 +1,34 @@
+//===--- CloexecPipeCheck.h - clang-tidy-*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_PIPE_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_PIPE_H
+
+#include "CloexecCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+/// Suggests to replace calls to pipe() with calls to pipe2().
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/android-cloexec-pipe.html
+class CloexecPipeCheck : public CloexecCheck {
+public:
+  CloexecPipeCheck(StringRef Name, ClangTidyContext *Context)
+  : CloexecCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+};
+
+} // namespace android
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_PIPE_H
Index: clang-tools-extra/clang-tidy/android/CloexecPipeCheck.cpp
===
--- /dev/null
+++ 

[PATCH] D62850: [X86] Fix builtins-x86.c test where it wasn't using immediates. NFC

[Russell Gallop via Phabricator via cfe-commits]

russell.gallop added a comment.

> We support non immediate on these because gcc does.

Thanks. Your comment crossed in mid-air. Okay, so is this test worth changing, 
or should it have both versions (immediate and non-immediate)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62850



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

[PATCH] D62850: [X86] Fix builtins-x86.c test where it wasn't using immediates. NFC

[Russell Gallop via Phabricator via cfe-commits]

russell.gallop added a comment.

> I'll have a look and see if there is a reason why these don't fail in the 
> same way (which would make the test fail in it's current form).

These do not have the "I" prefix (//  I   -> Required to constant fold to an 
integer constant expression.) in BuiltinsX86.def which is probably why they 
don't error.

Checking against the LLVM side, there is a comment in IntrinsicsX86.td:

  // Oddly these don't require an immediate due to a gcc compatibility issue.
  def int_x86_mmx_pslli_w : GCCBuiltin<"__builtin_ia32_psllwi">,
  Intrinsic<[llvm_x86mmx_ty], [llvm_x86mmx_ty,
 llvm_i32_ty], [IntrNoMem]>;

That comment was added recently by Craig in r355993. So it looks like they 
should work with either for compatibility.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62850



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

[PATCH] D62638: [analyzer] A Python script to prettify the ExplodedGraph dumps.

[Csaba Dabis via Phabricator via cfe-commits]

Charusso added inline comments.



Comment at: cfe/trunk/utils/analyzer/exploded-graph-rewriter.py:1
+#!/usr/bin/env python
+

```
# something else then
#
#==- exploded-graph-rewriter.py - Simplifies the ExplodedGraph -*- python -*-==#
#
# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
# See https://llvm.org/LICENSE.txt for license information.
# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
#
#======#
```
Whoops!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62638



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

[PATCH] D62049: [clang-tidy] Add a close-on-exec check on pipe2() in Android module.

[Jian Cai via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/test/clang-tidy/android-cloexec-pipe2.cpp:20
+  pipe2(pipefd, O_NONBLOCK);
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: 'pipe2' should use O_CLOEXEC 
where possible [android-cloexec-pipe2]
+  // CHECK-FIXES: pipe2(pipefd, O_NONBLOCK | O_CLOEXEC);

gribozavr wrote:
> jcai19 wrote:
> > gribozavr wrote:
> > > Same comment about the message as in D61967 -- the message should briefly 
> > > explain why the user should make this change. Users tend to ignore 
> > > warnings they don't understand.
> > > 
> > > "pipe2 should be called with O_CLOEXEC to avoid leaking file descriptors 
> > > to child processes"
> > It appeared to me that there was no easy way to change the warning message 
> > due to the way insertMacroFlag is implemented (called in  
> > CloexecPipe2Check::check(...) to add O_CLOEXEC flag when necessary). The 
> > function always issue a warning in the format of "%0 should use %1 where 
> > possible". So unless we parameterize the warning string (which could be 
> > solved by a different code change), we might end up implementing a similar 
> > function with different warning message, which creates extra work if we 
> > need to modify insertMacroFlag in the future. I am new to Clang so please 
> > let me know if there is a better way to udpate the warning message.
> I don't see an issue with parameterizing insertMacroFlag -- the current 
> message that it produces is not descriptive enough anyway, users tend to 
> ignore such messages.
I agree. But my point is insertMacroFlag is used by several other checks. 
Shouldn't we parameterize the warning message and update these checks together 
in a separate change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62049



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

[PATCH] D60974: Clang IFSO driver action.

[Puyan Lotfi via Phabricator via cfe-commits]

plotfi updated this revision to Diff 202976.
plotfi added a comment.

Adding a test for inheritance and constructors/destroctors. Also addressing 
feedback from @alexshap


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60974

Files:
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/Types.def
  clang/include/clang/Frontend/FrontendActions.h
  clang/include/clang/Frontend/FrontendOptions.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CMakeLists.txt
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp
  clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  clang/test/InterfaceStubs/bad-format.cpp
  clang/test/InterfaceStubs/class-template-specialization.cpp
  clang/test/InterfaceStubs/externstatic.c
  clang/test/InterfaceStubs/function-template-specialization.cpp
  clang/test/InterfaceStubs/inline.c
  clang/test/InterfaceStubs/inline.h
  clang/test/InterfaceStubs/object.cpp
  clang/test/InterfaceStubs/public-hidden.cpp
  clang/test/InterfaceStubs/template-namespace-function.cpp
  clang/test/InterfaceStubs/virtual.cpp
  clang/test/InterfaceStubs/visibility.cpp
  clang/test/InterfaceStubs/weak.cpp

Index: clang/test/InterfaceStubs/weak.cpp
===
--- /dev/null
+++ clang/test/InterfaceStubs/weak.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang -target x86_64-linux-gnu -o - -emit-interface-stubs \
+// RUN: -interface-stub-version=experimental-tapi-elf-v1 %s | \
+// RUN: FileCheck %s
+
+// RUN: %clang -target x86_64-linux-gnu -o - -emit-interface-stubs \
+// RUN: -interface-stub-version=experimental-yaml-elf-v1 %s | \
+// RUN: FileCheck --check-prefix=CHECK-YAML %s
+
+// RUN: %clang -target x86_64-unknown-linux-gnu -o - -c %s | llvm-nm - 2>&1 | \
+// RUN: FileCheck -check-prefix=CHECK-SYMBOLS %s
+
+// CHECK: Symbols:
+// CHECK-NEXT:  _Z8weakFuncv: { Type: Func, Weak: true }
+// CHECK-NEXT:  _Z10strongFuncv: { Type: Func }
+
+// CHECK-YAML: Symbols:
+// CHECK-YAML-NEXT:   - Name:_Z8weakFuncv
+// CHECK-YAML-NEXT: Type:STT_FUNC
+// CHECK-YAML-NEXT: Binding: STB_WEAK
+// CHECK-YAML-NEXT:   - Name:_Z10strongFuncv
+// CHECK-YAML-NEXT: Type:STT_FUNC
+// CHECK-YAML-NEXT: Binding: STB_GLOBAL
+
+// CHECK-SYMBOLS: _Z10strongFuncv
+// CHECK-SYMBOLS: _Z8weakFuncv
+__attribute__((weak)) void weakFunc() {}
+int strongFunc() { return 42; }
Index: clang/test/InterfaceStubs/visibility.cpp
===
--- /dev/null
+++ clang/test/InterfaceStubs/visibility.cpp
@@ -0,0 +1,35 @@
+// RUN: %clang -target x86_64-unknown-linux-gnu -o - -emit-interface-stubs \
+// RUN: -interface-stub-version=experimental-tapi-elf-v1 -fvisibility=hidden \
+// RUN: %s | FileCheck --check-prefix=CHECK-CMD-HIDDEN %s
+
+// RUN: %clang -target x86_64-unknown-linux-gnu -o - -emit-interface-stubs \
+// RUN: -interface-stub-version=experimental-yaml-elf-v1 -fvisibility=hidden \
+// RUN: %s | FileCheck --check-prefix=CHECK-CMD-HIDDEN %s
+
+// RUN: %clang -target x86_64-unknown-linux-gnu -o - -emit-interface-stubs \
+// RUN: -interface-stub-version=experimental-tapi-elf-v1 %s | FileCheck %s
+
+// RUN: %clang -target x86_64-unknown-linux-gnu -o - -emit-interface-stubs \
+// RUN: -interface-stub-version=experimental-yaml-elf-v1 %s | FileCheck %s
+
+// RUN: %clang -target x86_64-unknown-linux-gnu -o - -c %s | llvm-readelf -s - 2>&1 | \
+// RUN: FileCheck -check-prefix=CHECK-SYMBOLS %s
+
+// Always Be Hidden:
+// CHECK-CMD-HIDDEN-NOT: _Z6hiddenv
+// CHECK-NOT: _Z6hiddenv
+__attribute__((visibility("hidden"))) void hidden() {}
+
+// Always Be Visible:
+// CHECK-CMD-HIDDEN: _Z9nothiddenv
+// CHECK: _Z9nothiddenv
+__attribute__((visibility("default"))) void nothidden() {}
+
+// Do Whatever -fvisibility says:
+// CHECK-CMD-HIDDEN-NOT: _Z10cmdVisiblev
+// CHECK: _Z10cmdVisiblev
+void cmdVisible() {}
+
+// CHECK-SYMBOLS: DEFAULT{{.*}} _Z10cmdVisiblev
+// CHECK-SYMBOLS: HIDDEN {{.*}} _Z6hiddenv
+// CHECK-SYMBOLS: DEFAULT{{.*}} _Z9nothiddenv
Index: clang/test/InterfaceStubs/virtual.cpp
===
--- /dev/null
+++ clang/test/InterfaceStubs/virtual.cpp
@@ -0,0 +1,38 @@
+// RUN: %clang -target x86_64-unknown-linux-gnu -o - -emit-interface-stubs \
+// RUN: -interface-stub-version=experimental-tapi-elf-v1 %s | \
+// RUN: FileCheck -check-prefix=CHECK-TAPI %s
+// RUN: %clang -target x86_64-unknown-linux-gnu -o - -c %s | \
+// RUN: llvm-readelf -s - 2>&1 | FileCheck -check-prefix=CHECK-SYMBOLS %s
+
+#define HIDDEN  __attribute__((__visibility__(("hidden"
+#define DEFAULT __attribute__((__visibility__(("default"
+
+// CHECK-TAPI-NOT: _ZNK1Q5func1Ev
+// CHECK-TAPI-NOT: _ZNK1Q5func2Ev
+// CHECK-SYMBOLS: NOTYPE  GLOBAL HIDDEN   {{.*}} 

r362531 - PR42104: Support instantiations of lambdas that implicitly capture

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Jun  4 10:17:20 2019
New Revision: 362531

URL: http://llvm.org/viewvc/llvm-project?rev=362531=rev
Log:
PR42104: Support instantiations of lambdas that implicitly capture
packs.

Two changes:
 * Track odr-use via FunctionParmPackExprs to properly handle dependent
   odr-uses of packs in generic lambdas.
 * Do not instantiate implicit captures; instead, regenerate them by
   instantiating the body of the lambda. This is necessary to
   distinguish between cases where only one element of a pack is
   captured and cases where the entire pack is captured.

This reinstates r362358 (reverted in r362375) with a fix for an
uninitialized variable use in UpdateMarkingForLValueToRValue.

Added:
cfe/trunk/test/SemaTemplate/lambda-capture-pack.cpp
Modified:
cfe/trunk/include/clang/Sema/ScopeInfo.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/ScopeInfo.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/test/SemaCXX/cxx1y-generic-lambdas-capturing.cpp

Modified: cfe/trunk/include/clang/Sema/ScopeInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/ScopeInfo.h?rev=362531=362530=362531=diff
==
--- cfe/trunk/include/clang/Sema/ScopeInfo.h (original)
+++ cfe/trunk/include/clang/Sema/ScopeInfo.h Tue Jun  4 10:17:20 2019
@@ -15,6 +15,7 @@
 #define LLVM_CLANG_SEMA_SCOPEINFO_H
 
 #include "clang/AST/Expr.h"
+#include "clang/AST/ExprCXX.h"
 #include "clang/AST/Type.h"
 #include "clang/Basic/CapturedStmt.h"
 #include "clang/Basic/LLVM.h"
@@ -913,7 +914,8 @@ public:
   ///   };
   /// }
   void addPotentialCapture(Expr *VarExpr) {
-assert(isa(VarExpr) || isa(VarExpr));
+assert(isa(VarExpr) || isa(VarExpr) ||
+   isa(VarExpr));
 PotentiallyCapturingExprs.push_back(VarExpr);
   }
 
@@ -965,13 +967,15 @@ public:
   ///  building such a node. So we need a rule that anyone can implement and 
get
   ///  exactly the same result".
   void markVariableExprAsNonODRUsed(Expr *CapturingVarExpr) {
-assert(isa(CapturingVarExpr)
-|| isa(CapturingVarExpr));
+assert(isa(CapturingVarExpr) ||
+   isa(CapturingVarExpr) ||
+   isa(CapturingVarExpr));
 NonODRUsedCapturingExprs.insert(CapturingVarExpr);
   }
   bool isVariableExprMarkedAsNonODRUsed(Expr *CapturingVarExpr) const {
-assert(isa(CapturingVarExpr)
-  || isa(CapturingVarExpr));
+assert(isa(CapturingVarExpr) ||
+   isa(CapturingVarExpr) ||
+   isa(CapturingVarExpr));
 return NonODRUsedCapturingExprs.count(CapturingVarExpr);
   }
   void removePotentialCapture(Expr *E) {
@@ -993,9 +997,8 @@ public:
   PotentialThisCaptureLocation.isValid();
   }
 
-  // When passed the index, returns the VarDecl and Expr associated
-  // with the index.
-  void getPotentialVariableCapture(unsigned Idx, VarDecl *, Expr *) const;
+  void visitPotentialCaptures(
+  llvm::function_ref Callback) const;
 };
 
 FunctionScopeInfo::WeakObjectProfileTy::WeakObjectProfileTy()

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=362531=362530=362531=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Jun  4 10:17:20 2019
@@ -4181,6 +4181,7 @@ public:
   void MarkVariableReferenced(SourceLocation Loc, VarDecl *Var);
   void MarkDeclRefReferenced(DeclRefExpr *E, const Expr *Base = nullptr);
   void MarkMemberReferenced(MemberExpr *E);
+  void MarkFunctionParmPackReferenced(FunctionParmPackExpr *E);
   void MarkCaptureUsedInEnclosingContext(VarDecl *Capture, SourceLocation Loc,
  unsigned CapturingScopeIndex);
 

Modified: cfe/trunk/lib/Sema/ScopeInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/ScopeInfo.cpp?rev=362531=362530=362531=diff
==
--- cfe/trunk/lib/Sema/ScopeInfo.cpp (original)
+++ cfe/trunk/lib/Sema/ScopeInfo.cpp Tue Jun  4 10:17:20 2019
@@ -229,20 +229,20 @@ bool CapturingScopeInfo::isVLATypeCaptur
   return false;
 }
 
-void LambdaScopeInfo::getPotentialVariableCapture(unsigned Idx, VarDecl *,
-  Expr *) const {
-  assert(Idx < getNumPotentialVariableCaptures() &&
- "Index of potential capture must be within 0 to less than the "
- "number of captures!");
-  E = PotentiallyCapturingExprs[Idx];
-  if (DeclRefExpr *DRE = dyn_cast(E))
-VD = dyn_cast(DRE->getFoundDecl());
-  else if (MemberExpr *ME = dyn_cast(E))
-VD = dyn_cast(ME->getMemberDecl());
-  else
-llvm_unreachable("Only DeclRefExprs or MemberExprs 

r362530 - [Syntax] Do not depend on llvm targets for Syntax tests. NFC

[Ilya Biryukov via cfe-commits]

Author: ibiryukov
Date: Tue Jun  4 10:15:48 2019
New Revision: 362530

URL: http://llvm.org/viewvc/llvm-project?rev=362530=rev
Log:
[Syntax] Do not depend on llvm targets for Syntax tests. NFC

They are not required and only slow down the build.

Modified:
cfe/trunk/unittests/Tooling/Syntax/CMakeLists.txt

Modified: cfe/trunk/unittests/Tooling/Syntax/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/Syntax/CMakeLists.txt?rev=362530=362529=362530=diff
==
--- cfe/trunk/unittests/Tooling/Syntax/CMakeLists.txt (original)
+++ cfe/trunk/unittests/Tooling/Syntax/CMakeLists.txt Tue Jun  4 10:15:48 2019
@@ -1,5 +1,4 @@
 set(LLVM_LINK_COMPONENTS
-  ${LLVM_TARGETS_TO_BUILD}
   Support
   )
 


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

[PATCH] D62850: [X86] Fix builtins-x86.c test where it wasn't using immediates. NFC

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

We support non immediate on these because gcc does.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62850



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

[PATCH] D62850: [X86] Fix builtins-x86.c test where it wasn't using immediates. NFC

[Russell Gallop via Phabricator via cfe-commits]

russell.gallop added a comment.

> Then the test should be failing? Or is the current form also legal?

Hmm, __builtin_ia32_insertps128() errors if you pass a variable, but these 
don't (e.g.):
mytest.c:122:13: error: argument to '__builtin_ia32_insertps128' must be a 
constant integer

  tmp_V4f = __builtin_ia32_insertps128(tmp_V4f, tmp_V4f, tmp_i);

I'll have a look and see if there is a reason why these don't fail in the same 
way (which would make the test fail in it's current form).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62850



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

[PATCH] D62643: [CodeGen][ObjC] Convert '[self alloc]' in a class method to 'objc_alloc(self)'

[Akira Hatanaka via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
ahatanak marked 2 inline comments as done.
Closed by commit rL362521: [CodeGen][ObjC] Convert [self alloc] in 
a class method to a call to (authored by ahatanak, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D62643?vs=202821=202959#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D62643

Files:
  cfe/trunk/lib/CodeGen/CGObjC.cpp
  cfe/trunk/test/CodeGenObjC/convert-messages-to-runtime-calls.m
  cfe/trunk/test/CodeGenObjC/objc-alloc-init.m

Index: cfe/trunk/test/CodeGenObjC/objc-alloc-init.m
===
--- cfe/trunk/test/CodeGenObjC/objc-alloc-init.m
+++ cfe/trunk/test/CodeGenObjC/objc-alloc-init.m
@@ -23,14 +23,20 @@
 
 @interface Y : X
 +(void)meth;
+-(void)instanceMeth;
 @end
 
 @implementation Y
 +(void)meth {
   [[self alloc] init];
+  // OPTIMIZED: call i8* @objc_alloc_init(
+  // NOT_OPTIMIZED: call i8* @objc_alloc(
+}
+-(void)instanceMeth {
   // EITHER-NOT: call i8* @objc_alloc
   // EITHER: call {{.*}} @objc_msgSend
   // EITHER: call {{.*}} @objc_msgSend
+  [[self alloc] init];
 }
 @end
 
Index: cfe/trunk/test/CodeGenObjC/convert-messages-to-runtime-calls.m
===
--- cfe/trunk/test/CodeGenObjC/convert-messages-to-runtime-calls.m
+++ cfe/trunk/test/CodeGenObjC/convert-messages-to-runtime-calls.m
@@ -150,6 +150,34 @@
   return [c retain];
 }
 
+@interface TestSelf
++ (instancetype)alloc;
++ (instancetype)allocWithZone:(void*)zone;
++ (id)classMeth;
+- (id)instanceMeth;
+@end
+
+@implementation TestSelf
+// CHECK-LABEL: define internal i8* @"\01+[TestSelf classMeth]"(
++ (id)classMeth {
+  // MSGS: {{call.*@objc_msgSend}}
+  // MSGS: {{call.*@objc_msgSend}}
+  // CALLS: {{call.*@objc_allocWithZone\(}}
+  // CALLS: {{call.*@objc_alloc\(}}
+  [self allocWithZone:nil];
+  return [self alloc];
+}
+// CHECK-LABEL: define internal i8* @"\01-[TestSelf instanceMeth]"(
+- (id)instanceMeth {
+  // MSGS: {{call.*@objc_msgSend}}
+  // MSGS: {{call.*@objc_msgSend}}
+  // CALLS: {{call.*@objc_msgSend}}
+  // CALLS: {{call.*@objc_msgSend}}
+  [self allocWithZone:nil];
+  return [self alloc];
+}
+@end
+
 @interface NSString : NSObject
 + (void)retain_self;
 - (void)retain_super;
Index: cfe/trunk/lib/CodeGen/CGObjC.cpp
===
--- cfe/trunk/lib/CodeGen/CGObjC.cpp
+++ cfe/trunk/lib/CodeGen/CGObjC.cpp
@@ -383,10 +383,12 @@
 if (isClassMessage &&
 Runtime.shouldUseRuntimeFunctionsForAlloc() &&
 ResultType->isObjCObjectPointerType()) {
-// [Foo alloc] -> objc_alloc(Foo)
+// [Foo alloc] -> objc_alloc(Foo) or
+// [self alloc] -> objc_alloc(self)
 if (Sel.isUnarySelector() && Sel.getNameForSlot(0) == "alloc")
   return CGF.EmitObjCAlloc(Receiver, CGF.ConvertType(ResultType));
-// [Foo allocWithZone:nil] -> objc_allocWithZone(Foo)
+// [Foo allocWithZone:nil] -> objc_allocWithZone(Foo) or
+// [self allocWithZone:nil] -> objc_allocWithZone(self)
 if (Sel.isKeywordSelector() && Sel.getNumArgs() == 1 &&
 Args.size() == 1 && Args.front().getType()->isPointerType() &&
 Sel.getNameForSlot(0) == "allocWithZone") {
@@ -444,22 +446,38 @@
   Sel.getNameForSlot(0) != "init")
 return None;
 
-  // Okay, this is '[receiver init]', check if 'receiver' is '[cls alloc]'.
+  // Okay, this is '[receiver init]', check if 'receiver' is '[cls alloc]' or
+  // we are in an ObjC class method and 'receiver' is '[self alloc]'.
   auto *SubOME =
-  dyn_cast(OME->getInstanceReceiver()->IgnoreParens());
+  dyn_cast(OME->getInstanceReceiver()->IgnoreParenCasts());
   if (!SubOME)
 return None;
   Selector SubSel = SubOME->getSelector();
-  if (SubOME->getReceiverKind() != ObjCMessageExpr::Class ||
-  !SubOME->getType()->isObjCObjectPointerType() ||
+
+  // Check if we are in an ObjC class method and the receiver expression is
+  // 'self'.
+  const Expr *SelfInClassMethod = nullptr;
+  if (const auto *CurMD = dyn_cast_or_null(CGF.CurFuncDecl))
+if (CurMD->isClassMethod())
+  if ((SelfInClassMethod = SubOME->getInstanceReceiver()))
+if (!SelfInClassMethod->isObjCSelfExpr())
+  SelfInClassMethod = nullptr;
+
+  if ((SubOME->getReceiverKind() != ObjCMessageExpr::Class &&
+   !SelfInClassMethod) || !SubOME->getType()->isObjCObjectPointerType() ||
   !SubSel.isUnarySelector() || SubSel.getNameForSlot(0) != "alloc")
 return None;
 
-  QualType ReceiverType = SubOME->getClassReceiver();
-  const ObjCObjectType *ObjTy = ReceiverType->getAs();
-  const ObjCInterfaceDecl *ID = ObjTy->getInterface();
-  assert(ID && "null interface should be impossible here");
-  llvm::Value 

r362521 - [CodeGen][ObjC] Convert '[self alloc]' in a class method to a call to

[Akira Hatanaka via cfe-commits]

Author: ahatanak
Date: Tue Jun  4 09:29:58 2019
New Revision: 362521

URL: http://llvm.org/viewvc/llvm-project?rev=362521=rev
Log:
[CodeGen][ObjC] Convert '[self alloc]' in a class method to a call to
'objc_alloc(self)'

Also convert '[[self alloc] init]' in a class method to a call to
'objc_alloc_init(self)'.

rdar://problem/50855121

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

Modified:
cfe/trunk/lib/CodeGen/CGObjC.cpp
cfe/trunk/test/CodeGenObjC/convert-messages-to-runtime-calls.m
cfe/trunk/test/CodeGenObjC/objc-alloc-init.m

Modified: cfe/trunk/lib/CodeGen/CGObjC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjC.cpp?rev=362521=362520=362521=diff
==
--- cfe/trunk/lib/CodeGen/CGObjC.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjC.cpp Tue Jun  4 09:29:58 2019
@@ -383,10 +383,12 @@ tryGenerateSpecializedMessageSend(CodeGe
 if (isClassMessage &&
 Runtime.shouldUseRuntimeFunctionsForAlloc() &&
 ResultType->isObjCObjectPointerType()) {
-// [Foo alloc] -> objc_alloc(Foo)
+// [Foo alloc] -> objc_alloc(Foo) or
+// [self alloc] -> objc_alloc(self)
 if (Sel.isUnarySelector() && Sel.getNameForSlot(0) == "alloc")
   return CGF.EmitObjCAlloc(Receiver, CGF.ConvertType(ResultType));
-// [Foo allocWithZone:nil] -> objc_allocWithZone(Foo)
+// [Foo allocWithZone:nil] -> objc_allocWithZone(Foo) or
+// [self allocWithZone:nil] -> objc_allocWithZone(self)
 if (Sel.isKeywordSelector() && Sel.getNumArgs() == 1 &&
 Args.size() == 1 && Args.front().getType()->isPointerType() &&
 Sel.getNameForSlot(0) == "allocWithZone") {
@@ -444,22 +446,38 @@ tryEmitSpecializedAllocInit(CodeGenFunct
   Sel.getNameForSlot(0) != "init")
 return None;
 
-  // Okay, this is '[receiver init]', check if 'receiver' is '[cls alloc]'.
+  // Okay, this is '[receiver init]', check if 'receiver' is '[cls alloc]' or
+  // we are in an ObjC class method and 'receiver' is '[self alloc]'.
   auto *SubOME =
-  dyn_cast(OME->getInstanceReceiver()->IgnoreParens());
+  
dyn_cast(OME->getInstanceReceiver()->IgnoreParenCasts());
   if (!SubOME)
 return None;
   Selector SubSel = SubOME->getSelector();
-  if (SubOME->getReceiverKind() != ObjCMessageExpr::Class ||
-  !SubOME->getType()->isObjCObjectPointerType() ||
+
+  // Check if we are in an ObjC class method and the receiver expression is
+  // 'self'.
+  const Expr *SelfInClassMethod = nullptr;
+  if (const auto *CurMD = dyn_cast_or_null(CGF.CurFuncDecl))
+if (CurMD->isClassMethod())
+  if ((SelfInClassMethod = SubOME->getInstanceReceiver()))
+if (!SelfInClassMethod->isObjCSelfExpr())
+  SelfInClassMethod = nullptr;
+
+  if ((SubOME->getReceiverKind() != ObjCMessageExpr::Class &&
+   !SelfInClassMethod) || !SubOME->getType()->isObjCObjectPointerType() ||
   !SubSel.isUnarySelector() || SubSel.getNameForSlot(0) != "alloc")
 return None;
 
-  QualType ReceiverType = SubOME->getClassReceiver();
-  const ObjCObjectType *ObjTy = ReceiverType->getAs();
-  const ObjCInterfaceDecl *ID = ObjTy->getInterface();
-  assert(ID && "null interface should be impossible here");
-  llvm::Value *Receiver = CGF.CGM.getObjCRuntime().GetClass(CGF, ID);
+  llvm::Value *Receiver;
+  if (SelfInClassMethod) {
+Receiver = CGF.EmitScalarExpr(SelfInClassMethod);
+  } else {
+QualType ReceiverType = SubOME->getClassReceiver();
+const ObjCObjectType *ObjTy = ReceiverType->getAs();
+const ObjCInterfaceDecl *ID = ObjTy->getInterface();
+assert(ID && "null interface should be impossible here");
+Receiver = CGF.CGM.getObjCRuntime().GetClass(CGF, ID);
+  }
   return CGF.EmitObjCAllocInit(Receiver, CGF.ConvertType(OME->getType()));
 }
 
@@ -507,6 +525,10 @@ RValue CodeGenFunction::EmitObjCMessageE
   switch (E->getReceiverKind()) {
   case ObjCMessageExpr::Instance:
 ReceiverType = E->getInstanceReceiver()->getType();
+if (auto *OMD = dyn_cast_or_null(CurFuncDecl))
+  if (OMD->isClassMethod())
+if (E->getInstanceReceiver()->isObjCSelfExpr())
+  isClassMessage = true;
 if (retainSelf) {
   TryEmitResult ter = tryEmitARCRetainScalarExpr(*this,
E->getInstanceReceiver());

Modified: cfe/trunk/test/CodeGenObjC/convert-messages-to-runtime-calls.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/convert-messages-to-runtime-calls.m?rev=362521=362520=362521=diff
==
--- cfe/trunk/test/CodeGenObjC/convert-messages-to-runtime-calls.m (original)
+++ cfe/trunk/test/CodeGenObjC/convert-messages-to-runtime-calls.m Tue Jun  4 
09:29:58 2019
@@ -150,6 +150,34 @@ float test_cannot_message_return_float(C
   return [c retain];
 }
 
+@interface TestSelf
++ 

[clang-tools-extra] r362517 - [clangd] Minor cleanup. NFC

[Ilya Biryukov via cfe-commits]

Author: ibiryukov
Date: Tue Jun  4 09:19:11 2019
New Revision: 362517

URL: http://llvm.org/viewvc/llvm-project?rev=362517=rev
Log:
[clangd] Minor cleanup. NFC

Removed unused using declaration from TweakTests.cpp

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

Modified: clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp?rev=362517=362516=362517=diff
==
--- clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp (original)
+++ clang-tools-extra/trunk/clangd/unittests/TweakTests.cpp Tue Jun  4 09:19:11 
2019
@@ -21,7 +21,6 @@
 #include 
 
 using llvm::Failed;
-using llvm::HasValue;
 using llvm::Succeeded;
 
 namespace clang {


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

[PATCH] D48116: [libclang] Allow skipping warnings from all included files

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

@jkorous, could you take a look or suggest someone who can review the libclang 
changes?
As mentioned before, I've reviewed the clang bits (which are now gone), but 
don't have much experience in `libclang` parts.


Repository:
  rC Clang

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

https://reviews.llvm.org/D48116



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

[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 202950.
serge-sans-paille added a comment.

Take into account @philip.pfaffe remarks and improve support for new PM.

- harmonize static/dynamic loading, although two functions are still needed, 
one for dynamic loading and one for static loading (new PM)
- do not clutter the required API with extra namespaces

I've updated https://sergesanspaille.fedorapeople.org/bye.tgz to showcase a 
minimal example.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61446

Files:
  clang/tools/driver/CMakeLists.txt
  clang/tools/driver/cc1_main.cpp
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/docs/WritingAnLLVMPass.rst
  llvm/include/llvm/Config/llvm-config.h.cmake
  llvm/tools/CMakeLists.txt
  llvm/tools/bugpoint/CMakeLists.txt
  llvm/tools/bugpoint/bugpoint.cpp
  llvm/tools/opt/CMakeLists.txt
  llvm/tools/opt/NewPMDriver.cpp
  llvm/tools/opt/opt.cpp
  llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
  polly/CMakeLists.txt
  polly/lib/Support/RegisterPasses.cpp
  polly/test/Unit/lit.site.cfg.in
  polly/test/lit.site.cfg.in
  polly/test/update_check.py

Index: polly/test/update_check.py
===
--- polly/test/update_check.py
+++ polly/test/update_check.py
@@ -15,7 +15,7 @@
 polly_lib_dir = '''@POLLY_LIB_DIR@'''
 shlibext = '''@LLVM_SHLIBEXT@'''
 llvm_tools_dir = '''@LLVM_TOOLS_DIR@'''
-link_polly_into_tools = not '''@LINK_POLLY_INTO_TOOLS@'''.lower() in {'','0','n','no','off','false','notfound','link_polly_into_tools-notfound'}
+llvm_polly_link_into_tools = not '''@LLVM_POLLY_LINK_INTO_TOOLS@'''.lower() in {'','0','n','no','off','false','notfound','llvm_polly_link_into_tools-notfound'}
 
 runre = re.compile(r'\s*\;\s*RUN\s*\:(?P.*)')
 filecheckre = re.compile(r'\s*(?P.*)\|\s*(?PFileCheck\s[^|]*)')
@@ -298,7 +298,7 @@
 toolarg = toolarg.replace('%s', filename)
 toolarg = toolarg.replace('%S', os.path.dirname(filename))
 if toolarg == '%loadPolly':
-if not link_polly_into_tools:
+if not llvm_polly_link_into_tools:
 newtool += ['-load',os.path.join(polly_lib_dir,'LLVMPolly' + shlibext)]
 newtool.append('-polly-process-unprofitable')
 newtool.append('-polly-remarks-minimal')
Index: polly/test/lit.site.cfg.in
===
--- polly/test/lit.site.cfg.in
+++ polly/test/lit.site.cfg.in
@@ -8,7 +8,7 @@
 config.polly_lib_dir = "@POLLY_LIB_DIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
-config.link_polly_into_tools = "@LINK_POLLY_INTO_TOOLS@"
+config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.targets_to_build = "@TARGETS_TO_BUILD@"
 config.extra_paths = "@POLLY_TEST_EXTRA_PATHS@".split(";")
 
@@ -36,14 +36,14 @@
 # directories.
 config.excludes = ['Inputs']
 
-if config.link_polly_into_tools == '' or \
-   config.link_polly_into_tools.lower() == '0' or \
-   config.link_polly_into_tools.lower() == 'n' or \
-   config.link_polly_into_tools.lower() == 'no' or \
-   config.link_polly_into_tools.lower() == 'off' or \
-   config.link_polly_into_tools.lower() == 'false' or \
-   config.link_polly_into_tools.lower() == 'notfound' or \
-   config.link_polly_into_tools.lower() == 'link_polly_into_tools-notfound':
+if config.llvm_polly_link_into_tools == '' or \
+   config.llvm_polly_link_into_tools.lower() == '0' or \
+   config.llvm_polly_link_into_tools.lower() == 'n' or \
+   config.llvm_polly_link_into_tools.lower() == 'no' or \
+   config.llvm_polly_link_into_tools.lower() == 'off' or \
+   config.llvm_polly_link_into_tools.lower() == 'false' or \
+   config.llvm_polly_link_into_tools.lower() == 'notfound' or \
+   config.llvm_polly_link_into_tools.lower() == 'llvm_polly_link_into_tools-notfound':
 config.substitutions.append(('%loadPolly', '-load '
  + config.polly_lib_dir + '/LLVMPolly@LLVM_SHLIBEXT@'
  + ' -load-pass-plugin '
Index: polly/test/Unit/lit.site.cfg.in
===
--- polly/test/Unit/lit.site.cfg.in
+++ polly/test/Unit/lit.site.cfg.in
@@ -13,7 +13,7 @@
 config.shlibdir = "@SHLIBDIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
-config.link_polly_into_tools = "@LINK_POLLY_INTO_TOOLS@"
+config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.has_unittests = @POLLY_GTEST_AVAIL@
 
 # Support substitution of the tools_dir, libs_dirs, and build_mode with user
Index: polly/lib/Support/RegisterPasses.cpp
===
--- polly/lib/Support/RegisterPasses.cpp
+++ polly/lib/Support/RegisterPasses.cpp
@@ -234,7 

[PATCH] D62814: [clangd] Treat lambdas as functions when preparing hover response

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/unittests/XRefsTests.cpp:831
+ };
  return HI;
}},

kadircet wrote:
> ilya-biryukov wrote:
> > kadircet wrote:
> > > ilya-biryukov wrote:
> > > > Could you add another test with even weirder types where we fail to 
> > > > show the signature? To make sure we don't break when reaching the 
> > > > limitations of the chosen approach and document what those limitations 
> > > > are.
> > > > 
> > > > Something like:
> > > > ```
> > > > auto a = [](int a) { return 10; };
> > > > auto *b = 
> > > > auto *c = 
> > > > ```
> > > > 
> > > > We would fail to show the signature here, but it's totally ok to ignore 
> > > > it.
> > > added cases, and changed code(a lot simpler now) to generate signatures 
> > > for those cases as well.
> > Here's an example when the new approach falls short too:
> > 
> > ```
> > auto a = [](int) { return 10; }
> > std::function b;
> > ```
> > 
> > In general, are we ok with loosing all the information about the type that 
> > we drop?
> > One level of references and pointers seemed ok, dropping more is a bit more 
> > cheesy..
> > 
> > At the same time, either case is **so** rare that we probably don't care.
> are you talking about hovering over `x` ? I don't think AST contains 
> information regarding that one. 
> 
> for a code like this:
> ```
> auto foo = []() { return 5; };
> 
> template 
> class Cls {};
> 
> Cls X;
> ```
> 
> This is the AST dump for variable X:
> ```
> `-VarDecl 0x2b0e808  col:30 X 'Cls (decltype(foo))>':'Cls' callinit
>   `-CXXConstructExpr 0x2b12e80  'Cls':'Cls ((lambda at a.cc:1:12))>' 'void () noexcept'
> ```
I'm talking about hovering over `b` and, as Sam mentioned, there's a good 
chance you don't have this information in the type and we need to look at 
`TypeLocs` instead.

Also agree with Sam, we don't want **any** complexity for that case. Just 
wanted to make sure we added a test like this just to make sure we have some 
idea of what's produced there and it does not crash.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62814



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

Re: [PATCH] D62814: [clangd] Treat lambdas as functions when preparing hover response

[Sam McCall via cfe-commits]

AST dump doesn't traverse into typelocs, which is where x is.

That said, this particular case is not worth any complexity at all. Even
pointer-to-lambda is vanishingly rare.

Regarding dropping ref/pointer info: one option here is keeping the old
"class (lambda)&", and simply making sure we now populate return/params.
I'm not sure setting Type as if it were a function is actually clarifying.

If you don't want to do this, I'd suggest not unwrapping pointers, and
living with the lost ref qualifiers (only realistic case i can think of
where it matters is a by-ref capture of a lambda inside another lambda, and
i don't think anyone will notice if we pretend it's a value)

On Tue, Jun 4, 2019, 16:11 Kadir Cetinkaya via Phabricator <
revi...@reviews.llvm.org> wrote:

> kadircet added inline comments.
>
>
> 
> Comment at: clang-tools-extra/clangd/unittests/XRefsTests.cpp:831
> + };
>   return HI;
> }},
> 
> ilya-biryukov wrote:
> > kadircet wrote:
> > > ilya-biryukov wrote:
> > > > Could you add another test with even weirder types where we fail to
> show the signature? To make sure we don't break when reaching the
> limitations of the chosen approach and document what those limitations are.
> > > >
> > > > Something like:
> > > > ```
> > > > auto a = [](int a) { return 10; };
> > > > auto *b = 
> > > > auto *c = 
> > > > ```
> > > >
> > > > We would fail to show the signature here, but it's totally ok to
> ignore it.
> > > added cases, and changed code(a lot simpler now) to generate
> signatures for those cases as well.
> > Here's an example when the new approach falls short too:
> >
> > ```
> > auto a = [](int) { return 10; }
> > std::function b;
> > ```
> >
> > In general, are we ok with loosing all the information about the type
> that we drop?
> > One level of references and pointers seemed ok, dropping more is a bit
> more cheesy..
> >
> > At the same time, either case is **so** rare that we probably don't care.
> are you talking about hovering over `x` ? I don't think AST contains
> information regarding that one.
>
> for a code like this:
> ```
> auto foo = []() { return 5; };
>
> template 
> class Cls {};
>
> Cls X;
> ```
>
> This is the AST dump for variable X:
> ```
> `-VarDecl 0x2b0e808  col:30 X 'Cls (decltype(foo))>':'Cls' callinit
>   `-CXXConstructExpr 0x2b12e80  'Cls (decltype(foo))>':'Cls' 'void () noexcept'
> ```
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D62814/new/
>
> https://reviews.llvm.org/D62814
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D62845: [clang-tidy] Fix make-unique tests on C++2a.

[Dmitri Gribenko via Phabricator via cfe-commits]

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

Looks great, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62845



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

[PATCH] D62782: Fix -Wdouble-promotion warnings.

[Bruce Mitchener via Phabricator via cfe-commits]

brucem added a comment.

I'd modified `CMakeLists.txt` to add `-Wdouble-promotion` and removed this 
line: `-Wno-double-promotion # FIXME: remove me` ...


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D62782



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

[clang-tools-extra] r362467 - [clangd] SymbolCollector support for relations

[Nathan Ridge via cfe-commits]

Author: nridge
Date: Mon Jun  3 21:25:44 2019
New Revision: 362467

URL: http://llvm.org/viewvc/llvm-project?rev=362467=rev
Log:
[clangd] SymbolCollector support for relations

Summary:
The only relation currently collected is RelationBaseOf, because this is
all we need for type hierarchy subtypes. Additional relations can be
collected in the future as the need arises.

This patch builds on D59407 and D62459.

Reviewers: kadircet

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

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
clang-tools-extra/trunk/clangd/index/SymbolCollector.h
clang-tools-extra/trunk/clangd/unittests/SymbolCollectorTests.cpp

Modified: clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp?rev=362467=362466=362467=diff
==
--- clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp (original)
+++ clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp Mon Jun  3 
21:25:44 2019
@@ -193,6 +193,11 @@ RefKind toRefKind(index::SymbolRoleSet R
   return static_cast(static_cast(RefKind::All) & Roles);
 }
 
+bool shouldIndexRelation(const index::SymbolRelation ) {
+  // We currently only index BaseOf relations, for type hierarchy subtypes.
+  return R.Roles & static_cast(index::SymbolRole::RelationBaseOf);
+}
+
 } // namespace
 
 SymbolCollector::SymbolCollector(Options Opts) : Opts(std::move(Opts)) {}
@@ -291,6 +296,16 @@ bool SymbolCollector::handleDeclOccurenc
   SM.getFileID(SpellingLoc) == SM.getMainFileID())
 ReferencedDecls.insert(ND);
 
+  auto ID = getSymbolID(ND);
+  if (!ID)
+return true;
+
+  // Note: we need to process relations for all decl occurrences, including
+  // refs, because the indexing code only populates relations for specific
+  // occurrences. For example, RelationBaseOf is only populated for the
+  // occurrence inside the base-specifier.
+  processRelations(*ND, *ID, Relations);
+
   bool CollectRef = static_cast(Opts.RefFilter) & Roles;
   bool IsOnlyRef =
   !(Roles & (static_cast(index::SymbolRole::Declaration) |
@@ -315,10 +330,6 @@ bool SymbolCollector::handleDeclOccurenc
   if (IsOnlyRef)
 return true;
 
-  auto ID = getSymbolID(ND);
-  if (!ID)
-return true;
-
   // FIXME: ObjCPropertyDecl are not properly indexed here:
   // - ObjCPropertyDecl may have an OrigD of ObjCPropertyImplDecl, which is
   // not a NamedDecl.
@@ -338,6 +349,7 @@ bool SymbolCollector::handleDeclOccurenc
 
   if (Roles & static_cast(index::SymbolRole::Definition))
 addDefinition(*OriginalDecl, *BasicSymbol);
+
   return true;
 }
 
@@ -416,6 +428,37 @@ bool SymbolCollector::handleMacroOccuren
   return true;
 }
 
+void SymbolCollector::processRelations(
+const NamedDecl , const SymbolID ,
+ArrayRef Relations) {
+  // Store subtype relations.
+  if (!dyn_cast())
+return;
+
+  for (const auto  : Relations) {
+if (!shouldIndexRelation(R))
+  continue;
+
+const Decl *Object = R.RelatedSymbol;
+
+auto ObjectID = getSymbolID(Object);
+if (!ObjectID)
+  continue;
+
+// Record the relation.
+// TODO: There may be cases where the object decl is not indexed for some
+// reason. Those cases should probably be removed in due course, but for
+// now there are two possible ways to handle it:
+//   (A) Avoid storing the relation in such cases.
+//   (B) Store it anyways. Clients will likely lookup() the SymbolID
+//   in the index and find nothing, but that's a situation they
+//   probably need to handle for other reasons anyways.
+// We currently do (B) because it's simpler.
+this->Relations.insert(
+Relation{ID, index::SymbolRole::RelationBaseOf, *ObjectID});
+  }
+}
+
 void SymbolCollector::setIncludeLocation(const Symbol , SourceLocation Loc) {
   if (Opts.CollectIncludePath)
 if (shouldCollectIncludePath(S.SymInfo.Kind))

Modified: clang-tools-extra/trunk/clangd/index/SymbolCollector.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/SymbolCollector.h?rev=362467=362466=362467=diff
==
--- clang-tools-extra/trunk/clangd/index/SymbolCollector.h (original)
+++ clang-tools-extra/trunk/clangd/index/SymbolCollector.h Mon Jun  3 21:25:44 
2019
@@ -110,6 +110,7 @@ public:
 
   SymbolSlab takeSymbols() { return std::move(Symbols).build(); }
   RefSlab takeRefs() { return std::move(Refs).build(); }
+  RelationSlab takeRelations() { return std::move(Relations).build(); }
 
   void finish() override;
 
@@ -117,6 +118,8 @@ private:
   const Symbol *addDeclaration(const NamedDecl &, SymbolID,
bool IsMainFileSymbol);
   void addDefinition(const NamedDecl &, 

[PATCH] D56571: [RFC prototype] Implementation of asm-goto support in clang

[Jennifer Yu via Phabricator via cfe-commits]

jyu2 closed this revision.
jyu2 added a comment.

jyu2 committed rGb8fee677bf8e 
: Re-check 
in clang support gun asm goto after fixing tests. (authored by jyu2).


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

https://reviews.llvm.org/D56571



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

[clang-tools-extra] r362353 - [clangd] Serialization support for RelationSlab

[Nathan Ridge via cfe-commits]

Author: nridge
Date: Sun Jun  2 22:07:52 2019
New Revision: 362353

URL: http://llvm.org/viewvc/llvm-project?rev=362353=rev
Log:
[clangd] Serialization support for RelationSlab

Summary: This builds on D59407 to provide YAML and RIFF serialization support.

Reviewers: kadircet

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

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/index/Serialization.cpp
clang-tools-extra/trunk/clangd/index/Serialization.h
clang-tools-extra/trunk/clangd/index/YAMLSerialization.cpp
clang-tools-extra/trunk/clangd/unittests/SerializationTests.cpp

Modified: clang-tools-extra/trunk/clangd/index/Serialization.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Serialization.cpp?rev=362353=362352=362353=diff
==
--- clang-tools-extra/trunk/clangd/index/Serialization.cpp (original)
+++ clang-tools-extra/trunk/clangd/index/Serialization.cpp Sun Jun  2 22:07:52 
2019
@@ -24,6 +24,29 @@ llvm::Error makeError(const llvm::Twine
   return llvm::make_error(Msg,
  llvm::inconvertibleErrorCode());
 }
+} // namespace
+
+RelationKind symbolRoleToRelationKind(index::SymbolRole Role) {
+  // SymbolRole is used to record relations in the index.
+  // Only handle the relations we actually store currently.
+  // If we start storing more relations, this list can be expanded.
+  switch (Role) {
+  case index::SymbolRole::RelationBaseOf:
+return RelationKind::BaseOf;
+  default:
+llvm_unreachable("Unsupported symbol role");
+  }
+}
+
+index::SymbolRole relationKindToSymbolRole(RelationKind Kind) {
+  switch (Kind) {
+  case RelationKind::BaseOf:
+return index::SymbolRole::RelationBaseOf;
+  }
+  llvm_unreachable("Invalid relation kind");
+}
+
+namespace {
 
 // IO PRIMITIVES
 // We use little-endian 32 bit ints, sometimes with variable-length encoding.
@@ -358,6 +381,28 @@ readRefs(Reader , llvm::ArrayRef(Kind));
+  OS << R.Object.raw();
+}
+
+Relation readRelation(Reader ) {
+  SymbolID Subject = Data.consumeID();
+  index::SymbolRole Predicate =
+  relationKindToSymbolRole(static_cast(Data.consume8()));
+  SymbolID Object = Data.consumeID();
+  return {Subject, Predicate, Object};
+}
+
 // FILE ENCODING
 // A file is a RIFF chunk with type 'CdIx'.
 // It contains the sections:
@@ -434,6 +479,17 @@ llvm::Expected readRIFF(llv
   return makeError("malformed or truncated refs");
 Result.Refs = std::move(Refs).build();
   }
+  if (Chunks.count("rela")) {
+Reader RelationsReader(Chunks.lookup("rela"));
+RelationSlab::Builder Relations;
+while (!RelationsReader.eof()) {
+  auto Relation = readRelation(RelationsReader);
+  Relations.insert(Relation);
+}
+if (RelationsReader.err())
+  return makeError("malformed or truncated relations");
+Result.Relations = std::move(Relations).build();
+  }
   return std::move(Result);
 }
 
@@ -483,6 +539,14 @@ void writeRIFF(const IndexFileOut ,
 }
   }
 
+  std::vector Relations;
+  if (Data.Relations) {
+for (const auto  : *Data.Relations) {
+  Relations.emplace_back(Relation);
+  // No strings to be interned in relations.
+}
+  }
+
   std::string StringSection;
   {
 llvm::raw_string_ostream StringOS(StringSection);
@@ -508,6 +572,16 @@ void writeRIFF(const IndexFileOut ,
 RIFF.Chunks.push_back({riff::fourCC("refs"), RefsSection});
   }
 
+  std::string RelationSection;
+  if (Data.Relations) {
+{
+  llvm::raw_string_ostream RelationOS{RelationSection};
+  for (const auto  : Relations)
+writeRelation(Relation, RelationOS);
+}
+RIFF.Chunks.push_back({riff::fourCC("rela"), RelationSection});
+  }
+
   std::string SrcsSection;
   {
 {
@@ -561,6 +635,7 @@ std::unique_ptr loadIndex(l
 
   SymbolSlab Symbols;
   RefSlab Refs;
+  RelationSlab Relations;
   {
 trace::Span Tracer("ParseIndex");
 if (auto I = readIndexFile(Buffer->get()->getBuffer())) {
@@ -568,6 +643,8 @@ std::unique_ptr loadIndex(l
 Symbols = std::move(*I->Symbols);
   if (I->Refs)
 Refs = std::move(*I->Refs);
+  if (I->Relations)
+Relations = std::move(*I->Relations);
 } else {
   llvm::errs() << "Bad Index: " << llvm::toString(I.takeError()) << "\n";
   return nullptr;
@@ -576,15 +653,17 @@ std::unique_ptr loadIndex(l
 
   size_t NumSym = Symbols.size();
   size_t NumRefs = Refs.numRefs();
+  size_t NumRelations = Relations.size();
 
   trace::Span Tracer("BuildIndex");
   auto Index = UseDex ? dex::Dex::build(std::move(Symbols), std::move(Refs))
   : MemIndex::build(std::move(Symbols), std::move(Refs));
   vlog("Loaded {0} from {1} with estimated memory usage {2} bytes\n"
"  - number of symbols: {3}\n"
-   "  - number of refs: {4}\n",
+   "  - number of refs: 

[clang-tools-extra] r362352 - [clangd] Add RelationSlab

[Nathan Ridge via cfe-commits]

Author: nridge
Date: Sun Jun  2 21:55:46 2019
New Revision: 362352

URL: http://llvm.org/viewvc/llvm-project?rev=362352=rev
Log:
[clangd] Add RelationSlab

Summary:
RelationSlab is a new index data structure that stores relations between
symbols.

Reviewers: kadircet

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

Tags: #clang

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

Added:
clang-tools-extra/trunk/clangd/index/Relation.cpp
clang-tools-extra/trunk/clangd/index/Relation.h
Modified:
clang-tools-extra/trunk/clangd/CMakeLists.txt
clang-tools-extra/trunk/clangd/index/Index.h
clang-tools-extra/trunk/clangd/unittests/IndexTests.cpp

Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CMakeLists.txt?rev=362352=362351=362352=diff
==
--- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/CMakeLists.txt Sun Jun  2 21:55:46 2019
@@ -77,6 +77,7 @@ add_clang_library(clangDaemon
   index/MemIndex.cpp
   index/Merge.cpp
   index/Ref.cpp
+  index/Relation.cpp
   index/Serialization.cpp
   index/Symbol.cpp
   index/SymbolCollector.cpp

Modified: clang-tools-extra/trunk/clangd/index/Index.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Index.h?rev=362352=362351=362352=diff
==
--- clang-tools-extra/trunk/clangd/index/Index.h (original)
+++ clang-tools-extra/trunk/clangd/index/Index.h Sun Jun  2 21:55:46 2019
@@ -10,6 +10,7 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_INDEX_H
 
 #include "Ref.h"
+#include "Relation.h"
 #include "Symbol.h"
 #include "SymbolID.h"
 #include "llvm/ADT/DenseSet.h"

Added: clang-tools-extra/trunk/clangd/index/Relation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Relation.cpp?rev=362352=auto
==
--- clang-tools-extra/trunk/clangd/index/Relation.cpp (added)
+++ clang-tools-extra/trunk/clangd/index/Relation.cpp Sun Jun  2 21:55:46 2019
@@ -0,0 +1,40 @@
+//===--- Relation.cpp *- 
C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Relation.h"
+
+#include 
+
+namespace clang {
+namespace clangd {
+
+llvm::iterator_range
+RelationSlab::lookup(const SymbolID ,
+ index::SymbolRole Predicate) const {
+  auto IterPair = std::equal_range(Relations.begin(), Relations.end(),
+   Relation{Subject, Predicate, SymbolID{}},
+   [](const Relation , const Relation ) {
+ return std::tie(A.Subject, A.Predicate) <
+std::tie(B.Subject, B.Predicate);
+   });
+  return {IterPair.first, IterPair.second};
+}
+
+RelationSlab RelationSlab::Builder::build() && {
+  // Sort in SPO order.
+  std::sort(Relations.begin(), Relations.end());
+
+  // Remove duplicates.
+  Relations.erase(std::unique(Relations.begin(), Relations.end()),
+  Relations.end());
+
+  return RelationSlab{std::move(Relations)};
+}
+
+} // namespace clangd
+} // namespace clang

Added: clang-tools-extra/trunk/clangd/index/Relation.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Relation.h?rev=362352=auto
==
--- clang-tools-extra/trunk/clangd/index/Relation.h (added)
+++ clang-tools-extra/trunk/clangd/index/Relation.h Sun Jun  2 21:55:46 2019
@@ -0,0 +1,88 @@
+//===--- Relation.h --*- 
C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_RELATION_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_RELATION_H
+
+#include "SymbolID.h"
+#include "SymbolLocation.h"
+#include "clang/Index/IndexSymbol.h"
+#include "llvm/ADT/iterator_range.h"
+#include 
+#include 
+
+namespace clang {
+namespace clangd {
+
+/// Represents a relation between two symbols.
+/// For an example "A is a base class of B" may be represented
+/// as { Subject = A, Predicate = RelationBaseOf, Object = B }.
+struct Relation {
+  SymbolID Subject;
+  index::SymbolRole 

[PATCH] D62845: [clang-tidy] Fix make-unique tests on C++2a.

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

In D62845#1529190 , @gribozavr wrote:

> In D62845#1529149 , @hokein wrote:
>
> > > I think we should be looking at the intent of the test rather than its 
> > > name.
> > > 
> > > The intent looks like testing how the check works when `std::make_unique` 
> > > is available from the standard library (as opposed to some kind of 
> > > replacement like `absl::make_unique`).  See the patch that introduced it: 
> > > https://reviews.llvm.org/D43766
> > > 
> > > So modernize-make-unique-cxx14 is actually "C++14 or later".  (Probably 
> > > it should be renamed.)
> >
> > yeap, it seems to me that "modernize-make-unique-cxx14" is redundant, 
> > "modernize-make-unique" should cover what it tests, I believe. We also have 
> > "modernize-make-unique-cxx11" which runs on C++11 mode only, maybe we just 
> > repurpose the `modernize-make-unique-cxx14`, what do you think?
>
>
> Fair enough.
>
> >> I see.  Assuming it is desired behavior, I'd say for these cases we should 
> >> create separate files that are specifically run in C++14 and 17, and 
> >> another one for C++2a onward.
> >> 
> >> But is it desired behavior?  That is, can we generate a call to 
> >> `std::make_unique` in C++14 in practice -- would it compile?
> > 
> > The fix is compilable for C++14, but it is tricky to support it:
> > 
> > 1. `new NoCopyMoveCtor{}`: the `make_unique` fix is compilable
> > 2. `new NoCopyMoveCtor{1, 2}`: the `make_unique` fix is not compilable
> > 
> >   The AST for case 1) and 2)  are the same in C++14,  supporting that would 
> > introduce hacky change to the logic here 
> > .
> >  I'd leave it as-is now.
>
> Indeed, this is complicated.  Could you add tests for `new NoCopyMoveCtor{1, 
> 2}` with TODOs (the message suggests the user to do the impossible).


Done, but note that adding extra data fields to the `NoCopyMoveCtor` is 
uncompilable in C++2a :(




Comment at: clang-tools-extra/test/clang-tidy/modernize-make-unique-cxx14.cpp:1
-// RUN: %check_clang_tidy -std=c++14-or-later %s modernize-make-unique %t -- 
-- -I %S/Inputs/modernize-smart-ptr
+// RUN: %check_clang_tidy -std=c++14 %s modernize-make-unique %t -- -- -I 
%S/Inputs/modernize-smart-ptr
 

gribozavr wrote:
> WDYT about merging two tests and adding run lines like this:
> 
> ```
> // RUN: %check_clang_tidy -std=c++14,c++17 -check-suffix=CXX_14_17 %s 
> modernize-make-unique %t -- -- -I %S/Inputs/modernize-smart-ptr -D CXX_14_17=1
> // RUN: %check_clang_tidy -std=c++2a -check-suffix=CXX_2A %s 
> modernize-make-unique %t -- -- -I %S/Inputs/modernize-smart-ptr -DCXX_2A=1
> ```
Good point, done!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62845



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

[PATCH] D62845: [clang-tidy] Fix make-unique tests on C++2a.

[Haojian Wu via Phabricator via cfe-commits]

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

address review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62845

Files:
  clang-tools-extra/test/clang-tidy/modernize-make-unique-cxx14.cpp
  clang-tools-extra/test/clang-tidy/modernize-make-unique-inaccessible-ctors.cpp
  clang-tools-extra/test/clang-tidy/modernize-make-unique.cpp

Index: clang-tools-extra/test/clang-tidy/modernize-make-unique.cpp
===
--- clang-tools-extra/test/clang-tidy/modernize-make-unique.cpp
+++ clang-tools-extra/test/clang-tidy/modernize-make-unique.cpp
@@ -1,5 +1,4 @@
-// RUN: %check_clang_tidy -std=c++14,c++17 %s modernize-make-unique %t -- -- -I %S/Inputs/modernize-smart-ptr
-// FIXME: Fix the test code in C++2a mode.
+// RUN: %check_clang_tidy -std=c++14-or-later %s modernize-make-unique %t -- -- -I %S/Inputs/modernize-smart-ptr
 
 #include "unique_ptr.h"
 #include "initializer_list.h"
@@ -32,37 +31,6 @@
 
 struct Empty {};
 
-struct NoCopyMoveCtor {
-  NoCopyMoveCtor(const NoCopyMoveCtor &) = delete; // implies move ctor is deleted
-};
-
-struct NoCopyMoveCtorVisible {
-private:
-  NoCopyMoveCtorVisible(const NoCopyMoveCtorVisible&) = default;
-  NoCopyMoveCtorVisible(NoCopyMoveCtorVisible&&) = default;
-};
-
-struct OnlyMoveCtor {
-  OnlyMoveCtor() = default;
-  OnlyMoveCtor(OnlyMoveCtor&&) = default;
-  OnlyMoveCtor(const OnlyMoveCtor &) = delete;
-};
-
-struct OnlyCopyCtor {
-  OnlyCopyCtor(const OnlyCopyCtor&) = default;
-  OnlyCopyCtor(OnlyCopyCtor&&) = delete;
-};
-
-struct OnlyCopyCtorVisible {
-  OnlyCopyCtorVisible(const OnlyCopyCtorVisible &) = default;
-
-private:
-  OnlyCopyCtorVisible(OnlyCopyCtorVisible &&) = default;
-};
-
-struct ImplicitDeletedCopyCtor {
-  const OnlyMoveCtor ctor;
-};
 
 struct E {
   E(std::initializer_list);
@@ -314,33 +282,6 @@
   // CHECK-MESSAGES: :[[@LINE-1]]:35: warning: use std::make_unique instead
   // CHECK-FIXES: std::unique_ptr PEmpty = std::make_unique(Empty{});
 
-  // No fixes for classes with deleted copy constructors.
-  auto PNoCopyMoveCtor = std::unique_ptr(new NoCopyMoveCtor{});
-  // CHECK-MESSAGES: :[[@LINE-1]]:26: warning: use std::make_unique instead
-  // CHECK-FIXES: auto PNoCopyMoveCtor = std::unique_ptr(new NoCopyMoveCtor{});
-
-  auto PNoCopyMoveCtorVisible = std::unique_ptr(new NoCopyMoveCtorVisible{});
-  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: use std::make_unique instead
-  // CHECK-FIXES: auto PNoCopyMoveCtorVisible = std::unique_ptr(new NoCopyMoveCtorVisible{});
-
-  auto POnlyMoveCtor = std::unique_ptr(new OnlyMoveCtor{});
-  // CHECK-MESSAGES: :[[@LINE-1]]:24: warning: use std::make_unique instead
-  // CHECK-FIXES: auto POnlyMoveCtor = std::unique_ptr(new OnlyMoveCtor{});
-
-  // Fix for classes with classes with move constructor.
-  auto POnlyCopyCtor = std::unique_ptr(new OnlyCopyCtor{});
-  // CHECK-MESSAGES: :[[@LINE-1]]:24: warning: use std::make_unique instead
-  // CHECK-FIXES: auto POnlyCopyCtor = std::unique_ptr(new OnlyCopyCtor{});
-
-   // Fix for classes with classes with move constructor.
-  auto POnlyCopyCtorVisible = std::unique_ptr(new OnlyCopyCtorVisible{});
-  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: use std::make_unique instead
-  // CHECK-FIXES: auto POnlyCopyCtorVisible = std::unique_ptr(new OnlyCopyCtorVisible{});
-
-  auto PImplicitDeletedCopyCtor = std::unique_ptr(new ImplicitDeletedCopyCtor{});
-  // CHECK-MESSAGES: :[[@LINE-1]]:35: warning: use std::make_unique instead
-  // CHECK-FIXES: auto PImplicitDeletedCopyCtor = std::unique_ptr(new ImplicitDeletedCopyCtor{});
-
   // Initialization with default constructor.
   std::unique_ptr PE1 = std::unique_ptr(new E{});
   // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: use std::make_unique instead
Index: clang-tools-extra/test/clang-tidy/modernize-make-unique-inaccessible-ctors.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/modernize-make-unique-inaccessible-ctors.cpp
@@ -0,0 +1,113 @@
+// RUN: %check_clang_tidy -std=c++14,c++17 -check-suffix=CXX-14-17 %s modernize-make-unique %t -- -- -I %S/Inputs/modernize-smart-ptr -D CXX_14_17=1
+// RUN: %check_clang_tidy -std=c++2a -check-suffix=CXX-2A %s modernize-make-unique %t -- -- -I %S/Inputs/modernize-smart-ptr -D CXX_2A=1
+
+#include "unique_ptr.h"
+// CHECK-FIXES: #include 
+
+struct NoCopyMoveCtor {
+#ifdef CXX_2A
+  // C++2a requires to see the default constructor, otherwise it is illgal.
+  NoCopyMoveCtor() = default;
+#endif
+#ifdef CXX_14_17
+  int a, b;
+#endif
+  NoCopyMoveCtor(const NoCopyMoveCtor &) = delete; // implies move ctor is deleted
+};
+
+struct NoCopyMoveCtorVisible {
+#ifdef CXX_2A
+  NoCopyMoveCtorVisible() = default;
+#endif
+private:
+  NoCopyMoveCtorVisible(const NoCopyMoveCtorVisible&) = default;
+  

[PATCH] D60763: Prototype OpenCL BIFs using Tablegen

[Nicola Zaghen via Phabricator via cfe-commits]

Nicola added a comment.

A bit late to the review, but I've noticed a couple of issues with some of the 
implemented builtins:

- The fmin/fmax builtins are defined twice for scalar types, does this create 
problems in overload resolution when using them?
- The convert_ builtins don't have support for half types (which is present in 
the opencl-c.h header. Is that intended?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60763



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

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

[David Goldman via Phabricator via cfe-commits]

dgoldman updated this revision to Diff 202938.
dgoldman added a comment.

- Remove unused State variable


Repository:
  rC Clang

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

https://reviews.llvm.org/D62648

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

Index: test/Sema/typo-correction-recursive.cpp
===
--- /dev/null
+++ test/Sema/typo-correction-recursive.cpp
@@ -0,0 +1,71 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Check the following typo correction behavior:
+// - multiple typos in a single member call chain are all diagnosed
+// - no typos are diagnosed for multiple typos in an expression when not all
+//   typos can be corrected
+
+class DeepClass
+{
+public:
+  void trigger() const;  // expected-note {{'trigger' declared here}}
+};
+
+class Y
+{
+public:
+  const DeepClass& getX() const { return m_deepInstance; } // expected-note {{'getX' declared here}}
+  int getN() const { return m_n; }
+private:
+  DeepClass m_deepInstance;
+  int m_n;
+};
+
+class Z
+{
+public:
+  const Y& getY0() const { return m_y0; } // expected-note {{'getY0' declared here}}
+  const Y& getY1() const { return m_y1; }
+  const Y& getActiveY() const { return m_y0; }
+
+private:
+  Y m_y0;
+  Y m_y1;
+};
+
+Z z_obj;
+
+void testMultipleCorrections()
+{
+  z_obj.getY2(). // expected-error {{no member named 'getY2' in 'Z'; did you mean 'getY0'}}
+getM().  // expected-error {{no member named 'getM' in 'Y'; did you mean 'getX'}}
+triggee();   // expected-error {{no member named 'triggee' in 'DeepClass'; did you mean 'trigger'}}
+}
+
+void testNoCorrections()
+{
+  z_obj.getY2(). // expected-error {{no member named 'getY2' in 'Z'}}
+getM().
+thisDoesntSeemToMakeSense();
+}
+
+struct C {};
+struct D { int value; };
+struct A {
+  C get_me_a_C();
+};
+struct B {
+  D get_me_a_D(); // expected-note {{'get_me_a_D' declared here}}
+};
+class Scope {
+public:
+  A make_an_A();
+  B make_a_B(); // expected-note {{'make_a_B' declared here}}
+};
+
+Scope scope_obj;
+
+int testDiscardedCorrections() {
+  return scope_obj.make_an_E(). // expected-error {{no member named 'make_an_E' in 'Scope'; did you mean 'make_a_B'}}
+get_me_a_Z().value; // expected-error {{no member named 'get_me_a_Z' in 'B'; did you mean 'get_me_a_D'}}
+}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -7680,6 +7680,59 @@
 return ExprFilter(Res.get());
   }
 
+  // Try to transform the given expression, looping through the correction
+  // candidates with `CheckAndAdvanceTypoExprCorrectionStreams`.
+  //
+  // Since correcting typos may intoduce new TypoExprs, this function
+  // checks for new TypoExprs and recurses if it finds any. Note that it will
+  // only succeed if it is able to correct all typos in the given expression.
+  ExprResult RecursiveTransformLoop(Expr *E) {
+ExprResult Res;
+while (true) {
+  Res = TryTransform(E);
+
+  // The transform was valid: check if there any new TypoExprs were created.
+  // If so, we need to recurse to check their validity.
+  if (!Res.isInvalid() && !TypoExprs.empty()) {
+Expr *FixedExpr = Res.get();
+auto SavedTypoExprs = TypoExprs;
+llvm::SmallSetVector RecursiveTypoExprs;
+TypoExprs = RecursiveTypoExprs;
+FindTypoExprs(TypoExprs).TraverseStmt(FixedExpr);
+
+// Recurse to handle newly created TypoExprs. If we're not able to
+// handle them, discard these TypoExprs.
+ExprResult RecurResult = RecursiveTransformLoop(FixedExpr);
+if (RecurResult.isInvalid()) {
+  Res = ExprError();
+  // Recursive corrections didn't work, wipe them away and don't add
+  // them to the TypoExprs set.
+  for (auto TE : TypoExprs) {
+TransformCache.erase(TE);
+SemaRef.clearDelayedTypo(TE);
+  }
+} else {
+  // TypoExpr is valid: add newly created TypoExprs since we were
+  // able to correct them.
+  Res = RecurResult;
+  SavedTypoExprs.set_union(TypoExprs);
+}
+
+TypoExprs = SavedTypoExprs;
+  }
+  // If the transform is still valid after checking for any new typos,
+  // it's good to go.
+  if (!Res.isInvalid())
+break;
+
+  // The transform was invalid, see if we have any TypoExprs with untried
+  // correction candidates.
+  if (!CheckAndAdvanceTypoExprCorrectionStreams())
+break;
+}
+return Res;
+  }
+
 public:
   TransformTypos(Sema , VarDecl *InitDecl, llvm::function_ref Filter)
   : BaseTransform(SemaRef), InitDecl(InitDecl), ExprFilter(Filter) {}
@@ -7707,16 +7760,7 @@
   ExprResult TransformBlockExpr(BlockExpr *E) { return Owned(E); }
 
   ExprResult Transform(Expr *E) {
-ExprResult Res;
-

Re: [PATCH] D54258: [Clang] Fix pretty printing of CUDA address spaces

[Aaron Ballman via cfe-commits]

On Tue, Jun 4, 2019 at 5:37 AM Richard Membarth via Phabricator
 wrote:
>
> richardmembarth added a comment.
>
> Merging in two weeks is fine for me.
>
> My assumption was that accepted patches are merged into upstream in a timely 
> manner.
> Maybe this is not how it works?

Your assumption is correct. Usually, if you don't have commit
privileges yet, you mention it once your patch is accepted so that the
reviewers know you need it committed on your behalf. The commit
usually happens same- or next-day. However, because I am traveling, I
don't have the ability to watch build bots and revert on your behalf
if anything goes wrong, which explains the delay on my part.

Sorry for the hassle.

~Aaron

>
>
> Repository:
>   rC Clang
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D54258/new/
>
> https://reviews.llvm.org/D54258
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D60697: [ARM] Allow "-march=foo+fp" to vary with foo.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer updated this revision to Diff 202934.
SjoerdMeijer added a comment.

Hi Oliver, thanks for your comments!

This was the easy one, they have been added:

> I also don't see any tests for the negated forms of either feature.

The trouble begun with this:

> +fp.dp, but the FPU is already double-precision
>  +fp.dp, but no double-precision FPU exists (are there any FPUs which cause 
> this?)
>  +[no]fp or +[no]fp.dp for a CPU/arch which doesn't have any FPUs.

Because I found that basically none of this worked. The main reason was that we 
were always passing `generic`. To address that we at least have a chance of 
seeing a sensible CPU name, I have swapped the order of parsing -march and 
-mcpu. I.e., we parse -mcpu first, and pass that to `checkARMArchName`, which 
will eventually call `appendArchExtFeatures`. I think that makes more sense 
when we use the CPUname to query `getDefaultFPU`.

Then about the more fancy diagnostics (e.g. "fp.dp, but the FPU is already 
double-precision"): I've removed any attempt to throw clever diagnostics. I 
don't think, in general, that we provide this kind of service level. I.e., we 
need to do a lot more work here to avoid a meaningless, confusing, and thus 
useless  "--march=... not supported" error message when we provide +fp.dp on 
the -march when e.g. the CPU already enabled this.


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

https://reviews.llvm.org/D60697

Files:
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.h
  clang/test/Driver/armv8.1m.main.c
  clang/test/Driver/armv8.1m.main.s
  llvm/include/llvm/Support/ARMTargetParser.h
  llvm/lib/Support/ARMTargetParser.cpp

Index: llvm/lib/Support/ARMTargetParser.cpp
===
--- llvm/lib/Support/ARMTargetParser.cpp
+++ llvm/lib/Support/ARMTargetParser.cpp
@@ -484,22 +484,85 @@
   return StringRef();
 }
 
-StringRef ARM::getArchExtFeature(StringRef ArchExt) {
-  if (ArchExt.startswith("no")) {
-StringRef ArchExtBase(ArchExt.substr(2));
-for (const auto AE : ARCHExtNames) {
-  if (AE.NegFeature && ArchExtBase == AE.getName())
-return StringRef(AE.NegFeature);
-}
+static bool stripNegationPrefix(StringRef ) {
+  if (Name.startswith("no")) {
+Name = Name.substr(2);
+return true;
   }
+  return false;
+}
+
+StringRef ARM::getArchExtFeature(StringRef ArchExt) {
+  bool Negated = stripNegationPrefix(ArchExt);
   for (const auto AE : ARCHExtNames) {
 if (AE.Feature && ArchExt == AE.getName())
-  return StringRef(AE.Feature);
+  return StringRef(Negated ? AE.NegFeature : AE.Feature);
   }
 
   return StringRef();
 }
 
+static unsigned findDoublePrecisionFPU(unsigned InputFPUKind) {
+  const ARM::FPUName  = ARM::FPUNames[InputFPUKind];
+
+  // If the input FPU already supports double-precision, then there
+  // isn't any different FPU we can return here.
+  //
+  // The current available FPURestriction values are None (no
+  // restriction), D16 (only 16 d-regs) and SP_D16 (16 d-regs
+  // and single precision only); there's no value representing
+  // SP restriction without D16. So this test just means 'is it
+  // SP only?'.
+  if (InputFPU.Restriction != ARM::FPURestriction::SP_D16)
+return ARM::FK_INVALID;
+
+  // Otherwise, look for an FPU entry with all the same fields, except
+  // that SP_D16 has been replaced with just D16, representing adding
+  // double precision and not changing anything else.
+  for (const ARM::FPUName  : ARM::FPUNames) {
+if (CandidateFPU.FPUVer == InputFPU.FPUVer &&
+CandidateFPU.NeonSupport == InputFPU.NeonSupport &&
+CandidateFPU.Restriction == ARM::FPURestriction::D16) {
+  return CandidateFPU.ID;
+}
+  }
+
+  // nothing found
+  return ARM::FK_INVALID;
+}
+
+bool ARM::appendArchExtFeatures(
+  StringRef CPU, ARM::ArchKind AK, StringRef ArchExt,
+  std::vector ) {
+  StringRef StandardFeature = getArchExtFeature(ArchExt);
+  if (!StandardFeature.empty()) {
+Features.push_back(StandardFeature);
+return true;
+  }
+
+  const bool Negated = stripNegationPrefix(ArchExt);
+
+  if (CPU == "")
+CPU = "generic";
+
+  if (ArchExt == "fp" || ArchExt == "fp.dp") {
+unsigned FPUKind;
+if (ArchExt == "fp.dp") {
+  if (Negated) {
+Features.push_back("-fp64");
+return true;
+  }
+  FPUKind = findDoublePrecisionFPU(getDefaultFPU(CPU, AK));
+} else if (Negated) {
+  FPUKind = ARM::FK_NONE;
+} else {
+  FPUKind = getDefaultFPU(CPU, AK);
+}
+return ARM::getFPUFeatures(FPUKind, Features);
+  }
+  return false;
+}
+
 StringRef ARM::getHWDivName(unsigned HWDivKind) {
   for (const auto D : HWDivNames) {
 if (HWDivKind == D.ID)
Index: llvm/include/llvm/Support/ARMTargetParser.h
===
--- llvm/include/llvm/Support/ARMTargetParser.h
+++ llvm/include/llvm/Support/ARMTargetParser.h
@@ 

[PATCH] D62814: [clangd] Treat lambdas as functions when preparing hover response

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/unittests/XRefsTests.cpp:831
+ };
  return HI;
}},

ilya-biryukov wrote:
> kadircet wrote:
> > ilya-biryukov wrote:
> > > Could you add another test with even weirder types where we fail to show 
> > > the signature? To make sure we don't break when reaching the limitations 
> > > of the chosen approach and document what those limitations are.
> > > 
> > > Something like:
> > > ```
> > > auto a = [](int a) { return 10; };
> > > auto *b = 
> > > auto *c = 
> > > ```
> > > 
> > > We would fail to show the signature here, but it's totally ok to ignore 
> > > it.
> > added cases, and changed code(a lot simpler now) to generate signatures for 
> > those cases as well.
> Here's an example when the new approach falls short too:
> 
> ```
> auto a = [](int) { return 10; }
> std::function b;
> ```
> 
> In general, are we ok with loosing all the information about the type that we 
> drop?
> One level of references and pointers seemed ok, dropping more is a bit more 
> cheesy..
> 
> At the same time, either case is **so** rare that we probably don't care.
are you talking about hovering over `x` ? I don't think AST contains 
information regarding that one. 

for a code like this:
```
auto foo = []() { return 5; };

template 
class Cls {};

Cls X;
```

This is the AST dump for variable X:
```
`-VarDecl 0x2b0e808  col:30 X 'Cls':'Cls' callinit
  `-CXXConstructExpr 0x2b12e80  'Cls':'Cls' 'void () noexcept'
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62814



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