[PATCH] D92936: [Sema] Fix deleted function problem in implicitly movable test

[Yang Fan via Phabricator via cfe-commits]

nullptr.cpp added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92936

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

[PATCH] D93683: [clangd] Do not take stale definition from the static index.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D93683#2469553 , @ArcsinX wrote:

> In D93683#2468842 , @sammccall wrote:
>
>> I'm not 100% sure this bug would block adding the equivalent change for 
>> `fuzzyFind` though - it'll affect documentSymbol but not code-completion 
>> IIUC (because of the workaround I mentioned above). And these symbols are 
>> pretty rare.
>
> With the similar change for `fuzzyFind()`, `WorkspaceSymbols.Macros` test 
> fails. But maybe I can create one more review for this and we will discuss it 
> there.

Sorry, incomplete thought. I meant workspace/symbols would be broken for such 
macros, but maybe that was acceptable (it's not a terrible common feature nor 
symbol kind). Not great but we're trading one bug for another.
In particular, if we plan to fix both I don't think the *sequencing* matters.




Comment at: clang-tools-extra/clangd/index/FileIndex.cpp:434
+  PreambleSymbols.update(
+  *FilePath, std::make_unique(std::move(*IF->Symbols)),
+  std::make_unique(),

ArcsinX wrote:
> sammccall wrote:
> > ArcsinX wrote:
> > > We do not need this change to fix behaviour for removed definition, but 
> > > this is the only one place where we use URI instead of path as a key.
> > Yeah... nevertheless the key is totally arbitrary here, so we might as well 
> > use whatever is most convenient/cheapest.
> It's not arbitrary after D93393 (we use these keys to create the list of 
> indexed files).
> 
> But as it turns, the problem is deeper... I will try to explain.
> Preamble index does not contain references, so with that change our logic 
> about "file X is in the dynamic index, so toss references with location in X 
> from the static index" breaks here, seems we can not think about preamble 
> index that it is a part of the dynamic index for the background index 
> (static). I wonder why tests do not catch this, but with this change 
> find-all-references does not contain refs from headers for which we have 
> preamble index, that's why I reverted this. Maybe we need to add some comment 
> here about this behavior.
> Example:
> `test.h`
> ```
> void test();
> ```
> `test.c`
> ```
> #include "test.h"
> void te^st {}
> ```
> 
> - didOpen `test.c`
> - references (where ^ is)
> With this change only 1 element will be returned (definition of `test` in 
> `test.c` and nothing from `test.h`)
> 
> I am not sure what we can do here, but I think we need some special merge for 
> preamble and main file indexes (another merge class for this case instead of 
> `MergedIndex`?)
> Preamble index does not contain references, so with that change our logic 
> about "file X is in the dynamic index, so toss references with location in X 
> from the static index" breaks

Hmm, what if we made the return value of the indexedFiles functor a bitmask 
instead of a single boolean (contains symbols, contains refs, ...)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93683

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

[PATCH] D93683: [clangd] Do not take stale definition from the static index.

[Aleksandr Platonov via Phabricator via cfe-commits]

ArcsinX updated this revision to Diff 313504.
ArcsinX added a comment.

Add comment.
Fix possible `MergeIndexTest.LookupRemovedDefinition` test failure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93683

Files:
  clang-tools-extra/clangd/index/Merge.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
@@ -290,6 +290,40 @@
   EXPECT_THAT(lookup(M, {}), UnorderedElementsAre());
 }
 
+TEST(MergeIndexTest, LookupRemovedDefinition) {
+  FileIndex DynamicIndex, StaticIndex;
+  MergedIndex Merge(&DynamicIndex, &StaticIndex);
+
+  const char *HeaderCode = "class Foo;";
+  auto HeaderSymbols = TestTU::withHeaderCode(HeaderCode).headerSymbols();
+  auto Foo = findSymbol(HeaderSymbols, "Foo");
+
+  // Build static index for test.cc with Foo definition
+  TestTU Test;
+  Test.HeaderCode = HeaderCode;
+  Test.Code = "class Foo {};";
+  Test.Filename = "test.cc";
+  auto AST = Test.build();
+  StaticIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Remove Foo definition from test.cc, i.e. build dynamic index for test.cc
+  // without Foo definition.
+  Test.Code = "class Foo;";
+  AST = Test.build();
+  DynamicIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Merged index should not return the symbol definition if this definition
+  // location is inside a file from the dynamic index.
+  LookupRequest LookupReq;
+  LookupReq.IDs = {Foo.ID};
+  unsigned SymbolCounter = 0;
+  Merge.lookup(LookupReq, [&](const Symbol &Sym) {
+++SymbolCounter;
+EXPECT_FALSE(Sym.Definition);
+  });
+  EXPECT_EQ(SymbolCounter, 1u);
+}
+
 TEST(MergeIndexTest, FuzzyFind) {
   auto I = MemIndex::build(generateSymbols({"ns::A", "ns::B"}), RefSlab(),
RelationSlab()),
Index: clang-tools-extra/clangd/index/Merge.cpp
===
--- clang-tools-extra/clangd/index/Merge.cpp
+++ clang-tools-extra/clangd/index/Merge.cpp
@@ -76,7 +76,13 @@
   Dynamic->lookup(Req, [&](const Symbol &S) { B.insert(S); });
 
   auto RemainingIDs = Req.IDs;
+  auto DynamicContainsFile = Dynamic->indexedFiles();
   Static->lookup(Req, [&](const Symbol &S) {
+// We expect the definition to see the canonical declaration, so it seems
+// to be enough to check only the definition if it exists.
+if (DynamicContainsFile(S.Definition ? S.Definition.FileURI
+ : S.CanonicalDeclaration.FileURI))
+  return;
 const Symbol *Sym = B.find(S.ID);
 RemainingIDs.erase(S.ID);
 if (!Sym)


Index: clang-tools-extra/clangd/unittests/IndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/IndexTests.cpp
+++ clang-tools-extra/clangd/unittests/IndexTests.cpp
@@ -290,6 +290,40 @@
   EXPECT_THAT(lookup(M, {}), UnorderedElementsAre());
 }
 
+TEST(MergeIndexTest, LookupRemovedDefinition) {
+  FileIndex DynamicIndex, StaticIndex;
+  MergedIndex Merge(&DynamicIndex, &StaticIndex);
+
+  const char *HeaderCode = "class Foo;";
+  auto HeaderSymbols = TestTU::withHeaderCode(HeaderCode).headerSymbols();
+  auto Foo = findSymbol(HeaderSymbols, "Foo");
+
+  // Build static index for test.cc with Foo definition
+  TestTU Test;
+  Test.HeaderCode = HeaderCode;
+  Test.Code = "class Foo {};";
+  Test.Filename = "test.cc";
+  auto AST = Test.build();
+  StaticIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Remove Foo definition from test.cc, i.e. build dynamic index for test.cc
+  // without Foo definition.
+  Test.Code = "class Foo;";
+  AST = Test.build();
+  DynamicIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Merged index should not return the symbol definition if this definition
+  // location is inside a file from the dynamic index.
+  LookupRequest LookupReq;
+  LookupReq.IDs = {Foo.ID};
+  unsigned SymbolCounter = 0;
+  Merge.lookup(LookupReq, [&](const Symbol &Sym) {
+++SymbolCounter;
+EXPECT_FALSE(Sym.Definition);
+  });
+  EXPECT_EQ(SymbolCounter, 1u);
+}
+
 TEST(MergeIndexTest, FuzzyFind) {
   auto I = MemIndex::build(generateSymbols({"ns::A", "ns::B"}), RefSlab(),
RelationSlab()),
Index: clang-tools-extra/clangd/index/Merge.cpp
===
--- clang-tools-extra/clangd/index/Merge.cpp
+++ clang-tools-extra/clangd/index/Merge.cpp
@@ -76,7 +76,13 @@
   Dynamic->lookup(Req, [&](const Symbol &S) { B.insert(S); });
 
   auto RemainingIDs = Req.IDs;
+  auto DynamicContainsFile = Dynamic->indexedFiles();
   Static->lookup(Req, [&](const Symbol &S) {
+// We expect the definition to see the canonical declaration, so it seems
+// to be enough to 

[PATCH] D93683: [clangd] Do not take stale definition from the static index.

[Aleksandr Platonov via Phabricator via cfe-commits]

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

In D93683#2469584 , @sammccall wrote:

> In D93683#2469553 , @ArcsinX wrote:
>
>> In D93683#2468842 , @sammccall 
>> wrote:
>>
>>> I'm not 100% sure this bug would block adding the equivalent change for 
>>> `fuzzyFind` though - it'll affect documentSymbol but not code-completion 
>>> IIUC (because of the workaround I mentioned above). And these symbols are 
>>> pretty rare.
>>
>> With the similar change for `fuzzyFind()`, `WorkspaceSymbols.Macros` test 
>> fails. But maybe I can create one more review for this and we will discuss 
>> it there.
>
> Sorry, incomplete thought. I meant workspace/symbols would be broken for such 
> macros, but maybe that was acceptable (it's not a terrible common feature nor 
> symbol kind). Not great but we're trading one bug for another.
> In particular, if we plan to fix both I don't think the *sequencing* matters.

Ok. I will propose a separate patch for `fuzzyFind()` similar to this one.

Thank you for review.




Comment at: clang-tools-extra/clangd/index/FileIndex.cpp:434
+  PreambleSymbols.update(
+  *FilePath, std::make_unique(std::move(*IF->Symbols)),
+  std::make_unique(),

sammccall wrote:
> ArcsinX wrote:
> > sammccall wrote:
> > > ArcsinX wrote:
> > > > We do not need this change to fix behaviour for removed definition, but 
> > > > this is the only one place where we use URI instead of path as a key.
> > > Yeah... nevertheless the key is totally arbitrary here, so we might as 
> > > well use whatever is most convenient/cheapest.
> > It's not arbitrary after D93393 (we use these keys to create the list of 
> > indexed files).
> > 
> > But as it turns, the problem is deeper... I will try to explain.
> > Preamble index does not contain references, so with that change our logic 
> > about "file X is in the dynamic index, so toss references with location in 
> > X from the static index" breaks here, seems we can not think about preamble 
> > index that it is a part of the dynamic index for the background index 
> > (static). I wonder why tests do not catch this, but with this change 
> > find-all-references does not contain refs from headers for which we have 
> > preamble index, that's why I reverted this. Maybe we need to add some 
> > comment here about this behavior.
> > Example:
> > `test.h`
> > ```
> > void test();
> > ```
> > `test.c`
> > ```
> > #include "test.h"
> > void te^st {}
> > ```
> > 
> > - didOpen `test.c`
> > - references (where ^ is)
> > With this change only 1 element will be returned (definition of `test` in 
> > `test.c` and nothing from `test.h`)
> > 
> > I am not sure what we can do here, but I think we need some special merge 
> > for preamble and main file indexes (another merge class for this case 
> > instead of `MergedIndex`?)
> > Preamble index does not contain references, so with that change our logic 
> > about "file X is in the dynamic index, so toss references with location in 
> > X from the static index" breaks
> 
> Hmm, what if we made the return value of the indexedFiles functor a bitmask 
> instead of a single boolean (contains symbols, contains refs, ...)?
This sounds reasonable. I will try to implement a solution for this problem 
based on your suggestion (in a separate patch)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93683

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

[PATCH] D86844: [LoopDeletion] Allows deletion of possibly infinite side-effect free loops

[Florian Hahn via Phabricator via cfe-commits]

fhahn added inline comments.



Comment at: llvm/test/Other/loop-deletion-printer.ll:17
 
-define void @deleteme() {
+define void @deleteme() willreturn {
 entry:

atmnpatel wrote:
> fhahn wrote:
> > Is this change related to the patch? Same for the other test changes that 
> > just add `willreturn`?
> Yep, if these test functions aren't marked willreturn, we won't delete the 
> loop because it could be a legal infinite loop from C/C++.
I don't think that is the case here. The trip count of the loop here is 
constant, so it cannot be infinite. Also, the existing code already removes the 
loop, without `willreturn`, as implied by no changes to the check lines? 

I did not check all other cases, but I would expect that `willreturn` does not 
need to be added to cases where the trip count is a known constant and that 
already get removed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86844

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

[clang] 25a02c3 - Revert "PR24076, PR33655, C++ CWG 1558: Consider the instantiation-dependence of"

[Adrian Kuegel via cfe-commits]

Author: Adrian Kuegel
Date: 2020-12-23T12:31:52+01:00
New Revision: 25a02c3d1a688d3cd18faef96c75fa553efbbac7

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

LOG: Revert "PR24076, PR33655, C++ CWG 1558: Consider the 
instantiation-dependence of"

This reverts commit d3bf0bb18952d830fe6df6f791a64552b271000b.
This causes compilation in certain cases to fail.
Reproducer TBD.

Added: 


Modified: 
clang/include/clang/AST/Type.h
clang/lib/AST/ItaniumMangle.cpp
clang/test/CXX/drs/dr15xx.cpp
clang/test/CodeGenCXX/mangle-template.cpp
clang/test/SemaTemplate/partial-spec-instantiate.cpp
clang/www/cxx_dr_status.html

Removed: 
clang/test/SemaTemplate/instantiation-dependence.cpp



diff  --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index 21c8bf79152e..684005c4876d 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -5411,9 +5411,7 @@ class ElaboratedType final
   ElaboratedType(ElaboratedTypeKeyword Keyword, NestedNameSpecifier *NNS,
  QualType NamedType, QualType CanonType, TagDecl *OwnedTagDecl)
   : TypeWithKeyword(Keyword, Elaborated, CanonType,
-NamedType->getDependence() |
-(NNS ? toTypeDependence(NNS->getDependence())
- : TypeDependence::None)),
+NamedType->getDependence()),
 NNS(NNS), NamedType(NamedType) {
 ElaboratedTypeBits.HasOwnedTagDecl = false;
 if (OwnedTagDecl) {

diff  --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 6c8d5687c64a..73c8f17a5d36 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -2578,10 +2578,6 @@ void CXXNameMangler::mangleType(QualType T) {
 if (!TST->isTypeAlias())
   break;
 
-  // FIXME: We presumably shouldn't strip off ElaboratedTypes with
-  // instantation-dependent qualifiers. See
-  // https://github.com/itanium-cxx-abi/cxx-abi/issues/114.
-
   QualType Desugared
 = T.getSingleStepDesugaredType(Context.getASTContext());
   if (Desugared == T)

diff  --git a/clang/test/CXX/drs/dr15xx.cpp b/clang/test/CXX/drs/dr15xx.cpp
index 8bfa29a8b667..478a0d7d00dd 100644
--- a/clang/test/CXX/drs/dr15xx.cpp
+++ b/clang/test/CXX/drs/dr15xx.cpp
@@ -239,20 +239,6 @@ namespace dr1550 { // dr1550: yes
   }
 }
 
-namespace dr1558 { // dr1558: 12
-#if __cplusplus >= 201103L
-  template using first_of = T;
-  template first_of f(int); // expected-note 
{{'int' cannot be used prior to '::'}}
-  template void f(...) = delete; // expected-note {{deleted}}
-
-  struct X { typedef void type; };
-  void test() {
-f(0);
-f(0); // expected-error {{deleted}}
-  }
-#endif
-}
-
 namespace dr1560 { // dr1560: 3.5
   void f(bool b, int n) {
 (b ? throw 0 : n) = (b ? n : throw 0) = 0;

diff  --git a/clang/test/CodeGenCXX/mangle-template.cpp 
b/clang/test/CodeGenCXX/mangle-template.cpp
index 40688de7e12e..9b5220572c2e 100644
--- a/clang/test/CodeGenCXX/mangle-template.cpp
+++ b/clang/test/CodeGenCXX/mangle-template.cpp
@@ -342,23 +342,3 @@ namespace fixed_size_parameter_pack {
   template void f(A::B<0, Ns...>);
   void g() { f<1, 2>({}); }
 }
-
-namespace type_qualifier {
-  template using int_t = int;
-  template void f(decltype(int_t() + 1)) {}
-  // FIXME: This mangling doesn't work: we need to mangle the
-  // instantiation-dependent 'int_t' operand.
-  // CHECK: @_ZN14type_qualifier1fIPiEEvDTplcvi_ELi1EE
-  template void f(int);
-
-  // Note that this template has 
diff erent constraints but would mangle the
-  // same:
-  //template void f(decltype(int_t() + 1)) {}
-
-  struct impl { using type = void; };
-  template using alias = impl;
-  template void g(decltype(alias::type(), 1)) {}
-  // FIXME: Similarly we need to mangle the `T*` in here.
-  // CHECK: @_ZN14type_qualifier1gIPiEEvDTcmcvv_ELi1EE
-  template void g(int);
-}

diff  --git a/clang/test/SemaTemplate/instantiation-dependence.cpp 
b/clang/test/SemaTemplate/instantiation-dependence.cpp
deleted file mode 100644
index 75eb510cb68d..
--- a/clang/test/SemaTemplate/instantiation-dependence.cpp
+++ /dev/null
@@ -1,74 +0,0 @@
-// RUN: %clang_cc1 -std=c++2b -verify %s
-
-// Ensure we substitute into instantiation-dependent but non-dependent
-// constructs. The poster-child for this is...
-template using void_t = void;
-
-namespace PR24076 {
-  template T declval();
-  struct s {};
-
-  template() + 1)>>
-void foo(T) {} // expected-note {{invalid operands to binary expression}}
-
-  void f() {
-foo(s{}); // expected-error {{no matching function}}
-  }
-
-  template() + 1)>> // expected-error 
{{invalid operands to binary expression}}
-  struct bar {};
-
-  bar b

[PATCH] D93733: [NFC] replace resize calls with resize_for_overwrite

[Nathan James via Phabricator via cfe-commits]

njames93 created this revision.
Herald added subscribers: dexonsmith, asbirlea, hiraditya.
njames93 published this revision for review.
Herald added projects: clang, LLDB, LLVM.
Herald added subscribers: llvm-commits, lldb-commits, cfe-commits.

Also replace a few calls to resize followed by zeroing the data to calling 
assign(size, 0).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93733

Files:
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/lib/Lex/Lexer.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Sema/SemaExpr.cpp
  lldb/source/Core/ValueObject.cpp
  lldb/source/Host/common/LZMA.cpp
  lldb/source/Utility/VASprintf.cpp
  llvm/lib/CodeGen/MachineLICM.cpp
  llvm/lib/CodeGen/TargetSchedule.cpp
  llvm/lib/DebugInfo/CodeView/TypeStreamMerger.cpp
  llvm/lib/DebugInfo/DWARF/DWARFAcceleratorTable.cpp
  llvm/lib/MC/MCAsmStreamer.cpp
  llvm/lib/MC/MCDwarf.cpp
  llvm/lib/MC/MCParser/AsmParser.cpp
  llvm/lib/MC/MCParser/MasmParser.cpp
  llvm/lib/MC/MCStreamer.cpp
  llvm/lib/MC/StringTableBuilder.cpp
  llvm/lib/MC/WinCOFFObjectWriter.cpp
  llvm/lib/Object/IRSymtab.cpp
  llvm/lib/Object/MachOObjectFile.cpp
  llvm/lib/Support/ConvertUTFWrapper.cpp
  llvm/lib/Support/PrettyStackTrace.cpp
  llvm/lib/Support/raw_ostream.cpp

Index: llvm/lib/Support/raw_ostream.cpp
===
--- llvm/lib/Support/raw_ostream.cpp
+++ llvm/lib/Support/raw_ostream.cpp
@@ -331,7 +331,7 @@
   SmallVector V;
 
   while (true) {
-V.resize(NextBufferSize);
+V.resize_for_overwrite(NextBufferSize);
 
 // Try formatting into the SmallVector.
 size_t BytesUsed = Fmt.print(V.data(), NextBufferSize);
Index: llvm/lib/Support/PrettyStackTrace.cpp
===
--- llvm/lib/Support/PrettyStackTrace.cpp
+++ llvm/lib/Support/PrettyStackTrace.cpp
@@ -243,7 +243,7 @@
   }
 
   const int Size = SizeOrError + 1; // '\0'
-  Str.resize(Size);
+  Str.resize_for_overwrite(Size);
   va_start(AP, Format);
   vsnprintf(Str.data(), Size, Format, AP);
   va_end(AP);
Index: llvm/lib/Support/ConvertUTFWrapper.cpp
===
--- llvm/lib/Support/ConvertUTFWrapper.cpp
+++ llvm/lib/Support/ConvertUTFWrapper.cpp
@@ -160,7 +160,7 @@
   // UTF-8 encoding.  Allocate one extra byte for the null terminator though,
   // so that someone calling DstUTF16.data() gets a null terminated string.
   // We resize down later so we don't have to worry that this over allocates.
-  DstUTF16.resize(SrcUTF8.size()+1);
+  DstUTF16.resize_for_overwrite(SrcUTF8.size() + 1);
   UTF16 *Dst = &DstUTF16[0];
   UTF16 *DstEnd = Dst + DstUTF16.size();
 
Index: llvm/lib/Object/MachOObjectFile.cpp
===
--- llvm/lib/Object/MachOObjectFile.cpp
+++ llvm/lib/Object/MachOObjectFile.cpp
@@ -867,7 +867,7 @@
   " LC_BUILD_VERSION_COMMAND has incorrect cmdsize");
 
   auto Start = Load.Ptr + sizeof(MachO::build_version_command);
-  BuildTools.resize(BVC.ntools);
+  BuildTools.resize_for_overwrite(BVC.ntools);
   for (unsigned i = 0; i < BVC.ntools; ++i)
 BuildTools[i] = Start + i * sizeof(MachO::build_tool_version);
 
Index: llvm/lib/Object/IRSymtab.cpp
===
--- llvm/lib/Object/IRSymtab.cpp
+++ llvm/lib/Object/IRSymtab.cpp
@@ -327,7 +327,7 @@
 
   // We are about to fill in the header's range fields, so reserve space for it
   // and copy it in afterwards.
-  Symtab.resize(sizeof(storage::Header));
+  Symtab.resize_for_overwrite(sizeof(storage::Header));
   writeRange(Hdr.Modules, Mods);
   writeRange(Hdr.Comdats, Comdats);
   writeRange(Hdr.Symbols, Syms);
@@ -370,7 +370,7 @@
 return std::move(E);
 
   StrtabBuilder.finalizeInOrder();
-  FC.Strtab.resize(StrtabBuilder.getSize());
+  FC.Strtab.resize_for_overwrite(StrtabBuilder.getSize());
   StrtabBuilder.write((uint8_t *)FC.Strtab.data());
 
   FC.TheReader = {{FC.Symtab.data(), FC.Symtab.size()},
Index: llvm/lib/MC/WinCOFFObjectWriter.cpp
===
--- llvm/lib/MC/WinCOFFObjectWriter.cpp
+++ llvm/lib/MC/WinCOFFObjectWriter.cpp
@@ -860,7 +860,7 @@
 COFFSymbol *File = createSymbol(".file");
 File->Data.SectionNumber = COFF::IMAGE_SYM_DEBUG;
 File->Data.StorageClass = COFF::IMAGE_SYM_CLASS_FILE;
-File->Aux.resize(Count);
+File->Aux.resize_for_overwrite(Count);
 
 unsigned Offset = 0;
 unsigned Length = Name.size();
Index: llvm/lib/MC/StringTableBuilder.cpp
===
--- llvm/lib/MC/StringTableBuilder.cpp
+++ llvm/lib/MC/StringTableBuilder.cpp
@@ -59,7 +59,7 @@
 void StringTableBuilder::write(raw_ostream &OS) const {
   assert(isFinalized());
   SmallSt

[PATCH] D93758: [format][NFC] Use unsigned char as the base of all enums in FormatStyle

[Nathan James via Phabricator via cfe-commits]

njames93 created this revision.
njames93 added a reviewer: MyDeveloperDay.
njames93 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This removes alot of unnecessary padding, trimming the size of the struct from 
728->608 on 64 bit platforms.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93758

Files:
  clang/include/clang/Format/Format.h

Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -56,7 +56,7 @@
   int AccessModifierOffset;
 
   /// Different styles for aligning after open brackets.
-  enum BracketAlignmentStyle {
+  enum BracketAlignmentStyle : unsigned char {
 /// Align parameters on the open bracket, e.g.:
 /// \code
 ///   someLongFunction(argument1,
@@ -131,7 +131,7 @@
   bool AlignConsecutiveDeclarations;
 
   /// Different styles for aligning escaped newlines.
-  enum EscapedNewlineAlignmentStyle {
+  enum EscapedNewlineAlignmentStyle : unsigned char {
 /// Don't align escaped newlines.
 /// \code
 ///   #define A \
@@ -165,7 +165,7 @@
   EscapedNewlineAlignmentStyle AlignEscapedNewlines;
 
   /// Different styles for aligning operands.
-  enum OperandAlignmentStyle {
+  enum OperandAlignmentStyle : unsigned char {
 /// Do not align operands of binary and ternary expressions.
 /// The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
 /// the start of the line.
@@ -275,7 +275,7 @@
 
   /// Different styles for merging short blocks containing at most one
   /// statement.
-  enum ShortBlockStyle {
+  enum ShortBlockStyle : unsigned char {
 /// Never merge blocks into a single line.
 /// \code
 ///   while (true) {
@@ -320,7 +320,7 @@
 
   /// Different styles for merging short functions containing at most one
   /// statement.
-  enum ShortFunctionStyle {
+  enum ShortFunctionStyle : unsigned char {
 /// Never merge functions into a single line.
 SFS_None,
 /// Only merge functions defined inside a class. Same as "inline",
@@ -371,7 +371,7 @@
   ShortFunctionStyle AllowShortFunctionsOnASingleLine;
 
   /// Different styles for handling short if lines
-  enum ShortIfStyle {
+  enum ShortIfStyle : unsigned char {
 /// Never put short ifs on the same line.
 /// \code
 ///   if (a)
@@ -405,7 +405,7 @@
 
   /// Different styles for merging short lambdas containing at most one
   /// statement.
-  enum ShortLambdaStyle {
+  enum ShortLambdaStyle : unsigned char {
 /// Never merge lambdas into a single line.
 SLS_None,
 /// Only merge empty lambdas.
@@ -442,7 +442,7 @@
 
   /// Different ways to break after the function definition return type.
   /// This option is **deprecated** and is retained for backwards compatibility.
-  enum DefinitionReturnTypeBreakingStyle {
+  enum DefinitionReturnTypeBreakingStyle : unsigned char {
 /// Break after return type automatically.
 /// ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
 DRTBS_None,
@@ -454,7 +454,7 @@
 
   /// Different ways to break after the function definition or
   /// declaration return type.
-  enum ReturnTypeBreakingStyle {
+  enum ReturnTypeBreakingStyle : unsigned char {
 /// Break after return type automatically.
 /// ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
 /// \code
@@ -545,7 +545,7 @@
   bool AlwaysBreakBeforeMultilineStrings;
 
   /// Different ways to break after the template declaration.
-  enum BreakTemplateDeclarationsStyle {
+  enum BreakTemplateDeclarationsStyle : unsigned char {
 /// Do not force break before declaration.
 /// ``PenaltyBreakTemplateDeclaration`` is taken into account.
 /// \code
@@ -620,7 +620,7 @@
   bool BinPackArguments;
 
   /// The style of inserting trailing commas into container literals.
-  enum TrailingCommaStyle {
+  enum TrailingCommaStyle : unsigned char {
 /// Do not insert trailing commas.
 TCS_None,
 /// Insert trailing commas in container literals that were wrapped over
@@ -664,7 +664,7 @@
 
   /// The style of wrapping parameters on the same line (bin-packed) or
   /// on one line each.
-  enum BinPackStyle {
+  enum BinPackStyle : unsigned char {
 /// Automatically determine parameter bin-packing behavior.
 BPS_Auto,
 /// Always bin-pack parameters.
@@ -674,7 +674,7 @@
   };
 
   /// The style of breaking before or after binary operators.
-  enum BinaryOperatorStyle {
+  enum BinaryOperatorStyle : unsigned char {
 /// Break after operators.
 /// \code
 ///LooongType loongVariable =
@@ -717,7 +717,7 @@
   BinaryOperatorStyle BreakBeforeBinaryOperators;
 
   /// Different ways to attach braces to their surrounding context.
-  enum BraceBreakingStyle {
+  enum BraceBreakingStyle : unsigned char {
 /// Always attach braces to surrounding context.

[PATCH] D93600: [clangd] When querying drivers by binary, look in PATH too

[Giulio Girardi via Phabricator via cfe-commits]

rapgenic updated this revision to Diff 313528.

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

https://reviews.llvm.org/D93600

Files:
  clang-tools-extra/clangd/QueryDriverDatabase.cpp
  clang-tools-extra/clangd/test/system-include-extractor.test


Index: clang-tools-extra/clangd/test/system-include-extractor.test
===
--- clang-tools-extra/clangd/test/system-include-extractor.test
+++ clang-tools-extra/clangd/test/system-include-extractor.test
@@ -3,21 +3,24 @@
 # The mock driver below is a shell script:
 # REQUIRES: shell
 
+# Create a bin directory to store the mock-driver and add it to the path
+# RUN: mkdir -p %t.dir/bin
+# RUN: export PATH=%t.dir/bin:$PATH
 # Generate a mock-driver that will print %temp_dir%/my/dir and
 # %temp_dir%/my/dir2 as include search paths.
-# RUN: echo '#!/bin/sh' >> %t.dir/my_driver.sh
-# RUN: echo '[ "$0" = "%t.dir/my_driver.sh" ] || exit' >> %t.dir/my_driver.sh
-# RUN: echo 'args="$*"' >> %t.dir/my_driver.sh
-# RUN: echo '[ -z "${args##*"-nostdinc"*}" ] || exit' >> %t.dir/my_driver.sh
-# RUN: echo '[ -z "${args##*"-isysroot=/isysroot"*}" ] || exit' >> 
%t.dir/my_driver.sh
-# RUN: echo 'echo " $* " | grep " --sysroot /my/sysroot/path " || exit' >> 
%t.dir/my_driver.sh
-# RUN: echo 'echo line to ignore >&2' >> %t.dir/my_driver.sh
-# RUN: echo 'printf "Target: arm-linux-gnueabihf\r\n" >&2' >> 
%t.dir/my_driver.sh
-# RUN: echo 'printf "#include <...> search starts here:\r\n" >&2' >> 
%t.dir/my_driver.sh
-# RUN: echo 'echo %t.dir/my/dir/ >&2' >> %t.dir/my_driver.sh
-# RUN: echo 'echo %t.dir/my/dir2/ >&2' >> %t.dir/my_driver.sh
-# RUN: echo 'printf "End of search list.\r\n" >&2' >> %t.dir/my_driver.sh
-# RUN: chmod +x %t.dir/my_driver.sh
+# RUN: echo '#!/bin/sh' >> %t.dir/bin/my_driver.sh
+# RUN: echo '[ "$0" = "%t.dir/bin/my_driver.sh" ] || exit' >> 
%t.dir/bin/my_driver.sh
+# RUN: echo 'args="$*"' >> %t.dir/bin/my_driver.sh
+# RUN: echo '[ -z "${args##*"-nostdinc"*}" ] || exit' >> 
%t.dir/bin/my_driver.sh
+# RUN: echo '[ -z "${args##*"-isysroot=/isysroot"*}" ] || exit' >> 
%t.dir/bin/my_driver.sh
+# RUN: echo 'echo " $* " | grep " --sysroot /my/sysroot/path " || exit' >> 
%t.dir/bin/my_driver.sh
+# RUN: echo 'echo line to ignore >&2' >> %t.dir/bin/my_driver.sh
+# RUN: echo 'printf "Target: arm-linux-gnueabihf\r\n" >&2' >> 
%t.dir/bin/my_driver.sh
+# RUN: echo 'printf "#include <...> search starts here:\r\n" >&2' >> 
%t.dir/bin/my_driver.sh
+# RUN: echo 'echo %t.dir/my/dir/ >&2' >> %t.dir/bin/my_driver.sh
+# RUN: echo 'echo %t.dir/my/dir2/ >&2' >> %t.dir/bin/my_driver.sh
+# RUN: echo 'printf "End of search list.\r\n" >&2' >> %t.dir/bin/my_driver.sh
+# RUN: chmod +x %t.dir/bin/my_driver.sh
 
 # Create header files my/dir/a.h and my/dir2/b.h
 # RUN: mkdir -p %t.dir/my/dir
@@ -27,7 +30,7 @@
 
 # Generate a compile_commands.json that will query the mock driver we've
 # created. Which should add a.h and b.h into include search path.
-# RUN: echo '[{"directory": "%/t.dir", "command": "%/t.dir/my_driver.sh 
the-file.cpp -nostdinc --sysroot /my/sysroot/path -isysroot=/isysroot", "file": 
"the-file.cpp"}]' > %t.dir/compile_commands.json
+# RUN: echo '[{"directory": "%/t.dir", "command": "my_driver.sh the-file.cpp 
-nostdinc --sysroot /my/sysroot/path -isysroot=/isysroot", "file": 
"the-file.cpp"}]' > %t.dir/compile_commands.json
 
 # RUN: sed -e "s|INPUT_DIR|%/t.dir|g" %s > %t.test.1
 # On Windows, we need the URI in didOpen to look like "uri":"file:///C:/..."
Index: clang-tools-extra/clangd/QueryDriverDatabase.cpp
===
--- clang-tools-extra/clangd/QueryDriverDatabase.cpp
+++ clang-tools-extra/clangd/QueryDriverDatabase.cpp
@@ -136,10 +136,26 @@
 }
 
 llvm::Optional
-extractSystemIncludesAndTarget(PathRef Driver, llvm::StringRef Lang,
+extractSystemIncludesAndTarget(llvm::SmallString<128> Driver,
+   llvm::StringRef Lang,
llvm::ArrayRef CommandLine,
const llvm::Regex &QueryDriverRegex) {
   trace::Span Tracer("Extract system includes and target");
+
+  if (!llvm::sys::path::is_absolute(Driver)) {
+assert(llvm::none_of(
+Driver, [](char C) { return llvm::sys::path::is_separator(C); }));
+auto DriverProgram = llvm::sys::findProgramByName(Driver);
+if (DriverProgram) {
+  vlog("System include extraction: driver {0} expanded to {1}", Driver,
+   *DriverProgram);
+  Driver = *DriverProgram;
+} else {
+  elog("System include extraction: driver {0} not found in PATH", Driver);
+  return llvm::None;
+}
+  }
+
   SPAN_ATTACH(Tracer, "driver", Driver);
   SPAN_ATTACH(Tracer, "lang", Lang);
 
@@ -332,7 +348,11 @@
 }
 
 llvm::SmallString<128> Driver(Cmd->CommandLine.front());
-llvm::sys::fs::make_absolute(Cmd->Directory, Driver);
+if (llvm::any_of(Driver,
+   [](char C) { retur

[PATCH] D93600: [clangd] When querying drivers by binary, look in PATH too

[Giulio Girardi via Phabricator via cfe-commits]

rapgenic marked 3 inline comments as done.
rapgenic added a comment.

Done! My email is:

Giulio Girardi 

Thank you for your help!


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

https://reviews.llvm.org/D93600

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

[clang] eb9483b - [format] Add overload to parseConfiguration that accept llvm::MemoryBufferRef

[Nathan James via cfe-commits]

Author: Nathan James
Date: 2020-12-23T12:08:29Z
New Revision: eb9483b21053656b885f13ccfe41bfa76eb3df45

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

LOG: [format] Add overload to parseConfiguration that accept 
llvm::MemoryBufferRef

This overload should be used for better diagnostics when parsing configurations.
Now a failure to parse will list the filename (or ) instead of 
just `YAML`.

Reviewed By: MyDeveloperDay

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

Added: 


Modified: 
clang/include/clang/Format/Format.h
clang/lib/Format/Format.cpp
clang/test/Format/error-config.cpp

Removed: 




diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index fd5c0e32c5c2..208fc105d4b6 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -2879,7 +2879,8 @@ struct FormatStyle {
 private:
   FormatStyleSet StyleSet;
 
-  friend std::error_code parseConfiguration(StringRef Text, FormatStyle *Style,
+  friend std::error_code parseConfiguration(llvm::MemoryBufferRef Config,
+FormatStyle *Style,
 bool AllowUnknownOptions);
 };
 
@@ -2938,9 +2939,17 @@ bool getPredefinedStyle(StringRef Name, 
FormatStyle::LanguageKind Language,
 ///
 /// If AllowUnknownOptions is true, no errors are emitted if unknown
 /// format options are occured.
-std::error_code parseConfiguration(StringRef Text, FormatStyle *Style,
+std::error_code parseConfiguration(llvm::MemoryBufferRef Config,
+   FormatStyle *Style,
bool AllowUnknownOptions = false);
 
+/// Like above but accepts an unnamed buffer.
+inline std::error_code parseConfiguration(StringRef Config, FormatStyle *Style,
+  bool AllowUnknownOptions = false) {
+  return parseConfiguration(llvm::MemoryBufferRef(Config, "YAML"), Style,
+AllowUnknownOptions);
+}
+
 /// Gets configuration in a YAML string.
 std::string configurationAsText(const FormatStyle &Style);
 

diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 23eee19b1640..55abc12c61c4 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -1327,16 +1327,17 @@ bool getPredefinedStyle(StringRef Name, 
FormatStyle::LanguageKind Language,
   return true;
 }
 
-std::error_code parseConfiguration(StringRef Text, FormatStyle *Style,
+std::error_code parseConfiguration(llvm::MemoryBufferRef Config,
+   FormatStyle *Style,
bool AllowUnknownOptions) {
   assert(Style);
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
-  if (Text.trim().empty())
+  if (Config.getBuffer().trim().empty())
 return make_error_code(ParseError::Error);
   Style->StyleSet.Clear();
   std::vector Styles;
-  llvm::yaml::Input Input(Text);
+  llvm::yaml::Input Input(Config);
   // DocumentListTraits> uses the context to get default
   // values for the fields, keys for which are missing from the configuration.
   // Mapping also uses the context to get the language to find the correct
@@ -2864,8 +2865,9 @@ llvm::Expected getStyle(StringRef StyleName, 
StringRef FileName,
 
   if (StyleName.startswith("{")) {
 // Parse YAML/JSON style from the command line.
-if (std::error_code ec =
-parseConfiguration(StyleName, &Style, AllowUnknownOptions))
+if (std::error_code ec = parseConfiguration(
+llvm::MemoryBufferRef(StyleName, ""), &Style,
+AllowUnknownOptions))
   return make_string_error("Error parsing -style: " + ec.message());
 return Style;
   }
@@ -2909,8 +2911,8 @@ llvm::Expected getStyle(StringRef StyleName, 
StringRef FileName,
 FS->getBufferForFile(ConfigFile.str());
 if (std::error_code EC = Text.getError())
   return make_string_error(EC.message());
-if (std::error_code ec = parseConfiguration(
-Text.get()->getBuffer(), &Style, AllowUnknownOptions)) {
+if (std::error_code ec =
+parseConfiguration(*Text.get(), &Style, AllowUnknownOptions)) {
   if (ec == ParseError::Unsuitable) {
 if (!UnsuitableConfigFiles.empty())
   UnsuitableConfigFiles.append(", ");

diff  --git a/clang/test/Format/error-config.cpp 
b/clang/test/Format/error-config.cpp
index 7fbc869f3a3c..9f73a9eb9507 100644
--- a/clang/test/Format/error-config.cpp
+++ b/clang/test/Format/error-config.cpp
@@ -1,10 +1,10 @@
 // RUN: clang-format %s --Wno-error=unknown --style="{UnknownKey: true}" 2>&1 
| FileCheck %s -check-prefix=C

[PATCH] D93633: [format] Add overload to parseConfiguration that accept llvm::MemoryBufferRef

[Nathan James via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGeb9483b21053: [format] Add overload to parseConfiguration 
that accept llvm::MemoryBufferRef (authored by njames93).

Changed prior to commit:
  https://reviews.llvm.org/D93633?vs=313096&id=313530#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93633

Files:
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/test/Format/error-config.cpp


Index: clang/test/Format/error-config.cpp
===
--- clang/test/Format/error-config.cpp
+++ clang/test/Format/error-config.cpp
@@ -1,10 +1,10 @@
 // RUN: clang-format %s --Wno-error=unknown --style="{UnknownKey: true}" 2>&1 
| FileCheck %s -check-prefix=CHECK
 // RUN: not clang-format %s --style="{UnknownKey: true}" 2>&1 | FileCheck %s 
-check-prefix=CHECK-FAIL
 
-// CHECK: YAML:1:2: warning: unknown key 'UnknownKey'
+// CHECK: :1:2: warning: unknown key 'UnknownKey'
 // CHECK-NEXT: {UnknownKey: true}
 // CHECK-NEXT: ^~
-// CHECK-FAIL: YAML:1:2: error: unknown key 'UnknownKey'
+// CHECK-FAIL: :1:2: error: unknown key 'UnknownKey'
 // CHECK-FAIL-NEXT: {UnknownKey: true}
 // CHECK-FAIL-NEXT: ^~
 
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -1327,16 +1327,17 @@
   return true;
 }
 
-std::error_code parseConfiguration(StringRef Text, FormatStyle *Style,
+std::error_code parseConfiguration(llvm::MemoryBufferRef Config,
+   FormatStyle *Style,
bool AllowUnknownOptions) {
   assert(Style);
   FormatStyle::LanguageKind Language = Style->Language;
   assert(Language != FormatStyle::LK_None);
-  if (Text.trim().empty())
+  if (Config.getBuffer().trim().empty())
 return make_error_code(ParseError::Error);
   Style->StyleSet.Clear();
   std::vector Styles;
-  llvm::yaml::Input Input(Text);
+  llvm::yaml::Input Input(Config);
   // DocumentListTraits> uses the context to get default
   // values for the fields, keys for which are missing from the configuration.
   // Mapping also uses the context to get the language to find the correct
@@ -2864,8 +2865,9 @@
 
   if (StyleName.startswith("{")) {
 // Parse YAML/JSON style from the command line.
-if (std::error_code ec =
-parseConfiguration(StyleName, &Style, AllowUnknownOptions))
+if (std::error_code ec = parseConfiguration(
+llvm::MemoryBufferRef(StyleName, ""), &Style,
+AllowUnknownOptions))
   return make_string_error("Error parsing -style: " + ec.message());
 return Style;
   }
@@ -2909,8 +2911,8 @@
 FS->getBufferForFile(ConfigFile.str());
 if (std::error_code EC = Text.getError())
   return make_string_error(EC.message());
-if (std::error_code ec = parseConfiguration(
-Text.get()->getBuffer(), &Style, AllowUnknownOptions)) {
+if (std::error_code ec =
+parseConfiguration(*Text.get(), &Style, AllowUnknownOptions)) {
   if (ec == ParseError::Unsuitable) {
 if (!UnsuitableConfigFiles.empty())
   UnsuitableConfigFiles.append(", ");
Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -2879,7 +2879,8 @@
 private:
   FormatStyleSet StyleSet;
 
-  friend std::error_code parseConfiguration(StringRef Text, FormatStyle *Style,
+  friend std::error_code parseConfiguration(llvm::MemoryBufferRef Config,
+FormatStyle *Style,
 bool AllowUnknownOptions);
 };
 
@@ -2938,9 +2939,17 @@
 ///
 /// If AllowUnknownOptions is true, no errors are emitted if unknown
 /// format options are occured.
-std::error_code parseConfiguration(StringRef Text, FormatStyle *Style,
+std::error_code parseConfiguration(llvm::MemoryBufferRef Config,
+   FormatStyle *Style,
bool AllowUnknownOptions = false);
 
+/// Like above but accepts an unnamed buffer.
+inline std::error_code parseConfiguration(StringRef Config, FormatStyle *Style,
+  bool AllowUnknownOptions = false) {
+  return parseConfiguration(llvm::MemoryBufferRef(Config, "YAML"), Style,
+AllowUnknownOptions);
+}
+
 /// Gets configuration in a YAML string.
 std::string configurationAsText(const FormatStyle &Style);
 


Index: clang/test/Format/error-config.cpp
===
--- clang/test/Format/error-config.cpp
+++ clang/test/Format/error-config.cpp
@@ -1,10 +1,10 @@
 //

[PATCH] D93401: [flang][driver] Add support for `-D`, `-U`

[Faris via Phabricator via cfe-commits]

FarisRehman updated this revision to Diff 313532.
FarisRehman marked 5 inline comments as done.
FarisRehman added a comment.

Address review comments

This revision addresses comments by @awarzynski

Summary of changes:

- Update commit summary
- Use Doxygen style for input/output parameters
- Make method and variable names lowercase where required
- Remove unnecessary lines in added tests
- Update multiline macro test to have a stronger test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93401

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  clang/lib/Driver/ToolChains/Flang.h
  flang/include/flang/Frontend/CompilerInstance.h
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/PreprocessorOptions.h
  flang/lib/Frontend/CompilerInstance.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/test/Flang-Driver/driver-help-hidden.f90
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Flang-Driver/macro_def_undef.f90
  flang/test/Flang-Driver/macro_multiline.f90

Index: flang/test/Flang-Driver/macro_multiline.f90
===
--- /dev/null
+++ flang/test/Flang-Driver/macro_multiline.f90
@@ -0,0 +1,22 @@
+! Ensure the end-of-line character and anything that follows after in a macro definition (-D) is ignored.
+
+! REQUIRES: new-flang-driver
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+! RUN: printf -- "-DX=A\nTHIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT\n" | xargs %flang-new -E %s  2>&1 | FileCheck --strict-whitespace --match-full-lines %s
+
+!-
+! FRONTEND FLANG DRIVER (flang-new -fc1)
+!-
+! RUN: printf -- "-DX=A\nTHIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT\n" | xargs %flang-new -fc1 -E %s  2>&1 | FileCheck --strict-whitespace --match-full-lines %s
+
+!---
+! EXPECTED OUTPUT FOR MACRO 'X'
+!---
+! CHECK:start a end
+! CHECK-NOT:THIS_SHOULD_NOT_EXIST_IN_THE_OUTPUT
+! CHECK-NOT:this_should_not_exist_in_the_output
+
+START X END
\ No newline at end of file
Index: flang/test/Flang-Driver/macro_def_undef.f90
===
--- /dev/null
+++ flang/test/Flang-Driver/macro_def_undef.f90
@@ -0,0 +1,38 @@
+! Ensure arguments -D and -U work as expected.
+
+! REQUIRES: new-flang-driver
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+! RUN: %flang-new -E %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+! RUN: %flang-new -E -DX=A %s  2>&1 | FileCheck %s --check-prefix=DEFINED
+! RUN: %flang-new -E -DX=A -UX %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+
+!-
+! FRONTEND FLANG DRIVER (flang-new -fc1)
+!-
+! RUN: %flang-new -fc1 -E %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+! RUN: %flang-new -fc1 -E -DX=A %s  2>&1 | FileCheck %s --check-prefix=DEFINED
+! RUN: %flang-new -fc1 -E -DX -UX %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
+
+!
+! EXPECTED OUTPUT FOR AN UNDEFINED MACRO
+!
+! UNDEFINED:program b
+! UNDEFINED-NOT:program x
+! UNDEFINED-NEXT:end
+
+!
+! EXPECTED OUTPUT FOR MACRO 'X' DEFINED AS A
+!
+! DEFINED:program a
+! DEFINED-NOT:program b
+! DEFINED-NEXT:end
+
+#ifdef X
+program X
+#else
+program B
+#endif
+end
\ No newline at end of file
Index: flang/test/Flang-Driver/driver-help.f90
===
--- flang/test/Flang-Driver/driver-help.f90
+++ flang/test/Flang-Driver/driver-help.f90
@@ -19,11 +19,13 @@
 ! HELP-EMPTY:
 ! HELP-NEXT:OPTIONS:
 ! HELP-NEXT: -###   Print (but do not run) the commands to run for this compilation
+! HELP-NEXT: -D = Define  to  (or 1 if  omitted)
 ! HELP-NEXT: -E Only run the preprocessor
 ! HELP-NEXT: -fcolor-diagnosticsEnable colors in diagnostics
 ! HELP-NEXT: -fno-color-diagnostics Disable colors in diagnostics
 ! HELP-NEXT: -help  Display available options
 ! HELP-NEXT: -o   Write output to 
+! HELP-NEXT: -U  Undefine macro 
 ! HELP-NEXT: --version  Print version information
 
 !-
@@ -32,10 +34,12 @@
 ! HELP-FC1:USAGE: flang-new
 ! HELP-FC1-EMPTY:
 ! HELP-FC1-NEXT:OPTIONS:
-! HELP-FC1-NEXT: -EOnly run the preprocessor
-! HELP-FC1-NEXT: -help Display available options
-! HELP-FC1-NEXT: -o  Write output to 
-! HELP-FC1-NEXT: --version Print version information
+! HELP-FC1-NEXT: -D = Define  to  (or 1 if  omitted)
+! HELP-FC1-

[PATCH] D91000: [clang-tidy] CERT MSC24-C Obsolescent Functions check

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

steakhal requested changes to this revision.
steakhal added a comment.
This revision now requires changes to proceed.

In D91000#2465514 , @ktomi996 wrote:

> In D91000#2382562 , @steakhal wrote:
>
>> Quoting the revision summary:
>>
>>> This checker guards against using some vulnerable C functions which are 
>>> mentioned in MSC24-C in obsolescent functions table.
>>
>> Why don't we check the rest of the functions as well?
>> `asctime`, `atof`, `atoi`, `atol`, `atoll`, `ctime`, `fopen`, `freopen`, 
>> `rewind`, `setbuf`
>>
>> Hm, I get that `cert-err34-c` will already diagnose the uses of `atof`, 
>> `atoi`, `atol`, `atoll`, but then why do we check `vfscanf`, `vscanf` then?
>> We should probably omit these, while documenting this.
>> On the other hand, I would recommend checking `asctime`, `ctime`, `fopen`, 
>> `freopen`, `rewind`, `setbuf` for the sake of completeness.
>
> I only check functions which are in Unchecked Obsolescent Functions without 
> setbuf because setbuf does not have a safer alternative in Annex K.
> https://wiki.sei.cmu.edu/confluence/display/c/MSC24-C.+Do+not+use+deprecated+or+obsolescent+functions

From the user's point of view, it does not matter if the //safer alternative// 
is inside //annex K// or not.
IMO if the //CERT// rule says that don't use any of these functions but use 
these //other// functions instead.
If we don't check all of them in the list, this checker is incomplete. The name 
of this checker might lead the user to a false sense of security.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91000

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

[PATCH] D91000: [clang-tidy] CERT MSC24-C Obsolescent Functions check

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D91000#2469880 , @steakhal wrote:

> In D91000#2465514 , @ktomi996 wrote:
>
>> In D91000#2382562 , @steakhal wrote:
>>
>>> Quoting the revision summary:
>>>
 This checker guards against using some vulnerable C functions which are 
 mentioned in MSC24-C in obsolescent functions table.
>>>
>>> Why don't we check the rest of the functions as well?
>>> `asctime`, `atof`, `atoi`, `atol`, `atoll`, `ctime`, `fopen`, `freopen`, 
>>> `rewind`, `setbuf`
>>>
>>> Hm, I get that `cert-err34-c` will already diagnose the uses of `atof`, 
>>> `atoi`, `atol`, `atoll`, but then why do we check `vfscanf`, `vscanf` then?
>>> We should probably omit these, while documenting this.
>>> On the other hand, I would recommend checking `asctime`, `ctime`, `fopen`, 
>>> `freopen`, `rewind`, `setbuf` for the sake of completeness.
>>
>> I only check functions which are in Unchecked Obsolescent Functions without 
>> setbuf because setbuf does not have a safer alternative in Annex K.
>> https://wiki.sei.cmu.edu/confluence/display/c/MSC24-C.+Do+not+use+deprecated+or+obsolescent+functions
>
> From the user's point of view, it does not matter if the //safer 
> alternative// is inside //annex K// or not.

I suspect that should be a flag in the check's options.

> IMO if the //CERT// rule says that don't use any of these functions but use 
> these //other// functions instead.
> If we don't check all of them in the list, this checker is incomplete. The 
> name of this checker might lead the user to a false sense of security.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91000

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

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

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

steakhal planned changes to this revision.
steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:20-21
 #include "clang/Basic/Version.h"
 #include "clang/CrossTU/CrossTranslationUnit.h"
 #include "clang/Frontend/ASTUnit.h"
 #include "clang/Lex/Preprocessor.h"

NoQ wrote:
> Will these two includes be ultimately removed? Like, even in the CTU case?
I think `PlistDiagnostics` can depend on `CTU`.
`ASTUnit` is a different thing though. I think I just accidentally left that 
include.

I will remove the `#include "clang/Frontend/ASTUnit.h"` line.

---
What do you mean by the 'CTU case'?



Comment at: 
clang/test/Analysis/Inputs/expected-plists/plist-macros-with-expansion.cpp.plist:148
  nameSET_PTR_VAR_TO_NULL
- expansionptr = 0
+ expansionptr =0
 

NoQ wrote:
> steakhal wrote:
> > xazax.hun wrote:
> > > martong wrote:
> > > > martong wrote:
> > > > > I wonder how much added value do we have with these huge and clumsy 
> > > > > plist files... We already have the concise unittests, which are quite 
> > > > > self explanatory. I'd just simply delete these plist files.
> > > > Perhaps in the test cpp file we should just execute a FileCheck for the 
> > > > expansions. We are totally not interested to check the whole contents 
> > > > of the plist, we are interested only to see if there were expansions.
> > > We do need some plist tests to ensure that the correct plist format is 
> > > emitted. How much of those do we need might be up for debate.
> > It's certainly a pain to keep all the locations in sync with the code.
> I'm absolutely in favor of not testing the //entire// plist files whenever 
> possible. Just keep some minimal context available so that to not 
> accidentally match the wrong test. Yes we obviously need some tests for the 
> entire plist files but we already have a lot of that.
Ok, I will remove these files.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93224

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

[PATCH] D91000: [clang-tidy] CERT MSC24-C Obsolescent Functions check

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

steakhal added a comment.

In D91000#2469884 , @lebedev.ri wrote:

> In D91000#2469880 , @steakhal wrote:
>
>> In D91000#2465514 , @ktomi996 wrote:
>>
>>> In D91000#2382562 , @steakhal 
>>> wrote:
>>>
 Quoting the revision summary:

> This checker guards against using some vulnerable C functions which are 
> mentioned in MSC24-C in obsolescent functions table.

 Why don't we check the rest of the functions as well?
 `asctime`, `atof`, `atoi`, `atol`, `atoll`, `ctime`, `fopen`, `freopen`, 
 `rewind`, `setbuf`

 Hm, I get that `cert-err34-c` will already diagnose the uses of `atof`, 
 `atoi`, `atol`, `atoll`, but then why do we check `vfscanf`, `vscanf` then?
 We should probably omit these, while documenting this.
 On the other hand, I would recommend checking `asctime`, `ctime`, `fopen`, 
 `freopen`, `rewind`, `setbuf` for the sake of completeness.
>>>
>>> I only check functions which are in Unchecked Obsolescent Functions without 
>>> setbuf because setbuf does not have a safer alternative in Annex K.
>>> https://wiki.sei.cmu.edu/confluence/display/c/MSC24-C.+Do+not+use+deprecated+or+obsolescent+functions
>>
>> From the user's point of view, it does not matter if the //safer 
>> alternative// is inside //annex K// or not.
>
> I suspect that should be a flag in the check's options.

I don't see any value in disabling the check for eg. `setbuf`. Even the man 
page says that you should use the `setvbuf` instead.
Why would anyone disable this if one already wants diagnostics for the CERT 
rule it implements?

>> IMO if the //CERT// rule says that don't use any of these functions but use 
>> these //other// functions instead.
>> If we don't check all of them in the list, this checker is incomplete. The 
>> name of this checker might lead the user to a false sense of security.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91000

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

[PATCH] D93453: [flang][driver] Add support for `-I`

[Faris via Phabricator via cfe-commits]

FarisRehman updated this revision to Diff 313536.
FarisRehman added a comment.

Clean up test

Summary of changes:

- Clean up test include_header.f90
- Rename SearchDirectoriesFromDashI to searchDirectoriesFromDashI


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93453

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/PreprocessorOptions.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/test/Flang-Driver/Inputs/included.h
  flang/test/Flang-Driver/driver-help-hidden.f90
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Flang-Driver/include_header.f90

Index: flang/test/Flang-Driver/include_header.f90
===
--- /dev/null
+++ flang/test/Flang-Driver/include_header.f90
@@ -0,0 +1,39 @@
+! Ensure argument -I works as expected.
+
+! REQUIRES: new-flang-driver
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+! RUN: %flang-new -E %s  2>&1 | FileCheck %s --check-prefix=UNINCLUDED
+! RUN: %flang-new -E -I %S/Inputs %s  2>&1 | FileCheck %s --check-prefix=INCLUDED
+! RUN: %flang-new -E -I %S/InvalidFolder %s  2>&1 | FileCheck %s --check-prefix=UNINCLUDED
+
+!-
+! FRONTEND FLANG DRIVER (flang-new -fc1)
+!-
+! RUN: %flang-new -fc1 -E %s  2>&1 | FileCheck %s --check-prefix=UNINCLUDED
+! RUN: %flang-new -fc1 -E -I %S/Inputs %s  2>&1 | FileCheck %s --check-prefix=INCLUDED
+! RUN: %flang-new -fc1 -E -I %S/InvalidFolder %s  2>&1 | FileCheck %s --check-prefix=UNINCLUDED
+
+!
+! EXPECTED OUTPUT FOR MISSING INCLUDED FILE
+!
+! UNINCLUDED:program b
+! UNINCLUDED-NOT:program a
+! UNINCLUDED-NEXT:end
+
+!--
+! EXPECTED OUTPUT FOR INCLUDE
+!--
+! INCLUDED:program a
+! INCLUDED-NOT:program b
+! INCLUDED-NEXT:end
+
+#include 
+#ifdef X
+program A
+#else
+program B
+#endif
+end
\ No newline at end of file
Index: flang/test/Flang-Driver/driver-help.f90
===
--- flang/test/Flang-Driver/driver-help.f90
+++ flang/test/Flang-Driver/driver-help.f90
@@ -24,6 +24,7 @@
 ! HELP-NEXT: -fcolor-diagnosticsEnable colors in diagnostics
 ! HELP-NEXT: -fno-color-diagnostics Disable colors in diagnostics
 ! HELP-NEXT: -help  Display available options
+! HELP-NEXT: -IAdd directory to include search path. If there are multiple -I options, these directories are searched in the order they are given before the standard system directories are searched. If the same directory is in the SYSTEM include search paths, for example if also specified with -isystem, the -I option will be ignored
 ! HELP-NEXT: -o   Write output to 
 ! HELP-NEXT: -U  Undefine macro 
 ! HELP-NEXT: --version  Print version information
@@ -37,6 +38,7 @@
 ! HELP-FC1-NEXT: -D = Define  to  (or 1 if  omitted)
 ! HELP-FC1-NEXT: -E Only run the preprocessor
 ! HELP-FC1-NEXT: -help  Display available options
+! HELP-FC1-NEXT: -IAdd directory to include search path. If there are multiple -I options, these directories are searched in the order they are given before the standard system directories are searched. If the same directory is in the SYSTEM include search paths, for example if also specified with -isystem, the -I option will be ignored
 ! HELP-FC1-NEXT: -o   Write output to 
 ! HELP-FC1-NEXT: -U  Undefine macro 
 ! HELP-FC1-NEXT: --version  Print version information
Index: flang/test/Flang-Driver/driver-help-hidden.f90
===
--- flang/test/Flang-Driver/driver-help-hidden.f90
+++ flang/test/Flang-Driver/driver-help-hidden.f90
@@ -24,6 +24,7 @@
 ! CHECK-NEXT: -fcolor-diagnosticsEnable colors in diagnostics
 ! CHECK-NEXT: -fno-color-diagnostics Disable colors in diagnostics
 ! CHECK-NEXT: -help Display available options
+! CHECK-NEXT: -IAdd directory to include search path. If there are multiple -I options, these directories are searched in the order they are given before the standard system directories are searched. If the same directory is in the SYSTEM include search paths, for example if also specified with -isystem, the -I option will be ignored
 ! CHECK-NEXT: -o  Write output to 
 ! CHECK-NEXT: -test-io  Run the InputOuputTest action. Use for development and testing only.
 ! CHECK-NEXT: -U  Undefine macro 
Index: flang/test/Flang-Driver/Inputs/included.h
===
--- /dev/null
+++ flang/test/Flang-Driver/Inputs/included.h
@@ -0,

[PATCH] D91000: [clang-tidy] CERT MSC24-C Obsolescent Functions check

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D91000#2469894 , @steakhal wrote:

> In D91000#2469884 , @lebedev.ri 
> wrote:
>
>> In D91000#2469880 , @steakhal wrote:
>>
>>> In D91000#2465514 , @ktomi996 
>>> wrote:
>>>
 In D91000#2382562 , @steakhal 
 wrote:

> Quoting the revision summary:
>
>> This checker guards against using some vulnerable C functions which are 
>> mentioned in MSC24-C in obsolescent functions table.
>
> Why don't we check the rest of the functions as well?
> `asctime`, `atof`, `atoi`, `atol`, `atoll`, `ctime`, `fopen`, `freopen`, 
> `rewind`, `setbuf`
>
> Hm, I get that `cert-err34-c` will already diagnose the uses of `atof`, 
> `atoi`, `atol`, `atoll`, but then why do we check `vfscanf`, `vscanf` 
> then?
> We should probably omit these, while documenting this.
> On the other hand, I would recommend checking `asctime`, `ctime`, 
> `fopen`, `freopen`, `rewind`, `setbuf` for the sake of completeness.

 I only check functions which are in Unchecked Obsolescent Functions 
 without setbuf because setbuf does not have a safer alternative in Annex K.
 https://wiki.sei.cmu.edu/confluence/display/c/MSC24-C.+Do+not+use+deprecated+or+obsolescent+functions
>>>
>>> From the user's point of view, it does not matter if the //safer 
>>> alternative// is inside //annex K// or not.
>>
>> I suspect that should be a flag in the check's options.
>
> I don't see any value in disabling the check for eg. `setbuf`. Even the man 
> page says that you should use the `setvbuf` instead.
> Why would anyone disable this if one already wants diagnostics for the CERT 
> rule it implements?
>
>>> IMO if the //CERT// rule says that don't use any of these functions but use 
>>> these //other// functions instead.
>>> If we don't check all of them in the list, this checker is incomplete. The 
>>> name of this checker might lead the user to a false sense of security.

I think the question is, *why* are these checks being implemented?
Just to claim that for some particular rule there is a check, and cross it off 
a list?
Or for them to be actually used?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91000

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

[PATCH] D92039: [-Wcalled-once-parameter] Introduce 'called_once' attribute

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added inline comments.



Comment at: clang/include/clang/Analysis/Analyses/CalledOnceCheck.h:32
+/// \enum SwitchSkipped -- there is no call if none of the cases appies.
+/// \enum LoopEntered -- no call when the loop is entered.
+/// \enum LoopSkipped -- no call when the loop is not entered.

NoQ wrote:
> Hold up, how can this happen at all without path sensitivity? If the loop is 
> not entered then literally nothing happens, so there can't be a call. If 
> there's no call in either case then probably it's just "there's simply no 
> call at all"?
You can see examples in tests 😉 



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:541-542
+private:
+  NotCalledClarifier(const CFGBlock *Parent, const CFGBlock *SuccInQuestion)
+  : Parent(Parent), SuccInQuestion(SuccInQuestion) {}
+

NoQ wrote:
> This is one of the more subtle facilities, i really want a comment here a lot 
> more than on the `NamesCollector`. Like, which blocks do you feed into this 
> class? Do i understand correctly that `Parent` is the block at which we 
> decided to emit the warning? And `SuccInQuestion` is its successor on which 
> there was no call? Or on which there was a call? I can probably ultimately 
> figure this out if i read all the code but i would be much happier if there 
> was a comment.
These are correct questions and I will add a comment, but I want to point out 
that these questions should be asked not about a private constructor (I always 
consider those as "don't go there girlfriend!").  The only "entry point" to 
this class,`clarify`, has more reasonable parameter names.



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:560
+bool CheckConventionalParameters)
+  : FunctionCFG(FunctionCFG), AC(AC), Handler(Handler),
+CheckConventionalParameters(CheckConventionalParameters),

NoQ wrote:
> Why not `FunctionCFG(AC->getCFG())` and omit the CFG parameter? That's the 
> same function, right?
Right, I thought about it!  It is simply how it was done in some other 
analysis-based warning



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:780
+//
+// The following algorithm has the worst case complexity of O(N + E),
+// where N is the number of basic blocks in FunctionCFG,

NoQ wrote:
> I'm super used to `V` and `E` for Vertices and Edges in the big-O-notation 
> for graph algorithms, is it just me?
Yep, it is a rudiment of the previous version of this comment.  I'll change it!



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:822
+  /// calling the parameter itself, but rather uses it as the argument.
+  template 
+  void checkIndirectCall(const CallLikeExpr *CallOrMessage) {

NoQ wrote:
> Did you consider `AnyCall`? That's a universal wrapper for all kinds of AST 
> calls for exactly these cases. It's not super compile-time but it adds a lot 
> of convenience. (Also uh-oh, its doxygen page seems to be broken). It's ok if 
> you find it unsuitable but i kind of still want to popularize it.
It doesn't seem to have iteration over arguments.



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:1124
+ (ReturnChildren &&
+  ReturnChildren->getParent(SuspiciousStmt));
+}

NoQ wrote:
> 
Oh, didn't notice that one!



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:1132
+  /// Check if parameter with the given index was ever used.
+  /// NOTE: This function checks only for escapes.
+  bool wasEverUsed(unsigned Index) const {

NoQ wrote:
> So the contract of this function is "We haven't seen any actual calls, which 
> is why we're wondering", otherwise it's not expected to do what it says it 
> does?
Right!



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:1247
+   State &ToAlter) const {
+// Even when the analyzer is technically correct, it is a widespread 
pattern
+// not to call completion handlers in some scenarios.  These usually have

NoQ wrote:
> (:
So true 😄 



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:1310
+  /// a specified status for the given parameter.
+  bool isAnyOfSuccessorsHasStatus(const CFGBlock *Parent,
+  unsigned ParameterIndex,

NoQ wrote:
> "Successor is has status" doesn't sound right, maybe `anySuccessorHasStatus`?
Dern it! I noticed that before, but forgot to change it, thanks!



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:1442
+// is intentionally not called on this path.
+if (Cast->getType() == AC.getASTContext().VoidTy) {
+  checkEscapee(Cast->getSubExpr());

NoQ wrote:
> I feel really bad bringing this up in this context but i guess it kind of 
> makes sense to can

[PATCH] D91000: [clang-tidy] CERT MSC24-C Obsolescent Functions check

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

steakhal added a comment.

In D91000#2469898 , @lebedev.ri wrote:

> I think the question is, *why* are these checks being implemented?
> Just to claim that for some particular rule there is a check, and cross it 
> off a list?

Initially, yes. I think one could learn a lot from contributing to any project.
It's not inherently a bad thing to combine these two.

> Or for them to be actually used?

I want a useful checker, that's why I highlighted some of my concerns and 
suggested a way forward.
It might not be useful to everyone as it //tries to// implement a 
domain-specific CERT rule, but it's still up to the user to enable this.
I think we should ask, who is the audience of this checker?
I assume only the users who are interested in the CERT guideline would use 
this. At this point, we should be clear about what we are checking for.
I think it's OK, to say that only a part of the rule is implemented, and we 
should carefully document this fact. But IMO one should go the extra mile to 
try hard and implement the other parts of the rule as well.
Like, matching on the `setbuf` is not that hard really. The rest of the missing 
functions probably fall into the same category.

I might be wrong on this though.
Keep in mind that I'm not tidy dev, so take my opinion with a pinch of salt.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91000

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

[PATCH] D93758: [format][NFC] Use unsigned char as the base of all enums in FormatStyle

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

We should probably check the docs/tools/dump_format_style.py still works


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93758

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

[PATCH] D91927: [X86] Add x86_amx type for intel AMX.

[Pengfei Wang via Phabricator via cfe-commits]

pengfei added a comment.

> In my test case, it is transformed after Combine redundant instructions.

Can we disable it for AMX type? The pointer to AMX type is meaningless and may 
result in bad perfomance.




Comment at: llvm/lib/Target/X86/X86LowerAMXType.cpp:300
+// If the dst type is <256 x i32>*, it is valid intruction.
+// %0 = bitcast x86_amx* %tile to <256 x i32>*
+// %1 = load <256 x i32>, <256 x i32>* %0, align 64

I don't see any chance this happen. But we still need to handle the x86_amx* 
here if possible, right?
Maybe better to give an assertion for now.
```
cast(Src->getType())->isX86_AMXTy()
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91927

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

[PATCH] D92039: [-Wcalled-once-parameter] Introduce 'called_once' attribute

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added inline comments.



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:163
+  }
+  static bool canBeCalled(Kind K) {
+return (K & DefinitelyCalled) == DefinitelyCalled && K != Reported;

NoQ wrote:
> "Can be called" sounds like "Someone's allowed to call it". I was completely 
> confused when i saw a call site for that function.
> 
> I too am at loss because the concept of "is definitely potentially called" is 
> hard to explain especially when the concept of "maybe called" is already 
> defined and means something different.
> 
> Maybe `seenAnyCalls()` or something like that?
> 
> Maybe also rename `DefinitelyCalled` and `MaybeCalled` to `CalledOnAllPaths` 
> and `CalledOnSomePathsOnly`? That could eliminate a bit more confusion.
`DefinitelyCalled` is already a mouthful, so I prefer to keep it together with 
`MaybeCalled`.  Also I agree about `canBeCalled` and I like your alternative!



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:304-307
+// Function pointer/references can be dereferenced before a call.
+// That doesn't make it, however, any different from a regular call.
+// For this reason, dereference operation is a "no-op".
+case UO_Deref:

NoQ wrote:
> Technically the same applies to operator `&`, eg. `(&*foo)()` is your normal 
> call. Obviously, `(&foo)()` doesn't compile. That said, `if (&foo)` compiles 
> and is not your normal null check (but `if (&*foo)` and `if (*foo)` are).
I mean, we can add `case UO_AddrOf:`, but I don't think that we need more 
complex logic (in terms of `*` and `&`) here.



Comment at: clang/lib/Analysis/CalledOnceCheck.cpp:321-322
+case BO_NE: {
+  const DeclRefExpr *LHS = Visit(BO->getLHS());
+  return LHS ? LHS : Visit(BO->getRHS());
+}

NoQ wrote:
> You're potentially dropping some `DeclRefExpr`s. Also the ones that you find 
> aren't necessarily the function pointer variables you're looking for (as you 
> don't actually have any checks in `VisitDeclRefExpr`). Combined, i suspect 
> that there may be some exotic counterexamples like
> ```lang=c
> if (!foo) {
>   // "foo" is found
>   if (foo == completion_handler) {
> // ...
>   }
> }
> ```
> (which is probably ok anyway)
Yep, I thought about it and, honestly, decided to ignore 😊 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92039

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

[PATCH] D93758: [format][NFC] Use unsigned char as the base of all enums in FormatStyle

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

In D93758#2469967 , @MyDeveloperDay 
wrote:

> We should probably check the docs/tools/dump_format_style.py still works

Good catch, I'll update the script to optionally take an underlying type 
argument. Should that be part of this change, or a parent?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93758

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

[clang] 5426b2f - [clang-format] PR48535 clang-format Incorrectly Removes Space After C Style Cast When Type Is Not a Pointer

[via cfe-commits]

Author: mydeveloperday
Date: 2020-12-23T14:45:14Z
New Revision: 5426b2f9ed9f6f3a3e1d6452325f7a49a5d08ec4

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

LOG: [clang-format] PR48535 clang-format Incorrectly Removes Space After C 
Style Cast When Type Is Not a Pointer

https://bugs.llvm.org/show_bug.cgi?id=48535

using `SpaceAfterCStyleCast: true`

```
size_t idx = (size_t) a;
size_t idx = (size_t) (a - 1);
```

is formatted as:

```
size_t idx = (size_t) a;
size_t idx = (size_t)(a - 1);
```

This revision aims to improve that by improving the function which tries to 
identify a CastRParen

Reviewed By: curdeius

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

Added: 


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

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 733ca1e0e852..a0cb86cfcebf 100755
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -1915,6 +1915,13 @@ class AnnotatingParser {
 if (Tok.Next->isOneOf(tok::identifier, tok::kw_this))
   return true;
 
+if (Tok.Next->is(tok::l_paren) &&
+!(Tok.Previous && Tok.Previous->is(tok::identifier) &&
+  Tok.Previous->Previous &&
+  Tok.Previous->Previous->isOneOf(tok::arrowstar, tok::arrow,
+  tok::star)))
+  return true;
+
 if (!Tok.Next->Next)
   return false;
 

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index d2aed304f213..ee757c14eafb 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -11989,6 +11989,20 @@ TEST_F(FormatTest, ConfigurableSpacesInParentheses) {
"  do_something((int) i);\n"
"} while (something( ));",
Spaces);
+
+  verifyFormat("size_t idx = (size_t) (ptr - ((char *) file));", Spaces);
+  verifyFormat("size_t idx = (size_t) a;", Spaces);
+  verifyFormat("size_t idx = (size_t) (a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->*foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (*foo)(a - 1);", Spaces);
+  Spaces.SpaceAfterCStyleCast = false;
+  verifyFormat("size_t idx = (size_t)(ptr - ((char *)file));", Spaces);
+  verifyFormat("size_t idx = (size_t)a;", Spaces);
+  verifyFormat("size_t idx = (size_t)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->*foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (*foo)(a - 1);", Spaces);
 }
 
 TEST_F(FormatTest, ConfigurableSpacesInSquareBrackets) {



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

[clang] 031743c - [clang-format] PR48539 ReflowComments breaks Qt translation comments

[via cfe-commits]

Author: mydeveloperday
Date: 2020-12-23T14:45:14Z
New Revision: 031743cb5b3c6c2df85a67d8533ef72a95e76cdc

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

LOG: [clang-format] PR48539 ReflowComments breaks Qt translation comments

https://bugs.llvm.org/show_bug.cgi?id=48539

Add support for Qt Translator Comments to reflow

When reflown and a part of the comments are added on a new line, it should 
repeat these extra characters as part of the comment token.

Reviewed By: curdeius, HazardyKnusperkeks

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

Added: 


Modified: 
clang/lib/Format/BreakableToken.cpp
clang/unittests/Format/FormatTestComments.cpp

Removed: 




diff  --git a/clang/lib/Format/BreakableToken.cpp 
b/clang/lib/Format/BreakableToken.cpp
index ea5cc31af07a..6a240fdec8b9 100644
--- a/clang/lib/Format/BreakableToken.cpp
+++ b/clang/lib/Format/BreakableToken.cpp
@@ -41,8 +41,8 @@ static bool IsBlank(char C) {
 
 static StringRef getLineCommentIndentPrefix(StringRef Comment,
 const FormatStyle &Style) {
-  static const char *const KnownCStylePrefixes[] = {"///<", "//!<", "///", 
"//",
-"//!"};
+  static const char *const KnownCStylePrefixes[] = {"///<", "//!<", "///",
+"//",   "//!",  "//:"};
   static const char *const KnownTextProtoPrefixes[] = {"//", "#", "##", "###",
""};
   ArrayRef KnownPrefixes(KnownCStylePrefixes);

diff  --git a/clang/unittests/Format/FormatTestComments.cpp 
b/clang/unittests/Format/FormatTestComments.cpp
index 27dfe71367b3..457e7321ec75 100644
--- a/clang/unittests/Format/FormatTestComments.cpp
+++ b/clang/unittests/Format/FormatTestComments.cpp
@@ -702,6 +702,12 @@ TEST_F(FormatTestComments, SplitsLongCxxComments) {
"  // long 1 2 3 4 5 6\n"
"}",
getLLVMStyleWithColumns(20)));
+
+  EXPECT_EQ("//: A comment that\n"
+"//: doesn't fit on\n"
+"//: one line",
+format("//: A comment that doesn't fit on one line",
+   getLLVMStyleWithColumns(20)));
 }
 
 TEST_F(FormatTestComments, PreservesHangingIndentInCxxComments) {



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

[PATCH] D93626: [clang-format] PR48535 clang-format Incorrectly Removes Space After C Style Cast When Type Is Not a Pointer

[MyDeveloperDay via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5426b2f9ed9f: [clang-format] PR48535 clang-format 
Incorrectly Removes Space After C Style… (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93626

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -11989,6 +11989,20 @@
"  do_something((int) i);\n"
"} while (something( ));",
Spaces);
+
+  verifyFormat("size_t idx = (size_t) (ptr - ((char *) file));", Spaces);
+  verifyFormat("size_t idx = (size_t) a;", Spaces);
+  verifyFormat("size_t idx = (size_t) (a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->*foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (*foo)(a - 1);", Spaces);
+  Spaces.SpaceAfterCStyleCast = false;
+  verifyFormat("size_t idx = (size_t)(ptr - ((char *)file));", Spaces);
+  verifyFormat("size_t idx = (size_t)a;", Spaces);
+  verifyFormat("size_t idx = (size_t)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->*foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (*foo)(a - 1);", Spaces);
 }
 
 TEST_F(FormatTest, ConfigurableSpacesInSquareBrackets) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1915,6 +1915,13 @@
 if (Tok.Next->isOneOf(tok::identifier, tok::kw_this))
   return true;
 
+if (Tok.Next->is(tok::l_paren) &&
+!(Tok.Previous && Tok.Previous->is(tok::identifier) &&
+  Tok.Previous->Previous &&
+  Tok.Previous->Previous->isOneOf(tok::arrowstar, tok::arrow,
+  tok::star)))
+  return true;
+
 if (!Tok.Next->Next)
   return false;
 


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -11989,6 +11989,20 @@
"  do_something((int) i);\n"
"} while (something( ));",
Spaces);
+
+  verifyFormat("size_t idx = (size_t) (ptr - ((char *) file));", Spaces);
+  verifyFormat("size_t idx = (size_t) a;", Spaces);
+  verifyFormat("size_t idx = (size_t) (a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->*foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (*foo)(a - 1);", Spaces);
+  Spaces.SpaceAfterCStyleCast = false;
+  verifyFormat("size_t idx = (size_t)(ptr - ((char *)file));", Spaces);
+  verifyFormat("size_t idx = (size_t)a;", Spaces);
+  verifyFormat("size_t idx = (size_t)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->*foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (a->foo)(a - 1);", Spaces);
+  verifyFormat("size_t idx = (*foo)(a - 1);", Spaces);
 }
 
 TEST_F(FormatTest, ConfigurableSpacesInSquareBrackets) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1915,6 +1915,13 @@
 if (Tok.Next->isOneOf(tok::identifier, tok::kw_this))
   return true;
 
+if (Tok.Next->is(tok::l_paren) &&
+!(Tok.Previous && Tok.Previous->is(tok::identifier) &&
+  Tok.Previous->Previous &&
+  Tok.Previous->Previous->isOneOf(tok::arrowstar, tok::arrow,
+  tok::star)))
+  return true;
+
 if (!Tok.Next->Next)
   return false;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93490: [clang-format] PR48539 ReflowComments breaks Qt translation comments

[MyDeveloperDay via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG031743cb5b3c: [clang-format] PR48539 ReflowComments breaks 
Qt translation comments (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93490

Files:
  clang/lib/Format/BreakableToken.cpp
  clang/unittests/Format/FormatTestComments.cpp


Index: clang/unittests/Format/FormatTestComments.cpp
===
--- clang/unittests/Format/FormatTestComments.cpp
+++ clang/unittests/Format/FormatTestComments.cpp
@@ -702,6 +702,12 @@
"  // long 1 2 3 4 5 6\n"
"}",
getLLVMStyleWithColumns(20)));
+
+  EXPECT_EQ("//: A comment that\n"
+"//: doesn't fit on\n"
+"//: one line",
+format("//: A comment that doesn't fit on one line",
+   getLLVMStyleWithColumns(20)));
 }
 
 TEST_F(FormatTestComments, PreservesHangingIndentInCxxComments) {
Index: clang/lib/Format/BreakableToken.cpp
===
--- clang/lib/Format/BreakableToken.cpp
+++ clang/lib/Format/BreakableToken.cpp
@@ -41,8 +41,8 @@
 
 static StringRef getLineCommentIndentPrefix(StringRef Comment,
 const FormatStyle &Style) {
-  static const char *const KnownCStylePrefixes[] = {"///<", "//!<", "///", 
"//",
-"//!"};
+  static const char *const KnownCStylePrefixes[] = {"///<", "//!<", "///",
+"//",   "//!",  "//:"};
   static const char *const KnownTextProtoPrefixes[] = {"//", "#", "##", "###",
""};
   ArrayRef KnownPrefixes(KnownCStylePrefixes);


Index: clang/unittests/Format/FormatTestComments.cpp
===
--- clang/unittests/Format/FormatTestComments.cpp
+++ clang/unittests/Format/FormatTestComments.cpp
@@ -702,6 +702,12 @@
"  // long 1 2 3 4 5 6\n"
"}",
getLLVMStyleWithColumns(20)));
+
+  EXPECT_EQ("//: A comment that\n"
+"//: doesn't fit on\n"
+"//: one line",
+format("//: A comment that doesn't fit on one line",
+   getLLVMStyleWithColumns(20)));
 }
 
 TEST_F(FormatTestComments, PreservesHangingIndentInCxxComments) {
Index: clang/lib/Format/BreakableToken.cpp
===
--- clang/lib/Format/BreakableToken.cpp
+++ clang/lib/Format/BreakableToken.cpp
@@ -41,8 +41,8 @@
 
 static StringRef getLineCommentIndentPrefix(StringRef Comment,
 const FormatStyle &Style) {
-  static const char *const KnownCStylePrefixes[] = {"///<", "//!<", "///", "//",
-"//!"};
+  static const char *const KnownCStylePrefixes[] = {"///<", "//!<", "///",
+"//",   "//!",  "//:"};
   static const char *const KnownTextProtoPrefixes[] = {"//", "#", "##", "###",
""};
   ArrayRef KnownPrefixes(KnownCStylePrefixes);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93630: [Attr] Apply GNU-style attributes to expression statements

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko updated this revision to Diff 313550.
vsavchenko added a comment.

Refine condition for statement attributes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93630

Files:
  clang/lib/Parse/ParseStmt.cpp
  clang/test/Parser/stmt-attributes.c

Index: clang/test/Parser/stmt-attributes.c
===
--- /dev/null
+++ clang/test/Parser/stmt-attributes.c
@@ -0,0 +1,89 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+void foo(int i) {
+
+  __attribute__((unknown_attribute));// expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+  __attribute__((unknown_attribute)) {}  // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+  __attribute__((unknown_attribute)) if (0) {}   // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+  __attribute__((unknown_attribute)) for (;;);   // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+  __attribute__((unknown_attribute)) do {// expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+__attribute__((unknown_attribute)) continue; // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+  }
+  while (0)
+;
+  __attribute__((unknown_attribute)) while (0); // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+
+  __attribute__((unknown_attribute)) switch (i) {  // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+__attribute__((unknown_attribute)) case 0 :// expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+__attribute__((unknown_attribute)) default :   // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+ __attribute__((unknown_attribute)) break; // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+  }
+
+  __attribute__((unknown_attribute)) goto here; // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+  __attribute__((unknown_attribute)) here : // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+
+__attribute__((unknown_attribute)) return; // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+
+  __attribute__((noreturn)) {} // expected-error {{'noreturn' attribute cannot be applied to a statement}}
+  __attribute__((noreturn)) if (0) {}  // expected-error {{'noreturn' attribute cannot be applied to a statement}}
+  __attribute__((noreturn)) for (;;);  // expected-error {{'noreturn' attribute cannot be applied to a statement}}
+  __attribute__((noreturn)) do {   // expected-error {{'noreturn' attribute cannot be applied to a statement}}
+__attribute__((unavailable)) continue; // expected-error {{'unavailable' attribute cannot be applied to a statement}}
+  }
+  while (0)
+;
+  __attribute__((unknown_attributqqq)) while (0); // expected-warning {{unknown attribute 'unknown_attributqqq' ignored}}
+  // TODO: remove 'qqq' part and enjoy 'empty loop body' warning here (DiagnoseEmptyLoopBody)
+
+  __attribute__((unknown_attribute)) while (0); // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
+
+  __attribute__((unused)) switch (i) { // expected-error {{'unused' attribute cannot be applied to a statement}}
+  __attribute__((uuid)) case 0:// expected-warning {{unknown attribute 'uuid' ignored}}
+  __attribute__((visibility)) default: // expected-error {{'visibility' attribute cannot be applied to a statement}}
+__attribute__((carries_dependency)) break; // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  }
+
+  __attribute__((fastcall)) goto there; // expected-error {{'fastcall' attribute cannot be applied to a statement}}
+  __attribute__((noinline)) there : // expected-warning {{'noinline' attribute only applies to functions}}
+
+__attribute__((weakref)) return; // expected-error {{'weakref' attribute only applies to variables and functions}}
+
+  __attribute__((carries_dependency));// expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  __attribute__((carries_dependency)) {}  // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  __attribute__((carries_dependency)) if (0) {}   // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  __at

[PATCH] D93763: [clangd] Add a flag to disable the documentLinks LSP request

[Giulio Girardi via Phabricator via cfe-commits]

rapgenic created this revision.
Herald added subscribers: usaxena95, kadircet, arphaman.
rapgenic requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang.

On some editors (namely VSCode) documentLinks are rendered with an
underline, which might be distracting to see. This patch adds a flag to
disable such request, as it's used only for includes, and the open include
feature can be already fulfilled by the definition request

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93763

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/test/xrefs.test
  clang-tools-extra/clangd/tool/ClangdMain.cpp

Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -339,6 +339,15 @@
 Hidden,
 };
 
+opt IncludesAsLinks{
+"includes-as-links",
+cat(Features),
+desc("Provide a document link to the files included with #include "
+ "directive. If set to false, include files can still be opened with "
+ "go to definition feature"),
+init(true)
+};
+
 opt WorkerThreadsCount{
 "j",
 cat(Misc),
@@ -825,6 +834,7 @@
   Opts.PreserveRecoveryASTType = RecoveryASTType;
   Opts.FoldingRanges = FoldingRanges;
   Opts.MemoryCleanup = getMemoryCleanupFunction();
+  Opts.IncludesAsLinks = IncludesAsLinks;
 
   Opts.CodeComplete.IncludeIneligibleResults = IncludeIneligibleResults;
   Opts.CodeComplete.Limit = LimitResults;
Index: clang-tools-extra/clangd/test/xrefs.test
===
--- clang-tools-extra/clangd/test/xrefs.test
+++ clang-tools-extra/clangd/test/xrefs.test
@@ -1,9 +1,9 @@
 # RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
 {"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
 ---
-{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///main.cpp","languageId":"cpp","version":1,"text":"extern int x;\nint x = 0;\nint y = x;"}}}
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///main.cpp","languageId":"cpp","version":1,"text":"#include \nextern int x;\nint x = 0;\nint y = x;"}}}
 ---
-{"jsonrpc":"2.0","id":1,"method":"textDocument/definition","params":{"textDocument":{"uri":"test:///main.cpp"},"position":{"line":2,"character":8}}}
+{"jsonrpc":"2.0","id":1,"method":"textDocument/definition","params":{"textDocument":{"uri":"test:///main.cpp"},"position":{"line":3,"character":8}}}
 #  CHECK:  "id": 1,
 # CHECK-NEXT:  "jsonrpc": "2.0",
 # CHECK-NEXT:  "result": [
@@ -11,11 +11,11 @@
 # CHECK-NEXT:  "range": {
 # CHECK-NEXT:"end": {
 # CHECK-NEXT:  "character": 5,
-# CHECK-NEXT:  "line": 1
+# CHECK-NEXT:  "line": 2
 # CHECK-NEXT:},
 # CHECK-NEXT:"start": {
 # CHECK-NEXT:  "character": 4,
-# CHECK-NEXT:  "line": 1
+# CHECK-NEXT:  "line": 2
 # CHECK-NEXT:}
 # CHECK-NEXT:  },
 # CHECK-NEXT:  "uri": "file://{{.*}}/{{([A-Z]:/)?}}main.cpp"
@@ -23,7 +23,7 @@
 # CHECK-NEXT:  ]
 ---
 # Toggle: we're on the definition, so jump to the declaration.
-{"jsonrpc":"2.0","id":1,"method":"textDocument/definition","params":{"textDocument":{"uri":"test:///main.cpp"},"position":{"line":1,"character":4}}}
+{"jsonrpc":"2.0","id":1,"method":"textDocument/definition","params":{"textDocument":{"uri":"test:///main.cpp"},"position":{"line":2,"character":4}}}
 #  CHECK:  "id": 1,
 # CHECK-NEXT:  "jsonrpc": "2.0",
 # CHECK-NEXT:  "result": [
@@ -31,18 +31,18 @@
 # CHECK-NEXT:  "range": {
 # CHECK-NEXT:"end": {
 # CHECK-NEXT:  "character": 12,
-# CHECK-NEXT:  "line": 0
+# CHECK-NEXT:  "line": 1
 # CHECK-NEXT:},
 # CHECK-NEXT:"start": {
 # CHECK-NEXT:  "character": 11,
-# CHECK-NEXT:  "line": 0
+# CHECK-NEXT:  "line": 1
 # CHECK-NEXT:}
 # CHECK-NEXT:  },
 # CHECK-NEXT:  "uri": "file://{{.*}}/{{([A-Z]:/)?}}main.cpp"
 # CHECK-NEXT:}
 # CHECK-NEXT:  ]
 ---
-{"jsonrpc":"2.0","id":1,"method":"textDocument/documentHighlight","params":{"textDocument":{"uri":"test:///main.cpp"},"position":{"line":2,"character":8}}}
+{"jsonrpc":"2.0","id":1,"method":"textDocument/documentHighlight","params":{"textDocument":{"uri":"test:///main.cpp"},"position":{"line":3,"character":8}}}
 #  CHECK: "id": 1
 # CHECK-NEXT: "jsonrpc": "2.0",
 # CHECK-NEXT: "result": [
@@ -51,11 +51,11 @@
 # CHECK-NEXT: "range": {
 # CHECK-NEXT:   "end": {
 # CHECK-NEXT: "character": 12,
-# CHECK-NEXT: "line": 0
+# CHECK-NEXT: "line": 1
 # CHECK-NEXT:   },
 

[PATCH] D93630: [Attr] Apply GNU-style attributes to expression statements

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

In D93630#2468853 , @aaron.ballman 
wrote:

> Yeah, I kind of figured that might be the cause. I'm not 100% convinced (one 
> way or the other) if the suppress attribute should get a GNU spelling. The 
> `[[]]` spellings are available in all language modes (we have 
> `-fdouble-square-bracket-attributes` to enable this) and don't run afoul of 
> the "guess what this attribute appertains to" problem that GNU-style 
> attributes do.

I don't think that we can force our users into adding this flag.  Also, Obj-C 
codebases already use a good amount of GNU-style attributes, so it is pretty 
natural there.




Comment at: clang/lib/Parse/ParseStmt.cpp:213
  ParsedStmtContext()) &&
-(GNUAttributeLoc.isValid() || isDeclarationStatement())) {
+((GNUAttributeLoc.isValid() && !Attrs.back().isStmtAttr()) ||
+ isDeclarationStatement())) {

aaron.ballman wrote:
> I think you need to ensure there's at least one attribute before checking 
> `!Attrs.back().isStmtAttr()` as this may cause problems if the user does 
> something odd like `__attribute__(()) int x;` (I don't know if this will 
> result in a valid `GNUAttributeLoc` with no attributes or not.)
> 
> I'm not certain that logic is perfect either. It would be pretty mysterious 
> to handle these cases differently:
> ```
> __attribute__((stmt_attr, decl_attr)) int a, b, c;
> __attribute__((decl_attr, stmt_attr)) int x, y, z;
> ```
Yep, my bad.  I changed it so that ALL the attributes in the front should be 
statement attributes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93630

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

[clang-tools-extra] 2522fa0 - [clangd] Do not take stale definition from the static index.

[Aleksandr Platonov via cfe-commits]

Author: Aleksandr Platonov
Date: 2020-12-23T18:21:38+03:00
New Revision: 2522fa053b62520ae48b4b27117ca003a2c878ab

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

LOG: [clangd] Do not take stale definition from the static index.

This is follow up to D93393.
Without this patch clangd takes the symbol definition from the static index if 
this definition was removed from the dynamic index.

Reviewed By: sammccall

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

Added: 


Modified: 
clang-tools-extra/clangd/index/Merge.cpp
clang-tools-extra/clangd/unittests/IndexTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/index/Merge.cpp 
b/clang-tools-extra/clangd/index/Merge.cpp
index 97babacf2b38..f66f47499624 100644
--- a/clang-tools-extra/clangd/index/Merge.cpp
+++ b/clang-tools-extra/clangd/index/Merge.cpp
@@ -76,7 +76,13 @@ void MergedIndex::lookup(
   Dynamic->lookup(Req, [&](const Symbol &S) { B.insert(S); });
 
   auto RemainingIDs = Req.IDs;
+  auto DynamicContainsFile = Dynamic->indexedFiles();
   Static->lookup(Req, [&](const Symbol &S) {
+// We expect the definition to see the canonical declaration, so it seems
+// to be enough to check only the definition if it exists.
+if (DynamicContainsFile(S.Definition ? S.Definition.FileURI
+ : S.CanonicalDeclaration.FileURI))
+  return;
 const Symbol *Sym = B.find(S.ID);
 RemainingIDs.erase(S.ID);
 if (!Sym)

diff  --git a/clang-tools-extra/clangd/unittests/IndexTests.cpp 
b/clang-tools-extra/clangd/unittests/IndexTests.cpp
index 8efc637d1250..ce4845e3e144 100644
--- a/clang-tools-extra/clangd/unittests/IndexTests.cpp
+++ b/clang-tools-extra/clangd/unittests/IndexTests.cpp
@@ -290,6 +290,40 @@ TEST(MergeIndexTest, Lookup) {
   EXPECT_THAT(lookup(M, {}), UnorderedElementsAre());
 }
 
+TEST(MergeIndexTest, LookupRemovedDefinition) {
+  FileIndex DynamicIndex, StaticIndex;
+  MergedIndex Merge(&DynamicIndex, &StaticIndex);
+
+  const char *HeaderCode = "class Foo;";
+  auto HeaderSymbols = TestTU::withHeaderCode(HeaderCode).headerSymbols();
+  auto Foo = findSymbol(HeaderSymbols, "Foo");
+
+  // Build static index for test.cc with Foo definition
+  TestTU Test;
+  Test.HeaderCode = HeaderCode;
+  Test.Code = "class Foo {};";
+  Test.Filename = "test.cc";
+  auto AST = Test.build();
+  StaticIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Remove Foo definition from test.cc, i.e. build dynamic index for test.cc
+  // without Foo definition.
+  Test.Code = "class Foo;";
+  AST = Test.build();
+  DynamicIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Merged index should not return the symbol definition if this definition
+  // location is inside a file from the dynamic index.
+  LookupRequest LookupReq;
+  LookupReq.IDs = {Foo.ID};
+  unsigned SymbolCounter = 0;
+  Merge.lookup(LookupReq, [&](const Symbol &Sym) {
+++SymbolCounter;
+EXPECT_FALSE(Sym.Definition);
+  });
+  EXPECT_EQ(SymbolCounter, 1u);
+}
+
 TEST(MergeIndexTest, FuzzyFind) {
   auto I = MemIndex::build(generateSymbols({"ns::A", "ns::B"}), RefSlab(),
RelationSlab()),



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

[PATCH] D93683: [clangd] Do not take stale definition from the static index.

[Aleksandr Platonov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG2522fa053b62: [clangd] Do not take stale definition from the 
static index. (authored by ArcsinX).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93683

Files:
  clang-tools-extra/clangd/index/Merge.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
@@ -290,6 +290,40 @@
   EXPECT_THAT(lookup(M, {}), UnorderedElementsAre());
 }
 
+TEST(MergeIndexTest, LookupRemovedDefinition) {
+  FileIndex DynamicIndex, StaticIndex;
+  MergedIndex Merge(&DynamicIndex, &StaticIndex);
+
+  const char *HeaderCode = "class Foo;";
+  auto HeaderSymbols = TestTU::withHeaderCode(HeaderCode).headerSymbols();
+  auto Foo = findSymbol(HeaderSymbols, "Foo");
+
+  // Build static index for test.cc with Foo definition
+  TestTU Test;
+  Test.HeaderCode = HeaderCode;
+  Test.Code = "class Foo {};";
+  Test.Filename = "test.cc";
+  auto AST = Test.build();
+  StaticIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Remove Foo definition from test.cc, i.e. build dynamic index for test.cc
+  // without Foo definition.
+  Test.Code = "class Foo;";
+  AST = Test.build();
+  DynamicIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Merged index should not return the symbol definition if this definition
+  // location is inside a file from the dynamic index.
+  LookupRequest LookupReq;
+  LookupReq.IDs = {Foo.ID};
+  unsigned SymbolCounter = 0;
+  Merge.lookup(LookupReq, [&](const Symbol &Sym) {
+++SymbolCounter;
+EXPECT_FALSE(Sym.Definition);
+  });
+  EXPECT_EQ(SymbolCounter, 1u);
+}
+
 TEST(MergeIndexTest, FuzzyFind) {
   auto I = MemIndex::build(generateSymbols({"ns::A", "ns::B"}), RefSlab(),
RelationSlab()),
Index: clang-tools-extra/clangd/index/Merge.cpp
===
--- clang-tools-extra/clangd/index/Merge.cpp
+++ clang-tools-extra/clangd/index/Merge.cpp
@@ -76,7 +76,13 @@
   Dynamic->lookup(Req, [&](const Symbol &S) { B.insert(S); });
 
   auto RemainingIDs = Req.IDs;
+  auto DynamicContainsFile = Dynamic->indexedFiles();
   Static->lookup(Req, [&](const Symbol &S) {
+// We expect the definition to see the canonical declaration, so it seems
+// to be enough to check only the definition if it exists.
+if (DynamicContainsFile(S.Definition ? S.Definition.FileURI
+ : S.CanonicalDeclaration.FileURI))
+  return;
 const Symbol *Sym = B.find(S.ID);
 RemainingIDs.erase(S.ID);
 if (!Sym)


Index: clang-tools-extra/clangd/unittests/IndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/IndexTests.cpp
+++ clang-tools-extra/clangd/unittests/IndexTests.cpp
@@ -290,6 +290,40 @@
   EXPECT_THAT(lookup(M, {}), UnorderedElementsAre());
 }
 
+TEST(MergeIndexTest, LookupRemovedDefinition) {
+  FileIndex DynamicIndex, StaticIndex;
+  MergedIndex Merge(&DynamicIndex, &StaticIndex);
+
+  const char *HeaderCode = "class Foo;";
+  auto HeaderSymbols = TestTU::withHeaderCode(HeaderCode).headerSymbols();
+  auto Foo = findSymbol(HeaderSymbols, "Foo");
+
+  // Build static index for test.cc with Foo definition
+  TestTU Test;
+  Test.HeaderCode = HeaderCode;
+  Test.Code = "class Foo {};";
+  Test.Filename = "test.cc";
+  auto AST = Test.build();
+  StaticIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Remove Foo definition from test.cc, i.e. build dynamic index for test.cc
+  // without Foo definition.
+  Test.Code = "class Foo;";
+  AST = Test.build();
+  DynamicIndex.updateMain(testPath(Test.Filename), AST);
+
+  // Merged index should not return the symbol definition if this definition
+  // location is inside a file from the dynamic index.
+  LookupRequest LookupReq;
+  LookupReq.IDs = {Foo.ID};
+  unsigned SymbolCounter = 0;
+  Merge.lookup(LookupReq, [&](const Symbol &Sym) {
+++SymbolCounter;
+EXPECT_FALSE(Sym.Definition);
+  });
+  EXPECT_EQ(SymbolCounter, 1u);
+}
+
 TEST(MergeIndexTest, FuzzyFind) {
   auto I = MemIndex::build(generateSymbols({"ns::A", "ns::B"}), RefSlab(),
RelationSlab()),
Index: clang-tools-extra/clangd/index/Merge.cpp
===
--- clang-tools-extra/clangd/index/Merge.cpp
+++ clang-tools-extra/clangd/index/Merge.cpp
@@ -76,7 +76,13 @@
   Dynamic->lookup(Req, [&](const Symbol &S) { B.insert(S); });
 
   auto RemainingIDs = Req.IDs;
+  auto DynamicContainsFile = Dynamic->indexedFiles();
   Static->lookup(Req, [&](const Symbol &S) {
+// We expect the definition to see the canonical declaration

[PATCH] D83892: [clang][cli] Port CodeGen option flags to new option parsing system

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Heads-up: Looks like one of these changes, likely this one for CodeGen, made 
sanitizer output way larger: 
https://bugs.chromium.org/p/chromium/issues/detail?id=1161230


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83892

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

[PATCH] D93758: [format][NFC] Use unsigned char as the base of all enums in FormatStyle

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 313559.
njames93 added a comment.

- Update dump_format_style script

Only tweaked regex to support enum  :  ... {
Decided there wasn't much to gain from supporting nested types etc


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93758

Files:
  clang/docs/tools/dump_format_style.py
  clang/include/clang/Format/Format.h

Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -56,7 +56,7 @@
   int AccessModifierOffset;
 
   /// Different styles for aligning after open brackets.
-  enum BracketAlignmentStyle {
+  enum BracketAlignmentStyle : unsigned char {
 /// Align parameters on the open bracket, e.g.:
 /// \code
 ///   someLongFunction(argument1,
@@ -131,7 +131,7 @@
   bool AlignConsecutiveDeclarations;
 
   /// Different styles for aligning escaped newlines.
-  enum EscapedNewlineAlignmentStyle {
+  enum EscapedNewlineAlignmentStyle : unsigned char {
 /// Don't align escaped newlines.
 /// \code
 ///   #define A \
@@ -165,7 +165,7 @@
   EscapedNewlineAlignmentStyle AlignEscapedNewlines;
 
   /// Different styles for aligning operands.
-  enum OperandAlignmentStyle {
+  enum OperandAlignmentStyle : unsigned char {
 /// Do not align operands of binary and ternary expressions.
 /// The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
 /// the start of the line.
@@ -275,7 +275,7 @@
 
   /// Different styles for merging short blocks containing at most one
   /// statement.
-  enum ShortBlockStyle {
+  enum ShortBlockStyle : unsigned char {
 /// Never merge blocks into a single line.
 /// \code
 ///   while (true) {
@@ -320,7 +320,7 @@
 
   /// Different styles for merging short functions containing at most one
   /// statement.
-  enum ShortFunctionStyle {
+  enum ShortFunctionStyle : unsigned char {
 /// Never merge functions into a single line.
 SFS_None,
 /// Only merge functions defined inside a class. Same as "inline",
@@ -371,7 +371,7 @@
   ShortFunctionStyle AllowShortFunctionsOnASingleLine;
 
   /// Different styles for handling short if lines
-  enum ShortIfStyle {
+  enum ShortIfStyle : unsigned char {
 /// Never put short ifs on the same line.
 /// \code
 ///   if (a)
@@ -405,7 +405,7 @@
 
   /// Different styles for merging short lambdas containing at most one
   /// statement.
-  enum ShortLambdaStyle {
+  enum ShortLambdaStyle : unsigned char {
 /// Never merge lambdas into a single line.
 SLS_None,
 /// Only merge empty lambdas.
@@ -442,7 +442,7 @@
 
   /// Different ways to break after the function definition return type.
   /// This option is **deprecated** and is retained for backwards compatibility.
-  enum DefinitionReturnTypeBreakingStyle {
+  enum DefinitionReturnTypeBreakingStyle : unsigned char {
 /// Break after return type automatically.
 /// ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
 DRTBS_None,
@@ -454,7 +454,7 @@
 
   /// Different ways to break after the function definition or
   /// declaration return type.
-  enum ReturnTypeBreakingStyle {
+  enum ReturnTypeBreakingStyle : unsigned char {
 /// Break after return type automatically.
 /// ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
 /// \code
@@ -545,7 +545,7 @@
   bool AlwaysBreakBeforeMultilineStrings;
 
   /// Different ways to break after the template declaration.
-  enum BreakTemplateDeclarationsStyle {
+  enum BreakTemplateDeclarationsStyle : unsigned char {
 /// Do not force break before declaration.
 /// ``PenaltyBreakTemplateDeclaration`` is taken into account.
 /// \code
@@ -620,7 +620,7 @@
   bool BinPackArguments;
 
   /// The style of inserting trailing commas into container literals.
-  enum TrailingCommaStyle {
+  enum TrailingCommaStyle : unsigned char {
 /// Do not insert trailing commas.
 TCS_None,
 /// Insert trailing commas in container literals that were wrapped over
@@ -664,7 +664,7 @@
 
   /// The style of wrapping parameters on the same line (bin-packed) or
   /// on one line each.
-  enum BinPackStyle {
+  enum BinPackStyle : unsigned char {
 /// Automatically determine parameter bin-packing behavior.
 BPS_Auto,
 /// Always bin-pack parameters.
@@ -674,7 +674,7 @@
   };
 
   /// The style of breaking before or after binary operators.
-  enum BinaryOperatorStyle {
+  enum BinaryOperatorStyle : unsigned char {
 /// Break after operators.
 /// \code
 ///LooongType loongVariable =
@@ -717,7 +717,7 @@
   BinaryOperatorStyle BreakBeforeBinaryOperators;
 
   /// Different ways to attach braces to their surrounding context.
-  enum BraceBreakingStyle {
+  enum BraceBreakingStyle : unsigned char {
 /// Always attach brace

[PATCH] D93758: [format][NFC] Use unsigned char as the base of all enums in FormatStyle

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

I don't have any major issues with this other than it makes Format.h a bit more 
ugly. (there are more ugly and harder to understand pieces of code than this 
change!)

We'll only normally really have 1 of these in play at any one time, but it is 
passed around quite a bit on the stack, should we care about the extra space 
it's taking?  (I'm ok if the answer is "yes we should")


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93758

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

[PATCH] D93758: [format][NFC] Use unsigned char as the base of all enums in FormatStyle

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

In D93758#2470124 , @MyDeveloperDay 
wrote:

> I don't have any major issues with this other than it makes Format.h a bit 
> more ugly. (there are more ugly and harder to understand pieces of code than 
> this change!)
>
> We'll only normally really have 1 of these in play at any one time, but it is 
> passed around quite a bit on the stack, should we care about the extra space 
> it's taking?  (I'm ok if the answer is "yes we should")

We only keep one instance on the stack in clang-format. But in tools that embed 
clang format we may keep more than 1 around. In clangd we are hoping to cache 
format styles for each file(well directory). As these cached items will live on 
the heap, saving about 16% from the size is worth it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93758

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

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

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram added a comment.

In D93747#2469556 , @hoy wrote:

>> In D93656 , @dblaikie wrote:
>> Though the C case is interesting - it means you'll end up with C functions 
>> with the same DWARF 'name' but different linkage name. I don't know what 
>> that'll do to DWARF consumers - I guess they'll probably be OK-ish with it, 
>> as much as they are with C++ overloading. I think there are some cases of C 
>> name mangling so it's probably supported/OK-ish with DWARF Consumers. 
>> Wouldn't hurt for you to take a look/see what happens in that case with a 
>> debugger like gdb/check other cases of C name mangling to see what DWARF 
>> they end up creating (with both GCC and Clang).
>
> I did a quick experiment with C name managing with GCC and -flto. It turns 
> out the `DW_AT_linkage_name` field of `DW_TAG_subprogram` is never set for C 
> programs. If set, the gdb debugger will use that field to match the user 
> input and set breakpoints. Therefore, giving `DW_AT_linkage_name` a 
> uniquefied name prevents the debugger from setting a breakpoint based on 
> source names unless the user specifies a decorated name.
>
> Hence, this approach sounds like a workaround for us when the profile quality 
> matters more than debugging experience. I'm inclined to have it under a 
> switch. What do you think?

Just a thought, we could always check if rawLinkageName is set and only set it 
when it is not null.  That seems safe without needing the option. Not a strong 
opinion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

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

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[Hongtao Yu via Phabricator via cfe-commits]

hoy updated this revision to Diff 313566.
hoy edited the summary of this revision.
hoy added a comment.

Checking pipeline in clang test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93656

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/unique-internal-linkage-names.cpp
  llvm/include/llvm/Passes/PassBuilder.h
  llvm/lib/Passes/PassBuilder.cpp
  llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll

Index: llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
===
--- /dev/null
+++ llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
@@ -0,0 +1,37 @@
+; RUN: opt -S -unique-internal-linkage-names < %s | FileCheck %s
+; RUN: opt -S -passes=unique-internal-linkage-names < %s | FileCheck %s
+
+define internal i32 @foo() !dbg !15 {
+entry:
+  ret i32 0, !dbg !18
+}
+
+define dso_local i32 (...)* @bar() !dbg !7 {
+entry:
+  ret i32 (...)* bitcast (i32 ()* @foo to i32 (...)*), !dbg !14
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, enums: !2)
+!1 = !DIFile(filename: "test.c", directory: "")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!7 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 9, type: !8, scopeLine: 9, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!8 = !DISubroutineType(types: !9)
+!9 = !{!10}
+!10 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 64)
+!11 = !DISubroutineType(types: !12)
+!12 = !{!13, null}
+!13 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!14 = !DILocation(line: 10, column: 3, scope: !7)
+!15 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 5, type: !16, scopeLine: 5, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!16 = !DISubroutineType(types: !17)
+!17 = !{!13}
+!18 = !DILocation(line: 6, column: 3, scope: !15)
+
+; CHECK: define internal i32 @foo.__uniq.{{[0-9a-f]+}}()
+; CHECK: ret {{.*}} @foo.__uniq.{{[0-9a-f]+}} {{.*}}
Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -284,6 +284,7 @@
   LicmMssaNoAccForPromotionCap = SetLicmMssaNoAccForPromotionCap;
   CallGraphProfile = true;
   MergeFunctions = false;
+  UniqueLinkageNames = false;
 }
 
 extern cl::opt EnableConstraintElimination;
@@ -1001,6 +1002,11 @@
ThinLTOPhase Phase) {
   ModulePassManager MPM(DebugLogging);
 
+  // Add UniqueInternalLinkageNames Pass which renames internal linkage
+  // symbols with unique names.
+  if (PTO.UniqueLinkageNames)
+MPM.addPass(UniqueInternalLinkageNamesPass());
+
   // Place pseudo probe instrumentation as the first pass of the pipeline to
   // minimize the impact of optimization changes.
   if (PGOOpt && PGOOpt->PseudoProbeForProfiling &&
@@ -1764,6 +1770,11 @@
 
   ModulePassManager MPM(DebugLogging);
 
+  // Add UniqueInternalLinkageNames Pass which renames internal linkage
+  // symbols with unique names.
+  if (PTO.UniqueLinkageNames)
+MPM.addPass(UniqueInternalLinkageNamesPass());
+
   if (PGOOpt && (PGOOpt->Action == PGOOptions::IRInstr ||
  PGOOpt->Action == PGOOptions::IRUse))
 addPGOInstrPassesForO0(
Index: llvm/include/llvm/Passes/PassBuilder.h
===
--- llvm/include/llvm/Passes/PassBuilder.h
+++ llvm/include/llvm/Passes/PassBuilder.h
@@ -127,6 +127,9 @@
   /// Tuning option to enable/disable function merging. Its default value is
   /// false.
   bool MergeFunctions;
+
+  /// Uniquefy function linkage name. Its default value is false.
+  bool UniqueLinkageNames;
 };
 
 /// This class provides access to building LLVM's passes.
Index: clang/test/CodeGen/unique-internal-linkage-names.cpp
===
--- clang/test/CodeGen/unique-internal-linkage-names.cpp
+++ clang/test/CodeGen/unique-internal-linkage-names.cpp
@@ -1,10 +1,10 @@
 // This test checks if internal linkage symbols get unique names with
 // -funique-internal-linkage-names option.
 // RUN: %clang_cc1 -triple x86_64 -x c++ -S -emit-llvm -o - < %s | FileCheck %s --check-prefix=PLAIN
-// RUN: %clang_cc1 -triple x86_64 -x c++ -O0 -S -emit-llvm -funique-internal-linkage-names -o - < %s | FileCheck %s --check-prefix=UNIQUE
-// RUN: %clang_cc1 -triple x86_64 -x c++ -O1 -S -emit-llvm -funique-internal-linkage-names -o - < %s | FileCheck %s --check-prefix=UNIQUEO1
-// RUN: %clang_cc1 -triple x86_64 -x c++ -O0 -S -emit-llvm -fexperimental-new-pass-manager -funique-internal-linkage-names -o - < %s | FileCheck %s -

[PATCH] D92024: [clang] Implement P0692R1 from C++20 (access checking on specializations and instantiations)

[Alex Orlov via Phabricator via cfe-commits]

aorlov added a comment.

Please, somebody look at this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92024

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

[PATCH] D83892: [clang][cli] Port CodeGen option flags to new option parsing system

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

I verified it's due to this change. 
https://bugs.chromium.org/p/chromium/issues/detail?id=1161230#c15 has a 
stand-alone repro.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83892

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

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

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.

In D93747#2470178 , @tmsriram wrote:

> In D93747#2469556 , @hoy wrote:
>
>>> In D93656 , @dblaikie wrote:
>>> Though the C case is interesting - it means you'll end up with C functions 
>>> with the same DWARF 'name' but different linkage name. I don't know what 
>>> that'll do to DWARF consumers - I guess they'll probably be OK-ish with it, 
>>> as much as they are with C++ overloading. I think there are some cases of C 
>>> name mangling so it's probably supported/OK-ish with DWARF Consumers. 
>>> Wouldn't hurt for you to take a look/see what happens in that case with a 
>>> debugger like gdb/check other cases of C name mangling to see what DWARF 
>>> they end up creating (with both GCC and Clang).
>>
>> I did a quick experiment with C name managing with GCC and -flto. It turns 
>> out the `DW_AT_linkage_name` field of `DW_TAG_subprogram` is never set for C 
>> programs. If set, the gdb debugger will use that field to match the user 
>> input and set breakpoints. Therefore, giving `DW_AT_linkage_name` a 
>> uniquefied name prevents the debugger from setting a breakpoint based on 
>> source names unless the user specifies a decorated name.
>>
>> Hence, this approach sounds like a workaround for us when the profile 
>> quality matters more than debugging experience. I'm inclined to have it 
>> under a switch. What do you think?
>
> Just a thought, we could always check if rawLinkageName is set and only set 
> it when it is not null.  That seems safe without needing the option. Not a 
> strong opinion.

It seems that the demangler of the debugger is not able to handle an uniquefied 
name, even if the debug record originally comes with a linkage name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

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

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

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram added a comment.

In D93747#2470189 , @hoy wrote:

> In D93747#2470178 , @tmsriram wrote:
>
>> In D93747#2469556 , @hoy wrote:
>>
 In D93656 , @dblaikie wrote:
 Though the C case is interesting - it means you'll end up with C functions 
 with the same DWARF 'name' but different linkage name. I don't know what 
 that'll do to DWARF consumers - I guess they'll probably be OK-ish with 
 it, as much as they are with C++ overloading. I think there are some cases 
 of C name mangling so it's probably supported/OK-ish with DWARF Consumers. 
 Wouldn't hurt for you to take a look/see what happens in that case with a 
 debugger like gdb/check other cases of C name mangling to see what DWARF 
 they end up creating (with both GCC and Clang).
>>>
>>> I did a quick experiment with C name managing with GCC and -flto. It turns 
>>> out the `DW_AT_linkage_name` field of `DW_TAG_subprogram` is never set for 
>>> C programs. If set, the gdb debugger will use that field to match the user 
>>> input and set breakpoints. Therefore, giving `DW_AT_linkage_name` a 
>>> uniquefied name prevents the debugger from setting a breakpoint based on 
>>> source names unless the user specifies a decorated name.
>>>
>>> Hence, this approach sounds like a workaround for us when the profile 
>>> quality matters more than debugging experience. I'm inclined to have it 
>>> under a switch. What do you think?
>>
>> Just a thought, we could always check if rawLinkageName is set and only set 
>> it when it is not null.  That seems safe without needing the option. Not a 
>> strong opinion.
>
> It seems that the demangler of the debugger is not able to handle an 
> uniquefied name, even if the debug record originally comes with a linkage 
> name.

Yep, the demangler (which can be checked with c++filt) is very restricted on 
what comes after the "."  It can be either numbers or characters but not a mix 
of the two.  I guess we can enhance it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

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

[PATCH] D93769: RFC [clang] Add support for option -ffp-eval-method and extend #pragma float_control similarly

[Melanie Blower via Phabricator via cfe-commits]

mibintc created this revision.
mibintc added reviewers: kpn, sepavloff, andrew.w.kaylor, rjmccall.
Herald added subscribers: dexonsmith, dang.
mibintc requested review of this revision.
Herald added a project: clang.

The Intel compiler supports the option -fp-model={source|double|extended} which 
causes the compiler to use a wider type for intermediate floating point 
calculations.  Also supported is a way to embed this effect in the source 
program with #pragma float_control(source|double|extended).  This patch 
proposes to extend pragma float_control syntax, and also to support a new 
floating point option via -ffp-eval-method={source|double|extended}

Note that the C floating point working group has proposed nearly identical 
pragma semantics in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1974.pdf 
like this
#pragma STDC FENV_FLT_EVAL_METHOD width
I would like to add support for this also, but it's not in this patch.

I'm going to add an inline question about how to redefine __FLT_EVAL_METHOD__ 
macro

The ICL option with description of semantics is at this url, 
https://software.intel.com/content/www/us/en/develop/documentation/cpp-compiler-developer-guide-and-reference/top/compiler-reference/compiler-options/compiler-option-details/floating-point-options/fp-model-fp.html


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93769

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/FPOptions.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Basic/PragmaKinds.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGen/fp-floatcontrol-pragma.cpp

Index: clang/test/CodeGen/fp-floatcontrol-pragma.cpp
===
--- clang/test/CodeGen/fp-floatcontrol-pragma.cpp
+++ clang/test/CodeGen/fp-floatcontrol-pragma.cpp
@@ -2,6 +2,9 @@
 // RUN: %clang_cc1 -fexperimental-strict-floating-point -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -fexperimental-strict-floating-point -DFENV_ON=1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck -check-prefix=CHECK-FENV %s
 // RUN: %clang_cc1 -fexperimental-strict-floating-point -triple %itanium_abi_triple -O3 -emit-llvm -o - %s | FileCheck -check-prefix=CHECK-O3 %s
+// RUN: %clang_cc1 -fexperimental-strict-floating-point -triple x86_64-linux-gnu -emit-llvm -o - %s -ffp-eval-method=source | FileCheck %s -check-prefix=CHECK-SOURCE
+// RUN: %clang_cc1 -fexperimental-strict-floating-point -triple x86_64-linux-gnu -emit-llvm -o - %s -ffp-eval-method=double | FileCheck %s -check-prefix=CHECK-DOUBLE
+// RUN: %clang_cc1 -fexperimental-strict-floating-point -triple x86_64-linux-gnu -emit-llvm -o - %s -ffp-eval-method=extended | FileCheck %s -check-prefix=CHECK-EXTENDED
 
 // Verify float_control(precise, off) enables fast math flags on fp operations.
 float fp_precise_1(float a, float b, float c) {
@@ -229,3 +232,45 @@
   result = x + t;
   return result;
 }
+
+float mySub(float x, float y) {
+// CHECK: define float {{.*}}mySub{{.*}}
+// CHECK-NS: fsub float
+// CHECK-SOURCE: fsub float
+// CHECK-DOUBLE: fpext float
+// CHECK-DOUBLE: fpext float
+// CHECK-DOUBLE: fsub double
+// CHECK-DOUBLE: fptrunc double {{.*}} to float
+// CHECK-EXTENDED: fpext float
+// CHECK-EXTENDED: fpext float
+// CHECK-EXTENDED: fsub double
+// CHECK-EXTENDED: fptrunc double {{.*}} to float
+  return x - y;
+}
+
+float mySubSource( float x, float y ) {
+// CHECK: define float {{.*}}mySubSource{{.*}}
+#pragma float_control(source)
+  return x - y;
+// CHECK: fsub float
+}
+
+float mySubExtended( float x, float y ) {
+// CHECK: define float {{.*}}mySubExtended{{.*}}
+#pragma float_control(extended)
+  return x - y;
+// CHECK: fpext float
+// CHECK: fpext float
+// CHECK: fsub x86_fp80
+// CHECK: fptrunc x86_fp80 {{.*}} to float
+}
+
+float mySubDouble( float x, float y ) {
+// CHECK: define float {{.*}}mySubDouble{{.*}}
+#pragma float_control(double)
+  return x - y;
+// CHECK: fpext float
+// CHECK: fpext float
+// CHECK: fsub double
+// CHECK: fptrunc double {{.*}} to float
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -773,6 +773,32 @@
   QualType Ty = E->getType();
   assert(!Ty.isNull() && "UsualUnaryConversions - missing type");
 
+  auto EvalMethod = CurFPFeatures.getFPEvalMethod();
+  if (EvalMethod != LangOptions::FEM_Source &&
+  Ty->isFloatingType()) {
+switch (EvalMethod) {
+default:
+  llvm_unreachable("Unrecognized float evaluation method");
+  break;
+case LangOptions::FEM_Double:
+  if (Context.getFloatingTypeOrder(Context.DoubleTy, Ty) >0)
+   

[PATCH] D83892: [clang][cli] Port CodeGen option flags to new option parsing system

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

I reverted this (and a bunch of stuff that landed on top of it) in 
7ad666798f12456d9e663e763e17e29007c3728d 
 for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83892

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

[PATCH] D93769: RFC [clang] Add support for option -ffp-eval-method and extend #pragma float_control similarly

[Melanie Blower via Phabricator via cfe-commits]

mibintc added inline comments.



Comment at: clang/lib/Sema/SemaAttr.cpp:429
+  case PFC_Source:
+//Builder.defineMacro("__FLT_EVAL_METHOD__", Twine("0"));
+NewFPFeatures.setFPEvalMethodOverride(LangOptions::FEM_Source);

@rjmccall I would like to push a new value for __FLT_EVAL_METHOD__ at the start 
of the scope of this pragma, then pop that value of the macro to restore the 
previous setting when the scope is exited, should I do that in ParsePragma? Can 
I do that by injecting "pragma push_macro(...)" into the token stream, do you 
have other suggestion or is there something similar in clang that I can study 
how to do this? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93769

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

[PATCH] D92024: [clang] Implement P0692R1 from C++20 (access checking on specializations and instantiations)

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added inline comments.



Comment at: clang/lib/Parse/ParseTemplate.cpp:265
+  // We don't use `SuppressAccessChecks` here because
+  // it supresses ALL the dignostics kinds, but we need to keep some of them.
+  // For instance marked as unavailable:

Spelling: /supresses/suppresses/, /dignostics kinds/kinds of diagnostics/



Comment at: clang/test/CXX/class.access/class.friend/p1.cpp:290
   A::I f2(A::I i = A::x) {} // expected-error 3 {{is a private member of}}
-  template A::I g2(A::I i) { // expected-error 2 {{is a private 
member of}}
+  template  A::I g2(A::I i) { // expected-error {{is a private 
member of}}
 T t;

This whitespace diff is gratuitous.



Comment at: clang/test/CXX/class.access/class.friend/p1.cpp:294
+  template <> A::I g2(A::I i) { return 0; } // expected-error {{is a 
private member of}}
   template A::I g2(A::I i);
 }

IMHO it would make sense to add several other variations here too:

```
template <> A::I g2(A::I i); // expected-error {{is a private member of}}
template <> int g2(int i);  // expected-error??
template <> A::I g2(A::I i);  // expected-error??
template A::I g2(A::I i); // expected-error {{is a private member of}}
template int g2(int i);  // OK
template A::I g2(A::I i);  // OK??
```

It might also be better to use a well-formed template `template int 
g3(int) { return 0; }` instead of `g2` for the explicit specializations, and to 
use yet another template `template int g4(int) { return 0; }` instead of 
`g2` for the explicit instantiation declarations. That way there's no 
accidental "cross-talk" between the various declarations that might affect what 
diagnostics get printed.



Comment at: clang/test/CXX/temp/temp.spec/part.spec.cpp:10
+
+// class for tests
+class TestClass {

I wonder if this test can be shortened and/or removed, now that you're not 
doing weird parser tricks that need exhaustive testing. E.g. at least the stuff 
with the `final` keyword could be removed now, right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92024

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

[clang] b920adf - This is a test commit

[Alan Phipps via cfe-commits]

Author: Alan Phipps
Date: 2020-12-23T12:57:27-06:00
New Revision: b920adf3b4f16bef8dde937b67874d8e8ac1030e

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

LOG: This is a test commit

Added: 


Modified: 
clang/lib/CodeGen/README.txt

Removed: 




diff  --git a/clang/lib/CodeGen/README.txt b/clang/lib/CodeGen/README.txt
index e6d61095bf23..e4fd7816d65c 100644
--- a/clang/lib/CodeGen/README.txt
+++ b/clang/lib/CodeGen/README.txt
@@ -16,6 +16,7 @@ extension. For example, if the bitfield width is 8 and it is
 appropriately aligned then is is a lot shorter to just load the char
 directly.
 
+
 //===-===//
 
 It may be worth avoiding creation of alloca's for formal arguments



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

[clang] bbd758a - Revert "This is a test commit"

[Alan Phipps via cfe-commits]

Author: Alan Phipps
Date: 2020-12-23T13:04:37-06:00
New Revision: bbd758a7913b1c374ca26e5a734a01200754fe0e

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

LOG: Revert "This is a test commit"

This reverts commit b920adf3b4f16bef8dde937b67874d8e8ac1030e.

Added: 


Modified: 
clang/lib/CodeGen/README.txt

Removed: 




diff  --git a/clang/lib/CodeGen/README.txt b/clang/lib/CodeGen/README.txt
index e4fd7816d65c..e6d61095bf23 100644
--- a/clang/lib/CodeGen/README.txt
+++ b/clang/lib/CodeGen/README.txt
@@ -16,7 +16,6 @@ extension. For example, if the bitfield width is 8 and it is
 appropriately aligned then is is a lot shorter to just load the char
 directly.
 
-
 //===-===//
 
 It may be worth avoiding creation of alloca's for formal arguments



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

[clang] 1876a29 - Revert more changes that landed on top of 741978d727

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2020-12-23T14:20:21-05:00
New Revision: 1876a2914fe0bedf50f7be6a305f5bf35493e496

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

LOG: Revert more changes that landed on top of 741978d727

This should've been in 7ad666798f12456d9 but wasn't.

Squashes these twoc commits:
Revert "[clang][cli] Let denormalizer decide how to render the option based on 
the option class"
This reverts commit 70410a264949101ced3ce3458f37dd4cc2f5af85.

Revert "[clang][cli] Implement `getAllArgValues` marshalling"
This reverts commit 63a24816f561a5d8e28ca7054892bd8602618be4.

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Frontend/CompilerInvocation.cpp
clang/unittests/Frontend/CompilerInvocationTest.cpp
llvm/include/llvm/Option/OptParser.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 7f63a5577262..af209eb9089d 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1839,8 +1839,7 @@ def fsystem_module : Flag<["-"], "fsystem-module">, 
Flags<[CC1Option]>,
   MarshallingInfoFlag<"FrontendOpts.IsSystemModule">;
 def fmodule_map_file : Joined<["-"], "fmodule-map-file=">,
   Group, Flags<[NoXarchOption,CC1Option]>, MetaVarName<"">,
-  HelpText<"Load this module map file">,
-  MarshallingInfoStringVector<"FrontendOpts.ModuleMapFiles">;
+  HelpText<"Load this module map file">;
 def fmodule_file : Joined<["-"], "fmodule-file=">,
   Group, Flags<[NoXarchOption,CC1Option]>, 
MetaVarName<"[=]">,
   HelpText<"Specify the mapping of module name to precompiled module file, or 
load a module file if name is omitted.">;
@@ -4625,7 +4624,7 @@ def arcmt_action_EQ : Joined<["-"], "arcmt-action=">, 
Flags<[CC1Option, NoDriver
   NormalizedValuesScope<"FrontendOptions">,
   NormalizedValues<["ARCMT_Check", "ARCMT_Modify", "ARCMT_Migrate"]>,
   MarshallingInfoString<"FrontendOpts.ARCMTAction", "ARCMT_None">,
-  AutoNormalizeEnum;
+  AutoNormalizeEnumJoined;
 
 def opt_record_file : Separate<["-"], "opt-record-file">,
   HelpText<"File name to use for YAML optimization record output">;

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index a7a5a73eebdd..06d8d2e27c9b 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -152,8 +152,8 @@ static Optional 
normalizeSimpleNegativeFlag(OptSpecifier Opt, unsigned,
 /// argument.
 static void denormalizeSimpleFlag(SmallVectorImpl &Args,
   const char *Spelling,
-  CompilerInvocation::StringAllocator,
-  Option::OptionClass, unsigned, /*T*/...) {
+  CompilerInvocation::StringAllocator, 
unsigned,
+  /*T*/...) {
   Args.push_back(Spelling);
 }
 
@@ -193,41 +193,12 @@ static auto makeBooleanOptionNormalizer(bool Value, bool 
OtherValue,
 
 static auto makeBooleanOptionDenormalizer(bool Value) {
   return [Value](SmallVectorImpl &Args, const char *Spelling,
- CompilerInvocation::StringAllocator, Option::OptionClass,
- unsigned, bool KeyPath) {
+ CompilerInvocation::StringAllocator, unsigned, bool KeyPath) {
 if (KeyPath == Value)
   Args.push_back(Spelling);
   };
 }
 
-static void denormalizeStringImpl(SmallVectorImpl &Args,
-  const char *Spelling,
-  CompilerInvocation::StringAllocator SA,
-  Option::OptionClass OptClass, unsigned,
-  Twine Value) {
-  switch (OptClass) {
-  case Option::SeparateClass:
-  case Option::JoinedOrSeparateClass:
-Args.push_back(Spelling);
-Args.push_back(SA(Value));
-break;
-  case Option::JoinedClass:
-Args.push_back(SA(Twine(Spelling) + Value));
-break;
-  default:
-llvm_unreachable("Cannot denormalize an option with option class "
- "incompatible with string denormalization.");
-  }
-}
-
-template 
-static void
-denormalizeString(SmallVectorImpl &Args, const char *Spelling,
-  CompilerInvocation::StringAllocator SA,
-  Option::OptionClass OptClass, unsigned TableIndex, T Value) {
-  denormalizeStringImpl(Args, Spelling, SA, OptClass, TableIndex, 
Twine(Value));
-}
-
 static Optional
 findValueTableByName(const SimpleEnumValueTable &Table, StringRef Name) {
   for (int I = 0, E = Table.Size; I != E; ++I)
@@ -269,13 +240,12 @@ static llvm::Optional 
normalizeSimpleEnum(OptSpecifier Opt,
 static void denormalizeSimpleEnumImpl(SmallVectorImpl &Args,

[PATCH] D83892: [clang][cli] Port CodeGen option flags to new option parsing system

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

...and two more in 1876a2914fe0bedf50f7be6a305f5bf35493e496 
. Sorry 
for the churn!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83892

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

[clang] 4c37453 - clang: Build and run FrontendTests with CLANG_ENABLE_STATIC_ANALYZER=OFF too

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2020-12-23T14:27:09-05:00
New Revision: 4c37453a04f942dd676af1eda5d0760d4ffe8927

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

LOG: clang: Build and run FrontendTests with CLANG_ENABLE_STATIC_ANALYZER=OFF 
too

They seem to pass fine with the analyzer off, and with this I would've
noticed my last check-clang break locally.

Added: 


Modified: 
clang/unittests/CMakeLists.txt
llvm/utils/gn/secondary/clang/unittests/BUILD.gn

Removed: 




diff  --git a/clang/unittests/CMakeLists.txt b/clang/unittests/CMakeLists.txt
index 4c222e24599f..bb635dfff991 100644
--- a/clang/unittests/CMakeLists.txt
+++ b/clang/unittests/CMakeLists.txt
@@ -24,13 +24,13 @@ add_subdirectory(Driver)
 if(CLANG_ENABLE_STATIC_ANALYZER)
   add_subdirectory(Analysis)
   add_subdirectory(StaticAnalyzer)
-  add_subdirectory(Frontend)
 endif()
 add_subdirectory(ASTMatchers)
 add_subdirectory(AST)
 add_subdirectory(CrossTU)
 add_subdirectory(Tooling)
 add_subdirectory(Format)
+add_subdirectory(Frontend)
 add_subdirectory(Rewrite)
 add_subdirectory(Sema)
 add_subdirectory(CodeGen)

diff  --git a/llvm/utils/gn/secondary/clang/unittests/BUILD.gn 
b/llvm/utils/gn/secondary/clang/unittests/BUILD.gn
index d1382919b5e2..23f5d2dfac85 100644
--- a/llvm/utils/gn/secondary/clang/unittests/BUILD.gn
+++ b/llvm/utils/gn/secondary/clang/unittests/BUILD.gn
@@ -10,6 +10,7 @@ group("unittests") {
 "CrossTU:CrossTUTests",
 "Driver:ClangDriverTests",
 "Format:FormatTests",
+"Frontend:FrontendTests",
 "Index:IndexTests",
 "Lex:LexTests",
 "Rename:ClangRenameTests",
@@ -22,7 +23,6 @@ group("unittests") {
   if (clang_enable_static_analyzer) {
 deps += [
   "Analysis:ClangAnalysisTests",
-  "Frontend:FrontendTests",
   "StaticAnalyzer:StaticAnalysisTests",
 ]
   }



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

[clang] 34e70d7 - Append ".__part." to every basic block section symbol.

[Sriraman Tallam via cfe-commits]

Author: Sriraman Tallam
Date: 2020-12-23T11:35:44-08:00
New Revision: 34e70d722dfd0e73d460802e8d43d3a885d24784

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

LOG: Append ".__part." to every basic block section symbol.

Every basic block section symbol created by -fbasic-block-sections will contain
".__part." to know that this symbol corresponds to a basic block fragment of
the function.

This patch solves two problems:

a) Like D89617, we want function symbols with suffixes to be properly qualified
   so that external tools like profile aggregators know exactly what this
   symbol corresponds to.
b) The current basic block naming just adds a ".N" to the symbol name where N is
   some integer. This collides with how clang creates __cxx_global_var_init.N.
   clang creates these symbol names to call constructor functions and basic
   block symbol naming should not use the same style.

Fixed all the test cases and added an extra test for __cxx_global_var_init
breakage.

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

Added: 
llvm/test/CodeGen/X86/basic-block-sections_2.ll

Modified: 
clang/test/CodeGen/basic-block-sections.c
lld/test/ELF/lto/basic-block-sections.ll
llvm/lib/CodeGen/MachineBasicBlock.cpp
llvm/test/CodeGen/X86/basic-block-sections-blockaddress-taken.ll
llvm/test/CodeGen/X86/basic-block-sections-clusters-branches.ll
llvm/test/CodeGen/X86/basic-block-sections-clusters-eh.ll
llvm/test/CodeGen/X86/basic-block-sections-clusters.ll
llvm/test/CodeGen/X86/basic-block-sections-directjumps.ll
llvm/test/CodeGen/X86/basic-block-sections-eh.ll
llvm/test/CodeGen/X86/basic-block-sections-list.ll
llvm/test/CodeGen/X86/basic-block-sections-listbb.ll
llvm/test/CodeGen/X86/basic-block-sections-mir-parse.mir
llvm/test/CodeGen/X86/basic-block-sections-unreachable.ll
llvm/test/CodeGen/X86/basic-block-sections.ll
llvm/test/CodeGen/X86/cfi-basic-block-sections-1.ll

llvm/test/CodeGen/X86/cfi-inserter-basic-block-sections-callee-save-registers.ll
llvm/test/CodeGen/X86/gcc_except_table_bb_sections.ll
llvm/test/DebugInfo/X86/basic-block-sections_1.ll

Removed: 




diff  --git a/clang/test/CodeGen/basic-block-sections.c 
b/clang/test/CodeGen/basic-block-sections.c
index 805539f06f08..70cdeeebb0d3 100644
--- a/clang/test/CodeGen/basic-block-sections.c
+++ b/clang/test/CodeGen/basic-block-sections.c
@@ -31,14 +31,14 @@ int another(int a) {
 // BB_WORLD: .section .text.world,"ax",@progbits{{$}}
 // BB_WORLD: world:
 // BB_WORLD: .section .text.world,"ax",@progbits,unique
-// BB_WORLD: world.1:
+// BB_WORLD: world.__part.1:
 // BB_WORLD: .section .text.another,"ax",@progbits
 // BB_ALL: .section .text.another,"ax",@progbits,unique
-// BB_ALL: another.1:
+// BB_ALL: another.__part.1:
 // BB_LIST-NOT: .section .text.another,"ax",@progbits,unique
 // BB_LIST: another:
-// BB_LIST-NOT: another.1:
+// BB_LIST-NOT: another.__part.1:
 //
-// UNIQUE: .section .text.world.world.1,
-// UNIQUE: .section .text.another.another.1,
+// UNIQUE: .section .text.world.world.__part.1,
+// UNIQUE: .section .text.another.another.__part.1,
 // ERROR: error:  unable to load basic block sections function list: 
'{{[Nn]}}o such file or directory'

diff  --git a/lld/test/ELF/lto/basic-block-sections.ll 
b/lld/test/ELF/lto/basic-block-sections.ll
index 1f932ac50a87..35b638ac488a 100644
--- a/lld/test/ELF/lto/basic-block-sections.ll
+++ b/lld/test/ELF/lto/basic-block-sections.ll
@@ -11,12 +11,12 @@
 ; SECNAMES: Name: .text.foo {{.*}}
 
 ; SECNAMES-FULL: Name: .text.foo {{.*}}
-; SECNAMES-FULL: Name: .text.foo.foo.1 {{.*}}
-; SECNAMES-FULL: Name: .text.foo.foo.2 {{.*}}
+; SECNAMES-FULL: Name: .text.foo.foo.__part.1 {{.*}}
+; SECNAMES-FULL: Name: .text.foo.foo.__part.2 {{.*}}
 
 ; SYMS: foo
-; SYMS: foo.1
-; SYMS: foo.2
+; SYMS: foo.__part.1
+; SYMS: foo.__part.2
 
 target datalayout = 
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-linux-gnu"

diff  --git a/llvm/lib/CodeGen/MachineBasicBlock.cpp 
b/llvm/lib/CodeGen/MachineBasicBlock.cpp
index 0278999a8f72..14a270f994b4 100644
--- a/llvm/lib/CodeGen/MachineBasicBlock.cpp
+++ b/llvm/lib/CodeGen/MachineBasicBlock.cpp
@@ -71,7 +71,10 @@ MCSymbol *MachineBasicBlock::getSymbol() const {
   } else if (SectionID == MBBSectionID::ExceptionSectionID) {
 Suffix += ".eh";
   } else {
-Suffix += "." + std::to_string(SectionID.Number);
+// For symbols that represent basic block sections, we add ".__part." 
to
+// allow tools like symbolizers to know that this represents a part of
+// the original function.
+Suffix = (Suffix + Twine(".__part.") + Twine(SectionID.Number)).str();
   }
   CachedM

[PATCH] D93082: Append ".__part." to all basic block section symbols.

[Sriraman Tallam via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG34e70d722dfd: Append ".__part." to every basic 
block section symbol. (authored by tmsriram).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D93082?vs=313447&id=313587#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93082

Files:
  clang/test/CodeGen/basic-block-sections.c
  lld/test/ELF/lto/basic-block-sections.ll
  llvm/lib/CodeGen/MachineBasicBlock.cpp
  llvm/test/CodeGen/X86/basic-block-sections-blockaddress-taken.ll
  llvm/test/CodeGen/X86/basic-block-sections-clusters-branches.ll
  llvm/test/CodeGen/X86/basic-block-sections-clusters-eh.ll
  llvm/test/CodeGen/X86/basic-block-sections-clusters.ll
  llvm/test/CodeGen/X86/basic-block-sections-directjumps.ll
  llvm/test/CodeGen/X86/basic-block-sections-eh.ll
  llvm/test/CodeGen/X86/basic-block-sections-list.ll
  llvm/test/CodeGen/X86/basic-block-sections-listbb.ll
  llvm/test/CodeGen/X86/basic-block-sections-mir-parse.mir
  llvm/test/CodeGen/X86/basic-block-sections-unreachable.ll
  llvm/test/CodeGen/X86/basic-block-sections.ll
  llvm/test/CodeGen/X86/basic-block-sections_2.ll
  llvm/test/CodeGen/X86/cfi-basic-block-sections-1.ll
  
llvm/test/CodeGen/X86/cfi-inserter-basic-block-sections-callee-save-registers.ll
  llvm/test/CodeGen/X86/gcc_except_table_bb_sections.ll
  llvm/test/DebugInfo/X86/basic-block-sections_1.ll

Index: llvm/test/DebugInfo/X86/basic-block-sections_1.ll
===
--- llvm/test/DebugInfo/X86/basic-block-sections_1.ll
+++ llvm/test/DebugInfo/X86/basic-block-sections_1.ll
@@ -16,33 +16,33 @@
 ; NO-SECTIONS: DW_AT_high_pc [DW_FORM_data4] ({{.*}})
 ; BB-SECTIONS: DW_AT_low_pc [DW_FORM_addr] (0x)
 ; BB-SECTIONS-NEXT: DW_AT_ranges [DW_FORM_sec_offset]
-; BB-SECTIONS-NEXT: [{{.*}}) ".text._Z3fooi.1"
-; BB-SECTIONS-NEXT: [{{.*}}) ".text._Z3fooi.2"
-; BB-SECTIONS-NEXT: [{{.*}}) ".text._Z3fooi.3"
+; BB-SECTIONS-NEXT: [{{.*}}) ".text._Z3fooi.__part.1"
+; BB-SECTIONS-NEXT: [{{.*}}) ".text._Z3fooi.__part.2"
+; BB-SECTIONS-NEXT: [{{.*}}) ".text._Z3fooi.__part.3"
 ; BB-SECTIONS-NEXT: [{{.*}}) ".text"
 ; BB-SECTIONS-ASM: _Z3fooi:
 ; BB-SECTIONS-ASM: .Ltmp{{[0-9]+}}:
 ; BB-SECTIONS-ASM-NEXT: .loc 1 2 9 prologue_end
 ; BB-SECTIONS-ASM: .Ltmp{{[0-9]+}}:
 ; BB-SECTIONS-ASM-NEXT: .loc 1 2 7 is_stmt
-; BB-SECTIONS-ASM: _Z3fooi.1:
+; BB-SECTIONS-ASM: _Z3fooi.__part.1:
 ; BB-SECTIONS-ASM: .LBB_END0_{{[0-9]+}}:
-; BB-SECTIONS-ASM: .size	_Z3fooi.1, .LBB_END0_{{[0-9]+}}-_Z3fooi.1
-; BB-SECTIONS-ASM: _Z3fooi.2:
+; BB-SECTIONS-ASM: .size	_Z3fooi.__part.1, .LBB_END0_{{[0-9]+}}-_Z3fooi.__part.1
+; BB-SECTIONS-ASM: _Z3fooi.__part.2:
 ; BB-SECTIONS-ASM: .Ltmp{{[0-9]+}}:
 ; BB-SECTIONS-ASM-NEXT: .LBB_END0_{{[0-9]+}}:
-; BB-SECTIONS-ASM: .size	_Z3fooi.2, .LBB_END0_{{[0-9]+}}-_Z3fooi.2
-; BB-SECTIONS-ASM: _Z3fooi.3:
+; BB-SECTIONS-ASM: .size	_Z3fooi.__part.2, .LBB_END0_{{[0-9]+}}-_Z3fooi.__part.2
+; BB-SECTIONS-ASM: _Z3fooi.__part.3:
 ; BB-SECTIONS-ASM: .Ltmp{{[0-9]+}}:
 ; BB-SECTIONS-ASM-NEXT: .LBB_END0_{{[0-9]+}}:
-; BB-SECTIONS-ASM: .size	_Z3fooi.3, .LBB_END0_{{[0-9]+}}-_Z3fooi.3
+; BB-SECTIONS-ASM: .size	_Z3fooi.__part.3, .LBB_END0_{{[0-9]+}}-_Z3fooi.__part.3
 ; BB-SECTIONS-ASM: .Lfunc_end0:
 ; BB-SECTIONS-ASM: .Ldebug_ranges0:
-; BB-SECTIONS-ASM-NEXT:	.quad	_Z3fooi.1
+; BB-SECTIONS-ASM-NEXT:	.quad	_Z3fooi.__part.1
 ; BB-SECTIONS-ASM-NEXT:	.quad	.LBB_END0_{{[0-9]+}}
-; BB-SECTIONS-ASM-NEXT:	.quad	_Z3fooi.2
+; BB-SECTIONS-ASM-NEXT:	.quad	_Z3fooi.__part.2
 ; BB-SECTIONS-ASM-NEXT:	.quad	.LBB_END0_{{[0-9]+}}
-; BB-SECTIONS-ASM-NEXT:	.quad	_Z3fooi.3
+; BB-SECTIONS-ASM-NEXT:	.quad	_Z3fooi.__part.3
 ; BB-SECTIONS-ASM-NEXT:	.quad	.LBB_END0_{{[0-9]+}}
 ; BB-SECTIONS-ASM-NEXT:	.quad	.Lfunc_begin0
 ; BB-SECTIONS-ASM-NEXT:	.quad	.Lfunc_end0
Index: llvm/test/CodeGen/X86/gcc_except_table_bb_sections.ll
===
--- llvm/test/CodeGen/X86/gcc_except_table_bb_sections.ll
+++ llvm/test/CodeGen/X86/gcc_except_table_bb_sections.ll
@@ -27,7 +27,7 @@
 
 ; CHECK-NOT:.cfi_lsda
 
-; CHECK-LABEL:main.1:
+; CHECK-LABEL:main.__part.1:
 ; CHECK-NEXT:   .cfi_startproc
 
 ; CHECK-NON-PIC-NEXT:   .cfi_personality 3, __gxx_personality_v0
@@ -38,7 +38,7 @@
 
 ; CHECK-NOT:.cfi_lsda
 
-; CHECK-LABEL:main.2:
+; CHECK-LABEL:main.__part.2:
 ; CHECK-NEXT:   .cfi_startproc
 
 ; CHECK-NON-PIC-NEXT:   .cfi_personality 3, __gxx_personality_v0
@@ -82,12 +82,12 @@
 
 ;; Verify @LPStart encoding for NON-PIC mode.
 ; CHECK-NON-PIC-NEXT:   .byte	0   # @LPStart Encoding = absptr
-; CHECK-NON-PIC-NEXT:   .quad	main.2
+; CHECK-NON-PIC-NEXT:   .quad	main.__part.2
 
 ;; Verify @LPStart encoding for PIC mode.
 ; CHECK-PIC-NEXT:   .byte	16

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

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Please remove the clang test change - if this is an LLVM change with LLVM test 
coverage, that's enough. (we don't generally test every LLVM change from both 
LLVM and Clang)

I'd still be curious if you could look around to see whether there are other 
cases of function splitting/cloning/etc to see how they deal with updating the 
DISubprograms, to see if there's some prior art that should be used here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

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

[PATCH] D87188: [InstCombine] Canonicalize SPF to abs intrinc

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Heads up: Breaks a test for us: 
https://bugs.chromium.org/p/chromium/issues/detail?id=1161542

(No reduced repro yet, might be UB, just fyi at this point.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87188

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

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names.cpp:48-49
 
+// LPIPELINE: Unique Internal Linkage Names
+// NPIPELINE: Running pass: UniqueInternalLinkageNamesPass
 // PLAIN: @_ZL4glob = internal global

Does this test validate the new behavior? (ie: does this test fail without the 
LLVM changes and pass with it) Not that it necessarily has to - since Clang 
isn't here to test the LLVM behavior - perhaps this test is sufficient in Clang 
to test that the code in BackendUtil works to enable this pass.

This could possibly be staged as independent commits - adding the LLVM 
functionality in one commit, which would be a no-op for Clang because it 
wouldn't be setting PTO.UniqueLinkageNames - then committing the Clang change 
that would remove the custom pass addition and set PTO.UniqueLinkageNames - and 
then it'd probably be reasonable to have this test be made a bit more explicit 
(testing the pass manager structure/order) to show that that Clang change had 
an effect: Moving the pass to the desired location in the pass pipeline.



Comment at: 
llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll:1-2
+; RUN: opt -S -unique-internal-linkage-names < %s | FileCheck %s
+; RUN: opt -S -passes=unique-internal-linkage-names < %s | FileCheck %s
+

Does this test test any changes that are made in the rest of the patch? Since 
the test is specifying the pass to test, I would've assumed this test would 
pass with or without any changes that might move that pass around in the pass 
order (or indeed add or remove it from the pass manager in general).

I'd expect this change to be tested in LLVM by a pass manager structure test, 
similar to the Clang test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93656

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

[PATCH] D87188: [InstCombine] Canonicalize SPF to abs intrinc

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D87188#2470392 , @thakis wrote:

> Heads up: Breaks a test for us: 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1161542
>
> (No reduced repro yet, might be UB, just fyi at this point.)

Thanks for headsup. For now i'll deal with the problem @nlopes pointed out 
above in a bit..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87188

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

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[Hongtao Yu via Phabricator via cfe-commits]

hoy added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names.cpp:48-49
 
+// LPIPELINE: Unique Internal Linkage Names
+// NPIPELINE: Running pass: UniqueInternalLinkageNamesPass
 // PLAIN: @_ZL4glob = internal global

dblaikie wrote:
> Does this test validate the new behavior? (ie: does this test fail without 
> the LLVM changes and pass with it) Not that it necessarily has to - since 
> Clang isn't here to test the LLVM behavior - perhaps this test is sufficient 
> in Clang to test that the code in BackendUtil works to enable this pass.
> 
> This could possibly be staged as independent commits - adding the LLVM 
> functionality in one commit, which would be a no-op for Clang because it 
> wouldn't be setting PTO.UniqueLinkageNames - then committing the Clang change 
> that would remove the custom pass addition and set PTO.UniqueLinkageNames - 
> and then it'd probably be reasonable to have this test be made a bit more 
> explicit (testing the pass manager structure/order) to show that that Clang 
> change had an effect: Moving the pass to the desired location in the pass 
> pipeline.
This is a good question. No, this test does not validate the pipeline change on 
the LLVM side, since Clang shouldn't have knowledge about how the pipelines are 
arranged in LLVM. As you pointed out, the test here is to test if the specific 
pass is run and gives expected results.

Thanks for the suggestion to break the Clang changes and LLVM changes apart 
which would make the testing more specific. The pipeline ordering could be 
tested with a LLVM test but that would require a LLVM switch setup for 
UniqueLinkageNames and I'm not sure there's a need for that switch except for 
testing.



Comment at: 
llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll:1-2
+; RUN: opt -S -unique-internal-linkage-names < %s | FileCheck %s
+; RUN: opt -S -passes=unique-internal-linkage-names < %s | FileCheck %s
+

dblaikie wrote:
> Does this test test any changes that are made in the rest of the patch? Since 
> the test is specifying the pass to test, I would've assumed this test would 
> pass with or without any changes that might move that pass around in the pass 
> order (or indeed add or remove it from the pass manager in general).
> 
> I'd expect this change to be tested in LLVM by a pass manager structure test, 
> similar to the Clang test.
Right, the test here does not test the specific pass order set up by this 
change. It tests that the ordering change does not revert what's already there, 
i.e, the `UniqueInternalLinkageNamesPass` is still run and gives expected 
results.

Ideally the pipeline ordering should also be tested but that would require a 
LLVM switch setup to enable the pass and I'm not sure there's a need for that 
switch except for testing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93656

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

[PATCH] D86844: [LoopDeletion] Allows deletion of possibly infinite side-effect free loops

[Atmn Patel via Phabricator via cfe-commits]

atmnpatel updated this revision to Diff 313593.
atmnpatel added a comment.

As expected, @fhahn was right, adding willreturn to all those tests was an 
artifact from previous revisions of this patch and it passed the tests so I 
didn't pay them any mind, but I removed them now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86844

Files:
  clang/test/Misc/loop-opt-setup.c
  llvm/include/llvm/Transforms/Utils/LoopUtils.h
  llvm/lib/Transforms/Scalar/LoopDeletion.cpp
  llvm/lib/Transforms/Utils/LoopUtils.cpp
  llvm/test/Transforms/LoopDeletion/mustprogress.ll
  llvm/test/Transforms/LoopDeletion/no-exit-blocks.ll

Index: llvm/test/Transforms/LoopDeletion/no-exit-blocks.ll
===
--- llvm/test/Transforms/LoopDeletion/no-exit-blocks.ll
+++ llvm/test/Transforms/LoopDeletion/no-exit-blocks.ll
@@ -5,14 +5,7 @@
 ; CHECK: Function Attrs: mustprogress
 ; CHECK-LABEL: define {{[^@]+}}@f
 ; CHECK-SAME: () [[ATTR0:#.*]] {
-; CHECK-NEXT:br label [[TMP1:%.*]]
-; CHECK:   1:
-; CHECK-NEXT:[[DOT01:%.*]] = phi i32 [ 1, [[TMP0:%.*]] ], [ [[TMP3:%.*]], [[TMP2:%.*]] ]
-; CHECK-NEXT:[[DOT0:%.*]] = phi i32 [ 1, [[TMP0]] ], [ [[TMP3]], [[TMP2]] ]
-; CHECK-NEXT:br label [[TMP2]]
-; CHECK:   2:
-; CHECK-NEXT:[[TMP3]] = add nsw i32 [[DOT01]], [[DOT0]]
-; CHECK-NEXT:br label [[TMP1]]
+; CHECK-NEXT:unreachable
 ;
   br label %1
 
Index: llvm/test/Transforms/LoopDeletion/mustprogress.ll
===
--- /dev/null
+++ llvm/test/Transforms/LoopDeletion/mustprogress.ll
@@ -0,0 +1,237 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --function-signature --check-attributes
+; RUN: opt < %s -loop-deletion -S | FileCheck %s
+
+;; Original C Code:
+;;  void unknown_tripcount_mustprogress_attr_mustprogress_loopmd(int a, int b) {
+;;for (; a < b;) ;
+;;for (;;) ;
+;;  }
+
+define void @unknown_tripcount_mustprogress_attr_mustprogress_loopmd(i32 %a, i32 %b) #0 {
+; CHECK: Function Attrs: mustprogress
+; CHECK-LABEL: define {{[^@]+}}@unknown_tripcount_mustprogress_attr_mustprogress_loopmd
+; CHECK-SAME: (i32 [[A:%.*]], i32 [[B:%.*]]) [[ATTR0:#.*]] {
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:br label [[FOR_END:%.*]]
+; CHECK:   for.end:
+; CHECK-NEXT:unreachable
+;
+entry:
+  br label %for.cond
+for.cond:
+  %cmp = icmp slt i32 %a, %b
+  br i1 %cmp, label %for.body, label %for.end
+for.body:
+  br label %for.cond, !llvm.loop !2
+for.end:
+  br label %for.cond1
+for.cond1:
+  br label %for.cond1
+}
+
+;; Original C Code:
+;;  void unknown_tripcount_mustprogress_attr_no_mustprogress_loopmd(int a, int b) {
+;;for (; a < b;) ;
+;;for (;;) ;
+;;  }
+;;  => Removed mustprogress loop attribute
+
+define void @unknown_tripcount_mustprogress_attr_no_mustprogess_loopmd(i32 %a, i32 %b) #0 {
+; CHECK: Function Attrs: mustprogress
+; CHECK-LABEL: define {{[^@]+}}@unknown_tripcount_mustprogress_attr_no_mustprogess_loopmd
+; CHECK-SAME: (i32 [[A:%.*]], i32 [[B:%.*]]) [[ATTR0]] {
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:br label [[FOR_END:%.*]]
+; CHECK:   for.end:
+; CHECK-NEXT:unreachable
+;
+entry:
+  br label %for.cond
+for.cond:
+  %cmp = icmp slt i32 %a, %b
+  br i1 %cmp, label %for.body, label %for.end
+for.body:
+  br label %for.cond
+for.end:
+  br label %for.cond1
+for.cond1:
+  br label %for.cond1
+}
+
+;; Original C Code:
+;;  void known_tripcount_no_mustprogress_attr_no_mustprogress_loopmd() {
+;;for (int i = 0; i < 5; i++) ;
+;;  }
+
+define void @known_tripcount_no_mustprogress_attr_no_mustprogress_loopmd() {
+; CHECK-LABEL: define {{[^@]+}}@known_tripcount_no_mustprogress_attr_no_mustprogress_loopmd() {
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:br label [[FOR_END:%.*]]
+; CHECK:   for.end:
+; CHECK-NEXT:ret void
+;
+entry:
+  br label %for.cond
+for.cond:
+  %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.inc ]
+  %cmp = icmp slt i32 %i.0, 5
+  br i1 %cmp, label %for.body, label %for.end
+for.body:
+  br label %for.inc
+for.inc:
+  %inc = add nsw i32 %i.0, 1
+  br label %for.cond
+for.end:
+  ret void
+}
+
+;; Original C Code:
+;;  void known_tripcount_no_mustprogress_attr_mustprogress_loopmd() {
+;;for (int i = 0; i < 5; i++) ;
+;;  }
+;;  => Added mustprogress loop attribute
+
+define void @known_tripcount_no_mustprogress_attr_mustprogress_loopmd() {
+; CHECK-LABEL: define {{[^@]+}}@known_tripcount_no_mustprogress_attr_mustprogress_loopmd() {
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:br label [[FOR_END:%.*]]
+; CHECK:   for.end:
+; CHECK-NEXT:ret void
+;
+entry:
+  br label %for.cond
+for.cond:
+  %i.0 = phi i32 [ 0, %entry ], [ %inc, %for.inc ]
+  %cmp = icmp slt i32 %i.0, 5
+  br i1 %cmp, label %for.body, label %for.end
+for.body:
+  br label %for.inc
+for.inc:
+  %inc = add nsw i32 %i.0, 1
+  br label %for.cond, !llvm.loop !4

[PATCH] D93758: [format][NFC] Use unsigned char as the base of all enums in FormatStyle

[Nathan James via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc7e825b910a9: [format][NFC] Use unsigned char as the base of 
all enums in FormatStyle (authored by njames93).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93758

Files:
  clang/docs/tools/dump_format_style.py
  clang/include/clang/Format/Format.h

Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -56,7 +56,7 @@
   int AccessModifierOffset;
 
   /// Different styles for aligning after open brackets.
-  enum BracketAlignmentStyle {
+  enum BracketAlignmentStyle : unsigned char {
 /// Align parameters on the open bracket, e.g.:
 /// \code
 ///   someLongFunction(argument1,
@@ -131,7 +131,7 @@
   bool AlignConsecutiveDeclarations;
 
   /// Different styles for aligning escaped newlines.
-  enum EscapedNewlineAlignmentStyle {
+  enum EscapedNewlineAlignmentStyle : unsigned char {
 /// Don't align escaped newlines.
 /// \code
 ///   #define A \
@@ -165,7 +165,7 @@
   EscapedNewlineAlignmentStyle AlignEscapedNewlines;
 
   /// Different styles for aligning operands.
-  enum OperandAlignmentStyle {
+  enum OperandAlignmentStyle : unsigned char {
 /// Do not align operands of binary and ternary expressions.
 /// The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
 /// the start of the line.
@@ -275,7 +275,7 @@
 
   /// Different styles for merging short blocks containing at most one
   /// statement.
-  enum ShortBlockStyle {
+  enum ShortBlockStyle : unsigned char {
 /// Never merge blocks into a single line.
 /// \code
 ///   while (true) {
@@ -320,7 +320,7 @@
 
   /// Different styles for merging short functions containing at most one
   /// statement.
-  enum ShortFunctionStyle {
+  enum ShortFunctionStyle : unsigned char {
 /// Never merge functions into a single line.
 SFS_None,
 /// Only merge functions defined inside a class. Same as "inline",
@@ -371,7 +371,7 @@
   ShortFunctionStyle AllowShortFunctionsOnASingleLine;
 
   /// Different styles for handling short if lines
-  enum ShortIfStyle {
+  enum ShortIfStyle : unsigned char {
 /// Never put short ifs on the same line.
 /// \code
 ///   if (a)
@@ -405,7 +405,7 @@
 
   /// Different styles for merging short lambdas containing at most one
   /// statement.
-  enum ShortLambdaStyle {
+  enum ShortLambdaStyle : unsigned char {
 /// Never merge lambdas into a single line.
 SLS_None,
 /// Only merge empty lambdas.
@@ -442,7 +442,7 @@
 
   /// Different ways to break after the function definition return type.
   /// This option is **deprecated** and is retained for backwards compatibility.
-  enum DefinitionReturnTypeBreakingStyle {
+  enum DefinitionReturnTypeBreakingStyle : unsigned char {
 /// Break after return type automatically.
 /// ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
 DRTBS_None,
@@ -454,7 +454,7 @@
 
   /// Different ways to break after the function definition or
   /// declaration return type.
-  enum ReturnTypeBreakingStyle {
+  enum ReturnTypeBreakingStyle : unsigned char {
 /// Break after return type automatically.
 /// ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
 /// \code
@@ -545,7 +545,7 @@
   bool AlwaysBreakBeforeMultilineStrings;
 
   /// Different ways to break after the template declaration.
-  enum BreakTemplateDeclarationsStyle {
+  enum BreakTemplateDeclarationsStyle : unsigned char {
 /// Do not force break before declaration.
 /// ``PenaltyBreakTemplateDeclaration`` is taken into account.
 /// \code
@@ -620,7 +620,7 @@
   bool BinPackArguments;
 
   /// The style of inserting trailing commas into container literals.
-  enum TrailingCommaStyle {
+  enum TrailingCommaStyle : unsigned char {
 /// Do not insert trailing commas.
 TCS_None,
 /// Insert trailing commas in container literals that were wrapped over
@@ -664,7 +664,7 @@
 
   /// The style of wrapping parameters on the same line (bin-packed) or
   /// on one line each.
-  enum BinPackStyle {
+  enum BinPackStyle : unsigned char {
 /// Automatically determine parameter bin-packing behavior.
 BPS_Auto,
 /// Always bin-pack parameters.
@@ -674,7 +674,7 @@
   };
 
   /// The style of breaking before or after binary operators.
-  enum BinaryOperatorStyle {
+  enum BinaryOperatorStyle : unsigned char {
 /// Break after operators.
 /// \code
 ///LooongType loongVariable =
@@ -717,7 +717,7 @@
   BinaryOperatorStyle BreakBeforeBinaryOperators;
 
   /// Different ways to attach braces to their surrounding context.
-  enum BraceBreakingStyle {
+  enum BraceBreakingStyle : unsigned char {
 /// Always attach braces to surrounding c

[clang] c7e825b - [format][NFC] Use unsigned char as the base of all enums in FormatStyle

[Nathan James via cfe-commits]

Author: Nathan James
Date: 2020-12-23T20:27:44Z
New Revision: c7e825b910a96c42bda1de4e7fb34c369da76625

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

LOG: [format][NFC] Use unsigned char as the base of all enums in FormatStyle

This removes alot of unnecessary padding, trimming the size of the struct from 
728->608 on 64 bit platforms.

Reviewed By: MyDeveloperDay

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

Added: 


Modified: 
clang/docs/tools/dump_format_style.py
clang/include/clang/Format/Format.h

Removed: 




diff  --git a/clang/docs/tools/dump_format_style.py 
b/clang/docs/tools/dump_format_style.py
index 61167979b3e6..d01c823a9a20 100755
--- a/clang/docs/tools/dump_format_style.py
+++ b/clang/docs/tools/dump_format_style.py
@@ -144,7 +144,7 @@ class State(object):
 comment += clean_comment_line(line)
   elif line.startswith('enum'):
 state = State.InEnum
-name = re.sub(r'enum\s+(\w+)\s*\{', '\\1', line)
+name = re.sub(r'enum\s+(\w+)\s*(:((\s*\w+)+)\s*)?\{', '\\1', line)
 enum = Enum(name, comment)
   elif line.startswith('struct'):
 state = State.InNestedStruct

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 208fc105d4b6..9b8309213261 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -56,7 +56,7 @@ struct FormatStyle {
   int AccessModifierOffset;
 
   /// Different styles for aligning after open brackets.
-  enum BracketAlignmentStyle {
+  enum BracketAlignmentStyle : unsigned char {
 /// Align parameters on the open bracket, e.g.:
 /// \code
 ///   someLongFunction(argument1,
@@ -131,7 +131,7 @@ struct FormatStyle {
   bool AlignConsecutiveDeclarations;
 
   /// Different styles for aligning escaped newlines.
-  enum EscapedNewlineAlignmentStyle {
+  enum EscapedNewlineAlignmentStyle : unsigned char {
 /// Don't align escaped newlines.
 /// \code
 ///   #define A \
@@ -165,7 +165,7 @@ struct FormatStyle {
   EscapedNewlineAlignmentStyle AlignEscapedNewlines;
 
   /// Different styles for aligning operands.
-  enum OperandAlignmentStyle {
+  enum OperandAlignmentStyle : unsigned char {
 /// Do not align operands of binary and ternary expressions.
 /// The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
 /// the start of the line.
@@ -275,7 +275,7 @@ struct FormatStyle {
 
   /// Different styles for merging short blocks containing at most one
   /// statement.
-  enum ShortBlockStyle {
+  enum ShortBlockStyle : unsigned char {
 /// Never merge blocks into a single line.
 /// \code
 ///   while (true) {
@@ -320,7 +320,7 @@ struct FormatStyle {
 
   /// Different styles for merging short functions containing at most one
   /// statement.
-  enum ShortFunctionStyle {
+  enum ShortFunctionStyle : unsigned char {
 /// Never merge functions into a single line.
 SFS_None,
 /// Only merge functions defined inside a class. Same as "inline",
@@ -371,7 +371,7 @@ struct FormatStyle {
   ShortFunctionStyle AllowShortFunctionsOnASingleLine;
 
   /// Different styles for handling short if lines
-  enum ShortIfStyle {
+  enum ShortIfStyle : unsigned char {
 /// Never put short ifs on the same line.
 /// \code
 ///   if (a)
@@ -405,7 +405,7 @@ struct FormatStyle {
 
   /// Different styles for merging short lambdas containing at most one
   /// statement.
-  enum ShortLambdaStyle {
+  enum ShortLambdaStyle : unsigned char {
 /// Never merge lambdas into a single line.
 SLS_None,
 /// Only merge empty lambdas.
@@ -442,7 +442,7 @@ struct FormatStyle {
 
   /// Different ways to break after the function definition return type.
   /// This option is **deprecated** and is retained for backwards 
compatibility.
-  enum DefinitionReturnTypeBreakingStyle {
+  enum DefinitionReturnTypeBreakingStyle : unsigned char {
 /// Break after return type automatically.
 /// ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
 DRTBS_None,
@@ -454,7 +454,7 @@ struct FormatStyle {
 
   /// Different ways to break after the function definition or
   /// declaration return type.
-  enum ReturnTypeBreakingStyle {
+  enum ReturnTypeBreakingStyle : unsigned char {
 /// Break after return type automatically.
 /// ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
 /// \code
@@ -545,7 +545,7 @@ struct FormatStyle {
   bool AlwaysBreakBeforeMultilineStrings;
 
   /// Different ways to break after the template declaration.
-  enum BreakTemplateDeclarationsStyle {
+  enum BreakTemplateDeclarationsStyle : unsigned char {
 /// Do not force break before declaration.
 /// ``PenaltyBreakTemplateDeclaration`` is ta

[PATCH] D93772: [Clang][Driver] Fix read-after-free when using /clang:

[Alexandre Ganea via Phabricator via cfe-commits]

aganea created this revision.
aganea added reviewers: thakis, hans, rnk, neerajksingh.
aganea requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

As described in https://bugs.llvm.org/show_bug.cgi?id=42501

Fixes PR42501


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93772

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/cl-options.c


Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -686,6 +686,11 @@
 // CLANG-NOT: "--dependent-lib=libcmt"
 // CLANG-NOT: "-vectorize-slp"
 
+// Cover PR42501: clang-cl /clang: pass-through causes read-after-free with 
aliased options.
+// RUN: %clang_cl /clang:-save-temps /clang:-Wl,test1,test2 -### -- %s 2>&1 | 
FileCheck -check-prefix=SAVETEMPS %s
+// SAVETEMPS: "-save-temps=cwd"
+// SAVETEMPS: "test1" "test2"
+
 // Validate that the default triple is used when run an empty tools dir is 
specified
 // RUN: %clang_cl -vctoolsdir "" -### -- %s 2>&1 | FileCheck %s --check-prefix 
VCTOOLSDIR
 // VCTOOLSDIR: "-triple" "{{[a-zA-Z0-9_-]*}}-pc-windows-msvc19.11.0"
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -1009,13 +1009,15 @@
   // objects than Args. This copies an Arg from one of those other 
InputArgLists
   // to the ownership of Args.
   auto appendOneArg = [&Args](const Arg *Opt, const Arg *BaseArg) {
-  unsigned Index = Args.MakeIndex(Opt->getSpelling());
-  Arg *Copy = new llvm::opt::Arg(Opt->getOption(), Opt->getSpelling(),
- Index, BaseArg);
-  Copy->getValues() = Opt->getValues();
-  if (Opt->isClaimed())
-Copy->claim();
-  Args.append(Copy);
+unsigned Index = Args.MakeIndex(Opt->getSpelling());
+Arg *Copy = new llvm::opt::Arg(Opt->getOption(), Args.getArgString(Index),
+   Index, BaseArg);
+Copy->getValues() = Opt->getValues();
+if (Opt->isClaimed())
+  Copy->claim();
+Copy->setOwnsValues(Opt->getOwnsValues());
+Opt->setOwnsValues(false);
+Args.append(Copy);
   };
 
   if (HasConfigFile)


Index: clang/test/Driver/cl-options.c
===
--- clang/test/Driver/cl-options.c
+++ clang/test/Driver/cl-options.c
@@ -686,6 +686,11 @@
 // CLANG-NOT: "--dependent-lib=libcmt"
 // CLANG-NOT: "-vectorize-slp"
 
+// Cover PR42501: clang-cl /clang: pass-through causes read-after-free with aliased options.
+// RUN: %clang_cl /clang:-save-temps /clang:-Wl,test1,test2 -### -- %s 2>&1 | FileCheck -check-prefix=SAVETEMPS %s
+// SAVETEMPS: "-save-temps=cwd"
+// SAVETEMPS: "test1" "test2"
+
 // Validate that the default triple is used when run an empty tools dir is specified
 // RUN: %clang_cl -vctoolsdir "" -### -- %s 2>&1 | FileCheck %s --check-prefix VCTOOLSDIR
 // VCTOOLSDIR: "-triple" "{{[a-zA-Z0-9_-]*}}-pc-windows-msvc19.11.0"
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -1009,13 +1009,15 @@
   // objects than Args. This copies an Arg from one of those other InputArgLists
   // to the ownership of Args.
   auto appendOneArg = [&Args](const Arg *Opt, const Arg *BaseArg) {
-  unsigned Index = Args.MakeIndex(Opt->getSpelling());
-  Arg *Copy = new llvm::opt::Arg(Opt->getOption(), Opt->getSpelling(),
- Index, BaseArg);
-  Copy->getValues() = Opt->getValues();
-  if (Opt->isClaimed())
-Copy->claim();
-  Args.append(Copy);
+unsigned Index = Args.MakeIndex(Opt->getSpelling());
+Arg *Copy = new llvm::opt::Arg(Opt->getOption(), Args.getArgString(Index),
+   Index, BaseArg);
+Copy->getValues() = Opt->getValues();
+if (Opt->isClaimed())
+  Copy->claim();
+Copy->setOwnsValues(Opt->getOwnsValues());
+Opt->setOwnsValues(false);
+Args.append(Copy);
   };
 
   if (HasConfigFile)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93775: [WebAssembly] Prototype extending pairwise add instructions

[Thomas Lively via Phabricator via cfe-commits]

tlively created this revision.
tlively added a reviewer: aheejin.
Herald added subscribers: wingo, ecnelises, sunfish, hiraditya, 
jgravelle-google, sbc100, dschuff.
tlively requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

As proposed in https://github.com/WebAssembly/simd/pull/380. This commit makes
the new instructions available only via clang builtins and LLVM intrinsics to
make their use opt-in while they are still being evaluated for inclusion in the
SIMD proposal.

Depends on D93771 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93775

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
  llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
  llvm/test/MC/WebAssembly/simd-encodings.s

Index: llvm/test/MC/WebAssembly/simd-encodings.s
===
--- llvm/test/MC/WebAssembly/simd-encodings.s
+++ llvm/test/MC/WebAssembly/simd-encodings.s
@@ -724,4 +724,16 @@
 # CHECK: i64x2.signselect # encoding: [0xfd,0x94,0x01]
 i64x2.signselect
 
+# CHECK: i16x8.extadd_pairwise_i8x16_s # encoding: [0xfd,0xc2,0x01]
+i16x8.extadd_pairwise_i8x16_s
+
+# CHECK: i16x8.extadd_pairwise_i8x16_u # encoding: [0xfd,0xc3,0x01]
+i16x8.extadd_pairwise_i8x16_u
+
+# CHECK: i32x4.extadd_pairwise_i16x8_s # encoding: [0xfd,0xa5,0x01]
+i32x4.extadd_pairwise_i16x8_s
+
+# CHECK: i32x4.extadd_pairwise_i16x8_u # encoding: [0xfd,0xa6,0x01]
+i32x4.extadd_pairwise_i16x8_u
+
 end_function
Index: llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
===
--- llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
+++ llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
@@ -309,6 +309,26 @@
   ret <8 x i16> %a
 }
 
+; CHECK-LABEL: extadd_pairwise_s_v8i16:
+; SIMD128-NEXT: .functype extadd_pairwise_s_v8i16 (v128) -> (v128){{$}}
+; SIMD128-NEXT: i16x8.extadd_pairwise_i8x16_s $push[[R:[0-9]+]]=, $0{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare <8 x i16> @llvm.wasm.extadd.pairwise.signed.v8i16(<16 x i8>)
+define <8 x i16> @extadd_pairwise_s_v8i16(<16 x i8> %x) {
+  %a = call <8 x i16> @llvm.wasm.extadd.pairwise.signed.v8i16(<16 x i8> %x)
+  ret <8 x i16> %a
+}
+
+; CHECK-LABEL: extadd_pairwise_u_v8i16:
+; SIMD128-NEXT: .functype extadd_pairwise_u_v8i16 (v128) -> (v128){{$}}
+; SIMD128-NEXT: i16x8.extadd_pairwise_i8x16_u $push[[R:[0-9]+]]=, $0{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare <8 x i16> @llvm.wasm.extadd.pairwise.unsigned.v8i16(<16 x i8>)
+define <8 x i16> @extadd_pairwise_u_v8i16(<16 x i8> %x) {
+  %a = call <8 x i16> @llvm.wasm.extadd.pairwise.unsigned.v8i16(<16 x i8> %x)
+  ret <8 x i16> %a
+}
+
 ; CHECK-LABEL: any_v8i16:
 ; SIMD128-NEXT: .functype any_v8i16 (v128) -> (i32){{$}}
 ; SIMD128-NEXT: i16x8.any_true $push[[R:[0-9]+]]=, $0{{$}}
@@ -449,6 +469,27 @@
   ret <4 x i32> %a
 }
 
+; CHECK-LABEL: extadd_pairwise_s_v4i32:
+; SIMD128-NEXT: .functype extadd_pairwise_s_v4i32 (v128) -> (v128){{$}}
+; SIMD128-NEXT: i32x4.extadd_pairwise_i16x8_s $push[[R:[0-9]+]]=, $0{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare <4 x i32> @llvm.wasm.extadd.pairwise.signed.v4i32(<8 x i16>)
+define <4 x i32> @extadd_pairwise_s_v4i32(<8 x i16> %x) {
+  %a = call <4 x i32> @llvm.wasm.extadd.pairwise.signed.v4i32(<8 x i16> %x)
+  ret <4 x i32> %a
+}
+
+; CHECK-LABEL: extadd_pairwise_u_v4i32:
+; SIMD128-NEXT: .functype extadd_pairwise_u_v4i32 (v128) -> (v128){{$}}
+; SIMD128-NEXT: i32x4.extadd_pairwise_i16x8_u $push[[R:[0-9]+]]=, $0{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare <4 x i32> @llvm.wasm.extadd.pairwise.unsigned.v4i32(<8 x i16>)
+define <4 x i32> @extadd_pairwise_u_v4i32(<8 x i16> %x) {
+  %a = call <4 x i32> @llvm.wasm.extadd.pairwise.unsigned.v4i32(<8 x i16> %x)
+  ret <4 x i32> %a
+}
+
+
 ; CHECK-LABEL: any_v4i32:
 ; SIMD128-NEXT: .functype any_v4i32 (v128) -> (i32){{$}}
 ; SIMD128-NEXT: i32x4.any_true $push[[R:[0-9]+]]=, $0{{$}}
Index: llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
===
--- llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
+++ llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
@@ -1245,6 +1245,17 @@
 ) in
 def : Pat<(t1 (bitconvert (t2 V128:$v))), (t1 V128:$v)>;
 
+// Extended pairwise addition
+defm "" : SIMDConvert;
+defm "" : SIMDConvert;
+defm "" : SIMDConvert;
+defm "" : SIMDConvert;
+
+
 //===--===//
 // Quasi-Fused Multiply- Add and Subtract (QFMA/QFMS)
 //===--===//
Index: llvm/include/llvm/IR/IntrinsicsWebAssembly.td
===

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names.cpp:48-49
 
+// LPIPELINE: Unique Internal Linkage Names
+// NPIPELINE: Running pass: UniqueInternalLinkageNamesPass
 // PLAIN: @_ZL4glob = internal global

hoy wrote:
> dblaikie wrote:
> > Does this test validate the new behavior? (ie: does this test fail without 
> > the LLVM changes and pass with it) Not that it necessarily has to - since 
> > Clang isn't here to test the LLVM behavior - perhaps this test is 
> > sufficient in Clang to test that the code in BackendUtil works to enable 
> > this pass.
> > 
> > This could possibly be staged as independent commits - adding the LLVM 
> > functionality in one commit, which would be a no-op for Clang because it 
> > wouldn't be setting PTO.UniqueLinkageNames - then committing the Clang 
> > change that would remove the custom pass addition and set 
> > PTO.UniqueLinkageNames - and then it'd probably be reasonable to have this 
> > test be made a bit more explicit (testing the pass manager structure/order) 
> > to show that that Clang change had an effect: Moving the pass to the 
> > desired location in the pass pipeline.
> This is a good question. No, this test does not validate the pipeline change 
> on the LLVM side, since Clang shouldn't have knowledge about how the 
> pipelines are arranged in LLVM. As you pointed out, the test here is to test 
> if the specific pass is run and gives expected results.
> 
> Thanks for the suggestion to break the Clang changes and LLVM changes apart 
> which would make the testing more specific. The pipeline ordering could be 
> tested with a LLVM test but that would require a LLVM switch setup for 
> UniqueLinkageNames and I'm not sure there's a need for that switch except for 
> testing.
> No, this test does not validate the pipeline change on the LLVM side, since 
> Clang shouldn't have knowledge about how the pipelines are arranged in LLVM. 

"ish" - but Clang should have tests for changes to Clang, ideally. Usually they 
can simply be testing LLVM's IR output before it goes to LLVM for 
optimization/codegen - but for features that don't have this serialization 
boundary that makes testing and isolation clear/simple, it becomes a bit 
fuzzier.

In this case, there is a clang change - from adding the pass explicitly in 
Clang, to setting a parameter about how LLVM will add the pass, and it has an 
observable effect. One way to test this change while isolating the Clang test 
from further changes to the pipeline in LLVM, would be to test that the pass 
ends up somewhere in the LLVM-created part of the pass pipeline - the parts 
that you can't get to from the way the original pass addition was written in 
Clang. At least I assume that's the case/what motivated the change from adding 
it in Clang to adding it in LLVM?

eg: if LLVM always forms passes {x, y, z} and Clang is able to add passes 
before/after, say it always adds 'a' before and 'b' after, to make {a, x, y, z, 
b} - and this new pass u was previously added at the start to make {u, a, x, y, 
z, b} but now needs to go in {a, x, y, u, z, b} you could test that 'u' is 
after 'a' and before 'b', or between 'x' and 'z', etc. If there's some other 
more clear/simple/reliable marker of where the LLVM-created passes start/end in 
the structured dump, that'd be good to use as a landmark to make such a test 
more robust. If there's some meaningful pass that this pass always needs to go 
after - testing that might be OK, even if it's somewhat an implementation 
detail of LLVM - whatever's likely to make the test more legible and more 
reliable/resilient to unrelated changes would be good.

> As you pointed out, the test here is to test if the specific pass is run and 
> gives expected results.

If that's the case, this test could be committed standalone, before any of 
these other changes?

> The pipeline ordering could be tested with a LLVM test but that would require 
> a LLVM switch setup for UniqueLinkageNames and I'm not sure there's a need 
> for that switch except for testing.

That's OK, the entire 'opt' tool and all its switches only exist for testing. 
eg: 
https://github.com/llvm/llvm-project/blob/master/llvm/tools/opt/NewPMDriver.cpp#L284


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93656

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

[PATCH] D87188: [InstCombine] Canonicalize SPF to abs intrinc

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D87188#2467915 , @nlopes wrote:

> This patch regressed the following test of Transforms/InstCombine/abs-1.ll:
> (need to drop NSW in this case).
>
>   define i8 @nabs_canonical_3(i8 %x) {
>   %0:
> %cmp = icmp slt i8 %x, 0
> %neg = sub nsw i8 0, %x
> %abs = select i1 %cmp, i8 %x, i8 %neg
> ret i8 %abs
>   }
>   =>
>   define i8 @nabs_canonical_3(i8 %x) {
>   %0:
> %1 = abs i8 %x, 1
> %abs = sub nsw i8 0, %1
> ret i8 %abs
>   }
>   Transformation doesn't verify!
>   ERROR: Target is more poisonous than source
>   
>   Example:
>   i8 %x = #x80 (128, -128)
>   
>   Source:
>   i1 %cmp = #x1 (1)
>   i8 %neg = poison
>   i8 %abs = #x80 (128, -128)
>   
>   Target:
>   i8 %1 = poison
>   i8 %abs = poison
>   Source value: #x80 (128, -128)
>   Target value: poison
>
> (same bug occurs with @nabs_nabs_x01 in Transforms/InstCombine/abs_abs.ll)

Thanks, fixed in rGf8079355c604fead0f8538548bd7eb51fcc81e31 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87188

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

[clang] 374f1d8 - [clang-format] Fix handling of TextProto comments

[Björn Schäpers via cfe-commits]

Author: Björn Schäpers
Date: 2020-12-23T22:07:13+01:00
New Revision: 374f1d81febf8143e8e633296a42c2311699c5b3

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

LOG: [clang-format] Fix handling of TextProto comments

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

Added: 


Modified: 
clang/lib/Format/BreakableToken.cpp
clang/unittests/Format/FormatTestTextProto.cpp

Removed: 




diff  --git a/clang/lib/Format/BreakableToken.cpp 
b/clang/lib/Format/BreakableToken.cpp
index 6a240fdec8b9..c5edc670393c 100644
--- a/clang/lib/Format/BreakableToken.cpp
+++ b/clang/lib/Format/BreakableToken.cpp
@@ -789,9 +789,14 @@ BreakableLineCommentSection::BreakableLineCommentSection(
   Prefix[i] = "///< ";
 else if (Prefix[i] == "//!<")
   Prefix[i] = "//!< ";
-else if (Prefix[i] == "#" &&
- Style.Language == FormatStyle::LK_TextProto)
+else if (Prefix[i] == "#")
   Prefix[i] = "# ";
+else if (Prefix[i] == "##")
+  Prefix[i] = "## ";
+else if (Prefix[i] == "###")
+  Prefix[i] = "### ";
+else if (Prefix[i] == "")
+  Prefix[i] = " ";
   }
 
   Tokens[i] = LineTok;

diff  --git a/clang/unittests/Format/FormatTestTextProto.cpp 
b/clang/unittests/Format/FormatTestTextProto.cpp
index 3ae13d172865..1e2594893841 100644
--- a/clang/unittests/Format/FormatTestTextProto.cpp
+++ b/clang/unittests/Format/FormatTestTextProto.cpp
@@ -380,25 +380,29 @@ TEST_F(FormatTestTextProto, KeepsCommentsIndentedInList) {
": 3849");
 }
 
-TEST_F(FormatTestTextProto, UnderstandsHashHashComments) {
+TEST_F(FormatTestTextProto, UnderstandsHashComments) {
   FormatStyle Style = getGoogleStyle(FormatStyle::LK_TextProto);
   Style.ColumnLimit = 60; // To make writing tests easier.
   EXPECT_EQ("aaa: 100\n"
-"##this is a double-hash comment.\n"
+"## this is a double-hash comment.\n"
 "bb: 100\n"
 "## another double-hash comment.\n"
 "### a triple-hash comment\n"
 "cc: 200\n"
+"### another triple-hash comment\n"
 " a quadriple-hash comment\n"
-"dd: 100\n",
+"dd: 100\n"
+" another quadriple-hash comment\n",
 format("aaa: 100\n"
"##this is a double-hash comment.\n"
"bb: 100\n"
"## another double-hash comment.\n"
-   "### a triple-hash comment\n"
+   "###a triple-hash comment\n"
"cc: 200\n"
-   " a quadriple-hash comment\n"
-   "dd: 100\n",
+   "### another triple-hash comment\n"
+   "a quadriple-hash comment\n"
+   "dd: 100\n"
+   " another quadriple-hash comment\n",
Style));
 }
 



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

[PATCH] D93163: [clang-format] Fix handling of ## comments in TextProto

[Björn Schäpers via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG374f1d81febf: [clang-format] Fix handling of TextProto 
comments (authored by HazardyKnusperkeks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93163

Files:
  clang/lib/Format/BreakableToken.cpp
  clang/unittests/Format/FormatTestTextProto.cpp


Index: clang/unittests/Format/FormatTestTextProto.cpp
===
--- clang/unittests/Format/FormatTestTextProto.cpp
+++ clang/unittests/Format/FormatTestTextProto.cpp
@@ -380,25 +380,29 @@
": 3849");
 }
 
-TEST_F(FormatTestTextProto, UnderstandsHashHashComments) {
+TEST_F(FormatTestTextProto, UnderstandsHashComments) {
   FormatStyle Style = getGoogleStyle(FormatStyle::LK_TextProto);
   Style.ColumnLimit = 60; // To make writing tests easier.
   EXPECT_EQ("aaa: 100\n"
-"##this is a double-hash comment.\n"
+"## this is a double-hash comment.\n"
 "bb: 100\n"
 "## another double-hash comment.\n"
 "### a triple-hash comment\n"
 "cc: 200\n"
+"### another triple-hash comment\n"
 " a quadriple-hash comment\n"
-"dd: 100\n",
+"dd: 100\n"
+" another quadriple-hash comment\n",
 format("aaa: 100\n"
"##this is a double-hash comment.\n"
"bb: 100\n"
"## another double-hash comment.\n"
-   "### a triple-hash comment\n"
+   "###a triple-hash comment\n"
"cc: 200\n"
-   " a quadriple-hash comment\n"
-   "dd: 100\n",
+   "### another triple-hash comment\n"
+   "a quadriple-hash comment\n"
+   "dd: 100\n"
+   " another quadriple-hash comment\n",
Style));
 }
 
Index: clang/lib/Format/BreakableToken.cpp
===
--- clang/lib/Format/BreakableToken.cpp
+++ clang/lib/Format/BreakableToken.cpp
@@ -789,9 +789,14 @@
   Prefix[i] = "///< ";
 else if (Prefix[i] == "//!<")
   Prefix[i] = "//!< ";
-else if (Prefix[i] == "#" &&
- Style.Language == FormatStyle::LK_TextProto)
+else if (Prefix[i] == "#")
   Prefix[i] = "# ";
+else if (Prefix[i] == "##")
+  Prefix[i] = "## ";
+else if (Prefix[i] == "###")
+  Prefix[i] = "### ";
+else if (Prefix[i] == "")
+  Prefix[i] = " ";
   }
 
   Tokens[i] = LineTok;


Index: clang/unittests/Format/FormatTestTextProto.cpp
===
--- clang/unittests/Format/FormatTestTextProto.cpp
+++ clang/unittests/Format/FormatTestTextProto.cpp
@@ -380,25 +380,29 @@
": 3849");
 }
 
-TEST_F(FormatTestTextProto, UnderstandsHashHashComments) {
+TEST_F(FormatTestTextProto, UnderstandsHashComments) {
   FormatStyle Style = getGoogleStyle(FormatStyle::LK_TextProto);
   Style.ColumnLimit = 60; // To make writing tests easier.
   EXPECT_EQ("aaa: 100\n"
-"##this is a double-hash comment.\n"
+"## this is a double-hash comment.\n"
 "bb: 100\n"
 "## another double-hash comment.\n"
 "### a triple-hash comment\n"
 "cc: 200\n"
+"### another triple-hash comment\n"
 " a quadriple-hash comment\n"
-"dd: 100\n",
+"dd: 100\n"
+" another quadriple-hash comment\n",
 format("aaa: 100\n"
"##this is a double-hash comment.\n"
"bb: 100\n"
"## another double-hash comment.\n"
-   "### a triple-hash comment\n"
+   "###a triple-hash comment\n"
"cc: 200\n"
-   " a quadriple-hash comment\n"
-   "dd: 100\n",
+   "### another triple-hash comment\n"
+   "a quadriple-hash comment\n"
+   "dd: 100\n"
+   " another quadriple-hash comment\n",
Style));
 }
 
Index: clang/lib/Format/BreakableToken.cpp
===
--- clang/lib/Format/BreakableToken.cpp
+++ clang/lib/Format/BreakableToken.cpp
@@ -789,9 +789,14 @@
   Prefix[i] = "///< ";
 else if (Prefix[i] == "//!<")
   Prefix[i] = "//!< ";
-else if (Prefix[i] == "#" &&
- Style.Language == FormatStyle::LK_TextProto)
+else if (Prefix[i] == "#")
   Prefix[i] = "# ";
+else 

[clang] 47877c9 - [clang-format] Add SpaceBeforeCaseColon option

[Björn Schäpers via cfe-commits]

Author: Björn Schäpers
Date: 2020-12-23T22:07:14+01:00
New Revision: 47877c9079c27f19a954b660201ea47717c82fec

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

LOG: [clang-format] Add SpaceBeforeCaseColon option

With which you can add a space before the colon of a case or default
statement.

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

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/docs/ReleaseNotes.rst
clang/include/clang/Format/Format.h
clang/lib/Format/Format.cpp
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index 32942648378b..c58bb1af7ae6 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -2839,6 +2839,16 @@ the configuration (without a prefix: ``Auto``).
  int a = 5; vs. int a= 5;
  a += 42;   a+= 42;
 
+**SpaceBeforeCaseColon** (``bool``)
+  If ``false``, spaces will be removed before case colon.
+
+  .. code-block:: c++
+
+true:   false
+switch (x) {vs. switch (x) {
+  case 1 : break; case 1: break;
+}   }
+
 **SpaceBeforeCpp11BracedList** (``bool``)
   If ``true``, a space will be inserted before a C++11 braced list
   used to initialize an object (after the preceding identifier or type).

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index dd4de2d2015f..76d4b6bb5acd 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -293,6 +293,9 @@ clang-format
 
 - Option ``IndentPragmas`` has been added to allow #pragma to indented with 
the current scope level. This is especially useful when using #pragma to mark 
OpenMP sections of code.
 
+- Option ``SpaceBeforeCaseColon`` has been added to add a space before the
+  colon in a case or default statement.
+
 
 libclang
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 9b8309213261..c6a9818a8940 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -2438,6 +2438,15 @@ struct FormatStyle {
   /// \endcode
   bool SpaceBeforeAssignmentOperators;
 
+  /// If ``false``, spaces will be removed before case colon.
+  /// \code
+  ///   true:   false
+  ///   switch (x) {vs. switch (x) {
+  /// case 1 : break; case 1: break;
+  ///   }   }
+  /// \endcode
+  bool SpaceBeforeCaseColon;
+
   /// If ``true``, a space will be inserted before a C++11 braced list
   /// used to initialize an object (after the preceding identifier or type).
   /// \code
@@ -2820,6 +2829,7 @@ struct FormatStyle {
SpaceAfterLogicalNot == R.SpaceAfterLogicalNot &&
SpaceAfterTemplateKeyword == R.SpaceAfterTemplateKeyword &&
SpaceBeforeAssignmentOperators == R.SpaceBeforeAssignmentOperators 
&&
+   SpaceBeforeCaseColon == R.SpaceBeforeCaseColon &&
SpaceBeforeCpp11BracedList == R.SpaceBeforeCpp11BracedList &&
SpaceBeforeCtorInitializerColon ==
R.SpaceBeforeCtorInitializerColon &&

diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 55abc12c61c4..54424ae190e2 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -608,6 +608,7 @@ template <> struct MappingTraits {
Style.SpaceAfterTemplateKeyword);
 IO.mapOptional("SpaceBeforeAssignmentOperators",
Style.SpaceBeforeAssignmentOperators);
+IO.mapOptional("SpaceBeforeCaseColon", Style.SpaceBeforeCaseColon);
 IO.mapOptional("SpaceBeforeCpp11BracedList",
Style.SpaceBeforeCpp11BracedList);
 IO.mapOptional("SpaceBeforeCtorInitializerColon",
@@ -958,6 +959,7 @@ FormatStyle getLLVMStyle(FormatStyle::LanguageKind 
Language) {
   LLVMStyle.SpaceAfterLogicalNot = false;
   LLVMStyle.SpaceAfterTemplateKeyword = true;
   LLVMStyle.SpaceAroundPointerQualifiers = FormatStyle::SAPQ_Default;
+  LLVMStyle.SpaceBeforeCaseColon = false;
   LLVMStyle.SpaceBeforeCtorInitializerColon = true;
   LLVMStyle.SpaceBeforeInheritanceColon = true;
   LLVMStyle.SpaceBeforeParens = FormatStyle::SBPO_ControlStatements;

diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index a0cb86cfcebf..1588f7d08184 100755
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -896,7 +896,8 @@ class AnnotatingP

[PATCH] D93240: [clang-format] Add SpaceBeforeCaseColon option

[Björn Schäpers via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG47877c9079c2: [clang-format] Add SpaceBeforeCaseColon option 
(authored by HazardyKnusperkeks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93240

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -12091,6 +12091,17 @@
"case 1:\n"
"default:\n"
"}");
+  verifyFormat("switch (allBraces) {\n"
+   "case 1: {\n"
+   "  break;\n"
+   "}\n"
+   "case 2: {\n"
+   "  [[fallthrough]];\n"
+   "}\n"
+   "default: {\n"
+   "  break;\n"
+   "}\n"
+   "}");
 
   FormatStyle CtorInitializerStyle = getLLVMStyleWithColumns(30);
   CtorInitializerStyle.SpaceBeforeCtorInitializerColon = false;
@@ -12108,6 +12119,18 @@
"default:\n"
"}",
CtorInitializerStyle);
+  verifyFormat("switch (allBraces) {\n"
+   "case 1: {\n"
+   "  break;\n"
+   "}\n"
+   "case 2: {\n"
+   "  [[fallthrough]];\n"
+   "}\n"
+   "default: {\n"
+   "  break;\n"
+   "}\n"
+   "}",
+   CtorInitializerStyle);
   CtorInitializerStyle.BreakConstructorInitializers =
   FormatStyle::BCIS_AfterColon;
   verifyFormat("Fooo::Fooo():\n"
@@ -12148,6 +12171,18 @@
"default:\n"
"}",
InheritanceStyle);
+  verifyFormat("switch (allBraces) {\n"
+   "case 1: {\n"
+   "  break;\n"
+   "}\n"
+   "case 2: {\n"
+   "  [[fallthrough]];\n"
+   "}\n"
+   "default: {\n"
+   "  break;\n"
+   "}\n"
+   "}",
+   InheritanceStyle);
   InheritanceStyle.BreakInheritanceList = FormatStyle::BILS_AfterColon;
   verifyFormat("class Foo:\n"
"public aa,\n"
@@ -12188,8 +12223,45 @@
"default:\n"
"}",
ForLoopStyle);
+  verifyFormat("switch (allBraces) {\n"
+   "case 1: {\n"
+   "  break;\n"
+   "}\n"
+   "case 2: {\n"
+   "  [[fallthrough]];\n"
+   "}\n"
+   "default: {\n"
+   "  break;\n"
+   "}\n"
+   "}",
+   ForLoopStyle);
+
+  FormatStyle CaseStyle = getLLVMStyle();
+  CaseStyle.SpaceBeforeCaseColon = true;
+  verifyFormat("class Foo : public Bar {};", CaseStyle);
+  verifyFormat("Foo::Foo() : foo(1) {}", CaseStyle);
+  verifyFormat("for (auto a : b) {\n}", CaseStyle);
+  verifyFormat("int x = a ? b : c;", CaseStyle);
+  verifyFormat("switch (x) {\n"
+   "case 1 :\n"
+   "default :\n"
+   "}",
+   CaseStyle);
+  verifyFormat("switch (allBraces) {\n"
+   "case 1 : {\n"
+   "  break;\n"
+   "}\n"
+   "case 2 : {\n"
+   "  [[fallthrough]];\n"
+   "}\n"
+   "default : {\n"
+   "  break;\n"
+   "}\n"
+   "}",
+   CaseStyle);
 
   FormatStyle NoSpaceStyle = getLLVMStyle();
+  EXPECT_EQ(NoSpaceStyle.SpaceBeforeCaseColon, false);
   NoSpaceStyle.SpaceBeforeCtorInitializerColon = false;
   NoSpaceStyle.SpaceBeforeInheritanceColon = false;
   NoSpaceStyle.SpaceBeforeRangeBasedForLoopColon = false;
@@ -12207,6 +12279,54 @@
"default:\n"
"}",
NoSpaceStyle);
+  verifyFormat("switch (allBraces) {\n"
+   "case 1: {\n"
+   "  break;\n"
+   "}\n"
+   "case 2: {\n"
+   "  [[fallthrough]];\n"
+   "}\n"
+   "default: {\n"
+   "  break;\n"
+   "}\n"
+   "}",
+   NoSpaceStyle);
+
+  FormatStyle InvertedSpaceStyle = getLLVMStyle();
+  InvertedSpaceStyle.SpaceBeforeCaseColon = true;
+  InvertedSpaceStyle.SpaceBeforeCtorInitializerColon = false;
+  InvertedSpaceStyle.SpaceBeforeInheritanceColon = false;
+  InvertedSpaceStyle.SpaceBeforeRangeBasedForLoopColon = false;
+  verifyFormat("class Foo: public Bar {};", InvertedSpaceStyle);
+  verifyFormat("Foo::Foo(): foo(1) {}", InvertedSpaceStyle);
+  verifyFormat("for (auto a: b) {\n}", InvertedSpaceStyle

[PATCH] D93776: [clang-format] Add StatementAttributeLikeMacros option

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks created this revision.
HazardyKnusperkeks added reviewers: MyDeveloperDay, curdeius, JVApen.
HazardyKnusperkeks added a project: clang-format.
HazardyKnusperkeks requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This allows to ignore for example Qts emit when
AlignConsecutiveDeclarations is set, otherwise it is parsed as a type
and it results in some misformating:

  unsigned char MyChar = 'x';
  emit  signal(MyChar);

For those who don't know what emit (or Q_EMIT) is in Qt: A macro which is 
defined as nothing. But it is often used to display that a function call is a 
signal which is then "emitted". Technically emit could stand anywhere in the 
code, but if used right it is only before a signal emission.

I added `Q_EMIT` unconditionally because this is also done with `Q_UNUSED` and 
`QT_REQUIRE_VERSION`. I did not add `emit` because it's all lower case and 
could be used as actual identifier in non Qt code, or even in Qt code when the 
Qt keywords are deactivated.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93776

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/WhitespaceManager.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -14667,6 +14667,11 @@
   CHECK_PARSE("AttributeMacros: [attr1, attr2]", AttributeMacros,
   std::vector({"attr1", "attr2"}));
 
+  Style.StatementAttributeLikeMacros.clear();
+  CHECK_PARSE("StatementAttributeLikeMacros: [emit,Q_EMIT]",
+  StatementAttributeLikeMacros,
+  std::vector({"emit", "Q_EMIT"}));
+
   Style.StatementMacros.clear();
   CHECK_PARSE("StatementMacros: [QUNUSED]", StatementMacros,
   std::vector{"QUNUSED"});
@@ -17862,6 +17867,35 @@
Style));
 }
 
+TEST_F(FormatTest, StatementAttributeLikeMacros) {
+  FormatStyle Style = getLLVMStyle();
+  StringRef Source = "void Foo::slot() {\n"
+ "  unsigned char MyChar = 'x';\n"
+ "  emit signal(MyChar);\n"
+ "  Q_EMIT signal(MyChar);\n"
+ "}";
+
+  EXPECT_EQ(Source, format(Source, Style));
+
+  Style.AlignConsecutiveDeclarations = true;
+  EXPECT_EQ("void Foo::slot() {\n"
+"  unsigned char MyChar = 'x';\n"
+"  emit  signal(MyChar);\n"
+"  Q_EMIT signal(MyChar);\n"
+"}",
+format(Source, Style));
+
+  Style.StatementAttributeLikeMacros.push_back("emit");
+  EXPECT_EQ(Source, format(Source, Style));
+
+  Style.StatementAttributeLikeMacros = {};
+  EXPECT_EQ("void Foo::slot() {\n"
+"  unsigned char MyChar = 'x';\n"
+"  emit  signal(MyChar);\n"
+"  Q_EMITsignal(MyChar);\n"
+"}",
+format(Source, Style));
+}
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/lib/Format/WhitespaceManager.cpp
===
--- clang/lib/Format/WhitespaceManager.cpp
+++ clang/lib/Format/WhitespaceManager.cpp
@@ -655,6 +655,9 @@
   return true;
 if (C.Tok->isNot(TT_StartOfName))
   return false;
+if (C.Tok->Previous &&
+C.Tok->Previous->is(TT_StatementAttributeLikeMacro))
+  return false;
 // Check if there is a subsequent name that starts the same declaration.
 for (FormatToken *Next = C.Tok->Next; Next; Next = Next->Next) {
   if (Next->is(tok::comment))
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1368,7 +1368,8 @@
 TT_ImplicitStringLiteral, TT_InlineASMBrace, TT_JsFatArrow,
 TT_LambdaArrow, TT_NamespaceMacro, TT_OverloadedOperator,
 TT_RegexLiteral, TT_TemplateString, TT_ObjCStringLiteral,
-TT_UntouchableMacroFunc, TT_ConstraintJunctions))
+TT_UntouchableMacroFunc, TT_ConstraintJunctions,
+TT_StatementAttributeLikeMacro))
   CurrentToken->setType(TT_Unknown);
 CurrentToken->Role.reset();
 CurrentToken->MatchingParen = nullptr;
Index: clang/lib/Format/FormatTokenLexer.cpp
===
--- clang/lib/Format/FormatTokenLexer.cpp
+++ clang/lib/Format/FormatTokenLexer.cpp
@@ -52,6 +52,10 @@
 Macros.insert(
 {&IdentTable.get(WhitespaceSensitiveMacro), TT_UntouchableMacroFunc});
   }
+  for (const std:

[PATCH] D93776: [clang-format] Add StatementAttributeLikeMacros option

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added inline comments.



Comment at: clang/lib/Format/FormatToken.h:54
   TYPE(FunctionTypeLParen) 
\
+  TYPE(StatementAttributeLikeMacro)
\
   TYPE(ImplicitStringLiteral)  
\

This one I will move down, it was named differently before and I forgot to 
resort it after renaming.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93776

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

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

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.

In D93747#2470387 , @dblaikie wrote:

> Please remove the clang test change - if this is an LLVM change with LLVM 
> test coverage, that's enough. (we don't generally test every LLVM change from 
> both LLVM and Clang)

Sounds good.

> I'd still be curious if you could look around to see whether there are other 
> cases of function splitting/cloning/etc to see how they deal with updating 
> the DISubprograms, to see if there's some prior art that should be used here.

To the best of my knowledge, existing code does not change the linkage name 
field of a DISubprogram once created. You can create a new DISubprogram record 
with any linkage name you want but bear in mind how the debugger will consume 
the record. Looks like we are the first one to change existing record which 
will confuse the debugger.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

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

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

[Hongtao Yu via Phabricator via cfe-commits]

hoy updated this revision to Diff 313607.
hoy added a comment.

Undoing changes to the clang test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93747

Files:
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
  llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll


Index: llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
===
--- llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
+++ llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
@@ -32,5 +32,6 @@
 !17 = !{!13}
 !18 = !DILocation(line: 6, column: 3, scope: !15)
 
-; CHECK: define internal i32 @foo.__uniq.{{[0-9a-f]+}}()
+; CHECK: define internal i32 @foo.__uniq.{{[0-9a-f]+}}() !dbg ![[#DBG:]]
 ; CHECK: ret {{.*}} @foo.__uniq.{{[0-9a-f]+}} {{.*}}
+; CHECK: ![[#DBG]] = distinct !DISubprogram(name: "foo", linkageName: 
"foo.__uniq.{{[0-9a-f]+}}"
Index: llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
===
--- llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
+++ llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
@@ -13,6 +13,8 @@
 
 #include "llvm/Transforms/Utils/UniqueInternalLinkageNames.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/IR/DebugInfoMetadata.h"
+#include "llvm/IR/MDBuilder.h"
 #include "llvm/IR/Module.h"
 #include "llvm/InitializePasses.h"
 #include "llvm/Support/MD5.h"
@@ -31,11 +33,16 @@
   // this symbol is of internal linkage type.
   std::string ModuleNameHash = (Twine(".__uniq.") + Twine(Str)).str();
   bool Changed = false;
+  MDBuilder MDB(M.getContext());
 
   // Append the module hash to all internal linkage functions.
   for (auto &F : M) {
 if (F.hasInternalLinkage()) {
   F.setName(F.getName() + ModuleNameHash);
+  if (DISubprogram *SP = F.getSubprogram()) {
+auto *Name = MDB.createString(F.getName());
+SP->replaceRawLinkageName(Name);
+  }
   Changed = true;
 }
   }
Index: llvm/include/llvm/IR/DebugInfoMetadata.h
===
--- llvm/include/llvm/IR/DebugInfoMetadata.h
+++ llvm/include/llvm/IR/DebugInfoMetadata.h
@@ -2053,6 +2053,10 @@
 return getNumOperands() > 10 ? getOperandAs(10) : nullptr;
   }
 
+  void replaceRawLinkageName(MDString *LinkageName) {
+replaceOperandWith(3, LinkageName);
+  }
+
   /// Check if this subprogram describes the given function.
   ///
   /// FIXME: Should this be looking through bitcasts?


Index: llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
===
--- llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
+++ llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
@@ -32,5 +32,6 @@
 !17 = !{!13}
 !18 = !DILocation(line: 6, column: 3, scope: !15)
 
-; CHECK: define internal i32 @foo.__uniq.{{[0-9a-f]+}}()
+; CHECK: define internal i32 @foo.__uniq.{{[0-9a-f]+}}() !dbg ![[#DBG:]]
 ; CHECK: ret {{.*}} @foo.__uniq.{{[0-9a-f]+}} {{.*}}
+; CHECK: ![[#DBG]] = distinct !DISubprogram(name: "foo", linkageName: "foo.__uniq.{{[0-9a-f]+}}"
Index: llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
===
--- llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
+++ llvm/lib/Transforms/Utils/UniqueInternalLinkageNames.cpp
@@ -13,6 +13,8 @@
 
 #include "llvm/Transforms/Utils/UniqueInternalLinkageNames.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/IR/DebugInfoMetadata.h"
+#include "llvm/IR/MDBuilder.h"
 #include "llvm/IR/Module.h"
 #include "llvm/InitializePasses.h"
 #include "llvm/Support/MD5.h"
@@ -31,11 +33,16 @@
   // this symbol is of internal linkage type.
   std::string ModuleNameHash = (Twine(".__uniq.") + Twine(Str)).str();
   bool Changed = false;
+  MDBuilder MDB(M.getContext());
 
   // Append the module hash to all internal linkage functions.
   for (auto &F : M) {
 if (F.hasInternalLinkage()) {
   F.setName(F.getName() + ModuleNameHash);
+  if (DISubprogram *SP = F.getSubprogram()) {
+auto *Name = MDB.createString(F.getName());
+SP->replaceRawLinkageName(Name);
+  }
   Changed = true;
 }
   }
Index: llvm/include/llvm/IR/DebugInfoMetadata.h
===
--- llvm/include/llvm/IR/DebugInfoMetadata.h
+++ llvm/include/llvm/IR/DebugInfoMetadata.h
@@ -2053,6 +2053,10 @@
 return getNumOperands() > 10 ? getOperandAs(10) : nullptr;
   }
 
+  void replaceRawLinkageName(MDString *LinkageName) {
+replaceOperandWith(3, LinkageName);
+  }
+
   /// Check if this subprogram describes the given function.
   ///
   /// FIXME: Should this be l

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names.cpp:48-49
 
+// LPIPELINE: Unique Internal Linkage Names
+// NPIPELINE: Running pass: UniqueInternalLinkageNamesPass
 // PLAIN: @_ZL4glob = internal global

dblaikie wrote:
> hoy wrote:
> > dblaikie wrote:
> > > Does this test validate the new behavior? (ie: does this test fail 
> > > without the LLVM changes and pass with it) Not that it necessarily has to 
> > > - since Clang isn't here to test the LLVM behavior - perhaps this test is 
> > > sufficient in Clang to test that the code in BackendUtil works to enable 
> > > this pass.
> > > 
> > > This could possibly be staged as independent commits - adding the LLVM 
> > > functionality in one commit, which would be a no-op for Clang because it 
> > > wouldn't be setting PTO.UniqueLinkageNames - then committing the Clang 
> > > change that would remove the custom pass addition and set 
> > > PTO.UniqueLinkageNames - and then it'd probably be reasonable to have 
> > > this test be made a bit more explicit (testing the pass manager 
> > > structure/order) to show that that Clang change had an effect: Moving the 
> > > pass to the desired location in the pass pipeline.
> > This is a good question. No, this test does not validate the pipeline 
> > change on the LLVM side, since Clang shouldn't have knowledge about how the 
> > pipelines are arranged in LLVM. As you pointed out, the test here is to 
> > test if the specific pass is run and gives expected results.
> > 
> > Thanks for the suggestion to break the Clang changes and LLVM changes apart 
> > which would make the testing more specific. The pipeline ordering could be 
> > tested with a LLVM test but that would require a LLVM switch setup for 
> > UniqueLinkageNames and I'm not sure there's a need for that switch except 
> > for testing.
> > No, this test does not validate the pipeline change on the LLVM side, since 
> > Clang shouldn't have knowledge about how the pipelines are arranged in 
> > LLVM. 
> 
> "ish" - but Clang should have tests for changes to Clang, ideally. Usually 
> they can simply be testing LLVM's IR output before it goes to LLVM for 
> optimization/codegen - but for features that don't have this serialization 
> boundary that makes testing and isolation clear/simple, it becomes a bit 
> fuzzier.
> 
> In this case, there is a clang change - from adding the pass explicitly in 
> Clang, to setting a parameter about how LLVM will add the pass, and it has an 
> observable effect. One way to test this change while isolating the Clang test 
> from further changes to the pipeline in LLVM, would be to test that the pass 
> ends up somewhere in the LLVM-created part of the pass pipeline - the parts 
> that you can't get to from the way the original pass addition was written in 
> Clang. At least I assume that's the case/what motivated the change from 
> adding it in Clang to adding it in LLVM?
> 
> eg: if LLVM always forms passes {x, y, z} and Clang is able to add passes 
> before/after, say it always adds 'a' before and 'b' after, to make {a, x, y, 
> z, b} - and this new pass u was previously added at the start to make {u, a, 
> x, y, z, b} but now needs to go in {a, x, y, u, z, b} you could test that 'u' 
> is after 'a' and before 'b', or between 'x' and 'z', etc. If there's some 
> other more clear/simple/reliable marker of where the LLVM-created passes 
> start/end in the structured dump, that'd be good to use as a landmark to make 
> such a test more robust. If there's some meaningful pass that this pass 
> always needs to go after - testing that might be OK, even if it's somewhat an 
> implementation detail of LLVM - whatever's likely to make the test more 
> legible and more reliable/resilient to unrelated changes would be good.
> 
> > As you pointed out, the test here is to test if the specific pass is run 
> > and gives expected results.
> 
> If that's the case, this test could be committed standalone, before any of 
> these other changes?
> 
> > The pipeline ordering could be tested with a LLVM test but that would 
> > require a LLVM switch setup for UniqueLinkageNames and I'm not sure there's 
> > a need for that switch except for testing.
> 
> That's OK, the entire 'opt' tool and all its switches only exist for testing. 
> eg: 
> https://github.com/llvm/llvm-project/blob/master/llvm/tools/opt/NewPMDriver.cpp#L284
The point of this change is that UniqueInternalLinkageNamesPass should run 
before SampleProfileProbePass. That must make a difference in the output of 
something like `clang -emit-llvm -O1`, right? Maybe we can add a new clang test 
that checks for that new change in IR, no need to check -fdebug-pass-manager. 
(I'm not familiar with the passes, correct me if I'm wrong)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93656

[PATCH] D93776: [clang-format] Add StatementAttributeLikeMacros option

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added a comment.

Seems okay at the first glance. I'm wondering if we can find a better name 
though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93776

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

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[Hongtao Yu via Phabricator via cfe-commits]

hoy added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names.cpp:48-49
 
+// LPIPELINE: Unique Internal Linkage Names
+// NPIPELINE: Running pass: UniqueInternalLinkageNamesPass
 // PLAIN: @_ZL4glob = internal global

aeubanks wrote:
> dblaikie wrote:
> > hoy wrote:
> > > dblaikie wrote:
> > > > Does this test validate the new behavior? (ie: does this test fail 
> > > > without the LLVM changes and pass with it) Not that it necessarily has 
> > > > to - since Clang isn't here to test the LLVM behavior - perhaps this 
> > > > test is sufficient in Clang to test that the code in BackendUtil works 
> > > > to enable this pass.
> > > > 
> > > > This could possibly be staged as independent commits - adding the LLVM 
> > > > functionality in one commit, which would be a no-op for Clang because 
> > > > it wouldn't be setting PTO.UniqueLinkageNames - then committing the 
> > > > Clang change that would remove the custom pass addition and set 
> > > > PTO.UniqueLinkageNames - and then it'd probably be reasonable to have 
> > > > this test be made a bit more explicit (testing the pass manager 
> > > > structure/order) to show that that Clang change had an effect: Moving 
> > > > the pass to the desired location in the pass pipeline.
> > > This is a good question. No, this test does not validate the pipeline 
> > > change on the LLVM side, since Clang shouldn't have knowledge about how 
> > > the pipelines are arranged in LLVM. As you pointed out, the test here is 
> > > to test if the specific pass is run and gives expected results.
> > > 
> > > Thanks for the suggestion to break the Clang changes and LLVM changes 
> > > apart which would make the testing more specific. The pipeline ordering 
> > > could be tested with a LLVM test but that would require a LLVM switch 
> > > setup for UniqueLinkageNames and I'm not sure there's a need for that 
> > > switch except for testing.
> > > No, this test does not validate the pipeline change on the LLVM side, 
> > > since Clang shouldn't have knowledge about how the pipelines are arranged 
> > > in LLVM. 
> > 
> > "ish" - but Clang should have tests for changes to Clang, ideally. Usually 
> > they can simply be testing LLVM's IR output before it goes to LLVM for 
> > optimization/codegen - but for features that don't have this serialization 
> > boundary that makes testing and isolation clear/simple, it becomes a bit 
> > fuzzier.
> > 
> > In this case, there is a clang change - from adding the pass explicitly in 
> > Clang, to setting a parameter about how LLVM will add the pass, and it has 
> > an observable effect. One way to test this change while isolating the Clang 
> > test from further changes to the pipeline in LLVM, would be to test that 
> > the pass ends up somewhere in the LLVM-created part of the pass pipeline - 
> > the parts that you can't get to from the way the original pass addition was 
> > written in Clang. At least I assume that's the case/what motivated the 
> > change from adding it in Clang to adding it in LLVM?
> > 
> > eg: if LLVM always forms passes {x, y, z} and Clang is able to add passes 
> > before/after, say it always adds 'a' before and 'b' after, to make {a, x, 
> > y, z, b} - and this new pass u was previously added at the start to make 
> > {u, a, x, y, z, b} but now needs to go in {a, x, y, u, z, b} you could test 
> > that 'u' is after 'a' and before 'b', or between 'x' and 'z', etc. If 
> > there's some other more clear/simple/reliable marker of where the 
> > LLVM-created passes start/end in the structured dump, that'd be good to use 
> > as a landmark to make such a test more robust. If there's some meaningful 
> > pass that this pass always needs to go after - testing that might be OK, 
> > even if it's somewhat an implementation detail of LLVM - whatever's likely 
> > to make the test more legible and more reliable/resilient to unrelated 
> > changes would be good.
> > 
> > > As you pointed out, the test here is to test if the specific pass is run 
> > > and gives expected results.
> > 
> > If that's the case, this test could be committed standalone, before any of 
> > these other changes?
> > 
> > > The pipeline ordering could be tested with a LLVM test but that would 
> > > require a LLVM switch setup for UniqueLinkageNames and I'm not sure 
> > > there's a need for that switch except for testing.
> > 
> > That's OK, the entire 'opt' tool and all its switches only exist for 
> > testing. eg: 
> > https://github.com/llvm/llvm-project/blob/master/llvm/tools/opt/NewPMDriver.cpp#L284
> The point of this change is that UniqueInternalLinkageNamesPass should run 
> before SampleProfileProbePass. That must make a difference in the output of 
> something like `clang -emit-llvm -O1`, right? Maybe we can add a new clang 
> test that checks for that new change in IR, no need to check 
> -fdebug-pass-manager. (I'm not familiar with the passes, correct me if I'm 
> wrong)
Maybe we 

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names.cpp:48-49
 
+// LPIPELINE: Unique Internal Linkage Names
+// NPIPELINE: Running pass: UniqueInternalLinkageNamesPass
 // PLAIN: @_ZL4glob = internal global

hoy wrote:
> aeubanks wrote:
> > dblaikie wrote:
> > > hoy wrote:
> > > > dblaikie wrote:
> > > > > Does this test validate the new behavior? (ie: does this test fail 
> > > > > without the LLVM changes and pass with it) Not that it necessarily 
> > > > > has to - since Clang isn't here to test the LLVM behavior - perhaps 
> > > > > this test is sufficient in Clang to test that the code in BackendUtil 
> > > > > works to enable this pass.
> > > > > 
> > > > > This could possibly be staged as independent commits - adding the 
> > > > > LLVM functionality in one commit, which would be a no-op for Clang 
> > > > > because it wouldn't be setting PTO.UniqueLinkageNames - then 
> > > > > committing the Clang change that would remove the custom pass 
> > > > > addition and set PTO.UniqueLinkageNames - and then it'd probably be 
> > > > > reasonable to have this test be made a bit more explicit (testing the 
> > > > > pass manager structure/order) to show that that Clang change had an 
> > > > > effect: Moving the pass to the desired location in the pass pipeline.
> > > > This is a good question. No, this test does not validate the pipeline 
> > > > change on the LLVM side, since Clang shouldn't have knowledge about how 
> > > > the pipelines are arranged in LLVM. As you pointed out, the test here 
> > > > is to test if the specific pass is run and gives expected results.
> > > > 
> > > > Thanks for the suggestion to break the Clang changes and LLVM changes 
> > > > apart which would make the testing more specific. The pipeline ordering 
> > > > could be tested with a LLVM test but that would require a LLVM switch 
> > > > setup for UniqueLinkageNames and I'm not sure there's a need for that 
> > > > switch except for testing.
> > > > No, this test does not validate the pipeline change on the LLVM side, 
> > > > since Clang shouldn't have knowledge about how the pipelines are 
> > > > arranged in LLVM. 
> > > 
> > > "ish" - but Clang should have tests for changes to Clang, ideally. 
> > > Usually they can simply be testing LLVM's IR output before it goes to 
> > > LLVM for optimization/codegen - but for features that don't have this 
> > > serialization boundary that makes testing and isolation clear/simple, it 
> > > becomes a bit fuzzier.
> > > 
> > > In this case, there is a clang change - from adding the pass explicitly 
> > > in Clang, to setting a parameter about how LLVM will add the pass, and it 
> > > has an observable effect. One way to test this change while isolating the 
> > > Clang test from further changes to the pipeline in LLVM, would be to test 
> > > that the pass ends up somewhere in the LLVM-created part of the pass 
> > > pipeline - the parts that you can't get to from the way the original pass 
> > > addition was written in Clang. At least I assume that's the case/what 
> > > motivated the change from adding it in Clang to adding it in LLVM?
> > > 
> > > eg: if LLVM always forms passes {x, y, z} and Clang is able to add passes 
> > > before/after, say it always adds 'a' before and 'b' after, to make {a, x, 
> > > y, z, b} - and this new pass u was previously added at the start to make 
> > > {u, a, x, y, z, b} but now needs to go in {a, x, y, u, z, b} you could 
> > > test that 'u' is after 'a' and before 'b', or between 'x' and 'z', etc. 
> > > If there's some other more clear/simple/reliable marker of where the 
> > > LLVM-created passes start/end in the structured dump, that'd be good to 
> > > use as a landmark to make such a test more robust. If there's some 
> > > meaningful pass that this pass always needs to go after - testing that 
> > > might be OK, even if it's somewhat an implementation detail of LLVM - 
> > > whatever's likely to make the test more legible and more 
> > > reliable/resilient to unrelated changes would be good.
> > > 
> > > > As you pointed out, the test here is to test if the specific pass is 
> > > > run and gives expected results.
> > > 
> > > If that's the case, this test could be committed standalone, before any 
> > > of these other changes?
> > > 
> > > > The pipeline ordering could be tested with a LLVM test but that would 
> > > > require a LLVM switch setup for UniqueLinkageNames and I'm not sure 
> > > > there's a need for that switch except for testing.
> > > 
> > > That's OK, the entire 'opt' tool and all its switches only exist for 
> > > testing. eg: 
> > > https://github.com/llvm/llvm-project/blob/master/llvm/tools/opt/NewPMDriver.cpp#L284
> > The point of this change is that UniqueInternalLinkageNamesPass should run 
> > before SampleProfileProbePass. That must make a difference in the output of 
> > something like `clang -emit-llvm -O1`, right? Maybe we can add a new

[PATCH] D93776: [clang-format] Add StatementAttributeLikeMacros option

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added a comment.

In D93776#2470524 , @curdeius wrote:

> Seems okay at the first glance. I'm wondering if we can find a better name 
> though.

I'm all in for a better name. :) I could not think of any (my first shot was 
`IgnoredMacros`, but that's way worse in my opinion).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93776

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

[clang-tools-extra] 74b3ace - [clangd] Fix case mismatch crash on in CDB on windows after 92dd077af1ff8

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2020-12-23T22:42:45+01:00
New Revision: 74b3acefc7b6355e89bb9b09dc88a5948f65c342

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

LOG: [clangd] Fix case mismatch crash on in CDB on windows after 92dd077af1ff8

See https://github.com/clangd/clangd/issues/631

Added: 


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

Removed: 




diff  --git a/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp 
b/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
index 41b549cefc7c..86375fa11d3b 100644
--- a/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
+++ b/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
@@ -511,11 +511,14 @@ void 
DirectoryBasedGlobalCompilationDatabase::broadcastCDB(
   // Given that we know that CDBs have been moved/generated, don't trust 
caches.
   // (This should be rare, so it's OK to add a little latency).
   constexpr auto IgnoreCache = std::chrono::steady_clock::time_point::max();
-  for (DirectoryCache *Dir : getDirectoryCaches(FileAncestors)) {
+  auto DirectoryCaches = getDirectoryCaches(FileAncestors);
+  assert(DirectoryCaches.size() == FileAncestors.size());
+  for (unsigned I = 0; I < DirectoryCaches.size(); ++I) {
 bool ShouldBroadcast = false;
-if (Dir->get(Opts.TFS, ShouldBroadcast, /*FreshTime=*/IgnoreCache,
- /*FreshTimeMissing=*/IgnoreCache))
-  DirectoryHasCDB.find(Dir->Path)->setValue(true);
+if (DirectoryCaches[I]->get(Opts.TFS, ShouldBroadcast,
+/*FreshTime=*/IgnoreCache,
+/*FreshTimeMissing=*/IgnoreCache))
+  DirectoryHasCDB.find(FileAncestors[I])->setValue(true);
   }
 
   std::vector GovernedFiles;



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

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[Hongtao Yu via Phabricator via cfe-commits]

hoy added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names.cpp:48-49
 
+// LPIPELINE: Unique Internal Linkage Names
+// NPIPELINE: Running pass: UniqueInternalLinkageNamesPass
 // PLAIN: @_ZL4glob = internal global

aeubanks wrote:
> hoy wrote:
> > aeubanks wrote:
> > > dblaikie wrote:
> > > > hoy wrote:
> > > > > dblaikie wrote:
> > > > > > Does this test validate the new behavior? (ie: does this test fail 
> > > > > > without the LLVM changes and pass with it) Not that it necessarily 
> > > > > > has to - since Clang isn't here to test the LLVM behavior - perhaps 
> > > > > > this test is sufficient in Clang to test that the code in 
> > > > > > BackendUtil works to enable this pass.
> > > > > > 
> > > > > > This could possibly be staged as independent commits - adding the 
> > > > > > LLVM functionality in one commit, which would be a no-op for Clang 
> > > > > > because it wouldn't be setting PTO.UniqueLinkageNames - then 
> > > > > > committing the Clang change that would remove the custom pass 
> > > > > > addition and set PTO.UniqueLinkageNames - and then it'd probably be 
> > > > > > reasonable to have this test be made a bit more explicit (testing 
> > > > > > the pass manager structure/order) to show that that Clang change 
> > > > > > had an effect: Moving the pass to the desired location in the pass 
> > > > > > pipeline.
> > > > > This is a good question. No, this test does not validate the pipeline 
> > > > > change on the LLVM side, since Clang shouldn't have knowledge about 
> > > > > how the pipelines are arranged in LLVM. As you pointed out, the test 
> > > > > here is to test if the specific pass is run and gives expected 
> > > > > results.
> > > > > 
> > > > > Thanks for the suggestion to break the Clang changes and LLVM changes 
> > > > > apart which would make the testing more specific. The pipeline 
> > > > > ordering could be tested with a LLVM test but that would require a 
> > > > > LLVM switch setup for UniqueLinkageNames and I'm not sure there's a 
> > > > > need for that switch except for testing.
> > > > > No, this test does not validate the pipeline change on the LLVM side, 
> > > > > since Clang shouldn't have knowledge about how the pipelines are 
> > > > > arranged in LLVM. 
> > > > 
> > > > "ish" - but Clang should have tests for changes to Clang, ideally. 
> > > > Usually they can simply be testing LLVM's IR output before it goes to 
> > > > LLVM for optimization/codegen - but for features that don't have this 
> > > > serialization boundary that makes testing and isolation clear/simple, 
> > > > it becomes a bit fuzzier.
> > > > 
> > > > In this case, there is a clang change - from adding the pass explicitly 
> > > > in Clang, to setting a parameter about how LLVM will add the pass, and 
> > > > it has an observable effect. One way to test this change while 
> > > > isolating the Clang test from further changes to the pipeline in LLVM, 
> > > > would be to test that the pass ends up somewhere in the LLVM-created 
> > > > part of the pass pipeline - the parts that you can't get to from the 
> > > > way the original pass addition was written in Clang. At least I assume 
> > > > that's the case/what motivated the change from adding it in Clang to 
> > > > adding it in LLVM?
> > > > 
> > > > eg: if LLVM always forms passes {x, y, z} and Clang is able to add 
> > > > passes before/after, say it always adds 'a' before and 'b' after, to 
> > > > make {a, x, y, z, b} - and this new pass u was previously added at the 
> > > > start to make {u, a, x, y, z, b} but now needs to go in {a, x, y, u, z, 
> > > > b} you could test that 'u' is after 'a' and before 'b', or between 'x' 
> > > > and 'z', etc. If there's some other more clear/simple/reliable marker 
> > > > of where the LLVM-created passes start/end in the structured dump, 
> > > > that'd be good to use as a landmark to make such a test more robust. If 
> > > > there's some meaningful pass that this pass always needs to go after - 
> > > > testing that might be OK, even if it's somewhat an implementation 
> > > > detail of LLVM - whatever's likely to make the test more legible and 
> > > > more reliable/resilient to unrelated changes would be good.
> > > > 
> > > > > As you pointed out, the test here is to test if the specific pass is 
> > > > > run and gives expected results.
> > > > 
> > > > If that's the case, this test could be committed standalone, before any 
> > > > of these other changes?
> > > > 
> > > > > The pipeline ordering could be tested with a LLVM test but that would 
> > > > > require a LLVM switch setup for UniqueLinkageNames and I'm not sure 
> > > > > there's a need for that switch except for testing.
> > > > 
> > > > That's OK, the entire 'opt' tool and all its switches only exist for 
> > > > testing. eg: 
> > > > https://github.com/llvm/llvm-project/blob/master/llvm/tools/opt/NewPMDriver.cpp#L284
> > > The point of this change is that Un

[PATCH] D92195: [OPENMP50]Mapping of the subcomponents with the 'default' mappers.

[Abhinav Gaba via Phabricator via cfe-commits]

abhinavgaba added a comment.

The patch currently asserts for the following:

  #include 
  
  typedef struct { int a; double *b; } C; 
  #pragma omp declare mapper(default: C s) map(s.a, s.b[0:2]) 
  
  int main() {
  C s;
  s.a = 10;   
  double x[2]; x[0] = 20; 
  s.b = &x[0];
  C* sp = &s; 
  C** spp = &sp;
  
  printf("%d %lf %p\n", spp[0][0].a, spp[0][0].b[0], spp[0][0].b);
  
  #pragma omp target map(tofrom:spp[0][0])
  printf("%d %lf %p\n", spp[0][0].a, spp[0][0].b[0], spp[0][0].b);
  }   

Note that this doesn't work correctly before this patch either. This changes it 
from a runfail to a compfail.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92195

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

[PATCH] D93273: [CodeGen][ObjC] Destroy callee-destroyed arguments in the caller function when the receiver is nil

[John McCall via Phabricator via cfe-commits]

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

Functionally LGTM.  Minor suggestion.




Comment at: clang/lib/CodeGen/CGObjCMac.cpp:2169
+  return false;
+}
+

Is this something that could reasonably just be a method on `ParmVarDecl`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93273

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

[PATCH] D93763: [clangd] Add a flag to disable the documentLinks LSP request

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

Can you apply the clang-format patch suggested by the pre-merge bot. 
Alternatively, if you have a recent version of clang-format and the appropriate 
git-hooks you should be able to run `git clang-format` for the same effect.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93763

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

[clang] 245218b - Basic: Support named pipes natively in SourceManager and FileManager

[Duncan P. N. Exon Smith via cfe-commits]

Author: Duncan P. N. Exon Smith
Date: 2020-12-23T14:57:41-08:00
New Revision: 245218bb355599771ba43a0fe1449d1670f2666c

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

LOG: Basic: Support named pipes natively in SourceManager and FileManager

Handle named pipes natively in SourceManager and FileManager, removing a
call to `SourceManager::overrideFileContents` in
`CompilerInstance::InitializeSourceManager` (removing a blocker for
sinking the content cache to FileManager (which will incidently sink
this new named pipe logic with it)).

SourceManager usually checks if the file entry's size matches the
eventually loaded buffer, but that's now skipped for named pipes since
the `stat` won't reflect the full size.  Since we can't trust
`ContentsEntry->getSize()`, we also need shift the check for files that
are too large until after the buffer is loaded... and load the buffer
immediately in `createFileID` so that no client gets a bad value from
`ContentCache::getSize`. `FileManager::getBufferForFile` also needs to
treat these files as volatile when loading the buffer.

Native support in SourceManager / FileManager means that named pipes can
also be `#include`d, and clang/test/Misc/dev-fd-fs.c was expanded to
check for that.

This is a new version of 3b18a594c7717a328c33b9c1eba675e9f4bd367c, which
was reverted in b34632201987eed369bb7ef4646f341b901c95b8 since it was
missing the `SourceManager` changes.

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

Added: 


Modified: 
clang/lib/Basic/FileManager.cpp
clang/lib/Basic/SourceManager.cpp
clang/lib/Frontend/CompilerInstance.cpp
clang/test/Misc/dev-fd-fs.c

Removed: 




diff  --git a/clang/lib/Basic/FileManager.cpp b/clang/lib/Basic/FileManager.cpp
index c0d3685001ee..f3afe6dd5f48 100644
--- a/clang/lib/Basic/FileManager.cpp
+++ b/clang/lib/Basic/FileManager.cpp
@@ -489,7 +489,7 @@ FileManager::getBufferForFile(const FileEntry *Entry, bool 
isVolatile,
   uint64_t FileSize = Entry->getSize();
   // If there's a high enough chance that the file have changed since we
   // got its size, force a stat before opening it.
-  if (isVolatile)
+  if (isVolatile || Entry->isNamedPipe())
 FileSize = -1;
 
   StringRef Filename = Entry->getName();

diff  --git a/clang/lib/Basic/SourceManager.cpp 
b/clang/lib/Basic/SourceManager.cpp
index b71b2be0cc41..d2c0de5006c4 100644
--- a/clang/lib/Basic/SourceManager.cpp
+++ b/clang/lib/Basic/SourceManager.cpp
@@ -115,23 +115,6 @@ ContentCache::getBufferOrNone(DiagnosticsEngine &Diag, 
FileManager &FM,
   // return paths.
   IsBufferInvalid = true;
 
-  // Check that the file's size fits in an 'unsigned' (with room for a
-  // past-the-end value). This is deeply regrettable, but various parts of
-  // Clang (including elsewhere in this file!) use 'unsigned' to represent file
-  // offsets, line numbers, string literal lengths, and so on, and fail
-  // miserably on large source files.
-  if ((uint64_t)ContentsEntry->getSize() >=
-  std::numeric_limits::max()) {
-if (Diag.isDiagnosticInFlight())
-  Diag.SetDelayedDiagnostic(diag::err_file_too_large,
-ContentsEntry->getName());
-else
-  Diag.Report(Loc, diag::err_file_too_large)
-<< ContentsEntry->getName();
-
-return None;
-  }
-
   auto BufferOrError = FM.getBufferForFile(ContentsEntry, IsFileVolatile);
 
   // If we were unable to open the file, then we are in an inconsistent
@@ -153,9 +136,31 @@ ContentCache::getBufferOrNone(DiagnosticsEngine &Diag, 
FileManager &FM,
 
   Buffer = std::move(*BufferOrError);
 
-  // Check that the file's size is the same as in the file entry (which may
+  // Check that the file's size fits in an 'unsigned' (with room for a
+  // past-the-end value). This is deeply regrettable, but various parts of
+  // Clang (including elsewhere in this file!) use 'unsigned' to represent file
+  // offsets, line numbers, string literal lengths, and so on, and fail
+  // miserably on large source files.
+  //
+  // Note: ContentsEntry could be a named pipe, in which case
+  // ContentsEntry::getSize() could have the wrong size. Use
+  // MemoryBuffer::getBufferSize() instead.
+  if (Buffer->getBufferSize() >= std::numeric_limits::max()) {
+if (Diag.isDiagnosticInFlight())
+  Diag.SetDelayedDiagnostic(diag::err_file_too_large,
+ContentsEntry->getName());
+else
+  Diag.Report(Loc, diag::err_file_too_large)
+<< ContentsEntry->getName();
+
+return None;
+  }
+
+  // Unless this is a named pipe (in which case we can handle a mismatch),
+  // check that the file's size is the same as in the file entry (which may
   // have come from a stat cache).
-  if (Buffer->getBufferSize() != (size_t)ContentsEntry->

[PATCH] D92531: Basic: Support named pipes natively in SourceManager

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG245218bb3555: Basic: Support named pipes natively in 
SourceManager and FileManager (authored by dexonsmith).

Changed prior to commit:
  https://reviews.llvm.org/D92531?vs=311004&id=313618#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92531

Files:
  clang/lib/Basic/FileManager.cpp
  clang/lib/Basic/SourceManager.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/test/Misc/dev-fd-fs.c

Index: clang/test/Misc/dev-fd-fs.c
===
--- clang/test/Misc/dev-fd-fs.c
+++ clang/test/Misc/dev-fd-fs.c
@@ -8,7 +8,13 @@
 // RUN: cat %s | %clang -x c /dev/fd/0 -E > %t
 // RUN: FileCheck --check-prefix DEV-FD-INPUT < %t %s
 //
+// RUN: cat %s | %clang -x c %s -E -DINCLUDE_FROM_STDIN > %t
+// RUN: FileCheck --check-prefix DEV-FD-INPUT \
+// RUN:   --check-prefix DEV-FD-INPUT-INCLUDE < %t %s
+//
+// DEV-FD-INPUT-INCLUDE: int w;
 // DEV-FD-INPUT: int x;
+// DEV-FD-INPUT-INCLUDE: int y;
 
 
 // Check writing to /dev/fd named pipes. We use cat here as before to ensure we
@@ -27,4 +33,11 @@
 //
 // DEV-FD-REG-OUTPUT: int x;
 
+#ifdef INCLUDE_FROM_STDIN
+#undef INCLUDE_FROM_STDIN
+int w;
+#include "/dev/fd/0"
+int y;
+#else
 int x;
+#endif
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -856,32 +856,9 @@
   Diags.Report(diag::err_fe_error_reading) << InputFile;
   return false;
 }
-FileEntryRef File = *FileOrErr;
-
-// The natural SourceManager infrastructure can't currently handle named
-// pipes, but we would at least like to accept them for the main
-// file. Detect them here, read them with the volatile flag so FileMgr will
-// pick up the correct size, and simply override their contents as we do for
-// STDIN.
-if (File.getFileEntry().isNamedPipe()) {
-  auto MB =
-  FileMgr.getBufferForFile(&File.getFileEntry(), /*isVolatile=*/true);
-  if (MB) {
-// Create a new virtual file that will have the correct size.
-FileEntryRef FE =
-FileMgr.getVirtualFileRef(InputFile, (*MB)->getBufferSize(), 0);
-SourceMgr.overrideFileContents(FE, std::move(*MB));
-SourceMgr.setMainFileID(
-SourceMgr.createFileID(FE, SourceLocation(), Kind));
-  } else {
-Diags.Report(diag::err_cannot_open_file) << InputFile
- << MB.getError().message();
-return false;
-  }
-} else {
-  SourceMgr.setMainFileID(
-  SourceMgr.createFileID(File, SourceLocation(), Kind));
-}
+
+SourceMgr.setMainFileID(
+SourceMgr.createFileID(*FileOrErr, SourceLocation(), Kind));
   } else {
 llvm::ErrorOr> SBOrErr =
 llvm::MemoryBuffer::getSTDIN();
Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -115,23 +115,6 @@
   // return paths.
   IsBufferInvalid = true;
 
-  // Check that the file's size fits in an 'unsigned' (with room for a
-  // past-the-end value). This is deeply regrettable, but various parts of
-  // Clang (including elsewhere in this file!) use 'unsigned' to represent file
-  // offsets, line numbers, string literal lengths, and so on, and fail
-  // miserably on large source files.
-  if ((uint64_t)ContentsEntry->getSize() >=
-  std::numeric_limits::max()) {
-if (Diag.isDiagnosticInFlight())
-  Diag.SetDelayedDiagnostic(diag::err_file_too_large,
-ContentsEntry->getName());
-else
-  Diag.Report(Loc, diag::err_file_too_large)
-<< ContentsEntry->getName();
-
-return None;
-  }
-
   auto BufferOrError = FM.getBufferForFile(ContentsEntry, IsFileVolatile);
 
   // If we were unable to open the file, then we are in an inconsistent
@@ -153,9 +136,31 @@
 
   Buffer = std::move(*BufferOrError);
 
-  // Check that the file's size is the same as in the file entry (which may
+  // Check that the file's size fits in an 'unsigned' (with room for a
+  // past-the-end value). This is deeply regrettable, but various parts of
+  // Clang (including elsewhere in this file!) use 'unsigned' to represent file
+  // offsets, line numbers, string literal lengths, and so on, and fail
+  // miserably on large source files.
+  //
+  // Note: ContentsEntry could be a named pipe, in which case
+  // ContentsEntry::getSize() could have the wrong size. Use
+  // MemoryBuffer::getBufferSize() instead.
+  if (Buffer->getBufferSize() >= std::numeric_limits::max()) {
+if (Diag.isDiagnosticInFlight())
+  Diag.SetDelayedDiagnostic(diag::err_file_too_large,
+

[clang] 3ee43ad - Basic: Add native support for stdin to SourceManager and FileManager

[Duncan P. N. Exon Smith via cfe-commits]

Author: Duncan P. N. Exon Smith
Date: 2020-12-23T15:18:50-08:00
New Revision: 3ee43adfb20d5dc56b7043b314bd22f457c55483

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

LOG: Basic: Add native support for stdin to SourceManager and FileManager

Add support for stdin to SourceManager and FileManager. Adds
FileManager::getSTDIN, which adds a FileEntryRef for `` and reads
the MemoryBuffer, which is stored as `FileEntry::Content`.

Eventually the other buffers in `ContentCache` will sink to here as well
-- we probably usually want to load/save a MemoryBuffer eagerly -- but
it's happening early for stdin to get rid of
CompilerInstance::InitializeSourceManager's final call to
`SourceManager::overrideFileContents`.

clang/test/CXX/modules-ts/dcl.dcl/dcl.module/dcl.module.export/p1.cpp
relies on building a module from stdin; supporting that requires setting
ContentCache::BufferOverridden.

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

Added: 


Modified: 
clang/include/clang/Basic/FileEntry.h
clang/include/clang/Basic/FileManager.h
clang/lib/Basic/FileEntry.cpp
clang/lib/Basic/FileManager.cpp
clang/lib/Basic/SourceManager.cpp
clang/lib/Frontend/CompilerInstance.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/FileEntry.h 
b/clang/include/clang/Basic/FileEntry.h
index aa7bedec44ac..6e91b42e18b7 100644
--- a/clang/include/clang/Basic/FileEntry.h
+++ b/clang/include/clang/Basic/FileEntry.h
@@ -25,6 +25,9 @@
 #include "llvm/Support/FileSystem/UniqueID.h"
 
 namespace llvm {
+
+class MemoryBuffer;
+
 namespace vfs {
 
 class File;
@@ -67,6 +70,7 @@ class FileEntryRef {
   inline unsigned getUID() const;
   inline const llvm::sys::fs::UniqueID &getUniqueID() const;
   inline time_t getModificationTime() const;
+  inline bool isNamedPipe() const;
   inline void closeFile() const;
 
   /// Check if the underlying FileEntry is the same, intentially ignoring
@@ -339,6 +343,9 @@ class FileEntry {
   /// The open file, if it is owned by the \p FileEntry.
   mutable std::unique_ptr File;
 
+  /// The file content, if it is owned by the \p FileEntry.
+  std::unique_ptr Content;
+
   // First access name for this FileEntry.
   //
   // This is Optional only to allow delayed construction (FileEntryRef has no
@@ -390,6 +397,8 @@ time_t FileEntryRef::getModificationTime() const {
   return getFileEntry().getModificationTime();
 }
 
+bool FileEntryRef::isNamedPipe() const { return getFileEntry().isNamedPipe(); }
+
 void FileEntryRef::closeFile() const { getFileEntry().closeFile(); }
 
 } // end namespace clang

diff  --git a/clang/include/clang/Basic/FileManager.h 
b/clang/include/clang/Basic/FileManager.h
index 449aec2b3541..974771a8f8f3 100644
--- a/clang/include/clang/Basic/FileManager.h
+++ b/clang/include/clang/Basic/FileManager.h
@@ -99,6 +99,9 @@ class FileManager : public RefCountedBase {
   std::unique_ptr>>
   SeenBypassFileEntries;
 
+  /// The file entry for stdin, if it has been accessed through the 
FileManager.
+  Optional STDIN;
+
   /// The canonical names of files and directories .
   llvm::DenseMap CanonicalNames;
 
@@ -217,6 +220,14 @@ class FileManager : public RefCountedBase {
   bool OpenFile = false,
   bool CacheFailure = true);
 
+  /// Get the FileEntryRef for stdin, returning an error if stdin cannot be
+  /// read.
+  ///
+  /// This reads and caches stdin before returning. Subsequent calls return the
+  /// same file entry, and a reference to the cached input is returned by calls
+  /// to getBufferForFile.
+  llvm::Expected getSTDIN();
+
   /// Get a FileEntryRef if it exists, without doing anything on error.
   llvm::Optional getOptionalFileRef(StringRef Filename,
   bool OpenFile = false,

diff  --git a/clang/lib/Basic/FileEntry.cpp b/clang/lib/Basic/FileEntry.cpp
index 2efdcbbd46aa..5ee9bef9523e 100644
--- a/clang/lib/Basic/FileEntry.cpp
+++ b/clang/lib/Basic/FileEntry.cpp
@@ -12,6 +12,7 @@
 
//===--===//
 
 #include "clang/Basic/FileEntry.h"
+#include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/VirtualFileSystem.h"
 
 using namespace clang;

diff  --git a/clang/lib/Basic/FileManager.cpp b/clang/lib/Basic/FileManager.cpp
index f3afe6dd5f48..6e9d5d7fb422 100644
--- a/clang/lib/Basic/FileManager.cpp
+++ b/clang/lib/Basic/FileManager.cpp
@@ -338,6 +338,25 @@ FileManager::getFileRef(StringRef Filename, bool openFile, 
bool CacheFailure) {
   return ReturnedRef;
 }
 
+llvm::Expected FileManager::getSTDIN() {
+  // Only read stdin once.
+  if (STDIN)
+return *STDIN;
+
+  std::unique_ptr Content;
+  if (auto ContentOrError = llvm

[PATCH] D93148: Basic: Add native support for stdin to SourceManager and FileManager

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG3ee43adfb20d: Basic: Add native support for stdin to 
SourceManager and FileManager (authored by dexonsmith).

Changed prior to commit:
  https://reviews.llvm.org/D93148?vs=311338&id=313620#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93148

Files:
  clang/include/clang/Basic/FileEntry.h
  clang/include/clang/Basic/FileManager.h
  clang/lib/Basic/FileEntry.cpp
  clang/lib/Basic/FileManager.cpp
  clang/lib/Basic/SourceManager.cpp
  clang/lib/Frontend/CompilerInstance.cpp

Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -848,33 +848,22 @@
   StringRef InputFile = Input.getFile();
 
   // Figure out where to get and map in the main file.
-  if (InputFile != "-") {
-auto FileOrErr = FileMgr.getFileRef(InputFile, /*OpenFile=*/true);
-if (!FileOrErr) {
-  // FIXME: include the error in the diagnostic.
-  consumeError(FileOrErr.takeError());
+  auto FileOrErr = InputFile == "-"
+   ? FileMgr.getSTDIN()
+   : FileMgr.getFileRef(InputFile, /*OpenFile=*/true);
+  if (!FileOrErr) {
+// FIXME: include the error in the diagnostic even when it's not stdin.
+auto EC = llvm::errorToErrorCode(FileOrErr.takeError());
+if (InputFile != "-")
   Diags.Report(diag::err_fe_error_reading) << InputFile;
-  return false;
-}
-
-SourceMgr.setMainFileID(
-SourceMgr.createFileID(*FileOrErr, SourceLocation(), Kind));
-  } else {
-llvm::ErrorOr> SBOrErr =
-llvm::MemoryBuffer::getSTDIN();
-if (std::error_code EC = SBOrErr.getError()) {
+else
   Diags.Report(diag::err_fe_error_reading_stdin) << EC.message();
-  return false;
-}
-std::unique_ptr SB = std::move(SBOrErr.get());
-
-FileEntryRef File = FileMgr.getVirtualFileRef(SB->getBufferIdentifier(),
-  SB->getBufferSize(), 0);
-SourceMgr.setMainFileID(
-SourceMgr.createFileID(File, SourceLocation(), Kind));
-SourceMgr.overrideFileContents(File, std::move(SB));
+return false;
   }
 
+  SourceMgr.setMainFileID(
+  SourceMgr.createFileID(*FileOrErr, SourceLocation(), Kind));
+
   assert(SourceMgr.getMainFileID().isValid() &&
  "Couldn't establish MainFileID!");
   return true;
Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -414,6 +414,7 @@
 
   Entry->IsFileVolatile = UserFilesAreVolatile && !isSystemFile;
   Entry->IsTransient = FilesAreTransient;
+  Entry->BufferOverridden |= FileEnt->isNamedPipe();
 
   return *Entry;
 }
Index: clang/lib/Basic/FileManager.cpp
===
--- clang/lib/Basic/FileManager.cpp
+++ clang/lib/Basic/FileManager.cpp
@@ -338,6 +338,25 @@
   return ReturnedRef;
 }
 
+llvm::Expected FileManager::getSTDIN() {
+  // Only read stdin once.
+  if (STDIN)
+return *STDIN;
+
+  std::unique_ptr Content;
+  if (auto ContentOrError = llvm::MemoryBuffer::getSTDIN())
+Content = std::move(*ContentOrError);
+  else
+return llvm::errorCodeToError(ContentOrError.getError());
+
+  STDIN = getVirtualFileRef(Content->getBufferIdentifier(),
+Content->getBufferSize(), 0);
+  FileEntry &FE = const_cast(STDIN->getFileEntry());
+  FE.Content = std::move(Content);
+  FE.IsNamedPipe = true;
+  return *STDIN;
+}
+
 const FileEntry *FileManager::getVirtualFile(StringRef Filename, off_t Size,
  time_t ModificationTime) {
   return &getVirtualFileRef(Filename, Size, ModificationTime).getFileEntry();
@@ -486,6 +505,10 @@
 llvm::ErrorOr>
 FileManager::getBufferForFile(const FileEntry *Entry, bool isVolatile,
   bool RequiresNullTerminator) {
+  // If the content is living on the file entry, return a reference to it.
+  if (Entry->Content)
+return llvm::MemoryBuffer::getMemBuffer(Entry->Content->getMemBufferRef());
+
   uint64_t FileSize = Entry->getSize();
   // If there's a high enough chance that the file have changed since we
   // got its size, force a stat before opening it.
Index: clang/lib/Basic/FileEntry.cpp
===
--- clang/lib/Basic/FileEntry.cpp
+++ clang/lib/Basic/FileEntry.cpp
@@ -12,6 +12,7 @@
 //===--===//
 
 #include "clang/Basic/FileEntry.h"
+#include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/VirtualFileSystem.h"
 
 using namespace clang;

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names.cpp:48-49
 
+// LPIPELINE: Unique Internal Linkage Names
+// NPIPELINE: Running pass: UniqueInternalLinkageNamesPass
 // PLAIN: @_ZL4glob = internal global

hoy wrote:
> aeubanks wrote:
> > hoy wrote:
> > > aeubanks wrote:
> > > > dblaikie wrote:
> > > > > hoy wrote:
> > > > > > dblaikie wrote:
> > > > > > > Does this test validate the new behavior? (ie: does this test 
> > > > > > > fail without the LLVM changes and pass with it) Not that it 
> > > > > > > necessarily has to - since Clang isn't here to test the LLVM 
> > > > > > > behavior - perhaps this test is sufficient in Clang to test that 
> > > > > > > the code in BackendUtil works to enable this pass.
> > > > > > > 
> > > > > > > This could possibly be staged as independent commits - adding the 
> > > > > > > LLVM functionality in one commit, which would be a no-op for 
> > > > > > > Clang because it wouldn't be setting PTO.UniqueLinkageNames - 
> > > > > > > then committing the Clang change that would remove the custom 
> > > > > > > pass addition and set PTO.UniqueLinkageNames - and then it'd 
> > > > > > > probably be reasonable to have this test be made a bit more 
> > > > > > > explicit (testing the pass manager structure/order) to show that 
> > > > > > > that Clang change had an effect: Moving the pass to the desired 
> > > > > > > location in the pass pipeline.
> > > > > > This is a good question. No, this test does not validate the 
> > > > > > pipeline change on the LLVM side, since Clang shouldn't have 
> > > > > > knowledge about how the pipelines are arranged in LLVM. As you 
> > > > > > pointed out, the test here is to test if the specific pass is run 
> > > > > > and gives expected results.
> > > > > > 
> > > > > > Thanks for the suggestion to break the Clang changes and LLVM 
> > > > > > changes apart which would make the testing more specific. The 
> > > > > > pipeline ordering could be tested with a LLVM test but that would 
> > > > > > require a LLVM switch setup for UniqueLinkageNames and I'm not sure 
> > > > > > there's a need for that switch except for testing.
> > > > > > No, this test does not validate the pipeline change on the LLVM 
> > > > > > side, since Clang shouldn't have knowledge about how the pipelines 
> > > > > > are arranged in LLVM. 
> > > > > 
> > > > > "ish" - but Clang should have tests for changes to Clang, ideally. 
> > > > > Usually they can simply be testing LLVM's IR output before it goes to 
> > > > > LLVM for optimization/codegen - but for features that don't have this 
> > > > > serialization boundary that makes testing and isolation clear/simple, 
> > > > > it becomes a bit fuzzier.
> > > > > 
> > > > > In this case, there is a clang change - from adding the pass 
> > > > > explicitly in Clang, to setting a parameter about how LLVM will add 
> > > > > the pass, and it has an observable effect. One way to test this 
> > > > > change while isolating the Clang test from further changes to the 
> > > > > pipeline in LLVM, would be to test that the pass ends up somewhere in 
> > > > > the LLVM-created part of the pass pipeline - the parts that you can't 
> > > > > get to from the way the original pass addition was written in Clang. 
> > > > > At least I assume that's the case/what motivated the change from 
> > > > > adding it in Clang to adding it in LLVM?
> > > > > 
> > > > > eg: if LLVM always forms passes {x, y, z} and Clang is able to add 
> > > > > passes before/after, say it always adds 'a' before and 'b' after, to 
> > > > > make {a, x, y, z, b} - and this new pass u was previously added at 
> > > > > the start to make {u, a, x, y, z, b} but now needs to go in {a, x, y, 
> > > > > u, z, b} you could test that 'u' is after 'a' and before 'b', or 
> > > > > between 'x' and 'z', etc. If there's some other more 
> > > > > clear/simple/reliable marker of where the LLVM-created passes 
> > > > > start/end in the structured dump, that'd be good to use as a landmark 
> > > > > to make such a test more robust. If there's some meaningful pass that 
> > > > > this pass always needs to go after - testing that might be OK, even 
> > > > > if it's somewhat an implementation detail of LLVM - whatever's likely 
> > > > > to make the test more legible and more reliable/resilient to 
> > > > > unrelated changes would be good.
> > > > > 
> > > > > > As you pointed out, the test here is to test if the specific pass 
> > > > > > is run and gives expected results.
> > > > > 
> > > > > If that's the case, this test could be committed standalone, before 
> > > > > any of these other changes?
> > > > > 
> > > > > > The pipeline ordering could be tested with a LLVM test but that 
> > > > > > would require a LLVM switch setup for UniqueLinkageNames and I'm 
> > > > > > not sure there's a need for that switch except for testing.
> > > > > 
> > > > > That's OK, the entire 'opt' tool and all its sw

[PATCH] D90507: [Driver] Add DWARF64 flag: -gdwarf64

[Alexander Yermolovich via Phabricator via cfe-commits]

ayermolo updated this revision to Diff 313621.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90507

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/debug-options.c

Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -374,3 +374,19 @@
 // RUN:| FileCheck -check-prefix=NO_DEBUG_UNUSED_TYPES %s
 // NO_DEBUG_UNUSED_TYPES: "-debug-info-kind={{limited|line-tables-only|standalone}}"
 // NO_DEBUG_UNUSED_TYPES-NOT: "-debug-info-kind=unused-types"
+//
+// RUN: %clang -### -c -gdwarf-5 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-3 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-2 -gdwarf64 -target x86_64 %s 2>&1 | FileCheck -check-prefix=GDWARF64_VER %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target x86_64 -target x86_64 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=GDWARF64_ON %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target i386-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=GDWARF64_32ARCH %s
+// RUN: %clang -### -c -gdwarf-4 -gdwarf64 -target x86_64-apple-darwin %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=GDWARF64_ELF %s
+//
+// GDWARF64_ON:  "-gdwarf64"
+// GDWARF64_VER:  error: invalid argument '-gdwarf64' only allowed with 'DWARFv3 or greater'
+// GDWARF64_32ARCH: error: invalid argument '-gdwarf64' only allowed with '64 bit architecture'
+// GDWARF64_ELF: error: invalid argument '-gdwarf64' only allowed with 'ELF platforms'
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -963,6 +963,7 @@
   if (!Opts.ProfileInstrumentUsePath.empty())
 setPGOUseInstrumentor(Opts, Opts.ProfileInstrumentUsePath);
 
+  Opts.Dwarf64 = Args.hasArg(OPT_gdwarf64);
   Opts.CodeModel = TargetOpts.CodeModel;
 
   if (const Arg *A = Args.getLastArg(OPT_ftime_report, OPT_ftime_report_EQ)) {
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4013,6 +4013,25 @@
   if (DebuggerTuning == llvm::DebuggerKind::SCE)
 CmdArgs.push_back("-dwarf-explicit-import");
 
+  auto *DwarfFormatArg =
+  Args.getLastArg(options::OPT_gdwarf64, options::OPT_gdwarf32);
+  if (DwarfFormatArg &&
+  DwarfFormatArg->getOption().matches(options::OPT_gdwarf64)) {
+const llvm::Triple &RawTriple = TC.getTriple();
+if (EffectiveDWARFVersion < 3)
+  D.Diag(diag::err_drv_argument_only_allowed_with)
+  << DwarfFormatArg->getAsString(Args) << "DWARFv3 or greater";
+else if (!RawTriple.isArch64Bit())
+  D.Diag(diag::err_drv_argument_only_allowed_with)
+  << DwarfFormatArg->getAsString(Args) << "64 bit architecture";
+else if (!RawTriple.isOSBinFormatELF())
+  D.Diag(diag::err_drv_argument_only_allowed_with)
+  << DwarfFormatArg->getAsString(Args) << "ELF platforms";
+  }
+
+  if (DwarfFormatArg)
+DwarfFormatArg->render(Args, CmdArgs);
+
   RenderDebugInfoCompressionArgs(Args, CmdArgs, D, TC);
 }
 
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -571,6 +571,7 @@
   Options.MCOptions.MCFatalWarnings = CodeGenOpts.FatalWarnings;
   Options.MCOptions.MCNoWarn = CodeGenOpts.NoWarn;
   Options.MCOptions.AsmVerbose = CodeGenOpts.AsmVerbose;
+  Options.MCOptions.Dwarf64 = CodeGenOpts.Dwarf64;
   Options.MCOptions.PreserveAsmComments = CodeGenOpts.PreserveAsmComments;
   Options.MCOptions.ABIName = TargetOpts.ABI;
   for (const auto &Entry : HSOpts.UserEntries)
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2564,6 +2564,10 @@
   HelpText<"Generate source-level debug information with dwarf version 4">;
 def gdwarf_5 : Flag<["-"], "gdwarf-5">, Group,
   HelpText<"Generate source-level debug information with dwarf version 5">;
+def gdwarf64 : Flag<["-"], "gdwarf64">, Group, Flags<[CC1Option]>,
+  HelpText<"Enables DWARF64 format for ELF binaries, if debug information emission is enabled.">;
+def gdwarf32 : Flag<["-"], "gdwarf32">, Group, Flags<[CC1Opti

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names.cpp:48-49
 
+// LPIPELINE: Unique Internal Linkage Names
+// NPIPELINE: Running pass: UniqueInternalLinkageNamesPass
 // PLAIN: @_ZL4glob = internal global

dblaikie wrote:
> hoy wrote:
> > aeubanks wrote:
> > > hoy wrote:
> > > > aeubanks wrote:
> > > > > dblaikie wrote:
> > > > > > hoy wrote:
> > > > > > > dblaikie wrote:
> > > > > > > > Does this test validate the new behavior? (ie: does this test 
> > > > > > > > fail without the LLVM changes and pass with it) Not that it 
> > > > > > > > necessarily has to - since Clang isn't here to test the LLVM 
> > > > > > > > behavior - perhaps this test is sufficient in Clang to test 
> > > > > > > > that the code in BackendUtil works to enable this pass.
> > > > > > > > 
> > > > > > > > This could possibly be staged as independent commits - adding 
> > > > > > > > the LLVM functionality in one commit, which would be a no-op 
> > > > > > > > for Clang because it wouldn't be setting PTO.UniqueLinkageNames 
> > > > > > > > - then committing the Clang change that would remove the custom 
> > > > > > > > pass addition and set PTO.UniqueLinkageNames - and then it'd 
> > > > > > > > probably be reasonable to have this test be made a bit more 
> > > > > > > > explicit (testing the pass manager structure/order) to show 
> > > > > > > > that that Clang change had an effect: Moving the pass to the 
> > > > > > > > desired location in the pass pipeline.
> > > > > > > This is a good question. No, this test does not validate the 
> > > > > > > pipeline change on the LLVM side, since Clang shouldn't have 
> > > > > > > knowledge about how the pipelines are arranged in LLVM. As you 
> > > > > > > pointed out, the test here is to test if the specific pass is run 
> > > > > > > and gives expected results.
> > > > > > > 
> > > > > > > Thanks for the suggestion to break the Clang changes and LLVM 
> > > > > > > changes apart which would make the testing more specific. The 
> > > > > > > pipeline ordering could be tested with a LLVM test but that would 
> > > > > > > require a LLVM switch setup for UniqueLinkageNames and I'm not 
> > > > > > > sure there's a need for that switch except for testing.
> > > > > > > No, this test does not validate the pipeline change on the LLVM 
> > > > > > > side, since Clang shouldn't have knowledge about how the 
> > > > > > > pipelines are arranged in LLVM. 
> > > > > > 
> > > > > > "ish" - but Clang should have tests for changes to Clang, ideally. 
> > > > > > Usually they can simply be testing LLVM's IR output before it goes 
> > > > > > to LLVM for optimization/codegen - but for features that don't have 
> > > > > > this serialization boundary that makes testing and isolation 
> > > > > > clear/simple, it becomes a bit fuzzier.
> > > > > > 
> > > > > > In this case, there is a clang change - from adding the pass 
> > > > > > explicitly in Clang, to setting a parameter about how LLVM will add 
> > > > > > the pass, and it has an observable effect. One way to test this 
> > > > > > change while isolating the Clang test from further changes to the 
> > > > > > pipeline in LLVM, would be to test that the pass ends up somewhere 
> > > > > > in the LLVM-created part of the pass pipeline - the parts that you 
> > > > > > can't get to from the way the original pass addition was written in 
> > > > > > Clang. At least I assume that's the case/what motivated the change 
> > > > > > from adding it in Clang to adding it in LLVM?
> > > > > > 
> > > > > > eg: if LLVM always forms passes {x, y, z} and Clang is able to add 
> > > > > > passes before/after, say it always adds 'a' before and 'b' after, 
> > > > > > to make {a, x, y, z, b} - and this new pass u was previously added 
> > > > > > at the start to make {u, a, x, y, z, b} but now needs to go in {a, 
> > > > > > x, y, u, z, b} you could test that 'u' is after 'a' and before 'b', 
> > > > > > or between 'x' and 'z', etc. If there's some other more 
> > > > > > clear/simple/reliable marker of where the LLVM-created passes 
> > > > > > start/end in the structured dump, that'd be good to use as a 
> > > > > > landmark to make such a test more robust. If there's some 
> > > > > > meaningful pass that this pass always needs to go after - testing 
> > > > > > that might be OK, even if it's somewhat an implementation detail of 
> > > > > > LLVM - whatever's likely to make the test more legible and more 
> > > > > > reliable/resilient to unrelated changes would be good.
> > > > > > 
> > > > > > > As you pointed out, the test here is to test if the specific pass 
> > > > > > > is run and gives expected results.
> > > > > > 
> > > > > > If that's the case, this test could be committed standalone, before 
> > > > > > any of these other changes?
> > > > > > 
> > > > > > > The pipeline ordering could be tested with a LLVM test but that 
> > > > > > > would require a LLVM switch setup for Un

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names.cpp:48-49
 
+// LPIPELINE: Unique Internal Linkage Names
+// NPIPELINE: Running pass: UniqueInternalLinkageNamesPass
 // PLAIN: @_ZL4glob = internal global

aeubanks wrote:
> dblaikie wrote:
> > hoy wrote:
> > > aeubanks wrote:
> > > > hoy wrote:
> > > > > aeubanks wrote:
> > > > > > dblaikie wrote:
> > > > > > > hoy wrote:
> > > > > > > > dblaikie wrote:
> > > > > > > > > Does this test validate the new behavior? (ie: does this test 
> > > > > > > > > fail without the LLVM changes and pass with it) Not that it 
> > > > > > > > > necessarily has to - since Clang isn't here to test the LLVM 
> > > > > > > > > behavior - perhaps this test is sufficient in Clang to test 
> > > > > > > > > that the code in BackendUtil works to enable this pass.
> > > > > > > > > 
> > > > > > > > > This could possibly be staged as independent commits - adding 
> > > > > > > > > the LLVM functionality in one commit, which would be a no-op 
> > > > > > > > > for Clang because it wouldn't be setting 
> > > > > > > > > PTO.UniqueLinkageNames - then committing the Clang change 
> > > > > > > > > that would remove the custom pass addition and set 
> > > > > > > > > PTO.UniqueLinkageNames - and then it'd probably be reasonable 
> > > > > > > > > to have this test be made a bit more explicit (testing the 
> > > > > > > > > pass manager structure/order) to show that that Clang change 
> > > > > > > > > had an effect: Moving the pass to the desired location in the 
> > > > > > > > > pass pipeline.
> > > > > > > > This is a good question. No, this test does not validate the 
> > > > > > > > pipeline change on the LLVM side, since Clang shouldn't have 
> > > > > > > > knowledge about how the pipelines are arranged in LLVM. As you 
> > > > > > > > pointed out, the test here is to test if the specific pass is 
> > > > > > > > run and gives expected results.
> > > > > > > > 
> > > > > > > > Thanks for the suggestion to break the Clang changes and LLVM 
> > > > > > > > changes apart which would make the testing more specific. The 
> > > > > > > > pipeline ordering could be tested with a LLVM test but that 
> > > > > > > > would require a LLVM switch setup for UniqueLinkageNames and 
> > > > > > > > I'm not sure there's a need for that switch except for testing.
> > > > > > > > No, this test does not validate the pipeline change on the LLVM 
> > > > > > > > side, since Clang shouldn't have knowledge about how the 
> > > > > > > > pipelines are arranged in LLVM. 
> > > > > > > 
> > > > > > > "ish" - but Clang should have tests for changes to Clang, 
> > > > > > > ideally. Usually they can simply be testing LLVM's IR output 
> > > > > > > before it goes to LLVM for optimization/codegen - but for 
> > > > > > > features that don't have this serialization boundary that makes 
> > > > > > > testing and isolation clear/simple, it becomes a bit fuzzier.
> > > > > > > 
> > > > > > > In this case, there is a clang change - from adding the pass 
> > > > > > > explicitly in Clang, to setting a parameter about how LLVM will 
> > > > > > > add the pass, and it has an observable effect. One way to test 
> > > > > > > this change while isolating the Clang test from further changes 
> > > > > > > to the pipeline in LLVM, would be to test that the pass ends up 
> > > > > > > somewhere in the LLVM-created part of the pass pipeline - the 
> > > > > > > parts that you can't get to from the way the original pass 
> > > > > > > addition was written in Clang. At least I assume that's the 
> > > > > > > case/what motivated the change from adding it in Clang to adding 
> > > > > > > it in LLVM?
> > > > > > > 
> > > > > > > eg: if LLVM always forms passes {x, y, z} and Clang is able to 
> > > > > > > add passes before/after, say it always adds 'a' before and 'b' 
> > > > > > > after, to make {a, x, y, z, b} - and this new pass u was 
> > > > > > > previously added at the start to make {u, a, x, y, z, b} but now 
> > > > > > > needs to go in {a, x, y, u, z, b} you could test that 'u' is 
> > > > > > > after 'a' and before 'b', or between 'x' and 'z', etc. If there's 
> > > > > > > some other more clear/simple/reliable marker of where the 
> > > > > > > LLVM-created passes start/end in the structured dump, that'd be 
> > > > > > > good to use as a landmark to make such a test more robust. If 
> > > > > > > there's some meaningful pass that this pass always needs to go 
> > > > > > > after - testing that might be OK, even if it's somewhat an 
> > > > > > > implementation detail of LLVM - whatever's likely to make the 
> > > > > > > test more legible and more reliable/resilient to unrelated 
> > > > > > > changes would be good.
> > > > > > > 
> > > > > > > > As you pointed out, the test here is to test if the specific 
> > > > > > > > pass is run and gives expected results.
> > > > > > > 
> > > > > > > If that's the case, this test could be committ

[clang] 69132d1 - [Clang] Reverse test to save on indentation. NFC.

[Alexandre Ganea via cfe-commits]

Author: Alexandre Ganea
Date: 2020-12-23T19:24:53-05:00
New Revision: 69132d12deae749a8e4c9def5498ffa354ce1fa6

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

LOG: [Clang] Reverse test to save on indentation. NFC.

Added: 


Modified: 
clang/lib/CodeGen/CodeGenAction.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenAction.cpp 
b/clang/lib/CodeGen/CodeGenAction.cpp
index 5b23b6d2b7f5..778d4df3c2e9 100644
--- a/clang/lib/CodeGen/CodeGenAction.cpp
+++ b/clang/lib/CodeGen/CodeGenAction.cpp
@@ -1078,78 +1078,74 @@ CodeGenAction::loadModule(MemoryBufferRef MBRef) {
 }
 
 void CodeGenAction::ExecuteAction() {
-  // If this is an IR file, we have to treat it specially.
-  if (getCurrentFileKind().getLanguage() == Language::LLVM_IR) {
-BackendAction BA = static_cast(Act);
-CompilerInstance &CI = getCompilerInstance();
-auto &CodeGenOpts = CI.getCodeGenOpts();
-auto &Diagnostics = CI.getDiagnostics();
-std::unique_ptr OS =
-GetOutputStream(CI, getCurrentFile(), BA);
-if (BA != Backend_EmitNothing && !OS)
-  return;
-
-SourceManager &SM = CI.getSourceManager();
-FileID FID = SM.getMainFileID();
-Optional MainFile = SM.getBufferOrNone(FID);
-if (!MainFile)
-  return;
+  if (getCurrentFileKind().getLanguage() != Language::LLVM_IR) {
+this->ASTFrontendAction::ExecuteAction();
+return;
+  }
 
-TheModule = loadModule(*MainFile);
-if (!TheModule)
-  return;
+  // If this is an IR file, we have to treat it specially.
+  BackendAction BA = static_cast(Act);
+  CompilerInstance &CI = getCompilerInstance();
+  auto &CodeGenOpts = CI.getCodeGenOpts();
+  auto &Diagnostics = CI.getDiagnostics();
+  std::unique_ptr OS =
+  GetOutputStream(CI, getCurrentFile(), BA);
+  if (BA != Backend_EmitNothing && !OS)
+return;
 
-const TargetOptions &TargetOpts = CI.getTargetOpts();
-if (TheModule->getTargetTriple() != TargetOpts.Triple) {
-  Diagnostics.Report(SourceLocation(),
- diag::warn_fe_override_module)
-  << TargetOpts.Triple;
-  TheModule->setTargetTriple(TargetOpts.Triple);
-}
+  SourceManager &SM = CI.getSourceManager();
+  FileID FID = SM.getMainFileID();
+  Optional MainFile = SM.getBufferOrNone(FID);
+  if (!MainFile)
+return;
 
-EmbedBitcode(TheModule.get(), CodeGenOpts, *MainFile);
-
-LLVMContext &Ctx = TheModule->getContext();
-Ctx.setInlineAsmDiagnosticHandler(BitcodeInlineAsmDiagHandler,
-  &Diagnostics);
-
-// Set clang diagnostic handler. To do this we need to create a fake
-// BackendConsumer.
-BackendConsumer Result(BA, CI.getDiagnostics(), CI.getHeaderSearchOpts(),
-   CI.getPreprocessorOpts(), CI.getCodeGenOpts(),
-   CI.getTargetOpts(), CI.getLangOpts(),
-   std::move(LinkModules), *VMContext, nullptr);
-// PR44896: Force DiscardValueNames as false. DiscardValueNames cannot be
-// true here because the valued names are needed for reading textual IR.
-Ctx.setDiscardValueNames(false);
-Ctx.setDiagnosticHandler(
-std::make_unique(CodeGenOpts, &Result));
-
-Expected> OptRecordFileOrErr =
-setupLLVMOptimizationRemarks(
-Ctx, CodeGenOpts.OptRecordFile, CodeGenOpts.OptRecordPasses,
-CodeGenOpts.OptRecordFormat, CodeGenOpts.DiagnosticsWithHotness,
-CodeGenOpts.DiagnosticsHotnessThreshold);
-
-if (Error E = OptRecordFileOrErr.takeError()) {
-  reportOptRecordError(std::move(E), Diagnostics, CodeGenOpts);
-  return;
-}
-std::unique_ptr OptRecordFile =
-std::move(*OptRecordFileOrErr);
+  TheModule = loadModule(*MainFile);
+  if (!TheModule)
+return;
 
-EmitBackendOutput(Diagnostics, CI.getHeaderSearchOpts(), CodeGenOpts,
-  TargetOpts, CI.getLangOpts(),
-  CI.getTarget().getDataLayout(), TheModule.get(), BA,
-  std::move(OS));
+  const TargetOptions &TargetOpts = CI.getTargetOpts();
+  if (TheModule->getTargetTriple() != TargetOpts.Triple) {
+Diagnostics.Report(SourceLocation(), diag::warn_fe_override_module)
+<< TargetOpts.Triple;
+TheModule->setTargetTriple(TargetOpts.Triple);
+  }
 
-if (OptRecordFile)
-  OptRecordFile->keep();
+  EmbedBitcode(TheModule.get(), CodeGenOpts, *MainFile);
+
+  LLVMContext &Ctx = TheModule->getContext();
+  Ctx.setInlineAsmDiagnosticHandler(BitcodeInlineAsmDiagHandler, &Diagnostics);
+
+  // Set clang diagnostic handler. To do this we need to create a fake
+  // BackendConsumer.
+  BackendConsumer Result(BA, CI.getDiagnostics(), CI.getHeaderSearchOpts(),
+ CI.getPreprocessorOpt

[PATCH] D93785: [OpenMP][FIX] Ensure the isa trait is evaluated last

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert created this revision.
jdoerfert added reviewers: tianshilei1992, jhuber6, JonChesterfield.
Herald added subscribers: guansong, bollu, yaxunl.
jdoerfert requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, sstefan1.
Herald added projects: clang, LLVM.

Since isa can cause diagnostics we want it to be evaluated last to avoid
the "unknown isa" warning if the rest of the selector wouldn't match
anyway. That allows us to guard isa with arch properly.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93785

Files:
  clang/test/OpenMP/begin_declare_variant_messages.c
  clang/test/OpenMP/declare_variant_messages.c
  clang/test/OpenMP/declare_variant_messages.cpp
  clang/test/OpenMP/nvptx_declare_variant_name_mangling.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def

Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -1017,14 +1017,6 @@
 __OMP_TRAIT_PROPERTY(device, kind, fpga)
 __OMP_TRAIT_PROPERTY(device, kind, any)
 
-__OMP_TRAIT_SELECTOR(device, isa, true)
-
-// We use "__ANY" as a placeholder in the isa property to denote the
-// conceptual "any", not the literal `any` used in kind. The string we
-// we use is not important except that it will show up in diagnostics.
-OMP_TRAIT_PROPERTY(device_isa___ANY, device, device_isa,
-   "")
-
 __OMP_TRAIT_SELECTOR(device, arch, true)
 
 __OMP_TRAIT_PROPERTY(device, arch, arm)
@@ -1073,6 +1065,18 @@
 __OMP_TRAIT_PROPERTY(user, condition, false)
 __OMP_TRAIT_PROPERTY(user, condition, unknown)
 
+
+// Note that we put isa last so that the other conditions are checked first.
+// This allows us to issue warnings wrt. isa only if we match otherwise.
+__OMP_TRAIT_SELECTOR(device, isa, true)
+
+// We use "__ANY" as a placeholder in the isa property to denote the
+// conceptual "any", not the literal `any` used in kind. The string we
+// we use is not important except that it will show up in diagnostics.
+OMP_TRAIT_PROPERTY(device_isa___ANY, device, device_isa,
+   "")
+
+
 #undef OMP_TRAIT_SET
 #undef __OMP_TRAIT_SET
 ///}
Index: clang/test/OpenMP/nvptx_declare_variant_name_mangling.cpp
===
--- clang/test/OpenMP/nvptx_declare_variant_name_mangling.cpp
+++ clang/test/OpenMP/nvptx_declare_variant_name_mangling.cpp
@@ -6,10 +6,10 @@
 
 // CHECK-DAG: @_Z3barv
 // CHECK-DAG: @_Z3bazv
-// CHECK-DAG: @"_Z54bar$ompvariant$S2$s8$Pnvptx$Pnvptx64$S3$s10$Pmatch_anyv"
-// CHECK-DAG: @"_Z54baz$ompvariant$S2$s8$Pnvptx$Pnvptx64$S3$s10$Pmatch_anyv"
-// CHECK-DAG: call i32 @"_Z54bar$ompvariant$S2$s8$Pnvptx$Pnvptx64$S3$s10$Pmatch_anyv"()
-// CHECK-DAG: call i32 @"_Z54baz$ompvariant$S2$s8$Pnvptx$Pnvptx64$S3$s10$Pmatch_anyv"()
+// CHECK-DAG: @"_Z53bar$ompvariant$S2$s7$Pnvptx$Pnvptx64$S3$s9$Pmatch_anyv"
+// CHECK-DAG: @"_Z53baz$ompvariant$S2$s7$Pnvptx$Pnvptx64$S3$s9$Pmatch_anyv"
+// CHECK-DAG: call i32 @"_Z53bar$ompvariant$S2$s7$Pnvptx$Pnvptx64$S3$s9$Pmatch_anyv"()
+// CHECK-DAG: call i32 @"_Z53baz$ompvariant$S2$s7$Pnvptx$Pnvptx64$S3$s9$Pmatch_anyv"()
 
 #ifndef HEADER
 #define HEADER
@@ -38,4 +38,4 @@
   return res;
 }
 
-#endif
\ No newline at end of file
+#endif
Index: clang/test/OpenMP/declare_variant_messages.cpp
===
--- clang/test/OpenMP/declare_variant_messages.cpp
+++ clang/test/OpenMP/declare_variant_messages.cpp
@@ -39,7 +39,7 @@
 #pragma omp declare variant(foofoo ) match(implementation={vendor(score(foofoo ()) ibm)}) // expected-warning {{expected '':'' after the score expression; '':'' assumed}} expected-warning {{score expressions in the OpenMP context selector need to be constant; foofoo() is not and will be ignored}}
 #pragma omp declare variant(foofoo ) match(implementation={vendor(score(5): ibm), vendor(llvm)}) // expected-warning {{the context selector 'vendor' was used already in the same 'omp declare variant' directive; selector ignored}} expected-note {{the previous context selector 'vendor' used here}} expected-note {{the ignored selector spans until here}}
 #pragma omp declare variant(foofoo ) match(implementation={vendor(score(5): ibm), kind(cpu)}) // expected-warning {{the context selector 'kind' is not valid for the context set 'implementation'; selector ignored}} expected-note {{the context selector 'kind' can be nested in the context set 'device'; try 'match(device={kind(property)})'}} expected-note {{the ignored selector spans until here}}
-#pragma omp declare variant(foofoo ) match(device={xxx}) // expected-warning {{'xxx' is not a valid context selector for the context set 'device'; selector ignored}} expected-note {{context selector options are: 'kind' 'isa' 'arch'}} expected-note {{the ignored selector spans until here}}
+#pragma omp declare variant(foofoo ) match(devic

[PATCH] D93786: [OpenMP][Fix] Make the arch selector for x86_64 work

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert created this revision.
jdoerfert added reviewers: tianshilei1992, jhuber6, JonChesterfield.
Herald added subscribers: pengfei, guansong, bollu, hiraditya, yaxunl.
jdoerfert requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, sstefan1.
Herald added projects: clang, LLVM.

The triple uses a bar "x86-64" instead of an underscore. Since we
have troubles accepting x86-64 as an identifier, we stick with
x86_64 in the frontend and translate it explicitly.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93786

Files:
  clang/test/OpenMP/declare_variant_ast_x86_64.c
  llvm/lib/Frontend/OpenMP/OMPContext.cpp


Index: llvm/lib/Frontend/OpenMP/OMPContext.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPContext.cpp
+++ llvm/lib/Frontend/OpenMP/OMPContext.cpp
@@ -14,7 +14,9 @@
 
 #include "llvm/Frontend/OpenMP/OMPContext.h"
 #include "llvm/ADT/SetOperations.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSwitch.h"
+#include "llvm/ADT/Triple.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Support/raw_ostream.h"
 
@@ -57,9 +59,12 @@
 
   // Add the appropriate device architecture trait based on the triple.
 #define OMP_TRAIT_PROPERTY(Enum, TraitSetEnum, TraitSelectorEnum, Str) 
\
-  if (TraitSelector::TraitSelectorEnum == TraitSelector::device_arch)  
\
+  if (TraitSelector::TraitSelectorEnum == TraitSelector::device_arch) {
\
 if (TargetTriple.getArch() == TargetTriple.getArchTypeForLLVMName(Str))
\
-  ActiveTraits.set(unsigned(TraitProperty::Enum));
+  ActiveTraits.set(unsigned(TraitProperty::Enum)); 
\
+if (Str == "x86_64" && TargetTriple.getArch() == Triple::x86_64)   
\
+  ActiveTraits.set(unsigned(TraitProperty::Enum)); 
\
+  }
 #include "llvm/Frontend/OpenMP/OMPKinds.def"
 
   // TODO: What exactly do we want to see as device ISA trait?
Index: clang/test/OpenMP/declare_variant_ast_x86_64.c
===
--- /dev/null
+++ clang/test/OpenMP/declare_variant_ast_x86_64.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -verify -fopenmp -triple x86_64-unknown-unknown %s 
-ast-dump | FileCheck %s
+// expected-no-diagnostics
+
+#pragma omp begin declare variant match(device={arch(x86_64)})
+
+void bar() {}
+
+// CHECK: FunctionDecl {{.*}} bar[device={arch(x86_64)}] 'void ()'
+
+#pragma omp end declare variant


Index: llvm/lib/Frontend/OpenMP/OMPContext.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPContext.cpp
+++ llvm/lib/Frontend/OpenMP/OMPContext.cpp
@@ -14,7 +14,9 @@
 
 #include "llvm/Frontend/OpenMP/OMPContext.h"
 #include "llvm/ADT/SetOperations.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSwitch.h"
+#include "llvm/ADT/Triple.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Support/raw_ostream.h"
 
@@ -57,9 +59,12 @@
 
   // Add the appropriate device architecture trait based on the triple.
 #define OMP_TRAIT_PROPERTY(Enum, TraitSetEnum, TraitSelectorEnum, Str) \
-  if (TraitSelector::TraitSelectorEnum == TraitSelector::device_arch)  \
+  if (TraitSelector::TraitSelectorEnum == TraitSelector::device_arch) {\
 if (TargetTriple.getArch() == TargetTriple.getArchTypeForLLVMName(Str))\
-  ActiveTraits.set(unsigned(TraitProperty::Enum));
+  ActiveTraits.set(unsigned(TraitProperty::Enum)); \
+if (Str == "x86_64" && TargetTriple.getArch() == Triple::x86_64)   \
+  ActiveTraits.set(unsigned(TraitProperty::Enum)); \
+  }
 #include "llvm/Frontend/OpenMP/OMPKinds.def"
 
   // TODO: What exactly do we want to see as device ISA trait?
Index: clang/test/OpenMP/declare_variant_ast_x86_64.c
===
--- /dev/null
+++ clang/test/OpenMP/declare_variant_ast_x86_64.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -verify -fopenmp -triple x86_64-unknown-unknown %s -ast-dump | FileCheck %s
+// expected-no-diagnostics
+
+#pragma omp begin declare variant match(device={arch(x86_64)})
+
+void bar() {}
+
+// CHECK: FunctionDecl {{.*}} bar[device={arch(x86_64)}] 'void ()'
+
+#pragma omp end declare variant
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[Hongtao Yu via Phabricator via cfe-commits]

hoy added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names.cpp:48-49
 
+// LPIPELINE: Unique Internal Linkage Names
+// NPIPELINE: Running pass: UniqueInternalLinkageNamesPass
 // PLAIN: @_ZL4glob = internal global

dblaikie wrote:
> aeubanks wrote:
> > dblaikie wrote:
> > > hoy wrote:
> > > > aeubanks wrote:
> > > > > hoy wrote:
> > > > > > aeubanks wrote:
> > > > > > > dblaikie wrote:
> > > > > > > > hoy wrote:
> > > > > > > > > dblaikie wrote:
> > > > > > > > > > Does this test validate the new behavior? (ie: does this 
> > > > > > > > > > test fail without the LLVM changes and pass with it) Not 
> > > > > > > > > > that it necessarily has to - since Clang isn't here to test 
> > > > > > > > > > the LLVM behavior - perhaps this test is sufficient in 
> > > > > > > > > > Clang to test that the code in BackendUtil works to enable 
> > > > > > > > > > this pass.
> > > > > > > > > > 
> > > > > > > > > > This could possibly be staged as independent commits - 
> > > > > > > > > > adding the LLVM functionality in one commit, which would be 
> > > > > > > > > > a no-op for Clang because it wouldn't be setting 
> > > > > > > > > > PTO.UniqueLinkageNames - then committing the Clang change 
> > > > > > > > > > that would remove the custom pass addition and set 
> > > > > > > > > > PTO.UniqueLinkageNames - and then it'd probably be 
> > > > > > > > > > reasonable to have this test be made a bit more explicit 
> > > > > > > > > > (testing the pass manager structure/order) to show that 
> > > > > > > > > > that Clang change had an effect: Moving the pass to the 
> > > > > > > > > > desired location in the pass pipeline.
> > > > > > > > > This is a good question. No, this test does not validate the 
> > > > > > > > > pipeline change on the LLVM side, since Clang shouldn't have 
> > > > > > > > > knowledge about how the pipelines are arranged in LLVM. As 
> > > > > > > > > you pointed out, the test here is to test if the specific 
> > > > > > > > > pass is run and gives expected results.
> > > > > > > > > 
> > > > > > > > > Thanks for the suggestion to break the Clang changes and LLVM 
> > > > > > > > > changes apart which would make the testing more specific. The 
> > > > > > > > > pipeline ordering could be tested with a LLVM test but that 
> > > > > > > > > would require a LLVM switch setup for UniqueLinkageNames and 
> > > > > > > > > I'm not sure there's a need for that switch except for 
> > > > > > > > > testing.
> > > > > > > > > No, this test does not validate the pipeline change on the 
> > > > > > > > > LLVM side, since Clang shouldn't have knowledge about how the 
> > > > > > > > > pipelines are arranged in LLVM. 
> > > > > > > > 
> > > > > > > > "ish" - but Clang should have tests for changes to Clang, 
> > > > > > > > ideally. Usually they can simply be testing LLVM's IR output 
> > > > > > > > before it goes to LLVM for optimization/codegen - but for 
> > > > > > > > features that don't have this serialization boundary that makes 
> > > > > > > > testing and isolation clear/simple, it becomes a bit fuzzier.
> > > > > > > > 
> > > > > > > > In this case, there is a clang change - from adding the pass 
> > > > > > > > explicitly in Clang, to setting a parameter about how LLVM will 
> > > > > > > > add the pass, and it has an observable effect. One way to test 
> > > > > > > > this change while isolating the Clang test from further changes 
> > > > > > > > to the pipeline in LLVM, would be to test that the pass ends up 
> > > > > > > > somewhere in the LLVM-created part of the pass pipeline - the 
> > > > > > > > parts that you can't get to from the way the original pass 
> > > > > > > > addition was written in Clang. At least I assume that's the 
> > > > > > > > case/what motivated the change from adding it in Clang to 
> > > > > > > > adding it in LLVM?
> > > > > > > > 
> > > > > > > > eg: if LLVM always forms passes {x, y, z} and Clang is able to 
> > > > > > > > add passes before/after, say it always adds 'a' before and 'b' 
> > > > > > > > after, to make {a, x, y, z, b} - and this new pass u was 
> > > > > > > > previously added at the start to make {u, a, x, y, z, b} but 
> > > > > > > > now needs to go in {a, x, y, u, z, b} you could test that 'u' 
> > > > > > > > is after 'a' and before 'b', or between 'x' and 'z', etc. If 
> > > > > > > > there's some other more clear/simple/reliable marker of where 
> > > > > > > > the LLVM-created passes start/end in the structured dump, 
> > > > > > > > that'd be good to use as a landmark to make such a test more 
> > > > > > > > robust. If there's some meaningful pass that this pass always 
> > > > > > > > needs to go after - testing that might be OK, even if it's 
> > > > > > > > somewhat an implementation detail of LLVM - whatever's likely 
> > > > > > > > to make the test more legible and more reliable/resilient to 
> > > > > > > > unrelated changes would be good.
> > > > > > > > 
> > > > > > > 

[PATCH] D93786: [OpenMP][Fix] Make the arch selector for x86_64 work

[Shilei Tian via Phabricator via cfe-commits]

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

Is it because the triple is separated by `-`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93786

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

[PATCH] D93656: Moving UniqueInternalLinkageNamesPass to the start of IR pipelines.

[Hongtao Yu via Phabricator via cfe-commits]

hoy updated this revision to Diff 313630.
hoy added a comment.

Adding PTO checks in LLVM test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93656

Files:
  llvm/include/llvm/Passes/PassBuilder.h
  llvm/lib/Passes/PassBuilder.cpp
  llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
  llvm/tools/opt/NewPMDriver.cpp

Index: llvm/tools/opt/NewPMDriver.cpp
===
--- llvm/tools/opt/NewPMDriver.cpp
+++ llvm/tools/opt/NewPMDriver.cpp
@@ -133,6 +133,13 @@
 static cl::opt DebugInfoForProfiling(
 "new-pm-debug-info-for-profiling", cl::init(false), cl::Hidden,
 cl::desc("Emit special debug info to enable PGO profile generation."));
+static cl::opt PseudoProbeForProfiling(
+"new-pm-pseudo-probe-for-profiling", cl::init(false), cl::Hidden,
+cl::desc("Emit pseudo probes to enable PGO profile generation."));
+static cl::opt UniqueInternalLinkageNames(
+"new-pm-unique-internal-linkage-names", cl::init(false), cl::Hidden,
+cl::desc("Uniqueify Internal Linkage Symbol Names by appending the MD5 "
+ "hash of the module path."));
 /// @}}
 
 template 
@@ -246,6 +253,9 @@
 if (DebugInfoForProfiling)
   P = PGOOptions("", "", "", PGOOptions::NoAction, PGOOptions::NoCSAction,
  true);
+else if (PseudoProbeForProfiling)
+  P = PGOOptions("", "", "", PGOOptions::NoAction, PGOOptions::NoCSAction,
+ false, true);
 else
   P = None;
   }
@@ -281,6 +291,7 @@
   // option has been enabled.
   PTO.LoopUnrolling = !DisableLoopUnrolling;
   PTO.Coroutines = Coroutines;
+  PTO.UniqueLinkageNames = UniqueInternalLinkageNames;
   PassBuilder PB(DebugPM, TM, PTO, P, &PIC);
   registerEPCallbacks(PB);
 
Index: llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
===
--- /dev/null
+++ llvm/test/Transforms/UniqueLinkageNames/unique-internal-linkage-names.ll
@@ -0,0 +1,50 @@
+; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O0 --check-prefix=UNIQUE
+; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes='default' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+; RUN: opt -S -passes='thinlto-pre-link' -new-pm-pseudo-probe-for-profiling -new-pm-unique-internal-linkage-names -debug-pass-manager < %s 2>&1 | FileCheck %s --check-prefix=O2 --check-prefix=UNIQUE
+
+define internal i32 @foo() !dbg !15 {
+entry:
+  ret i32 0, !dbg !18
+}
+
+define dso_local i32 (...)* @bar() !dbg !7 {
+entry:
+  ret i32 (...)* bitcast (i32 ()* @foo to i32 (...)*), !dbg !14
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, enums: !2)
+!1 = !DIFile(filename: "test.c", directory: "")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 4}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!7 = distinct !DISubprogram(name: "bar", scope: !1, file: !1, line: 9, type: !8, scopeLine: 9, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!8 = !DISubroutineType(types: !9)
+!9 = !{!10}
+!10 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 64)
+!11 = !DISubroutineType(types: !12)
+!12 = !{!13, null}
+!13 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!14 = !DILocation(line: 10, column: 3, scope: !7)
+!15 = distinct !DISubprogram(name: "foo", scope: !1, file: !1, line: 5, type: !16, scopeLine: 5, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!16 = !DISubroutineType(types: !17)
+!17 = !{!13}
+!18 = !DILocation(line: 6, column: 3, scope: !15)
+
+; O0: Running pass: VerifierPass
+; O0: Running analysis: VerifierAnalysis
+; O0: Running pass: UniqueInternalLinkageNamesPass
+; O0: Invalidating analysis: VerifierAnalysis
+
+; O2: Running pass: ForceFunctionAttrsPass
+; O2: Running pass: UniqueInternalLinkageNamesPass
+; O2: Invalidating analysis: VerifierAnalysis
+; O2: Running pass: SampleProfileProbePass
+
+; UNIQUE: define internal i32 @foo.__uniq.{{[0-9a-f]+}}()
+; UNIQUE: ret {{.*}} @foo.__uniq.{{[0-9a-f]+}} {{.*}}
Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cp

[PATCH] D93787: [analyzer] Fix crash caused by accessing empty map

[Vince Bridgers via Phabricator via cfe-commits]

vabridgers created this revision.
vabridgers added a reviewer: Szelethus.
Herald added subscribers: steakhal, ASDenysPetrov, martong, Charusso, dkrupp, 
donat.nagy, mikhail.ramalho, a.sidorin, szepet, baloghadamsoftware, xazax.hun, 
whisperity.
vabridgers requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This change attempts to address
https://bugs.llvm.org/show_bug.cgi?id=48588.

In certain cases, it appears that __VA_ARGS__ is not in PrevParamMap
before it's accessed using at(). This change simply skips injectRange()
if __VA_ARGS__ is not found in PrevParamMap.

The crash seen is described below, the case this was discovered in was
distilled into a reproducer inserted into the LIT tests for this module.

terminate called after throwing an instance of 'std::out_of_range'

  what():  map::at
  
  #0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
  /llvm/lib/Support/Unix/Signals.inc:563:22

...

#11 std::__throw_out_of_range(char const*)

  /libstdc++-v3/src/c++11/functexcept.cc:82:5

#12 std::map, std::less, std::allocator > > >::at(clang::IdentifierInfo
const* const&) const
  /gcc/9.3.0/include/c++/9.3.0/bits/stl_map.h:549:10

#13 getMacroExpansionInfo((anonymous namespace)::MacroParamMap const&,

clang::SourceLocation, clang::Preprocessor const&)
  /clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:1242:66

...


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93787

Files:
  clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  
clang/test/Analysis/Inputs/expected-plists/plist-macros-with-expansion.cpp.plist
  clang/test/Analysis/plist-macros-with-expansion.cpp

Index: clang/test/Analysis/plist-macros-with-expansion.cpp
===
--- clang/test/Analysis/plist-macros-with-expansion.cpp
+++ clang/test/Analysis/plist-macros-with-expansion.cpp
@@ -543,3 +543,23 @@
 
 // CHECK: nameBZ44493_GNUVA
 // CHECK-NEXT: expansion--(a);
+
+// Expected warning, and don't crash
+const char *traceid(const char *);
+int trace(int, const char *, int, ...);
+#define TRACE_CALL(tracelevel, ...) \
+  { __VA_ARGS__; }
+
+#define TRACE(tracelevel, str, ...) \
+  TRACE_CALL((tracelevel), trace((0), traceid("formatstr " str), 0, tracelevel, __VA_ARGS__))
+
+#define TRACE_WRAPPER TRACE
+
+void funcXXX(
+void *Context_p) {
+  int localvar;
+  TRACE_WRAPPER(
+  localvar,
+  "localvar=%u ",
+  0); // expected-warning{{4th function call argument is an uninitialized value}}
+}
Index: clang/test/Analysis/Inputs/expected-plists/plist-macros-with-expansion.cpp.plist
===
--- clang/test/Analysis/Inputs/expected-plists/plist-macros-with-expansion.cpp.plist
+++ clang/test/Analysis/Inputs/expected-plists/plist-macros-with-expansion.cpp.plist
@@ -6923,6 +6923,142 @@

   
   
+  
+   path
+   
+
+ kindevent
+ location
+ 
+  line560
+  col3
+  file0
+ 
+ ranges
+ 
+   
+
+ line560
+ col3
+ file0
+
+
+ line560
+ col14
+ file0
+
+   
+ 
+ depth0
+ extended_message
+ 'localvar' declared without an initial value
+ message
+ 'localvar' declared without an initial value
+
+
+ kindcontrol
+ edges
+  
+   
+start
+ 
+  
+   line560
+   col3
+   file0
+  
+  
+   line560
+   col5
+   file0
+  
+ 
+end
+ 
+  
+   line561
+   col3
+   file0
+  
+  
+   line561
+   col15
+   file0
+  
+ 
+   
+  
+
+
+ kindevent
+ location
+ 
+  line561
+  col3
+  file0
+ 
+ ranges
+ 
+   
+
+ line561
+ col3
+ file0
+
+
+ line564
+ col12
+ file0
+
+   
+ 
+ depth0
+ extended_message
+ 4th function call argument is an uninitialized value
+ message
+ 4th function call argument is an uninitialized value
+
+   
+   macro_expansions
+   
+
+ location
+ 
+  line561
+  col3
+  file0
+ 
+ nameTRACE_WRAPPER
+ expansion{ trace((0), traceid("formatstr " str), 0, tracelevel,); }
+
+   
+   description4th function call argument is an uninitialized value
+   categoryLogic error
+   typeUninitialized argument value
+   check_namecore.CallAndMessage
+   
+   issue_hash_content_of_line_in_context7b4de363511977d731e5dfab4fd89c66
+  issue_context_kindfunction
+  issue_contextfuncXXX
+  issue_hash_function_offset2
+  location
+  
+   line561
+   col3
+   file0
+  
+  ExecutedLines
+  
+   0
+   
+557
+558
+559
+560
+561
+   
+  
+  
  
  files
  
Index: clang/lib/St