[PATCH] D88665: [ASTImporter][AST] Fix structural equivalency crash on dependent FieldDecl

[Raphael Isemann via Phabricator via cfe-commits]

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

Shouldn't this compare the actual width expressions? In other words, this patch 
wouldn't pass the test below:

  TEST_F(StructuralEquivalenceTemplateTest, DependentFieldDeclDifferentVal) {
const char *Code1 = "template  class foo { int a : 
sizeof(A); };";
const char *Code2 = "template  class foo { int a : 
sizeof(B); };";
auto t = makeNamedDecls(Code1, Code2, Lang_CXX03);
EXPECT_FALSE(testStructuralMatch(t));
  }

I don't want to derail the simple crash fix here, but I'm tempted to say that 
we might as well just simplify all this to `return 
IsStructurallyEquivalent(Context, Field1->getBitWidth(), 
Field2->getBitWidth());`. The nice diagnostic could live behind behind a check 
that ensures that both widths are not value-dependent.

If you want to keep this simple because you want to backport it I would also be 
fine with the current patch (not crashing is clearly an improvement)

In D88665#2307562 , @shafik wrote:

> So was the bug we were saying there were falsely equivalent or falsely not 
> equivalent?

I think the bug is the crash :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88665

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

[PATCH] D88634: [clangd] Extend the rename API.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 295747.
hokein marked 6 inline comments as done.
hokein added a comment.

address review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88634

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/test/rename.test
  clang-tools-extra/clangd/unittests/RenameTests.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.h

Index: clang-tools-extra/clangd/unittests/SyncAPI.h
===
--- clang-tools-extra/clangd/unittests/SyncAPI.h
+++ clang-tools-extra/clangd/unittests/SyncAPI.h
@@ -40,9 +40,13 @@
 llvm::Expected>
 runFindDocumentHighlights(ClangdServer &Server, PathRef File, Position Pos);
 
-llvm::Expected runRename(ClangdServer &Server, PathRef File,
-Position Pos, StringRef NewName,
-const clangd::RenameOptions &RenameOpts);
+llvm::Expected runRename(ClangdServer &Server, PathRef File,
+   Position Pos, StringRef NewName,
+   const clangd::RenameOptions &RenameOpts);
+
+llvm::Expected
+runPrepareRename(ClangdServer &Server, PathRef File, Position Pos,
+ const clangd::RenameOptions &RenameOpts);
 
 llvm::Expected
 runFormatFile(ClangdServer &Server, PathRef File, StringRef Code);
Index: clang-tools-extra/clangd/unittests/SyncAPI.cpp
===
--- clang-tools-extra/clangd/unittests/SyncAPI.cpp
+++ clang-tools-extra/clangd/unittests/SyncAPI.cpp
@@ -97,14 +97,22 @@
   return std::move(*Result);
 }
 
-llvm::Expected runRename(ClangdServer &Server, PathRef File,
-Position Pos, llvm::StringRef NewName,
-const RenameOptions &RenameOpts) {
-  llvm::Optional> Result;
+llvm::Expected runRename(ClangdServer &Server, PathRef File,
+   Position Pos, llvm::StringRef NewName,
+   const RenameOptions &RenameOpts) {
+  llvm::Optional> Result;
   Server.rename(File, Pos, NewName, RenameOpts, capture(Result));
   return std::move(*Result);
 }
 
+llvm::Expected runPrepareRename(ClangdServer &Server,
+  PathRef File, Position Pos,
+  const RenameOptions &RenameOpts) {
+  llvm::Optional> Result;
+  Server.prepareRename(File, Pos, RenameOpts, capture(Result));
+  return std::move(*Result);
+}
+
 llvm::Expected
 runFormatFile(ClangdServer &Server, PathRef File, StringRef Code) {
   llvm::Optional> Result;
Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -502,8 +502,8 @@
   auto RenameResult =
   rename({RenamePos, NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
+  ASSERT_EQ(1u, RenameResult->Edits.size());
+  EXPECT_EQ(applyEdits(std::move(RenameResult->Edits)).front().second,
 expectedResult(Code, NewName));
 }
   }
@@ -653,8 +653,8 @@
 } else {
   EXPECT_TRUE(bool(Results)) << "rename returned an error: "
  << llvm::toString(Results.takeError());
-  ASSERT_EQ(1u, Results->size());
-  EXPECT_EQ(applyEdits(std::move(*Results)).front().second,
+  ASSERT_EQ(1u, Results->Edits.size());
+  EXPECT_EQ(applyEdits(std::move(Results->Edits)).front().second,
 expectedResult(T, NewName));
 }
   }
@@ -683,8 +683,8 @@
   auto RenameResult =
   rename({Code.point(), NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError() << Code.point();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
+  ASSERT_EQ(1u, RenameResult->Edits.size());
+  EXPECT_EQ(applyEdits(std::move(RenameResult->Edits)).front().second,
 expectedResult(Code, NewName));
 }
 
@@ -703,6 +703,43 @@
   testing::HasSubstr("not a supported kind"));
 }
 
+TEST(RenameTest, PrepareRename) {
+  Annotations FooH("void func();");
+  Annotations FooCC(R"cpp(
+#include "foo.h"
+void [[fu^nc]]() {}
+  )cpp");
+  std::string FooHPath = testPath("foo.h");
+  std::string FooCCPath

[clang-tools-extra] bc18d8d - [clangd] Drop dependence on standard library in check.test

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2020-10-02T09:53:06+02:00
New Revision: bc18d8d9b705d31a94c51900c8b18e4feaf9c7fb

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

LOG: [clangd] Drop dependence on standard library in check.test

Added: 


Modified: 
clang-tools-extra/clangd/test/check.test

Removed: 




diff  --git a/clang-tools-extra/clangd/test/check.test 
b/clang-tools-extra/clangd/test/check.test
index 832629ce29ef..d83562c4dcf0 100644
--- a/clang-tools-extra/clangd/test/check.test
+++ b/clang-tools-extra/clangd/test/check.test
@@ -1,13 +1,18 @@
-# RUN: clangd -log=verbose -check 2>&1 | FileCheck -strict-whitespace %s
+// RUN: cp %s %t.cpp
+// RUN: clangd -log=verbose -check=%t.cpp 2>&1 | FileCheck -strict-whitespace 
%s
 
-CHECK: Testing on source file {{.*}}test.cc
-CHECK: internal (cc1) args are: -cc1
-CHECK: Building preamble...
-CHECK: Built preamble
-CHECK: Building AST...
-CHECK: Testing features at each token
-CHECK-DAG: hover: false
-CHECK-DAG: hover: true
-CHECK-DAG: tweak: AddUsing
-CHECK: All checks completed, 0 errors
+// CHECK: Testing on source file
+// CHECK: internal (cc1) args are: -cc1
+// CHECK: Building preamble...
+// CHECK: Built preamble
+// CHECK: Building AST...
+// CHECK: Testing features at each token
+// CHECK-DAG: tweak: ExpandAuto
+// CHECK-DAG: hover: true
+// CHECK-DAG: tweak: AddUsing
+// CHECK: All checks completed, 0 errors
 
+namespace ns {
+struct Foo {};
+} // namespace ns
+auto f = ns::Foo();



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

[PATCH] D88634: [clangd] Extend the rename API.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/ClangdServer.cpp:416
+auto Results = clangd::rename(
+{Pos, "dummy", InpAST->AST, File,
+ RenameOpts.AllowCrossFile ? &EmptyIndex : Index, RenameOpts});

sammccall wrote:
> we're now returning the "dummy" string to the caller, so we should document 
> it somewhere (or ideally just make it the empty string and document that)
make it empty string, and added document.



Comment at: clang-tools-extra/clangd/refactor/Rename.h:61
+  Range R;
+  FileEdits Edits;
+};

sammccall wrote:
> It's slightly awkward to have the half-populated state (may or may not 
> contain cross-file results, can't tell without the query).
> 
> I'd consider redundantly including `Edit LocalChanges` and `FileEdits 
> GlobalChanges` with the former always set and the latter empty when returned 
> from preparerename.
> It's slightly awkward to have the half-populated state (may or may not 
> contain cross-file results, can't tell without the query).

I feel this is not too bad, the query is quite trivial, just `Edits.size() > 1`.

> I'd consider redundantly including Edit LocalChanges and FileEdits 
> GlobalChanges with the former always set and the latter empty when returned 
> from preparerename.

This change seems nice to get changes for main-file, but I think 
`GlobalChanges` should include LocalChanges (otherwise, client side needs to 
combine these two when applying the final rename edits)? then we can't leave 
the later empty while keeping the former set.

Happy to do the change, but it looks like we don't have usage of `LocalChanges` 
so far. In prepareRename, we want main-file occurrences, `rename` will always 
return them regardless of single-file or cross-file rename, so I think `Edits` 
is efficient. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88634

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

[PATCH] D88338: [clangd] clangd --check: standalone diagnosis of common problems

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

Sorry @rsmith @hoy, I've replaced the test with one without such dependencies 
in bc18d8d9b705d31a94c51900c8b18e4feaf9c7fb 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88338

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

[PATCH] D85528: [analyzer] Fix cast evaluation on scoped enums in ExprEngine

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

steakhal added a comment.

In D85528#2307785 , @NoQ wrote:

> Aha, ok, thanks, I now understand what the problem is because I was able to 
> run the test before the patch and see how the patch changes the behavior.
>
> What do you think about flattening the enum type out entirely? I.e., instead 
> of `(unsigned char) conj_$2{enum ScopedSugared}` have `conj_$2{unsigned 
> char}` from the start. Possibly same for unscoped enums. I don't think we 
> actually extract any value from knowing that a symbol is an enum value. We 
> also don't track enum types for concrete values (i.e., `nonloc::ConcreteInt` 
> doesn't know whether it belongs to an enum).

That's a great idea. It should work. I will investigate this direction.

---

By the same token - being cheap on modeling explicit casts - I have seen other 
cases where we do not represent casts explicitly. Just like in this example, at 
the inner-most if branch we will simply assume that `a == b` instead of 
`(uchar)a == b`.

  void should_warn_twice(int a, unsigned char b) {
// Consider this interpretation: {a: -250, b: 6}
// It should satisfy both branches since (unsigned char)-250 == 6.
if (a < -200) {
  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
  if ((unsigned char)a == b) {
clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}, no 
report shown WITH refutation
  }
}
  }

Refutation does not cooperate well with our constraint manager if we don't emit 
the symbolic casts in the Z3 model. And we won't since we store constraints 
without casts.
Without this cast, Z3 will find the constraints of the second bugreport to be 
//unsatisfiable//, thus invalidating a true-positive bugreport.

To come around this problem, I would suggest to evaluate any casts as-is in the 
analyzed source code and make sure that we can recognize and reuse the 
constraints on any form of a symbol.
We might be able to do that by extending the Equivalence class of the 
constraint map with the notion of casts of:

- which do **not change** the castee's value range (eg. `int -> long`, 
`unsigned char -> unsigned long`)
- which do **change** the value range (eg. `int -> signed char`, `int -> 
unsigned int`)

I might will raise this on cfe-dev - that's probably a better place to discuss 
such ideas.




Comment at: clang/test/Analysis/z3-refute-enum-crash.cpp:25
+void test_enum_types() {
+  int sym1 = static_cast(conjure()) & 0x0F;
+  int sym2 = static_cast(conjure()) & 0x0F;

I will document the step-by-step reasoning in the test code to make sure why 
the crash happened.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85528

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

[PATCH] D88721: [clangd][lit] Update document-link.test to respect custom resource-dir locations

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88721

Files:
  clang-tools-extra/clangd/test/document-link.test


Index: clang-tools-extra/clangd/test/document-link.test
===
--- clang-tools-extra/clangd/test/document-link.test
+++ clang-tools-extra/clangd/test/document-link.test
@@ -1,4 +1,6 @@
-# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+# %resource_dir actually points at builtin_include_dir, go up one directory to
+# reach resource_dir.
+# RUN: clangd -lit-test -resource-dir=%resource_dir/.. < %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":"#include
 \n#include "}}}


Index: clang-tools-extra/clangd/test/document-link.test
===
--- clang-tools-extra/clangd/test/document-link.test
+++ clang-tools-extra/clangd/test/document-link.test
@@ -1,4 +1,6 @@
-# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+# %resource_dir actually points at builtin_include_dir, go up one directory to
+# reach resource_dir.
+# RUN: clangd -lit-test -resource-dir=%resource_dir/.. < %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":"#include \n#include "}}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88518: Recognize setjmp and friends as builtins even if jmp_buf is not declared yet.

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

This broke use of setjmp for mingw on x86_64. IIRC, in MSVC environments, the 
`_setjmp` function is considered built-in, which is given an implicit second 
argument by the compiler. In mingw targets on the other hand, the compiler 
normally doesn't know of any such extra mechanisms, and it's hooked up e.g. 
like this:

  #define setjmp(BUF) _setjmp((BUF), __builtin_frame_address (0))
  int __cdecl __attribute__ ((__nothrow__,__returns_twice__)) _setjmp(jmp_buf 
_Buf, void *_Ctx);

After this commit, in C++, this errors out with "error: too many arguments to 
function call, expected 1, have 2", while in C it merely produces a warning 
"warning: incompatible redeclaration of library function '_setjmp'" (and that 
warning is produced by the SDK headers, where those warnings normally are 
silenced).

A full repro case here follows:

  typedef __attribute__ ((__aligned__ (16))) struct _SETJMP_FLOAT128 {
__extension__ unsigned long long Part[2];
  } SETJMP_FLOAT128;
  #define _JBLEN 16
  typedef SETJMP_FLOAT128 _JBTYPE;
  typedef _JBTYPE jmp_buf[_JBLEN];
  
  #ifdef __cplusplus
  extern "C" {
  #endif
  
  #define setjmp(BUF) _setjmp((BUF), __builtin_frame_address (0))
  int __cdecl __attribute__ ((__nothrow__,__returns_twice__)) _setjmp(jmp_buf 
_Buf, void *_Ctx);
  
  #ifdef __cplusplus
  }
  #endif
  
  void other(void);
  jmp_buf buf;
  int func(void) {
  if (setjmp(buf)) {
  return 1;
  }
  other();
  return 0;
  }

  $ clang++ -x c++ -target x86_64-w64-mingw32 -c setjmp.c
  setjmp.c:29:9: error: too many arguments to function call, expected 1, have 2
  if (setjmp(buf)) {
  ^~~
  setjmp.c:12:36: note: expanded from macro 'setjmp'
  #define setjmp(BUF) _setjmp((BUF), __builtin_frame_address (0))
 ^~~

(The exact functions that is used for setjmp in mingw configuration is a bit of 
a jungle, with different CRT setups on different architectures: 
https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-headers/crt/setjmp.h#L213-L243)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88518

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

[PATCH] D87256: [clangd] Avoid relations being overwritten in a header shard

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp:232
 
+TEST_F(BackgroundIndexTest, RelationsMultiFile) {
+  MockFS FS;

kadircet wrote:
> do we still need this test?
this one was marked as resolved but i still don't see the reasoning. can we 
test this in fileindextests instead?

we already test the sharding logic, we need to test the merging logic now. can 
we rather test it at FileSymbols layer directly? or is there something extra 
that i am misisng?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87256

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

[PATCH] D88634: [clangd] Extend the rename API.

[Sam McCall via Phabricator via cfe-commits]

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

LG, introducing a separate field for locally affected ranges is up to you.




Comment at: clang-tools-extra/clangd/ClangdServer.h:277
+  ///
+  /// It is equal to invoke rename with an empty NewName, except that the
+  /// returned resuslt only contains main-file occurrences (for performance).

This seems a little like spelling out too many implementation details, and 
"equal to invoke" isn't quite right grammatically. Maybe just...

"The returned result describes edits in the current file only (all occurrences 
of the target name are simply deleted)".

(Note that if we split out the field for file ranges it could just be 
vector, avoiding the need to explain the replacement with empty string)



Comment at: clang-tools-extra/clangd/ClangdServer.h:278
+  /// It is equal to invoke rename with an empty NewName, except that the
+  /// returned resuslt only contains main-file occurrences (for performance).
   void prepareRename(PathRef File, Position Pos,

nit: resulslt -> result



Comment at: clang-tools-extra/clangd/refactor/Rename.h:61
+  Range R;
+  FileEdits Edits;
+};

hokein wrote:
> sammccall wrote:
> > It's slightly awkward to have the half-populated state (may or may not 
> > contain cross-file results, can't tell without the query).
> > 
> > I'd consider redundantly including `Edit LocalChanges` and `FileEdits 
> > GlobalChanges` with the former always set and the latter empty when 
> > returned from preparerename.
> > It's slightly awkward to have the half-populated state (may or may not 
> > contain cross-file results, can't tell without the query).
> 
> I feel this is not too bad, the query is quite trivial, just `Edits.size() > 
> 1`.
> 
> > I'd consider redundantly including Edit LocalChanges and FileEdits 
> > GlobalChanges with the former always set and the latter empty when returned 
> > from preparerename.
> 
> This change seems nice to get changes for main-file, but I think 
> `GlobalChanges` should include LocalChanges (otherwise, client side needs to 
> combine these two when applying the final rename edits)? then we can't leave 
> the later empty while keeping the former set.
> 
> Happy to do the change, but it looks like we don't have usage of 
> `LocalChanges` so far. In prepareRename, we want main-file occurrences, 
> `rename` will always return them regardless of single-file or cross-file 
> rename, so I think `Edits` is efficient. 
> > It's slightly awkward to have the half-populated state (may or may not 
> > contain cross-file results, can't tell without the query).
> 
> I feel this is not too bad, the query is quite trivial, just `Edits.size() > 
> 1`.
This isn't sufficient though: if Edits.size() == 1 then the results may be 
either complete or incomplete. (Sorry my wording above may have been poor, but 
this is the distinction I was referring to).

> > I'd consider redundantly including Edit LocalChanges and FileEdits 
> > GlobalChanges with the former always set and the latter empty when returned 
> > from preparerename.
> 
> This change seems nice to get changes for main-file, but I think 
> `GlobalChanges` should include LocalChanges (otherwise, client side needs to 
> combine these two when applying the final rename edits)? then we can't leave 
> the later empty while keeping the former set.

Sure we can. `// If the full set of changes is unknown, this field is empty.`

> Happy to do the change, but it looks like we don't have usage of 
> `LocalChanges` so far. In prepareRename, we want main-file occurrences, 
> `rename` will always return them regardless of single-file or cross-file 
> rename, so I think `Edits` is efficient. 

Yes, it's possible to implement correct behavior on top of the current API. It 
effectively reuses the same field with different semantics/contracts, and the 
client has enough information to know which contract is in place (and throw 
away the key in the expected singleton map).
However I think this is fragile and harder to understand than providing 
separate fields for the two contracts - using types to distinguish local vs 
global results makes the data harder to misuse. Given we expect this to be used 
by embedders, I think it's worth adding the second field.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88634

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

[PATCH] D88721: [clangd][lit] Update document-link.test to respect custom resource-dir locations

[Sam McCall via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/test/document-link.test:1
-# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+# %resource_dir actually points at builtin_include_dir, go up one directory to
+# reach resource_dir.

nit: i'd drop "to reach resource_dir" to get this to fit on one line
(Remembering that this quirk is almost always uninteresting to people reading 
this test)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88721

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

[clang-tools-extra] 17747d2 - [clangd] Remove Tweak::Intent, use CodeAction kind directly. NFC

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2020-10-02T11:14:23+02:00
New Revision: 17747d2ec8ec4471748197db54c8703f0c07c91c

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

LOG: [clangd] Remove Tweak::Intent, use CodeAction kind directly. NFC

Intent was a nice idea but it ends up being a bit awkward/heavyweight
without adding much.

In particular, it makes it hard to implement `CodeActionParams.only` properly
(there's an inheritance hierarchy for kinds).

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

Added: 


Modified: 
clang-tools-extra/clangd/ClangdLSPServer.cpp
clang-tools-extra/clangd/ClangdServer.cpp
clang-tools-extra/clangd/ClangdServer.h
clang-tools-extra/clangd/refactor/Tweak.h
clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
clang-tools-extra/clangd/refactor/tweaks/AnnotateHighlightings.cpp
clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
clang-tools-extra/clangd/refactor/tweaks/ExpandAutoType.cpp
clang-tools-extra/clangd/refactor/tweaks/ExpandMacro.cpp
clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
clang-tools-extra/clangd/refactor/tweaks/ObjCLocalizeStringLiteral.cpp
clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
clang-tools-extra/clangd/refactor/tweaks/RawStringLiteral.cpp
clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
clang-tools-extra/clangd/refactor/tweaks/SwapIfBranches.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/ClangdLSPServer.cpp 
b/clang-tools-extra/clangd/ClangdLSPServer.cpp
index dfd26ad40b89..c2915aeada4f 100644
--- a/clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ b/clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -68,14 +68,7 @@ CodeAction toCodeAction(const ClangdServer::TweakRef &T, 
const URIForFile &File,
 Range Selection) {
   CodeAction CA;
   CA.title = T.Title;
-  switch (T.Intent) {
-  case Tweak::Refactor:
-CA.kind = std::string(CodeAction::REFACTOR_KIND);
-break;
-  case Tweak::Info:
-CA.kind = std::string(CodeAction::INFO_KIND);
-break;
-  }
+  CA.kind = T.Kind.str();
   // This tweak may have an expensive second stage, we only run it if the user
   // actually chooses it in the UI. We reply with a command that would run the
   // corresponding tweak.

diff  --git a/clang-tools-extra/clangd/ClangdServer.cpp 
b/clang-tools-extra/clangd/ClangdServer.cpp
index 27d1a2dc7cdc..8c73b6a7d063 100644
--- a/clang-tools-extra/clangd/ClangdServer.cpp
+++ b/clang-tools-extra/clangd/ClangdServer.cpp
@@ -521,7 +521,7 @@ void ClangdServer::enumerateTweaks(PathRef File, Range Sel,
 };
 for (const auto &Sel : *Selections) {
   for (auto &T : prepareTweaks(*Sel, Filter)) {
-Res.push_back({T->id(), T->title(), T->intent()});
+Res.push_back({T->id(), T->title(), T->kind()});
 PreparedTweaks.insert(T->id());
 TweakAvailable.record(1, T->id());
   }

diff  --git a/clang-tools-extra/clangd/ClangdServer.h 
b/clang-tools-extra/clangd/ClangdServer.h
index ae10dba32b58..d801d3cd4353 100644
--- a/clang-tools-extra/clangd/ClangdServer.h
+++ b/clang-tools-extra/clangd/ClangdServer.h
@@ -288,7 +288,7 @@ class ClangdServer {
   struct TweakRef {
 std::string ID;/// ID to pass for applyTweak.
 std::string Title; /// A single-line message to show in the UI.
-Tweak::Intent Intent;
+llvm::StringLiteral Kind;
   };
   /// Enumerate the code tweaks available to the user at a specified point.
   void enumerateTweaks(PathRef File, Range Sel,

diff  --git a/clang-tools-extra/clangd/refactor/Tweak.h 
b/clang-tools-extra/clangd/refactor/Tweak.h
index 10e3e8d3e565..f991b78d8960 100644
--- a/clang-tools-extra/clangd/refactor/Tweak.h
+++ b/clang-tools-extra/clangd/refactor/Tweak.h
@@ -67,13 +67,6 @@ class Tweak {
 // FIXME: provide a way to get sources and ASTs for other files.
   };
 
-  /// Output of a tweak.
-  enum Intent {
-/// Apply changes that preserve the behavior of the code.
-Refactor,
-/// Provide information to the user.
-Info,
-  };
   struct Effect {
 /// A message to be displayed to the user.
 llvm::Optional ShowMessage;
@@ -120,7 +113,7 @@ class Tweak {
   virtual std::string title() const = 0;
   /// Describes what kind of action this is.
   /// EXPECTS: prepare() was called and returned true.
-  virtual Intent intent() const = 0;
+  virtual llvm::StringLiteral kind() const = 0;
   /// Is this a 'hidden' tweak, which are off by default.
   virtual bool hidden() const { return false; }
 };

diff  --git a/clang-tools-extra/clangd/refac

[PATCH] D88427: [clangd] Remove Tweak::Intent, use CodeAction kind directly

[Sam McCall via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG17747d2ec8ec: [clangd] Remove Tweak::Intent, use CodeAction 
kind directly. NFC (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D88427?vs=294726&id=295763#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88427

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/refactor/Tweak.h
  clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
  clang-tools-extra/clangd/refactor/tweaks/AnnotateHighlightings.cpp
  clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
  clang-tools-extra/clangd/refactor/tweaks/DefineOutline.cpp
  clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExpandAutoType.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExpandMacro.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
  clang-tools-extra/clangd/refactor/tweaks/ObjCLocalizeStringLiteral.cpp
  clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
  clang-tools-extra/clangd/refactor/tweaks/RawStringLiteral.cpp
  clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
  clang-tools-extra/clangd/refactor/tweaks/SwapIfBranches.cpp

Index: clang-tools-extra/clangd/refactor/tweaks/SwapIfBranches.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/SwapIfBranches.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/SwapIfBranches.cpp
@@ -39,7 +39,9 @@
   bool prepare(const Selection &Inputs) override;
   Expected apply(const Selection &Inputs) override;
   std::string title() const override { return "Swap if branches"; }
-  Intent intent() const override { return Refactor; }
+  llvm::StringLiteral kind() const override {
+return CodeAction::REFACTOR_KIND;
+  }
   bool hidden() const override { return true; }
 
 private:
Index: clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
@@ -39,7 +39,9 @@
   bool prepare(const Selection &Inputs) override;
   Expected apply(const Selection &Inputs) override;
   std::string title() const override;
-  Intent intent() const override { return Refactor; }
+  llvm::StringLiteral kind() const override {
+return CodeAction::REFACTOR_KIND;
+  }
 
 private:
   const UsingDirectiveDecl *TargetDirective = nullptr;
Index: clang-tools-extra/clangd/refactor/tweaks/RawStringLiteral.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/RawStringLiteral.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/RawStringLiteral.cpp
@@ -41,7 +41,9 @@
   bool prepare(const Selection &Inputs) override;
   Expected apply(const Selection &Inputs) override;
   std::string title() const override { return "Convert to raw string"; }
-  Intent intent() const override { return Refactor; }
+  llvm::StringLiteral kind() const override {
+return CodeAction::REFACTOR_KIND;
+  }
 
 private:
   const clang::StringLiteral *Str = nullptr;
Index: clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
@@ -52,7 +52,9 @@
   bool prepare(const Selection &Sel) override;
   Expected apply(const Selection &Sel) override;
   std::string title() const override { return "Populate switch"; }
-  Intent intent() const override { return Refactor; }
+  llvm::StringLiteral kind() const override {
+return CodeAction::REFACTOR_KIND;
+  }
 
 private:
   const DeclContext *DeclCtx = nullptr;
Index: clang-tools-extra/clangd/refactor/tweaks/ObjCLocalizeStringLiteral.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/ObjCLocalizeStringLiteral.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/ObjCLocalizeStringLiteral.cpp
@@ -35,7 +35,9 @@
 class ObjCLocalizeStringLiteral : public Tweak {
 public:
   const char *id() const override final;
-  Intent intent() const override { return Intent::Refactor; }
+  llvm::StringLiteral kind() const override {
+return CodeAction::REFACTOR_KIND;
+  }
 
   bool prepare(const Selection &Inputs) override;
   Expected apply(const Selection &Inputs) override;
Index: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
===
--- clang-tools-e

[PATCH] D87962: [clang] Change the multi-character character constants from extension to implementation-defined.

[Chuyang Chen via Phabricator via cfe-commits]

nomanous updated this revision to Diff 295766.
nomanous added a comment.

I change the four-char constants back to "Warning" in this revision, but set it 
to be ignored by default.


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

https://reviews.llvm.org/D87962

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/test/FixIt/format.m
  clang/test/Lexer/constants.c
  clang/test/Lexer/multi-char-constants.c


Index: clang/test/Lexer/multi-char-constants.c
===
--- /dev/null
+++ clang/test/Lexer/multi-char-constants.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wfour-char-constants 
-pedantic-errors %s
+
+int x = 'ab'; // expected-warning {{multi-character character constant}}
+int y = 'abcd'; // expected-warning {{multi-character character constant}}
+
+int main() {
+   return 0;
+}
+
Index: clang/test/Lexer/constants.c
===
--- clang/test/Lexer/constants.c
+++ clang/test/Lexer/constants.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -pedantic -ftrigraphs %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wfour-char-constants -pedantic 
-ftrigraphs %s
 
 int x = 00080;  // expected-error {{invalid digit}}
 
@@ -26,7 +26,7 @@
   '\\
 t',
   '??!',  // expected-warning {{trigraph converted to '|' character}}
-  'abcd'  // expected-warning {{multi-character character constant}}
+  'abcd' // expected-warning {{multi-character character constant}}
 };
 
 //  PR4499
@@ -36,15 +36,14 @@
 int m3 = '\\\
 ';
 
-
 #pragma clang diagnostic ignored "-Wmultichar"
 
 int d = 'df'; // no warning.
-int e = 'abcd';  // still warn: expected-warning {{multi-character character 
constant}}
+int e = 'abcd'; // still warn: expected-warning {{multi-character character 
constant}}
 
 #pragma clang diagnostic ignored "-Wfour-char-constants"
 
-int f = 'abcd';  // ignored.
+int f = 'abcd'; // ignored.
 
 // rdar://problem/6974641
 float t0[] = {
Index: clang/test/FixIt/format.m
===
--- clang/test/FixIt/format.m
+++ clang/test/FixIt/format.m
@@ -177,7 +177,7 @@
   // type-checker expects %c to correspond to an integer argument, because
   // many C library functions like fgetc() actually return an int (using -1
   // as a sentinel).
-  NSLog(@"%c", 'abcd'); // missing-warning{{format specifies type 'char' but 
the argument has type 'int'}}
+  NSLog(@"%c", 'abcd'); // missing-warning{{format specifies type 'char' but 
the argument has type 'int'}} \
   // CHECK-NOT: fix-it:"{{.*}}":{[[@LINE-1]]:11-[[@LINE-1]]:13}:"%d"
 }
 
Index: clang/include/clang/Basic/DiagnosticLexKinds.td
===
--- clang/include/clang/Basic/DiagnosticLexKinds.td
+++ clang/include/clang/Basic/DiagnosticLexKinds.td
@@ -104,10 +104,10 @@
   "raw string literals are incompatible with C++98">,
   InGroup, DefaultIgnore;
 
-def ext_multichar_character_literal : ExtWarn<
+def ext_multichar_character_literal : Warning<
   "multi-character character constant">, InGroup;
-def ext_four_char_character_literal : Extension<
-  "multi-character character constant">, InGroup;
+def ext_four_char_character_literal : Warning<
+  "multi-character character constant">, InGroup, 
DefaultIgnore;
 
 
 // Unicode and UCNs


Index: clang/test/Lexer/multi-char-constants.c
===
--- /dev/null
+++ clang/test/Lexer/multi-char-constants.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wfour-char-constants -pedantic-errors %s
+
+int x = 'ab'; // expected-warning {{multi-character character constant}}
+int y = 'abcd'; // expected-warning {{multi-character character constant}}
+
+int main() {
+   return 0;
+}
+
Index: clang/test/Lexer/constants.c
===
--- clang/test/Lexer/constants.c
+++ clang/test/Lexer/constants.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -pedantic -ftrigraphs %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wfour-char-constants -pedantic -ftrigraphs %s
 
 int x = 00080;  // expected-error {{invalid digit}}
 
@@ -26,7 +26,7 @@
   '\\
 t',
   '??!',  // expected-warning {{trigraph converted to '|' character}}
-  'abcd'  // expected-warning {{multi-character character constant}}
+  'abcd' // expected-warning {{multi-character character constant}}
 };
 
 //  PR4499
@@ -36,15 +36,14 @@
 int m3 = '\\\
 ';
 
-
 #pragma clang diagnostic ignored "-Wmultichar"
 
 int d = 'df'; // no warning.
-int e = 'abcd';  // still warn: expected-warning {{multi-character character constant}}
+int e = 'abcd'; // still warn: expected-warning {{multi-character character constant}}
 
 #pragma clang diagnostic ignored "-Wfour-char-constants"
 
-int f = 'abcd';  // ignored.
+int f = 'abcd'; // ignored.
 
 // rdar://problem/6974641
 float t0[] = {
Index

[PATCH] D88724: [clangd] Make the tweak filter a parameter to enumerateTweaks. NFC

[Sam McCall via Phabricator via cfe-commits]

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

(Required for CodeActionContext.only)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88724

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

Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -163,11 +163,6 @@
 /// Enable preview of FoldingRanges feature.
 bool FoldingRanges = false;
 
-/// Returns true if the tweak should be enabled.
-std::function TweakFilter = [](const Tweak &T) {
-  return !T.hidden(); // only enable non-hidden tweaks.
-};
-
 explicit operator TUScheduler::Options() const;
   };
   // Sensible default options for use in tests.
@@ -291,7 +286,9 @@
 llvm::StringLiteral Kind;
   };
   /// Enumerate the code tweaks available to the user at a specified point.
+  /// Tweaks where Filter returns false will not be checked or included.
   void enumerateTweaks(PathRef File, Range Sel,
+   llvm::unique_function Filter,
Callback> CB);
 
   /// Apply the code tweak with a specified \p ID.
@@ -379,8 +376,6 @@
   // If true, preserve the type for recovery AST.
   bool PreserveRecoveryASTType = false;
 
-  std::function TweakFilter;
-
   // GUARDED_BY(CachedCompletionFuzzyFindRequestMutex)
   llvm::StringMap>
   CachedCompletionFuzzyFindRequestByFile;
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -180,7 +180,7 @@
   SuggestMissingIncludes(Opts.SuggestMissingIncludes),
   BuildRecoveryAST(Opts.BuildRecoveryAST),
   PreserveRecoveryASTType(Opts.PreserveRecoveryASTType),
-  TweakFilter(Opts.TweakFilter), WorkspaceRoot(Opts.WorkspaceRoot),
+  WorkspaceRoot(Opts.WorkspaceRoot),
   // Pass a callback into `WorkScheduler` to extract symbols from a newly
   // parsed file and rebuild the file index synchronously each time an AST
   // is parsed.
@@ -501,13 +501,15 @@
   return std::move(Result);
 }
 
-void ClangdServer::enumerateTweaks(PathRef File, Range Sel,
-   Callback> CB) {
+void ClangdServer::enumerateTweaks(
+PathRef File, Range Sel, llvm::unique_function Filter,
+Callback> CB) {
   // Tracks number of times a tweak has been offered.
   static constexpr trace::Metric TweakAvailable(
   "tweak_available", trace::Metric::Counter, "tweak_id");
   auto Action = [File = File.str(), Sel, CB = std::move(CB),
- this](Expected InpAST) mutable {
+ Filter =
+ std::move(Filter)](Expected InpAST) mutable {
 if (!InpAST)
   return CB(InpAST.takeError());
 auto Selections = tweakSelection(Sel, *InpAST);
@@ -516,11 +518,11 @@
 std::vector Res;
 // Don't allow a tweak to fire more than once across ambiguous selections.
 llvm::DenseSet PreparedTweaks;
-auto Filter = [&](const Tweak &T) {
-  return TweakFilter(T) && !PreparedTweaks.count(T.id());
+auto DeduplicatingFilter = [&](const Tweak &T) {
+  return Filter(T) && !PreparedTweaks.count(T.id());
 };
 for (const auto &Sel : *Selections) {
-  for (auto &T : prepareTweaks(*Sel, Filter)) {
+  for (auto &T : prepareTweaks(*Sel, DeduplicatingFilter)) {
 Res.push_back({T->id(), T->title(), T->kind()});
 PreparedTweaks.insert(T->id());
 TweakAvailable.record(1, T->id());
Index: clang-tools-extra/clangd/ClangdLSPServer.h
===
--- clang-tools-extra/clangd/ClangdLSPServer.h
+++ clang-tools-extra/clangd/ClangdLSPServer.h
@@ -50,6 +50,10 @@
 /// per-request, but LSP allows limited/no customizations.
 clangd::CodeCompleteOptions CodeComplete;
 clangd::RenameOptions Rename;
+/// Returns true if the tweak should be enabled.
+std::function TweakFilter = [](const Tweak &T) {
+  return !T.hidden(); // only enable non-hidden tweaks.
+};
   };
 
   ClangdLSPServer(Transport &Transp, const ThreadsafeFS &TFS,
Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -1024,7 +1024,15 @@
 return Reply(llvm::json::Array(Commands));
   };
 
-  Server->enumerateTweaks(File.file(), Params.range, std::move(ConsumeActions)

[PATCH] D87962: [clang] Change the multi-character character constants from extension to implementation-defined.

[Chuyang Chen via Phabricator via cfe-commits]

nomanous updated this revision to Diff 295771.
nomanous added a comment.

I restore some needless modification in the previous patch.


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

https://reviews.llvm.org/D87962

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/test/Lexer/constants.c
  clang/test/Lexer/multi-char-constants.c


Index: clang/test/Lexer/multi-char-constants.c
===
--- /dev/null
+++ clang/test/Lexer/multi-char-constants.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wfour-char-constants 
-pedantic-errors %s
+
+int x = 'ab'; // expected-warning {{multi-character character constant}}
+int y = 'abcd'; // expected-warning {{multi-character character constant}}
+
+int main() {
+   return 0;
+}
+
Index: clang/test/Lexer/constants.c
===
--- clang/test/Lexer/constants.c
+++ clang/test/Lexer/constants.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -pedantic -ftrigraphs %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wfour-char-constants -pedantic 
-ftrigraphs %s
 
 int x = 00080;  // expected-error {{invalid digit}}
 
Index: clang/include/clang/Basic/DiagnosticLexKinds.td
===
--- clang/include/clang/Basic/DiagnosticLexKinds.td
+++ clang/include/clang/Basic/DiagnosticLexKinds.td
@@ -104,10 +104,10 @@
   "raw string literals are incompatible with C++98">,
   InGroup, DefaultIgnore;
 
-def ext_multichar_character_literal : ExtWarn<
+def ext_multichar_character_literal : Warning<
   "multi-character character constant">, InGroup;
-def ext_four_char_character_literal : Extension<
-  "multi-character character constant">, InGroup;
+def ext_four_char_character_literal : Warning<
+  "multi-character character constant">, InGroup, 
DefaultIgnore;
 
 
 // Unicode and UCNs


Index: clang/test/Lexer/multi-char-constants.c
===
--- /dev/null
+++ clang/test/Lexer/multi-char-constants.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wfour-char-constants -pedantic-errors %s
+
+int x = 'ab'; // expected-warning {{multi-character character constant}}
+int y = 'abcd'; // expected-warning {{multi-character character constant}}
+
+int main() {
+   return 0;
+}
+
Index: clang/test/Lexer/constants.c
===
--- clang/test/Lexer/constants.c
+++ clang/test/Lexer/constants.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -pedantic -ftrigraphs %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wfour-char-constants -pedantic -ftrigraphs %s
 
 int x = 00080;  // expected-error {{invalid digit}}
 
Index: clang/include/clang/Basic/DiagnosticLexKinds.td
===
--- clang/include/clang/Basic/DiagnosticLexKinds.td
+++ clang/include/clang/Basic/DiagnosticLexKinds.td
@@ -104,10 +104,10 @@
   "raw string literals are incompatible with C++98">,
   InGroup, DefaultIgnore;
 
-def ext_multichar_character_literal : ExtWarn<
+def ext_multichar_character_literal : Warning<
   "multi-character character constant">, InGroup;
-def ext_four_char_character_literal : Extension<
-  "multi-character character constant">, InGroup;
+def ext_four_char_character_literal : Warning<
+  "multi-character character constant">, InGroup, DefaultIgnore;
 
 
 // Unicode and UCNs
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

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

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



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:33
+
+  for (const FunctionDecl *D : Node.redecls())
+if (D->getASTContext().getSourceManager().isInSystemHeader(

aaron.ballman wrote:
> I'm not certain I understand why we're looking through the entire 
> redeclaration chain to see if the function is ever mentioned in a system 
> header. I was expecting we'd look at the expansion location of the 
> declaration and see if that's in a system header, which is already handled by 
> the `isExpansionInSystemHeader()` matcher. Similar below.
This function is called from ` SignalHandlerCheck::check` when any function 
call is found. So the check for system header is needed. It was unclear to me 
what the "expansion location" means but it seems to work if using that 
expansion location and checking for system header, instead of this loop. I will 
update the code.



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:84
+  functionDecl(hasName(SignalFun), parameterCountIs(2),
+   anyOf(isInStdNamespace(), isTopLevelSystemFunction()));
+  auto HandlerExpr =

aaron.ballman wrote:
> I think this can be simplified to remove the `anyOf`:
> ```
> functionDecl(hasAnyName("::signal", "::std::signal"), 
> isExpansionInSystemHeader())
> ```
> should be sufficient (if there's a function named `signal` in a system header 
> that has the wrong parameter count, I'd be surprised).
I was not aware of the possibility of using namespaces in the name, it is 
really more simple this way (and the `isExpansionInSystemHeader` seems to work 
good here).



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-sig30-c.rst:13
+(for ``signal`` there are additional conditions that are not checked).
+Every other system call is considered as non asynchronous-safe by the checker.
+

aaron.ballman wrote:
> I would document this as: `Any function that cannot be determined to be an 
> asynchronous-safe function call is assumed to be non-asynchronous-safe by the 
> checker, including function calls for which only the declaration of the 
> called function is visible.`
"including function calls for which only the declaration of the called function 
is visible": Is this the better approach? The checker does not make warning for 
such functions in the current state.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87449

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

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

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

balazske added a comment.

I plan to add the option for extended set of asynchronous-safe functions 
(defined by the POSIX list) in a next patch. There is other possible 
improvement to check at least something of the criteria listed here 
 for C++17 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87449

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

[PATCH] D88411: [clangd] Introduce MemoryTrees

[Kadir Cetinkaya via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/support/MemoryTree.cpp:28
+size_t ChildrenSize = 0;
+for (const auto &C : Children) {
+  C.traverseTree(CollapseDetails,

sammccall wrote:
> Here the detailed nodes are entirely collapsed. This isn't quite as powerful 
> as collapsing the detail *edges* only, which is worth considering.
> 
> e.g. consider TUScheduler. The natural accounting of resources is (IMO)
> ```
> clangd.TUScheduler..AST
> clangd.TUScheduler..Preamble.InMemory
> clangd.TUScheduler..Preamble.Inputs
> ```
> or something like that.
> 
> Instead of aggregating to `clangd.TUScheduler` only, collapsing the 
> `` edges mean you get `clangd.TUScheduler.AST` etc.
yes this was an option i hadn't considered. my only hesitation is this likely 
implies different paths with the same name. current api also doesn't protect 
against it, but they are a lot less likely as we collapse whole subtrees.

I believe deleting the edge should also imply aggregating all the paths with 
the same name, e.g.
`a.b..c, 5` and `a.b..c, 8` should end up being 
`a.b.c,13`. WDYT?



Comment at: clang-tools-extra/clangd/support/MemoryTree.h:22
+/// preserving the hierarchy.
+struct MemoryTree {
+public:

sammccall wrote:
> (I'm wondering if there are other resources we'd like to count, like disk 
> size or so, but probably YAGNI and a concrete name is nice)
i went with this one as i didn't want to call it `Tree` and couldn't find a 
nice generic name, maybe something around `NamedBytesTree`.



Comment at: clang-tools-extra/clangd/support/MemoryTree.h:25
+  void addChild(llvm::StringRef Name, MemoryTree MT, bool IsDetail = false);
+  void addChild(llvm::StringRef Name, size_t Size);
+

sammccall wrote:
> do we support nodes with both usage and children?
> This API makes such a construction awkward.
> 
> vs something like addUsage(size_t)
yes we do, I haven't added any because it wasn't needed and internal collapsing 
mechanism could update the size. i'll add an explicit `addUsage` too.



Comment at: clang-tools-extra/clangd/support/MemoryTree.h:31
+  /// detail to root, and doesn't report any descendants.
+  void traverseTree(bool CollapseDetails,
+llvm::function_ref sammccall wrote:
> > In earlier discussions we talked about avoiding the cost of *assembling* 
> > the detailed tree, not just summarizing it at output time.
> > 
> > This requires `CollapseDetails` to be passed into the profiling function, 
> > which in turn suggests making it part of a tree and passing a reference to 
> > the tree in. e.g. an API like
> > 
> > ```
> > class MemoryTree {
> >   MemoryTree(bool Detailed);
> >   MemoryTree* addChild(StringLiteral); // no copy
> >   MemoryTree* addDetail(StringRef); // returns `this` unless detailed
> >   void addUsage(size_t);
> > }
> > ```
> It's hard to evaluate a tree-traversal API without its usages... how will 
> this be used?
you can find some in https://reviews.llvm.org/D88414


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88411

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

[PATCH] D88726: [clangd] Make PopulateSwitch a fix.

[Sam McCall via Phabricator via cfe-commits]

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

It fixes the -Wswitch warning, though we mark it as a fix even if that is off.
This makes it the "recommended" action on an incomplete switch, which seems OK.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88726

Files:
  clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp


Index: clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
@@ -53,7 +53,7 @@
   Expected apply(const Selection &Sel) override;
   std::string title() const override { return "Populate switch"; }
   llvm::StringLiteral kind() const override {
-return CodeAction::REFACTOR_KIND;
+return CodeAction::QUICKFIX_KIND;
   }
 
 private:


Index: clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
@@ -53,7 +53,7 @@
   Expected apply(const Selection &Sel) override;
   std::string title() const override { return "Populate switch"; }
   llvm::StringLiteral kind() const override {
-return CodeAction::REFACTOR_KIND;
+return CodeAction::QUICKFIX_KIND;
   }
 
 private:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88721: [clangd][lit] Update document-link.test to respect custom resource-dir locations

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 295779.
kadircet added a comment.

- update comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88721

Files:
  clang-tools-extra/clangd/test/document-link.test


Index: clang-tools-extra/clangd/test/document-link.test
===
--- clang-tools-extra/clangd/test/document-link.test
+++ clang-tools-extra/clangd/test/document-link.test
@@ -1,4 +1,5 @@
-# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+# %resource_dir actually points at builtin_include_dir, go up one directory.
+# RUN: clangd -lit-test -resource-dir=%resource_dir/.. < %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":"#include
 \n#include "}}}


Index: clang-tools-extra/clangd/test/document-link.test
===
--- clang-tools-extra/clangd/test/document-link.test
+++ clang-tools-extra/clangd/test/document-link.test
@@ -1,4 +1,5 @@
-# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+# %resource_dir actually points at builtin_include_dir, go up one directory.
+# RUN: clangd -lit-test -resource-dir=%resource_dir/.. < %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":"#include \n#include "}}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88721: [clangd][lit] Update document-link.test to respect custom resource-dir locations

[Kadir Cetinkaya 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 rG54c03d8f7da7: [clangd][lit] Update document-link.test to 
respect custom resource-dir locations (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88721

Files:
  clang-tools-extra/clangd/test/document-link.test


Index: clang-tools-extra/clangd/test/document-link.test
===
--- clang-tools-extra/clangd/test/document-link.test
+++ clang-tools-extra/clangd/test/document-link.test
@@ -1,4 +1,5 @@
-# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+# %resource_dir actually points at builtin_include_dir, go up one directory.
+# RUN: clangd -lit-test -resource-dir=%resource_dir/.. < %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":"#include
 \n#include "}}}


Index: clang-tools-extra/clangd/test/document-link.test
===
--- clang-tools-extra/clangd/test/document-link.test
+++ clang-tools-extra/clangd/test/document-link.test
@@ -1,4 +1,5 @@
-# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+# %resource_dir actually points at builtin_include_dir, go up one directory.
+# RUN: clangd -lit-test -resource-dir=%resource_dir/.. < %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":"#include \n#include "}}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88680: Add ability to turn off -fpch-instantiate-templates in clang-cl

[Shivanshu Goyal via Phabricator via cfe-commits]

shivanshu3 added a comment.

Also, I wanted to mention that clang-cl.exe actually crashes deterministically 
when running precompiles for 2 of our headers when using 
'-fpch-instantiate-templates' with the following signature:

  1.   parser at end of file
  2.  Per-file LLVM IR generation
  3.  {msvc}\lib\native\include\xmemory:807:41: Generating code for 
declaration 'std::allocator::allocate'
  4.  {msvc}\lib\native\include\xmemory:44:30: LLVM IR generation of 
declaration 'std::_New_alignof'

Once I'm able to get a smaller repro which I can share, I will update you guys 
with it. @llunak FYI


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88680

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

[clang-tools-extra] 54c03d8 - [clangd][lit] Update document-link.test to respect custom resource-dir locations

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2020-10-02T12:24:06+02:00
New Revision: 54c03d8f7da72fdf1a9e122391c51c2f0ea7b298

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

LOG: [clangd][lit] Update document-link.test to respect custom resource-dir 
locations

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

Added: 


Modified: 
clang-tools-extra/clangd/test/document-link.test

Removed: 




diff  --git a/clang-tools-extra/clangd/test/document-link.test 
b/clang-tools-extra/clangd/test/document-link.test
index 7802fe784568..a4c82e5b2fb6 100644
--- a/clang-tools-extra/clangd/test/document-link.test
+++ b/clang-tools-extra/clangd/test/document-link.test
@@ -1,4 +1,5 @@
-# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+# %resource_dir actually points at builtin_include_dir, go up one directory.
+# RUN: clangd -lit-test -resource-dir=%resource_dir/.. < %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":"#include
 \n#include "}}}



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

[PATCH] D88721: [clangd][lit] Update document-link.test to respect custom resource-dir locations

[Aleksandr Platonov via Phabricator via cfe-commits]

ArcsinX added a comment.

Just a question.
On Windows `%resource_dir/..` looks a bit inconsistent after substitution 
(`d:\llvm-project\build\lib\clang\12.0.0\include/..`), but this test passes.
As far as Windows accepts forward and back slashes, I expect something like 
this `%/resource_dir/..` to be consistent across all platforms.
Are there any plans to add `%/resource_dir` substitution as it was done for %T, 
%s, etc?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88721

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

[PATCH] D77062: [analyzer] Improve zero assumption in CStringChecke::assumeZero

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

@steakhal

> Till then, I recommend you to follow my effort at D88477 
> .

I'm aleady on this way. I'm debugging the Store. I think we load a wrong type 
because we store a wrong type.


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

https://reviews.llvm.org/D77062

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

[clang-tools-extra] 57ac47d - [clangd] Make PopulateSwitch a fix.

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2020-10-02T13:24:24+02:00
New Revision: 57ac47d78885c9a3d712692b1476d99840591db1

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

LOG: [clangd] Make PopulateSwitch a fix.

It fixes the -Wswitch warning, though we mark it as a fix even if that is off.
This makes it the "recommended" action on an incomplete switch, which seems OK.

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

Added: 


Modified: 
clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp 
b/clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
index 12a6e49a1684..a8ad90596681 100644
--- a/clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
+++ b/clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
@@ -53,7 +53,7 @@ class PopulateSwitch : public Tweak {
   Expected apply(const Selection &Sel) override;
   std::string title() const override { return "Populate switch"; }
   llvm::StringLiteral kind() const override {
-return CodeAction::REFACTOR_KIND;
+return CodeAction::QUICKFIX_KIND;
   }
 
 private:



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

[PATCH] D88726: [clangd] Make PopulateSwitch a fix.

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG57ac47d78885: [clangd] Make PopulateSwitch a fix. (authored 
by sammccall).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88726

Files:
  clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp


Index: clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
@@ -53,7 +53,7 @@
   Expected apply(const Selection &Sel) override;
   std::string title() const override { return "Populate switch"; }
   llvm::StringLiteral kind() const override {
-return CodeAction::REFACTOR_KIND;
+return CodeAction::QUICKFIX_KIND;
   }
 
 private:


Index: clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/PopulateSwitch.cpp
@@ -53,7 +53,7 @@
   Expected apply(const Selection &Sel) override;
   std::string title() const override { return "Populate switch"; }
   llvm::StringLiteral kind() const override {
-return CodeAction::REFACTOR_KIND;
+return CodeAction::QUICKFIX_KIND;
   }
 
 private:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88721: [clangd][lit] Update document-link.test to respect custom resource-dir locations

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

> As far as Windows accepts forward and back slashes

Note we don't rely on windows itself for this support.
All access through `llvm::sys::fs` APIs on windows ultimately goes through 
`widenPath` to convert to UTF-16, and this substitutes slashes.
So LLVM tools do always support `/` on windows and it's fairly common to rely 
on this for tests (abstraction is hard in lit tests).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88721

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

[PATCH] D88411: [clangd] Introduce MemoryTrees

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/support/MemoryTree.cpp:28
+size_t ChildrenSize = 0;
+for (const auto &C : Children) {
+  C.traverseTree(CollapseDetails,

kadircet wrote:
> sammccall wrote:
> > Here the detailed nodes are entirely collapsed. This isn't quite as 
> > powerful as collapsing the detail *edges* only, which is worth considering.
> > 
> > e.g. consider TUScheduler. The natural accounting of resources is (IMO)
> > ```
> > clangd.TUScheduler..AST
> > clangd.TUScheduler..Preamble.InMemory
> > clangd.TUScheduler..Preamble.Inputs
> > ```
> > or something like that.
> > 
> > Instead of aggregating to `clangd.TUScheduler` only, collapsing the 
> > `` edges mean you get `clangd.TUScheduler.AST` etc.
> yes this was an option i hadn't considered. my only hesitation is this likely 
> implies different paths with the same name. current api also doesn't protect 
> against it, but they are a lot less likely as we collapse whole subtrees.
> 
> I believe deleting the edge should also imply aggregating all the paths with 
> the same name, e.g.
> `a.b..c, 5` and `a.b..c, 8` should end up being 
> `a.b.c,13`. WDYT?
Agree with your desired behavior.

If you're willing to make collapsing a property of the tree rather than the 
query, you avoid this problem, because you collapse up-front and make addChild 
idempotent:

```
class Tree {
  BumpPtrAllocator *DetailAllocator; // Null if no detail
  StringMap Children;
  size_t Self = 0;

  Tree* childImpl(StringRef Name) {
return &*Children.try_emplace(Name, DetailAllocator).first;
  }

public:  
  Tree(BumpPtrAllocator *);
  Tree* child(StringLiteral Name) { return childImpl(Name); }
  Tree* detail(StringRef Name) {
return DetailAllocator ? child(DetailAllocator->copy(Name)) : this;
  }
  void add(unsigned Size) { Self += Size; }
};
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88411

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

[PATCH] D71524: [analyzer] Support tainted objects in GenericTaintChecker

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

steakhal added a comment.

In D71524#2304742 , @boga95 wrote:

> As far as I remember I tried to make `std::cin` tainted, but it was 
> complicated.

What sort of issues did you find by implementing that approach? Could you 
elaborate?

> I run the checker against many projects and there wasn't any false positive 
> related to this heuristic.

It seems a bit hand-wavy to me.

> We can restrict the `operator>>`  to `std::basic_stream` and cover only the 
> standard library.

If we choose this approach, then we have to do something about this, yes. This 
could be a reasonable choice.

We are arguing about whether the `operator>>` is a //propagation// or a 
//source// function.
IMO this operator should //propagate// taint, from the //stream// to an object.

I've opened the cppreference  
to find an example where your logic would introduce serious false positives.
I've spent like 2 minutes to come up with this, there might be many more:

  std::istringstream is("hello, world");
  char arr[10];
  is >> std::setw(6) >> arr;
  std::cout << "Input from \"" << is.str() << "\" with setw(6) gave \""
<< arr << "\"\n";

godbolt 

You would deliberately mark `arr` as a tainted.
Fortunately/unfortunately it's quite hard to //remove// taint - so any 
unnecessarily tainted value is a serious problem, thus requires careful design 
decisions.

This example might seem to be a made-up one, however, we should consider 
developers who want to extract data from streams - which aren't tainted.
Marking the stream itself tainted, and propagating taint over the //extraction 
operator// would not have such false positives.


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

https://reviews.llvm.org/D71524

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

[clang] 8825fec - [AArch64] Add CPU Cortex-R82

[Sjoerd Meijer via cfe-commits]

Author: Sjoerd Meijer
Date: 2020-10-02T12:47:23+01:00
New Revision: 8825fec37e73eea1bc3e4f5c125e1fd02d002d6c

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

LOG: [AArch64] Add CPU Cortex-R82

This adds support for -mcpu=cortex-r82. Some more information about this
core can be found here:

https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r82

One note about the system register: that is a bit of a refactoring because of
small differences between v8.4-A AArch64 and v8-R AArch64.

This is based on patches from Mark Murray and Mikhail Maltsev.

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

Added: 


Modified: 
clang/lib/Basic/Targets/AArch64.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/test/Driver/aarch64-cpus.c
clang/test/Driver/aarch64-dotprod.c
clang/test/Preprocessor/aarch64-target-features.c
llvm/include/llvm/Support/AArch64TargetParser.def
llvm/lib/Support/AArch64TargetParser.cpp
llvm/lib/Target/AArch64/AArch64.td
llvm/lib/Target/AArch64/AArch64Subtarget.cpp
llvm/lib/Target/AArch64/AArch64Subtarget.h
llvm/lib/Target/AArch64/AArch64SystemOperands.td
llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
llvm/unittests/Support/TargetParserTest.cpp

Removed: 




diff  --git a/clang/lib/Basic/Targets/AArch64.cpp 
b/clang/lib/Basic/Targets/AArch64.cpp
index 7f0a0f0d86dc..e25a783cfa66 100644
--- a/clang/lib/Basic/Targets/AArch64.cpp
+++ b/clang/lib/Basic/Targets/AArch64.cpp
@@ -481,6 +481,8 @@ bool 
AArch64TargetInfo::handleTargetFeatures(std::vector &Features,
   ArchKind = llvm::AArch64::ArchKind::ARMV8_5A;
 if (Feature == "+v8.6a")
   ArchKind = llvm::AArch64::ArchKind::ARMV8_6A;
+if (Feature == "+v8r")
+  ArchKind = llvm::AArch64::ArchKind::ARMV8R;
 if (Feature == "+fullfp16")
   HasFullFP16 = true;
 if (Feature == "+dotprod")

diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp 
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index 6c5e43704cc4..fe742b4bcfcd 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -306,7 +306,8 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
   NoCrypto = true;
   }
 
-  if (std::find(ItBegin, ItEnd, "+v8.4a") != ItEnd) {
+  if (std::find(ItBegin, ItEnd, "+v8.4a") != ItEnd ||
+  std::find(ItBegin, ItEnd, "+v8r") != ItEnd) {
 if (HasCrypto && !NoCrypto) {
   // Check if we have NOT disabled an algorithm with something like:
   //   +crypto, -algorithm

diff  --git a/clang/test/Driver/aarch64-cpus.c 
b/clang/test/Driver/aarch64-cpus.c
index f39241bee8a6..356674e7a707 100644
--- a/clang/test/Driver/aarch64-cpus.c
+++ b/clang/test/Driver/aarch64-cpus.c
@@ -178,6 +178,9 @@
 // RUN: %clang -target aarch64 -mcpu=cortex-a78  -### -c %s 2>&1 | FileCheck 
-check-prefix=CORTEXA78 %s
 // CORTEXA78: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "cortex-a78"
 
+// RUN: %clang -target aarch64 -mcpu=cortex-r82  -### -c %s 2>&1 | FileCheck 
-check-prefix=CORTEXR82 %s
+// CORTEXR82: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "cortex-r82"
+
 // RUN: %clang -target aarch64_be -mcpu=exynos-m3 -### -c %s 2>&1 | FileCheck 
-check-prefix=M3 %s
 // RUN: %clang -target aarch64 -mbig-endian -mcpu=exynos-m3 -### -c %s 2>&1 | 
FileCheck -check-prefix=M3 %s
 // RUN: %clang -target aarch64_be -mbig-endian -mcpu=exynos-m3 -### -c %s 2>&1 
| FileCheck -check-prefix=M3 %s

diff  --git a/clang/test/Driver/aarch64-dotprod.c 
b/clang/test/Driver/aarch64-dotprod.c
index a6d0c9c4e1ce..3ca79d54daa7 100644
--- a/clang/test/Driver/aarch64-dotprod.c
+++ b/clang/test/Driver/aarch64-dotprod.c
@@ -9,4 +9,5 @@
 // RUN: %clang -### -target aarch64 -mcpu=cortex-a75 %s 2>&1 | FileCheck %s
 // RUN: %clang -### -target aarch64 -mcpu=cortex-a76 %s 2>&1 | FileCheck %s
 // RUN: %clang -### -target aarch64 -mcpu=cortex-a55 %s 2>&1 | FileCheck %s
+// RUN: %clang -### -target aarch64 -mcpu=cortex-r82 %s 2>&1 | FileCheck %s
 // CHECK: "+dotprod"

diff  --git a/clang/test/Preprocessor/aarch64-target-features.c 
b/clang/test/Preprocessor/aarch64-target-features.c
index cb137eea072e..ad84ba93ccf3 100644
--- a/clang/test/Preprocessor/aarch64-target-features.c
+++ b/clang/test/Preprocessor/aarch64-target-features.c
@@ -219,6 +219,7 @@
 // RUN: %clang -target aarch64 -mcpu=cortex-a57 -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-MCPU-A57 %s
 // RUN: %clang -target aarch64 -mcpu=cortex-a72 -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-MCPU-A72 %s
 // RUN: %clang -target aarch64 -mcpu=cortex-a73 -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-MCPU-CORTEX-A73 %s
+// RUN: %clang -target aarch64 -mcpu=cortex-r82 -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-MCPU-CORTEX-R82 %s
 // RUN:

[PATCH] D88660: [AArch64] Add CPU Cortex-R82

[Sjoerd Meijer via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8825fec37e73: [AArch64] Add CPU Cortex-R82 (authored by 
SjoerdMeijer).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D88660?vs=295573&id=295791#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88660

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/aarch64-dotprod.c
  clang/test/Preprocessor/aarch64-target-features.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/lib/Support/AArch64TargetParser.cpp
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/lib/Target/AArch64/AArch64SystemOperands.td
  llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -881,6 +881,14 @@
   AArch64::AEK_LSE | AArch64::AEK_FP16 | AArch64::AEK_DOTPROD |
   AArch64::AEK_RCPC | AArch64::AEK_SSBS,
   "8.2-A"));
+  EXPECT_TRUE(testAArch64CPU(
+ "cortex-r82", "armv8-r", "crypto-neon-fp-armv8",
+  AArch64::AEK_CRC | AArch64::AEK_RDM  | AArch64::AEK_SSBS|
+  AArch64::AEK_CRYPTO  | AArch64::AEK_SM4  | AArch64::AEK_SHA3|
+  AArch64::AEK_SHA2| AArch64::AEK_AES  | AArch64::AEK_DOTPROD |
+  AArch64::AEK_FP  | AArch64::AEK_SIMD | AArch64::AEK_FP16|
+  AArch64::AEK_FP16FML | AArch64::AEK_RAS  | AArch64::AEK_RCPC|
+  AArch64::AEK_SB, "8-R"));
   EXPECT_TRUE(testAArch64CPU(
   "cortex-x1", "armv8.2-a", "crypto-neon-fp-armv8",
   AArch64::AEK_CRC | AArch64::AEK_CRYPTO | AArch64::AEK_FP |
@@ -1026,7 +1034,7 @@
   "8.2-A"));
 }
 
-static constexpr unsigned NumAArch64CPUArchs = 42;
+static constexpr unsigned NumAArch64CPUArchs = 43;
 
 TEST(TargetParserTest, testAArch64CPUArchList) {
   SmallVector List;
Index: llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
===
--- llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
+++ llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
@@ -5251,6 +5251,7 @@
 case AArch64::ArchKind::ARMV8_4A:
 case AArch64::ArchKind::ARMV8_5A:
 case AArch64::ArchKind::ARMV8_6A:
+case AArch64::ArchKind::ARMV8R:
   RequestedExtensions.push_back("sm4");
   RequestedExtensions.push_back("sha3");
   RequestedExtensions.push_back("sha2");
Index: llvm/lib/Target/AArch64/AArch64SystemOperands.td
===
--- llvm/lib/Target/AArch64/AArch64SystemOperands.td
+++ llvm/lib/Target/AArch64/AArch64SystemOperands.td
@@ -32,6 +32,11 @@
  AssemblerPredicate<(all_of FeaturePAN_RWV),
  "ARM v8.2 PAN AT S1E1R and AT S1E1W Variation">;
 
+def HasCONTEXTIDREL2
+   : Predicate<"Subtarget->hasCONTEXTIDREL2()">,
+ AssemblerPredicate<(all_of FeatureCONTEXTIDREL2),
+ "Target contains CONTEXTIDR_EL2 RW operand">;
+
 //===--===//
 // AT (address translate) instruction options.
 //===--===//
@@ -1220,7 +1225,6 @@
 //  Op0Op1 CRn CRmOp2
 let Requires = [{ {AArch64::FeatureVH} }] in {
 def : RWSysReg<"TTBR1_EL2",   0b11, 0b100, 0b0010, 0b, 0b001>;
-def : RWSysReg<"CONTEXTIDR_EL2",  0b11, 0b100, 0b1101, 0b, 0b001>;
 def : RWSysReg<"CNTHV_TVAL_EL2",  0b11, 0b100, 0b1110, 0b0011, 0b000>;
 def : RWSysReg<"CNTHV_CVAL_EL2",  0b11, 0b100, 0b1110, 0b0011, 0b010>;
 def : RWSysReg<"CNTHV_CTL_EL2",   0b11, 0b100, 0b1110, 0b0011, 0b001>;
@@ -1246,6 +1250,9 @@
 def : RWSysReg<"CNTV_CVAL_EL02",  0b11, 0b101, 0b1110, 0b0011, 0b010>;
 def : RWSysReg<"SPSR_EL12",   0b11, 0b101, 0b0100, 0b, 0b000>;
 def : RWSysReg<"ELR_EL12",0b11, 0b101, 0b0100, 0b, 0b001>;
+let Requires = [{ {AArch64::FeatureCONTEXTIDREL2} }] in {
+  def : RWSysReg<"CONTEXTIDR_EL2",  0b11, 0b100, 0b1101, 0b, 0b001>;
+}
 }
 // v8.2a registers
 //  Op0Op1 CRn CRmOp2
Index: llvm/lib/Target/AArch64/AArch64Subtarget.h
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.h
+++ llvm/lib/Target/AArch64/AArch64Subtarget.h
@@ -57,6 +57,7 @@
 CortexA76,
 CortexA77,
 CortexA78,
+CortexR82,
 CortexX1,
 ExynosM3,
 Falkor,
@@ -84,6 +85,9 @@
   bool HasV8_5aOps = false;
   bool Has

[PATCH] D88590: [clangd] Add benchmark for measuring latency of DecisionForest model.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 updated this revision to Diff 295796.
usaxena95 marked 3 inline comments as done.
usaxena95 added a comment.

Addressed comments: Default seeded the RNG for the benchmark.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88590

Files:
  clang-tools-extra/clangd/benchmarks/CMakeLists.txt
  clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
  
clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp

Index: clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
@@ -0,0 +1,87 @@
+//===--- DecisionForestBenchmark.cpp *- C++ -*-===//
+//
+// Benchmark for code completion ranking latency.
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// Usage:
+//ninja DecisionForestBenchmark && \
+//tools/clang/tools/extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark
+//===--===//
+
+#include "CompletionModel.h"
+#include "benchmark/benchmark.h"
+#include "llvm/ADT/StringRef.h"
+
+#include 
+
+namespace clang {
+namespace clangd {
+namespace {
+std::vector generateRandomDataset(int NumExamples) {
+  auto FlipCoin = [&](float Probability) {
+return rand() % 1000 <= Probability * 1000;
+  };
+  auto RandInt = [&](int Max) { return rand() % Max; };
+  auto RandFloat = [&](float Max = 1.0) {
+return rand() % 1000 / 1000.0 * Max;
+  };
+
+  std::vector Examples;
+  Examples.reserve(NumExamples);
+  for (int I = 0; I < NumExamples; ++I) {
+Example E;
+E.setIsDeprecated(FlipCoin(0.1));   // Boolean.
+E.setIsReservedName(FlipCoin(0.1)); // Boolean.
+E.setIsImplementationDetail(FlipCoin(0.3)); // Boolean.
+E.setNumReferences(RandInt(1)); // Can be large integer.
+E.setSymbolCategory(RandInt(10));   // 10 Symbol Category.
+
+E.setIsNameInContext(FlipCoin(0.5)); // Boolean.
+E.setIsForbidden(FlipCoin(0.1)); // Boolean.
+E.setIsInBaseClass(FlipCoin(0.3));   // Boolean.
+E.setFileProximityDistance(
+FlipCoin(0.1)
+? std::numeric_limits::max()
+: RandInt(20)); // Sometimes file distance is not available.
+E.setSemaFileProximityScore(RandFloat(1)); // Float in range [0,1].
+E.setSymbolScopeDistance(
+FlipCoin(0.1)
+? std::numeric_limits::max()
+: RandInt(20)); // Sometimes scope distance is not available.
+E.setSemaSaysInScope(FlipCoin(0.5));  // Boolean.
+E.setScope(RandInt(4));   // 4 Scopes.
+E.setContextKind(RandInt(32));// 32 Context kinds.
+E.setIsInstanceMember(FlipCoin(0.5)); // Boolean.
+E.setHadContextType(FlipCoin(0.6));   // Boolean.
+E.setHadSymbolType(FlipCoin(0.6));// Boolean.
+E.setTypeMatchesPreferred(FlipCoin(0.5)); // Boolean.
+E.setFilterLength(RandInt(15));
+Examples.push_back(E);
+  }
+  return Examples;
+}
+
+void runDecisionForestPrediciton(const std::vector Examples) {
+  for (const Example &E : Examples)
+Evaluate(E);
+}
+
+static void decisionForestPredict(benchmark::State &State) {
+  for (auto _ : State) {
+srand(0);
+State.PauseTiming();
+const std::vector Examples = generateRandomDataset(100);
+State.ResumeTiming();
+runDecisionForestPrediciton(Examples);
+  }
+}
+BENCHMARK(decisionForestPredict);
+
+} // namespace
+} // namespace clangd
+} // namespace clang
+
+BENCHMARK_MAIN();
\ No newline at end of file
Index: clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
@@ -0,0 +1,9 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
+
+add_benchmark(DecisionForestBenchmark DecisionForestBenchmark.cpp)
+
+target_link_libraries(DecisionForestBenchmark
+  PRIVATE
+  clangDaemon
+  LLVMSupport
+  )
\ No newline at end of file
Index: clang-tools-extra/clangd/benchmarks/CMakeLists.txt
===
--- clang-tools-extra/clangd/benchmarks/CMakeLists.txt
+++ clang-tools-extra/clangd/benchmarks/CMakeLists.txt
@@ -1,9 +1,11 @@
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
 
+add_subdirectory(CompletionModel)
+
 add_benchmark(IndexBenchmark IndexBenchmark.cpp)
 
 target_link_libraries(IndexBenchmark
   PRIVATE
   clangDaemon
   LLVMSupport
-  )
+  )
\ No newline at end of file
___
cfe-commits mailing list

[PATCH] D88590: [clangd] Add benchmark for measuring latency of DecisionForest model.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 updated this revision to Diff 295797.
usaxena95 added a comment.

Added newline at end of files.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88590

Files:
  clang-tools-extra/clangd/benchmarks/CMakeLists.txt
  clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
  
clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp

Index: clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
@@ -0,0 +1,87 @@
+//===--- DecisionForestBenchmark.cpp *- C++ -*-===//
+//
+// Benchmark for code completion ranking latency.
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// Usage:
+//ninja DecisionForestBenchmark && \
+//tools/clang/tools/extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark
+//===--===//
+
+#include "CompletionModel.h"
+#include "benchmark/benchmark.h"
+#include "llvm/ADT/StringRef.h"
+
+#include 
+
+namespace clang {
+namespace clangd {
+namespace {
+std::vector generateRandomDataset(int NumExamples) {
+  auto FlipCoin = [&](float Probability) {
+return rand() % 1000 <= Probability * 1000;
+  };
+  auto RandInt = [&](int Max) { return rand() % Max; };
+  auto RandFloat = [&](float Max = 1.0) {
+return rand() % 1000 / 1000.0 * Max;
+  };
+
+  std::vector Examples;
+  Examples.reserve(NumExamples);
+  for (int I = 0; I < NumExamples; ++I) {
+Example E;
+E.setIsDeprecated(FlipCoin(0.1));   // Boolean.
+E.setIsReservedName(FlipCoin(0.1)); // Boolean.
+E.setIsImplementationDetail(FlipCoin(0.3)); // Boolean.
+E.setNumReferences(RandInt(1)); // Can be large integer.
+E.setSymbolCategory(RandInt(10));   // 10 Symbol Category.
+
+E.setIsNameInContext(FlipCoin(0.5)); // Boolean.
+E.setIsForbidden(FlipCoin(0.1)); // Boolean.
+E.setIsInBaseClass(FlipCoin(0.3));   // Boolean.
+E.setFileProximityDistance(
+FlipCoin(0.1)
+? std::numeric_limits::max()
+: RandInt(20)); // Sometimes file distance is not available.
+E.setSemaFileProximityScore(RandFloat(1)); // Float in range [0,1].
+E.setSymbolScopeDistance(
+FlipCoin(0.1)
+? std::numeric_limits::max()
+: RandInt(20)); // Sometimes scope distance is not available.
+E.setSemaSaysInScope(FlipCoin(0.5));  // Boolean.
+E.setScope(RandInt(4));   // 4 Scopes.
+E.setContextKind(RandInt(32));// 32 Context kinds.
+E.setIsInstanceMember(FlipCoin(0.5)); // Boolean.
+E.setHadContextType(FlipCoin(0.6));   // Boolean.
+E.setHadSymbolType(FlipCoin(0.6));// Boolean.
+E.setTypeMatchesPreferred(FlipCoin(0.5)); // Boolean.
+E.setFilterLength(RandInt(15));
+Examples.push_back(E);
+  }
+  return Examples;
+}
+
+void runDecisionForestPrediciton(const std::vector Examples) {
+  for (const Example &E : Examples)
+Evaluate(E);
+}
+
+static void decisionForestPredict(benchmark::State &State) {
+  for (auto _ : State) {
+srand(0);
+State.PauseTiming();
+const std::vector Examples = generateRandomDataset(100);
+State.ResumeTiming();
+runDecisionForestPrediciton(Examples);
+  }
+}
+BENCHMARK(decisionForestPredict);
+
+} // namespace
+} // namespace clangd
+} // namespace clang
+
+BENCHMARK_MAIN();
Index: clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
@@ -0,0 +1,9 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
+
+add_benchmark(DecisionForestBenchmark DecisionForestBenchmark.cpp)
+
+target_link_libraries(DecisionForestBenchmark
+  PRIVATE
+  clangDaemon
+  LLVMSupport
+  )
Index: clang-tools-extra/clangd/benchmarks/CMakeLists.txt
===
--- clang-tools-extra/clangd/benchmarks/CMakeLists.txt
+++ clang-tools-extra/clangd/benchmarks/CMakeLists.txt
@@ -1,5 +1,7 @@
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
 
+add_subdirectory(CompletionModel)
+
 add_benchmark(IndexBenchmark IndexBenchmark.cpp)
 
 target_link_libraries(IndexBenchmark
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87030: Adapt CastExpr::getSubExprAsWritten to ConstantExpr

[Stephan Bergmann via Phabricator via cfe-commits]

sberg added a comment.

friendly ping


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

https://reviews.llvm.org/D87030

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

[PATCH] D88634: [clangd] Extend the rename API.

[Haojian Wu via Phabricator via cfe-commits]

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

address comment: add the LocalChanges field in RenameResult.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88634

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/test/rename.test
  clang-tools-extra/clangd/unittests/RenameTests.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.h

Index: clang-tools-extra/clangd/unittests/SyncAPI.h
===
--- clang-tools-extra/clangd/unittests/SyncAPI.h
+++ clang-tools-extra/clangd/unittests/SyncAPI.h
@@ -40,9 +40,13 @@
 llvm::Expected>
 runFindDocumentHighlights(ClangdServer &Server, PathRef File, Position Pos);
 
-llvm::Expected runRename(ClangdServer &Server, PathRef File,
-Position Pos, StringRef NewName,
-const clangd::RenameOptions &RenameOpts);
+llvm::Expected runRename(ClangdServer &Server, PathRef File,
+   Position Pos, StringRef NewName,
+   const clangd::RenameOptions &RenameOpts);
+
+llvm::Expected
+runPrepareRename(ClangdServer &Server, PathRef File, Position Pos,
+ const clangd::RenameOptions &RenameOpts);
 
 llvm::Expected
 runFormatFile(ClangdServer &Server, PathRef File, StringRef Code);
Index: clang-tools-extra/clangd/unittests/SyncAPI.cpp
===
--- clang-tools-extra/clangd/unittests/SyncAPI.cpp
+++ clang-tools-extra/clangd/unittests/SyncAPI.cpp
@@ -97,14 +97,22 @@
   return std::move(*Result);
 }
 
-llvm::Expected runRename(ClangdServer &Server, PathRef File,
-Position Pos, llvm::StringRef NewName,
-const RenameOptions &RenameOpts) {
-  llvm::Optional> Result;
+llvm::Expected runRename(ClangdServer &Server, PathRef File,
+   Position Pos, llvm::StringRef NewName,
+   const RenameOptions &RenameOpts) {
+  llvm::Optional> Result;
   Server.rename(File, Pos, NewName, RenameOpts, capture(Result));
   return std::move(*Result);
 }
 
+llvm::Expected runPrepareRename(ClangdServer &Server,
+  PathRef File, Position Pos,
+  const RenameOptions &RenameOpts) {
+  llvm::Optional> Result;
+  Server.prepareRename(File, Pos, RenameOpts, capture(Result));
+  return std::move(*Result);
+}
+
 llvm::Expected
 runFormatFile(ClangdServer &Server, PathRef File, StringRef Code) {
   llvm::Optional> Result;
Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -502,8 +502,8 @@
   auto RenameResult =
   rename({RenamePos, NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
+  ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
+  EXPECT_EQ(applyEdits(std::move(RenameResult->GlobalChanges)).front().second,
 expectedResult(Code, NewName));
 }
   }
@@ -653,8 +653,8 @@
 } else {
   EXPECT_TRUE(bool(Results)) << "rename returned an error: "
  << llvm::toString(Results.takeError());
-  ASSERT_EQ(1u, Results->size());
-  EXPECT_EQ(applyEdits(std::move(*Results)).front().second,
+  ASSERT_EQ(1u, Results->GlobalChanges.size());
+  EXPECT_EQ(applyEdits(std::move(Results->GlobalChanges)).front().second,
 expectedResult(T, NewName));
 }
   }
@@ -683,8 +683,8 @@
   auto RenameResult =
   rename({Code.point(), NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError() << Code.point();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
+  ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
+  EXPECT_EQ(applyEdits(std::move(RenameResult->GlobalChanges)).front().second,
 expectedResult(Code, NewName));
 }
 
@@ -703,6 +703,46 @@
   testing::HasSubstr("not a supported kind"));
 }
 
+TEST(RenameTest, PrepareRename) {
+  Annotations FooH("void func();");
+  Annotations FooCC(R"cpp(
+#include "foo.h"
+void [[fu^nc]]()

[PATCH] D88634: [clangd] Extend the rename API.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/refactor/Rename.h:61
+  Range R;
+  FileEdits Edits;
+};

sammccall wrote:
> hokein wrote:
> > sammccall wrote:
> > > It's slightly awkward to have the half-populated state (may or may not 
> > > contain cross-file results, can't tell without the query).
> > > 
> > > I'd consider redundantly including `Edit LocalChanges` and `FileEdits 
> > > GlobalChanges` with the former always set and the latter empty when 
> > > returned from preparerename.
> > > It's slightly awkward to have the half-populated state (may or may not 
> > > contain cross-file results, can't tell without the query).
> > 
> > I feel this is not too bad, the query is quite trivial, just `Edits.size() 
> > > 1`.
> > 
> > > I'd consider redundantly including Edit LocalChanges and FileEdits 
> > > GlobalChanges with the former always set and the latter empty when 
> > > returned from preparerename.
> > 
> > This change seems nice to get changes for main-file, but I think 
> > `GlobalChanges` should include LocalChanges (otherwise, client side needs 
> > to combine these two when applying the final rename edits)? then we can't 
> > leave the later empty while keeping the former set.
> > 
> > Happy to do the change, but it looks like we don't have usage of 
> > `LocalChanges` so far. In prepareRename, we want main-file occurrences, 
> > `rename` will always return them regardless of single-file or cross-file 
> > rename, so I think `Edits` is efficient. 
> > > It's slightly awkward to have the half-populated state (may or may not 
> > > contain cross-file results, can't tell without the query).
> > 
> > I feel this is not too bad, the query is quite trivial, just `Edits.size() 
> > > 1`.
> This isn't sufficient though: if Edits.size() == 1 then the results may be 
> either complete or incomplete. (Sorry my wording above may have been poor, 
> but this is the distinction I was referring to).
> 
> > > I'd consider redundantly including Edit LocalChanges and FileEdits 
> > > GlobalChanges with the former always set and the latter empty when 
> > > returned from preparerename.
> > 
> > This change seems nice to get changes for main-file, but I think 
> > `GlobalChanges` should include LocalChanges (otherwise, client side needs 
> > to combine these two when applying the final rename edits)? then we can't 
> > leave the later empty while keeping the former set.
> 
> Sure we can. `// If the full set of changes is unknown, this field is empty.`
> 
> > Happy to do the change, but it looks like we don't have usage of 
> > `LocalChanges` so far. In prepareRename, we want main-file occurrences, 
> > `rename` will always return them regardless of single-file or cross-file 
> > rename, so I think `Edits` is efficient. 
> 
> Yes, it's possible to implement correct behavior on top of the current API. 
> It effectively reuses the same field with different semantics/contracts, and 
> the client has enough information to know which contract is in place (and 
> throw away the key in the expected singleton map).
> However I think this is fragile and harder to understand than providing 
> separate fields for the two contracts - using types to distinguish local vs 
> global results makes the data harder to misuse. Given we expect this to be 
> used by embedders, I think it's worth adding the second field.
ah, I see your points, agreed. Added the LocalChanges.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88634

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

[PATCH] D88721: [clangd][lit] Update document-link.test to respect custom resource-dir locations

[Aleksandr Platonov via Phabricator via cfe-commits]

ArcsinX added a comment.

In D88721#2308296 , @sammccall wrote:

>> As far as Windows accepts forward and back slashes
>
> Note we don't rely on windows itself for this support.
> All access through `llvm::sys::fs` APIs on windows ultimately goes through 
> `widenPath` to convert to UTF-16, and this substitutes slashes.
> So LLVM tools do always support `/` on windows and it's fairly common to rely 
> on this for tests (abstraction is hard in lit tests).

I am not sure that understood you correctly, but `widenPath` does nothing for 
me, if I pass mixed-slash path to it.
Code:

  std::string From("C:\\a/b\\c");
  SmallVector To;
  llvm::sys::windows::widenPath(From, To);
  std::wcerr << To.data();

Output:

  C:\a/b\c

So, if we imagine that Windows does not support `/`, then paths with `/` could 
not be opened with `llvm::sys::fs` API.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88721

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

[PATCH] D88665: [ASTImporter][AST] Fix structural equivalency crash on dependent FieldDecl

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

> In D88665#2307562 , @shafik wrote:
>
>> So was the bug we were saying there were falsely equivalent or falsely not 
>> equivalent?
>
> I think the bug is the crash :)

Yes. More specifically, the call of `getBitWidthValue()` caused a segfault with 
release builds and with assertions enabled it caused the mentioned assert on 
the given test code.

In D88665#2307945 , @teemperor wrote:

> Shouldn't this compare the actual width expressions? In other words, this 
> patch wouldn't pass the test below:
>
>   TEST_F(StructuralEquivalenceTemplateTest, DependentFieldDeclDifferentVal) {
> const char *Code1 = "template  class foo { int a : 
> sizeof(A); };";
> const char *Code2 = "template  class foo { int a : 
> sizeof(B); };";
> auto t = makeNamedDecls(Code1, Code2, Lang_CXX03);
> EXPECT_FALSE(testStructuralMatch(t));
>   }



> 

Yes, absolutely, it should. I have updated the patch this way, thanks! However, 
I was struggling to pass the existing lit test (`ASTMerge/struct/test.c`). 
Finally, I decided to remove all the BitField diagnostic code because it was 
already flawed - we called getBitWidthValue unchecked.

Currently, we are totally inconsistent about the diagnostics. Either we should 
emit a diagnostic before all `return false` or we should not ever emit any 
diags. The diagnostics in their current form are misleading, because there 
could be many notes missing. I am not sure how much do you guys value these 
diags in LLDB, but in CTU we simply don't care about them. I'd rather remove 
these diags from the equivalency check code, because they are causing only 
confusion. (Or we should properly implement and test all aspects of the diags.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88665

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

[PATCH] D88665: [ASTImporter][AST] Fix structural equivalency crash on dependent FieldDecl

[Gabor Marton via Phabricator via cfe-commits]

martong updated this revision to Diff 295800.
martong added a comment.

- Delegate to BitWidth Expr matching in case of BitFields


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88665

Files:
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/test/ASTMerge/struct/test.c
  clang/unittests/AST/StructuralEquivalenceTest.cpp

Index: clang/unittests/AST/StructuralEquivalenceTest.cpp
===
--- clang/unittests/AST/StructuralEquivalenceTest.cpp
+++ clang/unittests/AST/StructuralEquivalenceTest.cpp
@@ -976,6 +976,39 @@
   EXPECT_FALSE(testStructuralMatch(t));
 }
 
+TEST_F(StructuralEquivalenceTemplateTest, BitFieldDecl) {
+  const char *Code = "class foo { int a : 2; };";
+  auto t = makeNamedDecls(Code, Code, Lang_CXX03);
+  EXPECT_TRUE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceTemplateTest, BitFieldDeclDifferentWidth) {
+  auto t = makeNamedDecls("class foo { int a : 2; };",
+  "class foo { int a : 4; };", Lang_CXX03);
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceTemplateTest, DependentBitFieldDecl) {
+  const char *Code = "template  class foo { int a : sizeof(T); };";
+  auto t = makeNamedDecls(Code, Code, Lang_CXX03);
+  EXPECT_TRUE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceTemplateTest, DependentBitFieldDeclDifferentVal) {
+  auto t = makeNamedDecls(
+  "template  class foo { int a : sizeof(A); };",
+  "template  class foo { int a : sizeof(B); };",
+  Lang_CXX03);
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
+TEST_F(StructuralEquivalenceTemplateTest, DependentBitFieldDeclDifferentVal2) {
+  auto t = makeNamedDecls(
+  "template  class foo { int a : sizeof(A); };",
+  "template  class foo { int a : sizeof(A) + 1; };", Lang_CXX03);
+  EXPECT_FALSE(testStructuralMatch(t));
+}
+
 TEST_F(StructuralEquivalenceTemplateTest, ExplicitBoolSame) {
   auto Decls = makeNamedDecls(
   "template  struct foo {explicit(b) foo(int);};",
Index: clang/test/ASTMerge/struct/test.c
===
--- clang/test/ASTMerge/struct/test.c
+++ clang/test/ASTMerge/struct/test.c
@@ -21,16 +21,6 @@
 // CHECK: struct1.c:27:8: note: no corresponding field here
 // CHECK: struct2.c:24:31: warning: external variable 'x4' declared with incompatible types in different translation units ('struct S4' vs. 'struct S4')
 // CHECK: struct1.c:27:22: note: declared here with type 'struct S4'
-// CHECK: struct1.c:33:8: warning: type 'struct S6' has incompatible definitions in different translation units
-// CHECK: struct1.c:33:33: note: bit-field 'j' with type 'unsigned int' and length 8 here
-// CHECK: struct2.c:30:33: note: field 'j' is not a bit-field
-// CHECK: struct2.c:30:38: warning: external variable 'x6' declared with incompatible types in different translation units ('struct S6' vs. 'struct S6')
-// CHECK: struct1.c:33:42: note: declared here with type 'struct S6'
-// CHECK: struct1.c:36:8: warning: type 'struct S7' has incompatible definitions in different translation units
-// CHECK: struct1.c:36:33: note: bit-field 'j' with type 'unsigned int' and length 8 here
-// CHECK: struct2.c:33:33: note: bit-field 'j' with type 'unsigned int' and length 16 here
-// CHECK: struct2.c:33:43: warning: external variable 'x7' declared with incompatible types in different translation units ('struct S7' vs. 'struct S7')
-// CHECK: struct1.c:36:42: note: declared here with type 'struct S7'
 // CHECK: struct1.c:56:10: warning: type 'struct DeeperError' has incompatible definitions in different translation units
 // CHECK: struct1.c:56:35: note: field 'f' has type 'int' here
 // CHECK: struct2.c:53:37: note: field 'f' has type 'float' here
@@ -52,4 +42,4 @@
 // CHECK: struct2.c:129:9: note: field 'S' has type 'struct (anonymous struct at [[PATH_TO_INPUTS]]struct2.c:127:7)' here
 // CHECK: struct2.c:138:3: warning: external variable 'x16' declared with incompatible types in different translation units ('struct DeepUnnamedError' vs. 'struct DeepUnnamedError')
 // CHECK: struct1.c:141:3: note: declared here with type 'struct DeepUnnamedError'
-// CHECK: 20 warnings generated
+// CHECK: 17 warnings generated
Index: clang/lib/AST/ASTStructuralEquivalence.cpp
===
--- clang/lib/AST/ASTStructuralEquivalence.cpp
+++ clang/lib/AST/ASTStructuralEquivalence.cpp
@@ -1256,48 +1256,9 @@
 return false;
   }
 
-  if (Field1->isBitField() != Field2->isBitField()) {
-if (Context.Complain) {
-  Context.Diag2(
-  Owner2->getLocation(),
-  Context.getApplicableDiagnostic(diag::err_odr_tag_type_inconsistent))
-  << Context.ToCtx.getTypeDeclType(Owner2);
-  if (Field1->isBitField()) {
-Context.Diag1(Field1->getLocation(), diag::note_odr_bit_field)
-<< Field

[PATCH] D88199: Introduce and use a new section type for the bb_addr_map section.

[Rahman Lavaee via Phabricator via cfe-commits]

rahmanl updated this revision to Diff 295666.
rahmanl added a comment.
Herald added subscribers: libcxx-commits, openmp-commits, lldb-commits, 
Sanitizers, cfe-commits, tatianashp, wenlei, ThomasRaoux, AlexeySotkin, 
msifontes, sstefan1, jurahul, Kayjukh, grosul1, Joonsoo, stephenneuendorffer, 
kerbowa, liufengdb, aartbik, lucyrfox, mgester, arpith-jacob, csigg, 
nicolasvasilache, antiagainst, shauheen, rriddle, mehdi_amini, usaxena95, 
s.egerton, dmgreen, Jim, ormris, mstorsjo, kadircet, jfb, arphaman, dexonsmith, 
steven_wu, atanasyan, mgrang, jrtc27, gbedwell, delcypher, simoncook, kbarton, 
aheejin, fedor.sergeev, jgravelle-google, arichardson, sbc100, mgorny, 
nhaehnle, jvesely, nemanjai, emaste, dylanmckay, dschuff, arsenm.
Herald added a reviewer: espindola.
Herald added a reviewer: andreadb.
Herald added a reviewer: alexshap.
Herald added a reviewer: jdoerfert.
Herald added a reviewer: mravishankar.
Herald added a reviewer: antiagainst.
Herald added a reviewer: nicolasvasilache.
Herald added a reviewer: herhut.
Herald added a reviewer: rriddle.
Herald added a reviewer: aartbik.
Herald added a reviewer: ftynse.
Herald added a reviewer: silvas.
Herald added a reviewer: JDevlieghere.
Herald added projects: clang, Sanitizers, LLDB, libc++, OpenMP, libc++abi, MLIR.
Herald added a reviewer: libc++.
Herald added a reviewer: libc++abi.

- Rename section to __llvm_bb_addr_map.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88199

Files:
  clang-tools-extra/clang-tidy/android/ComparisonInTempFailureRetryCheck.cpp
  clang-tools-extra/clang-tidy/android/ComparisonInTempFailureRetryCheck.h
  clang-tools-extra/clangd/URI.cpp
  clang-tools-extra/clangd/quality/CompletionModelCodegen.py
  clang-tools-extra/clangd/test/check-fail.test
  clang-tools-extra/clangd/test/check.test
  clang-tools-extra/clangd/tool/CMakeLists.txt
  clang-tools-extra/clangd/tool/Check.cpp
  clang-tools-extra/clangd/tool/ClangdMain.cpp
  
clang-tools-extra/docs/clang-tidy/checks/android-comparison-in-temp-failure-retry.rst
  
clang-tools-extra/test/clang-tidy/checkers/android-comparison-in-temp-failure-retry-custom-macro.c
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/AST/Decl.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Driver/ToolChains/AIX.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Nodes.cpp
  clang/lib/Tooling/Syntax/Synthesis.cpp
  clang/test/CodeGen/builtin-nan-exception.c
  clang/test/CodeGen/builtin-nan-legacy.c
  clang/test/CodeGen/mips-unsupported-nan.c
  clang/test/CodeGenOpenCL/amdgpu-attrs.cl
  clang/test/CodeGenOpenCL/fpmath.cl
  clang/test/Driver/aix-ld.c
  clang/test/Headers/arm-neon-header.c
  clang/test/SemaCXX/cxx20-constinit.cpp
  clang/test/SemaCXX/warn-overaligned-type-thrown.cpp
  clang/unittests/Format/SortIncludesTest.cpp
  clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
  clang/unittests/Tooling/Syntax/SynthesisTest.cpp
  compiler-rt/cmake/base-config-ix.cmake
  compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc
  compiler-rt/lib/sanitizer_common/sanitizer_platform_interceptors.h
  compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_stacktrace.h
  compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cpp
  compiler-rt/test/asan/TestCases/Posix/no_asan_gen_globals.c
  compiler-rt/test/sanitizer_common/TestCases/Linux/ptsname.c
  debuginfo-tests/CMakeLists.txt
  debuginfo-tests/lit.cfg.py
  debuginfo-tests/lit.site.cfg.py.in
  debuginfo-tests/llvm-prettyprinters/gdb/lit.local.cfg
  debuginfo-tests/llvm-prettyprinters/gdb/llvm-support.cpp
  debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.cpp
  debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.gdb
  flang/include/flang/Evaluate/characteristics.h
  flang/include/flang/Evaluate/type.h
  flang/include/flang/Lower/PFTBuilder.h
  flang/include/flang/Semantics/symbol.h
  flang/include/flang/Semantics/tools.h
  flang/lib/Evaluate/characteristics.cpp
  flang/lib/Evaluate/fold-implementation.h
  flang/lib/Evaluate/tools.cpp
  flang/lib/Evaluate/type.cpp
  flang/lib/Lower/CMakeLists.txt
  flang/lib/Lower/PFTBuilder.cpp
  flang/lib/Parser/unparse.cpp
  flang/lib/Semantics/check-call.cpp
  flang/lib/Semantics/check-declarations.cpp
  flang/lib/Semantics/mod-file.cpp
  flang/lib/Semantics/mod-file.h
  flang/lib/Semantics/pointer-assignment.cpp
  flang/lib/Semantics/resolve-names.cpp
  flang/lib/Semantics/symbol.cpp
  flang/lib/Semantics/tools.cpp
  flang/runtime/descriptor-io.h
  flang/runtime/edit-output.cpp
  flang/runtime/format-implementation.h
  flang/runtime/io-api.cpp
  flang/runtime/io-api.h
  flang/runtime/io-stmt.cpp
  flang/runtime/io-

Re: [PATCH] D88721: [clangd][lit] Update document-link.test to respect custom resource-dir locations

[Kadir Çetinkaya via cfe-commits]

not that i know of.

On Fri, Oct 2, 2020 at 12:34 PM Aleksandr Platonov via Phabricator <
revi...@reviews.llvm.org> wrote:

> ArcsinX added a comment.
>
> Just a question.
> On Windows `%resource_dir/..` looks a bit inconsistent after substitution
> (`d:\llvm-project\build\lib\clang\12.0.0\include/..`), but this test passes.
> As far as Windows accepts forward and back slashes, I expect something
> like this `%/resource_dir/..` to be consistent across all platforms.
> Are there any plans to add `%/resource_dir` substitution as it was done
> for %T, %s, etc?
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D88721/new/
>
> https://reviews.llvm.org/D88721
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88199: Introduce and use a new section type for the bb_addr_map section.

[Rahman Lavaee via Phabricator via cfe-commits]

rahmanl updated this revision to Diff 295668.
rahmanl added a comment.

Diff reupload.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88199

Files:
  llvm/include/llvm/BinaryFormat/ELF.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/CodeGen/BasicBlockSections.cpp
  llvm/lib/MC/MCObjectFileInfo.cpp
  llvm/lib/MC/MCParser/ELFAsmParser.cpp
  llvm/lib/MC/MCSectionELF.cpp
  llvm/lib/Object/ELF.cpp
  llvm/test/CodeGen/X86/basic-block-sections-labels-functions-sections.ll
  llvm/test/CodeGen/X86/basic-block-sections-labels.ll
  llvm/test/MC/AsmParser/llvm_section_types.s

Index: llvm/test/MC/AsmParser/llvm_section_types.s
===
--- /dev/null
+++ llvm/test/MC/AsmParser/llvm_section_types.s
@@ -0,0 +1,27 @@
+## Verify that LLVM-specific section types are correctly inferred from assembly input.
+# RUN: llvm-mc -triple i386-pc-linux-gnu -filetype=obj -o %t %s
+# RUN: llvm-readobj -S - < %t | FileCheck %s
+.section.section1,"",@llvm_bb_addr_map
+.byte 1
+.section.section2,"",@llvm_call_graph_profile
+.byte 1
+.section.section3,"",@llvm_odrtab
+.byte 1
+.section.section4,"",@llvm_linker_options
+.byte 1
+.section.section5,"",@llvm_sympart
+.byte 1
+.section.section6,"",@llvm_dependent_libraries
+.byte 1
+# CHECK:Name: .section1
+# CHECK-NEXT:   Type: SHT_LLVM_BB_ADDR_MAP
+# CHECK:Name: .section2
+# CHECK-NEXT:   Type: SHT_LLVM_CALL_GRAPH_PROFILE
+# CHECK:Name: .section3
+# CHECK-NEXT:   Type: SHT_LLVM_ODRTAB
+# CHECK:Name: .section4
+# CHECK-NEXT:   Type: SHT_LLVM_LINKER_OPTIONS
+# CHECK:Name: .section5
+# CHECK-NEXT:   Type: SHT_LLVM_SYMPART
+# CHECK:Name: .section6
+# CHECK-NEXT:   Type: SHT_LLVM_DEPENDENT_LIBRARIES
Index: llvm/test/CodeGen/X86/basic-block-sections-labels.ll
===
--- llvm/test/CodeGen/X86/basic-block-sections-labels.ll
+++ llvm/test/CodeGen/X86/basic-block-sections-labels.ll
@@ -39,7 +39,7 @@
 ; CHECK-LABEL:	.LBB_END0_3:
 ; CHECK-LABEL:	.Lfunc_end0:
 
-; CHECK:	.section	.bb_addr_map,"o",@progbits,.text
+; CHECK:	.section	__llvm_bb_addr_map,"o",@llvm_bb_addr_map,.text
 ; CHECK-NEXT:	.quad	.Lfunc_begin0
 ; CHECK-NEXT:	.byte	4
 ; CHECK-NEXT:	.uleb128 .Lfunc_begin0-.Lfunc_begin0
Index: llvm/test/CodeGen/X86/basic-block-sections-labels-functions-sections.ll
===
--- llvm/test/CodeGen/X86/basic-block-sections-labels-functions-sections.ll
+++ llvm/test/CodeGen/X86/basic-block-sections-labels-functions-sections.ll
@@ -5,11 +5,11 @@
 define dso_local i32 @_Z3barv() {
   ret i32 0
 }
-;; Check we add SHF_LINK_ORDER for .bb_addr_map and link it with the corresponding .text sections.
+;; Check we add SHF_LINK_ORDER for __llvm_bb_addr_map and link it with the corresponding .text sections.
 ; CHECK:		.section .text._Z3barv,"ax",@progbits
 ; CHECK-LABEL:	_Z3barv:
 ; CHECK-NEXT:	[[BAR_BEGIN:.Lfunc_begin[0-9]+]]:
-; CHECK:		.section .bb_addr_map,"o",@progbits,.text._Z3barv{{$}}
+; CHECK:		.section __llvm_bb_addr_map,"o",@llvm_bb_addr_map,.text._Z3barv{{$}}
 ; CHECK-NEXT:		.quad [[BAR_BEGIN]]
 
 
@@ -20,16 +20,16 @@
 ; CHECK:		.section .text._Z3foov,"ax",@progbits
 ; CHECK-LABEL:	_Z3foov:
 ; CHECK-NEXT:	[[FOO_BEGIN:.Lfunc_begin[0-9]+]]:
-; CHECK:		.section  .bb_addr_map,"o",@progbits,.text._Z3foov{{$}}
+; CHECK:		.section  __llvm_bb_addr_map,"o",@llvm_bb_addr_map,.text._Z3foov{{$}}
 ; CHECK-NEXT:		.quad [[FOO_BEGIN]]
 
 
 define linkonce_odr dso_local i32 @_Z4fooTIiET_v() comdat {
   ret i32 0
 }
-;; Check we add .bb_addr_map section to a COMDAT group with the corresponding .text section if such a COMDAT exists.
+;; Check we add __llvm_bb_addr_map section to a COMDAT group with the corresponding .text section if such a COMDAT exists.
 ; CHECK:		.section .text._Z4fooTIiET_v,"axG",@progbits,_Z4fooTIiET_v,comdat
 ; CHECK-LABEL:	_Z4fooTIiET_v:
 ; CHECK-NEXT:	[[FOOCOMDAT_BEGIN:.Lfunc_begin[0-9]+]]:
-; CHECK:		.section .bb_addr_map,"Go",@progbits,_Z4fooTIiET_v,comdat,.text._Z4fooTIiET_v{{$}}
+; CHECK:		.section __llvm_bb_addr_map,"Go",@llvm_bb_addr_map,_Z4fooTIiET_v,comdat,.text._Z4fooTIiET_v{{$}}
 ; CHECK-NEXT:		.quad [[FOOCOMDAT_BEGIN]]
Index: llvm/lib/Object/ELF.cpp
===
--- llvm/lib/Object/ELF.cpp
+++ llvm/lib/Object/ELF.cpp
@@ -276,6 +276,7 @@
 STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_SYMPART);
 STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_PART_EHDR);
 STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_PART_PHDR);
+STRINGIFY_ENUM_CASE(ELF, SHT_LLVM_BB_ADDR_MAP);
 STRINGIFY_ENUM_CASE(ELF, SHT_GNU_ATTRIBUTES);
 STRINGIFY_ENUM_CASE(ELF, SHT_GNU_HASH);
 STRINGIFY_ENUM_CASE(ELF, SHT_GNU_verdef);
Index: llvm/lib/MC/MCSectionELF.cpp
===
--- llvm/lib/MC/MCSect

[PATCH] D88730: [HIP] Fix default output file for -E

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added a reviewer: tra.
yaxunl requested review of this revision.

By convention the default output file for -E is "-" (stdout).
This is expected by tools like ccache, which uses output
of -E to determine if a file and its dependence has changed.

Currently clang does not use stdout as default output file for -E
for HIP, which causes ccache not working.

This patch fixes that.


https://reviews.llvm.org/D88730

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/hip-output-file-name.hip


Index: clang/test/Driver/hip-output-file-name.hip
===
--- clang/test/Driver/hip-output-file-name.hip
+++ clang/test/Driver/hip-output-file-name.hip
@@ -7,3 +7,27 @@
 // RUN: 2>&1 | FileCheck %s
 
 // CHECK: {{.*}}clang-offload-bundler{{.*}}"-outputs=hip-output-file-name.o"
+
+// Check -E default output is "-" (stdout).
+
+// RUN: %clang -### -E -target x86_64-linux-gnu \
+// RUN:   --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN: 2>&1 | FileCheck -check-prefixes=DASH %s
+
+// RUN: %clang -### -E -save-temps -target x86_64-linux-gnu \
+// RUN:   --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN: 2>&1 | FileCheck -check-prefixes=DASH %s
+
+// DASH: {{.*}}clang-offload-bundler{{.*}}"-outputs=-"
+
+// Check -E with -o.
+
+// RUN: %clang -### -E -o test.cui -target x86_64-linux-gnu \
+// RUN:   --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN: 2>&1 | FileCheck -check-prefixes=OUT %s
+
+// RUN: %clang -### -E -o test.cui -save-temps -target x86_64-linux-gnu \
+// RUN:   --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN: 2>&1 | FileCheck -check-prefixes=OUT %s
+
+// OUT: {{.*}}clang-offload-bundler{{.*}}"-outputs=test.cui"
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -4604,6 +4604,17 @@
   return Args.MakeArgString(Filename.c_str());
 }
 
+static bool HasPreprocessOutput(const Action &JA) {
+  if (isa(JA))
+return true;
+  if (isa(JA) && isa(JA.getInputs()[0]))
+return true;
+  if (isa(JA) &&
+  HasPreprocessOutput(*(JA.getInputs()[0])))
+return true;
+  return false;
+}
+
 const char *Driver::GetNamedOutputPath(Compilation &C, const JobAction &JA,
const char *BaseInput,
StringRef BoundArch, bool AtTopLevel,
@@ -4629,8 +4640,9 @@
   }
 
   // Default to writing to stdout?
-  if (AtTopLevel && !CCGenDiagnostics && isa(JA))
+  if (AtTopLevel && !CCGenDiagnostics && HasPreprocessOutput(JA)) {
 return "-";
+  }
 
   // Is this the assembly listing for /FA?
   if (JA.getType() == types::TY_PP_Asm &&


Index: clang/test/Driver/hip-output-file-name.hip
===
--- clang/test/Driver/hip-output-file-name.hip
+++ clang/test/Driver/hip-output-file-name.hip
@@ -7,3 +7,27 @@
 // RUN: 2>&1 | FileCheck %s
 
 // CHECK: {{.*}}clang-offload-bundler{{.*}}"-outputs=hip-output-file-name.o"
+
+// Check -E default output is "-" (stdout).
+
+// RUN: %clang -### -E -target x86_64-linux-gnu \
+// RUN:   --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN: 2>&1 | FileCheck -check-prefixes=DASH %s
+
+// RUN: %clang -### -E -save-temps -target x86_64-linux-gnu \
+// RUN:   --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN: 2>&1 | FileCheck -check-prefixes=DASH %s
+
+// DASH: {{.*}}clang-offload-bundler{{.*}}"-outputs=-"
+
+// Check -E with -o.
+
+// RUN: %clang -### -E -o test.cui -target x86_64-linux-gnu \
+// RUN:   --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN: 2>&1 | FileCheck -check-prefixes=OUT %s
+
+// RUN: %clang -### -E -o test.cui -save-temps -target x86_64-linux-gnu \
+// RUN:   --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN: 2>&1 | FileCheck -check-prefixes=OUT %s
+
+// OUT: {{.*}}clang-offload-bundler{{.*}}"-outputs=test.cui"
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -4604,6 +4604,17 @@
   return Args.MakeArgString(Filename.c_str());
 }
 
+static bool HasPreprocessOutput(const Action &JA) {
+  if (isa(JA))
+return true;
+  if (isa(JA) && isa(JA.getInputs()[0]))
+return true;
+  if (isa(JA) &&
+  HasPreprocessOutput(*(JA.getInputs()[0])))
+return true;
+  return false;
+}
+
 const char *Driver::GetNamedOutputPath(Compilation &C, const JobAction &JA,
const char *BaseInput,
StringRef BoundArch, bool AtTopLevel,
@@ -4629,8 +4640,9 @@
   }
 
   // Default to writing to stdout?
-  if (AtTopLevel && !CCGenDiagnostics && isa(JA))
+  if (AtTopLevel && !CCGenDiagnostics && HasPreprocessOutput(JA)) {
 return "-";
+  }
 
   // Is this the assembly listing for /FA?
   if (

[PATCH] D88721: [clangd][lit] Update document-link.test to respect custom resource-dir locations

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D88721#2308361 , @ArcsinX wrote:

> In D88721#2308296 , @sammccall wrote:
>
>>> As far as Windows accepts forward and back slashes
>>
>> Note we don't rely on windows itself for this support.
>> All access through `llvm::sys::fs` APIs on windows ultimately goes through 
>> `widenPath` to convert to UTF-16, and this substitutes slashes.
>> So LLVM tools do always support `/` on windows and it's fairly common to 
>> rely on this for tests (abstraction is hard in lit tests).
>
> I am not sure that understood you correctly, but `widenPath` does nothing for 
> me, if I pass mixed-slash path to it.

Ack, you're right. I've looked at this before, and was looking at this line:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Support/Windows/Path.inc#L103
But in the common case, we've already exited by then, so you're absolutely 
right...

> Code:
>
>   std::string From("C:\\a/b\\c");
>   SmallVector To;
>   llvm::sys::windows::widenPath(From, To);
>   std::wcerr << To.data();
>
> Output:
>
>   C:\a/b\c
>
> So, if we imagine that Windows does not support `/`, then paths with `/` 
> could not be opened with `llvm::sys::fs` API.

But at a higher level, ISTM the purpose of `widenPath` is exactly to produce a 
path that the win32 APIs will accept, including if the input has `/` (as shown 
by the long-path case I was confused by).
So the contract of the llvm functions ensuring that forward slashes are safe 
still seems to be there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88721

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

[PATCH] D88634: [clangd] Extend the rename API.

[Sam McCall via Phabricator via cfe-commits]

sammccall accepted this revision.
sammccall added a comment.

LG, thanks!




Comment at: clang-tools-extra/clangd/refactor/Rename.h:62
+  // Edits for the current main file.
+  Edit LocalChanges;
+  // Complete edits for the rename, including LocalChanges.

this could just be a vector, as we don't have a use case for the 
replacements and it avoids the issue of what to replace with. Up to you though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88634

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

[PATCH] D88734: [HIP] Align device binary

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added reviewers: tra, ashi1.
yaxunl requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added a subscriber: sstefan1.

To facilitate faster loading of device binaries and share them among processes,
HIP runtime favors their alignment being 4096 bytes. HIP runtime can load
unaligned device binaries, however, aligning them at 4096 bytes results in
faster loading and less shared memory usage.

This patch adds an option -bundle-align to clang-offload-bundler which allows
bundles to be aligned at specified alignment. By default it is 1, which is NFC
compared to existing format.

This patch then aligns embedded fat binary and device binary inside fat binary
at 4096 bytes.

It has been verified this change does not cause significant overall file size 
increase
for typical HIP applications (less than 1%).


https://reviews.llvm.org/D88734

Files:
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/test/CodeGenCUDA/device-stub.cu
  clang/test/Driver/clang-offload-bundler.c
  clang/test/Driver/hip-toolchain-no-rdc.hip
  clang/test/Driver/hip-toolchain-rdc.hip
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -94,6 +94,11 @@
  "instead of actually executing them - for testing purposes.\n"),
 cl::init(false), cl::cat(ClangOffloadBundlerCategory));
 
+static cl::opt
+BundleAlignment("bundle-align",
+cl::desc("Alignment of bundle for binary files"),
+cl::init(1), cl::cat(ClangOffloadBundlerCategory));
+
 /// Magic string that marks the existence of offloading data.
 #define OFFLOAD_BUNDLER_MAGIC_STR "__CLANG_OFFLOAD_BUNDLE__"
 
@@ -223,6 +228,9 @@
   StringMap::iterator CurBundleInfo;
   StringMap::iterator NextBundleInfo;
 
+  /// Current bundle target to be written.
+  std::string CurWriteBundleTarget;
+
 public:
   BinaryFileHandler() : FileHandler() {}
 
@@ -337,10 +345,12 @@
 unsigned Idx = 0;
 for (auto &T : TargetNames) {
   MemoryBuffer &MB = *Inputs[Idx++];
+  HeaderSize = alignTo(HeaderSize, BundleAlignment);
   // Bundle offset.
   Write8byteIntegerToBuffer(OS, HeaderSize);
   // Size of the bundle (adds to the next bundle's offset)
   Write8byteIntegerToBuffer(OS, MB.getBufferSize());
+  BundlesInfo[T] = BundleInfo(MB.getBufferSize(), HeaderSize);
   HeaderSize += MB.getBufferSize();
   // Size of the triple
   Write8byteIntegerToBuffer(OS, T.size());
@@ -351,6 +361,7 @@
   }
 
   Error WriteBundleStart(raw_fd_ostream &OS, StringRef TargetTriple) final {
+CurWriteBundleTarget = TargetTriple.str();
 return Error::success();
   }
 
@@ -359,6 +370,8 @@
   }
 
   Error WriteBundle(raw_fd_ostream &OS, MemoryBuffer &Input) final {
+auto BI = BundlesInfo[CurWriteBundleTarget];
+OS.seek(BI.Offset);
 OS.write(Input.getBufferStart(), Input.getBufferSize());
 return Error::success();
   }
Index: clang/test/Driver/hip-toolchain-rdc.hip
===
--- clang/test/Driver/hip-toolchain-rdc.hip
+++ clang/test/Driver/hip-toolchain-rdc.hip
@@ -8,10 +8,14 @@
 // RUN:   --hip-device-lib-path=%S/Inputs/hip_multiple_inputs/lib1 \
 // RUN:   --hip-device-lib-path=%S/Inputs/hip_multiple_inputs/lib2 \
 // RUN:   -fuse-ld=lld -fgpu-rdc -nogpuinc \
+// RUN:   -fhip-dump-offload-linker-script \
 // RUN:   %S/Inputs/hip_multiple_inputs/a.cu \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s
 
+// check code object alignment in dumped llvm-mc input
+// CHECK: .p2align 12
+
 // emit objects for host side path
 // CHECK: [[CLANG:".*clang.*"]] "-cc1" "-triple" "x86_64-unknown-linux-gnu"
 // CHECK-SAME: "-aux-triple" "amdgcn-amd-amdhsa"
@@ -87,6 +91,7 @@
 
 // combine images generated into hip fat binary object
 // CHECK: [[BUNDLER:".*clang-offload-bundler"]] "-type=o"
+// CHECK-SAME: "-bundle-align=4096"
 // CHECK-SAME: "-targets={{.*}},hip-amdgcn-amd-amdhsa-gfx803,hip-amdgcn-amd-amdhsa-gfx900"
 // CHECK-SAME: "-inputs={{.*}},[[IMG_DEV1]],[[IMG_DEV2]]" "-outputs=[[BUNDLE:.*hipfb]]"
 
Index: clang/test/Driver/hip-toolchain-no-rdc.hip
===
--- clang/test/Driver/hip-toolchain-no-rdc.hip
+++ clang/test/Driver/hip-toolchain-no-rdc.hip
@@ -81,6 +81,7 @@
 //
 
 // CHECK: [[BUNDLER:".*clang-offload-bundler"]] "-type=o"
+// CHECK-SAME: "-bundle-align=4096"
 // CHECK-SAME: "-targets={{.*}},hip-amdgcn-amd-amdhsa-gfx803,hip-amdgcn-amd-amdhsa-gfx900"
 // CHECK-SAME: "-inputs={{.*}},[[IMG_DEV_A_803]],[[IMG_DEV_A_900]]" "-outputs=[[BUNDLE_A:.*hipfb]]"
 
@@ -143,6 +144,7 @@
 //
 
 // CHECK: [[BUNDLER:".*clang-offload-bundler"]]

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:33
+
+  for (const FunctionDecl *D : Node.redecls())
+if (D->getASTContext().getSourceManager().isInSystemHeader(

balazske wrote:
> aaron.ballman wrote:
> > I'm not certain I understand why we're looking through the entire 
> > redeclaration chain to see if the function is ever mentioned in a system 
> > header. I was expecting we'd look at the expansion location of the 
> > declaration and see if that's in a system header, which is already handled 
> > by the `isExpansionInSystemHeader()` matcher. Similar below.
> This function is called from ` SignalHandlerCheck::check` when any function 
> call is found. So the check for system header is needed. It was unclear to me 
> what the "expansion location" means but it seems to work if using that 
> expansion location and checking for system header, instead of this loop. I 
> will update the code.
> This function is called from  SignalHandlerCheck::check when any function 
> call is found. So the check for system header is needed. 

The check for the system header isn't what I was concerned by, it was the fact 
that we're walking the entire redeclaration chain to see if *any* declaration 
is in a system header that I don't understand the purpose of.

> It was unclear to me what the "expansion location" means but it seems to work 
> if using that expansion location and checking for system header, instead of 
> this loop. I will update the code.

The spelling location is where the user wrote the code and the expansion 
location is where the macro name is written, but thinking on it harder, that 
shouldn't matter for this situation as either location would be in the system 
header anyway.



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-sig30-c.rst:13
+(for ``signal`` there are additional conditions that are not checked).
+Every other system call is considered as non asynchronous-safe by the checker.
+

balazske wrote:
> aaron.ballman wrote:
> > I would document this as: `Any function that cannot be determined to be an 
> > asynchronous-safe function call is assumed to be non-asynchronous-safe by 
> > the checker, including function calls for which only the declaration of the 
> > called function is visible.`
> "including function calls for which only the declaration of the called 
> function is visible": Is this the better approach? The checker does not make 
> warning for such functions in the current state.
Ooh, thank you for calling this out, you're right that I wasn't describing the 
current behavior.

My thinking is: most system functions aren't safe to call within a signal 
handler and user-defined functions will eventually call a system function more 
often than they won't, so assuming a function for which you can't see the 
definition is not signal safe is a somewhat reasonable assumption, but may have 
false positives. However, under the assumption that most signal handlers are 
working as intended, then perhaps it's better to assume that the author of such 
unseen function bodies did the right thing as you're doing, but then you may 
have false negatives.

Given that the CERT rules are about security, I think it's better to err on the 
side of more false positives than more false negatives, but it's open for 
debate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87449

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

[PATCH] D88314: Added llvm-string-referencing check

[Bogdan Serea via Phabricator via cfe-commits]

bogser01 updated this revision to Diff 295810.
bogser01 added a comment.

Removed residual conflict markers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88314

Files:
  clang-tools-extra/clang-tidy/llvm/CMakeLists.txt
  clang-tools-extra/clang-tidy/llvm/LLVMTidyModule.cpp
  clang-tools-extra/clang-tidy/llvm/StringReferencingCheck.cpp
  clang-tools-extra/clang-tidy/llvm/StringReferencingCheck.h
  clang-tools-extra/docs/clang-tidy/Contributing.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/llvm-string-referencing.rst
  clang-tools-extra/test/clang-tidy/checkers/llvm-string-referencing.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/llvm-string-referencing.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/llvm-string-referencing.cpp
@@ -0,0 +1,66 @@
+// RUN: %check_clang_tidy %s llvm-string-referencing %t
+
+namespace std {
+class string {};
+class u18_string_t;
+
+} // namespace std
+
+namespace llvm {
+class StringRef;
+} // namespace llvm
+
+class String;
+
+namespace A {
+using namespace std;
+void f(const string &P);
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void f(llvm::StringRef P);{{$}}
+} // namespace A
+
+namespace B {
+using std::string;
+void f1(const string &P);
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void f1(llvm::StringRef P);{{$}}
+} // namespace B
+
+void f2(std::string, int, const std::string &);
+// CHECK-MESSAGES: :[[@LINE-1]]:27: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void f2(std::string, int, llvm::StringRef );{{$}}
+void f2(std::string P, int x, const std::string &P2) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+  // CHECK-FIXES: void f2(std::string P, int x, llvm::StringRef P2) {{{$}}
+  return;
+}
+
+void f3(const std::string &P1, const std::string &P2);
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-MESSAGES: :[[@LINE-2]]:32: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void f3(llvm::StringRef P1, llvm::StringRef P2);{{$}}
+
+struct St {
+  void operator=(const std::string &Val) const {
+// CHECK-MESSAGES: :[[@LINE-1]]:18: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void operator=(llvm::StringRef Val) const {{{$}}
+return;
+  }
+};
+
+void f7(const std::string &);
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void f7(llvm::StringRef );{{$}}
+
+// Functions below this line should not trigger the check
+void f1(std::string &P);
+
+void f4(std::string *P);
+
+void f5(String &P);
+
+void f6(llvm::StringRef P);
+
+void f9(std::u18_string_t &P);
+
+void f10(const std::string &&P);
Index: clang-tools-extra/docs/clang-tidy/checks/llvm-string-referencing.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/llvm-string-referencing.rst
@@ -0,0 +1,6 @@
+.. title:: clang-tidy - llvm-string-referencing
+
+llvm-string-referencing
+===
+
+FIXME: Describe what patterns does the check detect and why. Give examples.
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -192,6 +192,7 @@
`llvm-namespace-comment `_,
`llvm-prefer-isa-or-dyn-cast-in-conditionals `_, "Yes"
`llvm-prefer-register-over-unsigned `_, "Yes"
+   `llvm-string-referencing `_, "Yes"
`llvm-twine-local `_, "Yes"
`llvmlibc-callee-namespace `_,
`llvmlibc-implementation-in-namespace `_,
Index: clang-tools-extra/docs/clang-tidy/Contributing.rst
===
--- clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -201,8 +201,13 @@
   }
 
   void AwesomeFunctionNamesCheck::check(const MatchFinder::MatchResult &Result) {
+<<< HEAD
+const auto *MatchedDecl = Result.Nodes.getNodeAs("x");
+if ((!MatchedDecl->getIdentifier()) || MatchedDecl->getName().startswith("awesome_"))
+

[PATCH] D88314: Added llvm-string-referencing check

[Bogdan Serea via Phabricator via cfe-commits]

bogser01 updated this revision to Diff 295811.
bogser01 added a comment.

Remove conflict markers 2


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88314

Files:
  clang-tools-extra/clang-tidy/llvm/CMakeLists.txt
  clang-tools-extra/clang-tidy/llvm/LLVMTidyModule.cpp
  clang-tools-extra/clang-tidy/llvm/StringReferencingCheck.cpp
  clang-tools-extra/clang-tidy/llvm/StringReferencingCheck.h
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/llvm-string-referencing.rst
  clang-tools-extra/test/clang-tidy/checkers/llvm-string-referencing.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/llvm-string-referencing.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/llvm-string-referencing.cpp
@@ -0,0 +1,66 @@
+// RUN: %check_clang_tidy %s llvm-string-referencing %t
+
+namespace std {
+class string {};
+class u18_string_t;
+
+} // namespace std
+
+namespace llvm {
+class StringRef;
+} // namespace llvm
+
+class String;
+
+namespace A {
+using namespace std;
+void f(const string &P);
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void f(llvm::StringRef P);{{$}}
+} // namespace A
+
+namespace B {
+using std::string;
+void f1(const string &P);
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void f1(llvm::StringRef P);{{$}}
+} // namespace B
+
+void f2(std::string, int, const std::string &);
+// CHECK-MESSAGES: :[[@LINE-1]]:27: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void f2(std::string, int, llvm::StringRef );{{$}}
+void f2(std::string P, int x, const std::string &P2) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+  // CHECK-FIXES: void f2(std::string P, int x, llvm::StringRef P2) {{{$}}
+  return;
+}
+
+void f3(const std::string &P1, const std::string &P2);
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-MESSAGES: :[[@LINE-2]]:32: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void f3(llvm::StringRef P1, llvm::StringRef P2);{{$}}
+
+struct St {
+  void operator=(const std::string &Val) const {
+// CHECK-MESSAGES: :[[@LINE-1]]:18: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void operator=(llvm::StringRef Val) const {{{$}}
+return;
+  }
+};
+
+void f7(const std::string &);
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: Use of const std::string & is discouraged in the LLVM Programmer's Manual [llvm-string-referencing]
+// CHECK-FIXES: void f7(llvm::StringRef );{{$}}
+
+// Functions below this line should not trigger the check
+void f1(std::string &P);
+
+void f4(std::string *P);
+
+void f5(String &P);
+
+void f6(llvm::StringRef P);
+
+void f9(std::u18_string_t &P);
+
+void f10(const std::string &&P);
Index: clang-tools-extra/docs/clang-tidy/checks/llvm-string-referencing.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/llvm-string-referencing.rst
@@ -0,0 +1,6 @@
+.. title:: clang-tidy - llvm-string-referencing
+
+llvm-string-referencing
+===
+
+FIXME: Describe what patterns does the check detect and why. Give examples.
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -192,6 +192,7 @@
`llvm-namespace-comment `_,
`llvm-prefer-isa-or-dyn-cast-in-conditionals `_, "Yes"
`llvm-prefer-register-over-unsigned `_, "Yes"
+   `llvm-string-referencing `_, "Yes"
`llvm-twine-local `_, "Yes"
`llvmlibc-callee-namespace `_,
`llvmlibc-implementation-in-namespace `_,
Index: clang-tools-extra/clang-tidy/llvm/StringReferencingCheck.h
===
--- /dev/null
+++ clang-tools-extra/clang-tidy/llvm/StringReferencingCheck.h
@@ -0,0 +1,46 @@
+//===--- StringReferencingCheck.h - clang-tidy --*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--

[PATCH] D87962: [clang] Change the multi-character character constants from extension to implementation-defined.

[Aaron Ballman via Phabricator via cfe-commits]

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

In D87962#2307824 , @rsmith wrote:

> In D87962#2306043 , @aaron.ballman 
> wrote:
>
>> That doesn't sound like the right approach to me -- Remarks are usually for 
>> reporting backend decision-making to the frontend for things like 
>> optimization passes.
>
> To be clear: that's how they happen to most visibly be used, but the more 
> general idea is that Remarks are for purely informational messages. One test 
> for whether a diagnostic could reasonably be a remark is: can we imagine 
> anyone ever reasonably wanting to promote it to an error as part of the flags 
> for some project? If so, then use of a remark is inappropriate. That's 
> certainly the case here: it's entirely reasonable to want to be able to 
> reject use of non-portable functionality such as this. So I agree, this 
> should not be a remark.

Thank you for the explanation!

The patch LGTM with a minor nit about the test case.




Comment at: clang/test/Lexer/multi-char-constants.c:6
+
+int main() {
+   return 0;

You can remove the empty `main()`.


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

https://reviews.llvm.org/D87962

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

[PATCH] D88700: [clang-tidy] modernize-use-trailing-return-type fix #44206

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88700

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

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

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

balazske added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:33
+
+  for (const FunctionDecl *D : Node.redecls())
+if (D->getASTContext().getSourceManager().isInSystemHeader(

aaron.ballman wrote:
> balazske wrote:
> > aaron.ballman wrote:
> > > I'm not certain I understand why we're looking through the entire 
> > > redeclaration chain to see if the function is ever mentioned in a system 
> > > header. I was expecting we'd look at the expansion location of the 
> > > declaration and see if that's in a system header, which is already 
> > > handled by the `isExpansionInSystemHeader()` matcher. Similar below.
> > This function is called from ` SignalHandlerCheck::check` when any function 
> > call is found. So the check for system header is needed. It was unclear to 
> > me what the "expansion location" means but it seems to work if using that 
> > expansion location and checking for system header, instead of this loop. I 
> > will update the code.
> > This function is called from  SignalHandlerCheck::check when any function 
> > call is found. So the check for system header is needed. 
> 
> The check for the system header isn't what I was concerned by, it was the 
> fact that we're walking the entire redeclaration chain to see if *any* 
> declaration is in a system header that I don't understand the purpose of.
> 
> > It was unclear to me what the "expansion location" means but it seems to 
> > work if using that expansion location and checking for system header, 
> > instead of this loop. I will update the code.
> 
> The spelling location is where the user wrote the code and the expansion 
> location is where the macro name is written, but thinking on it harder, that 
> shouldn't matter for this situation as either location would be in the system 
> header anyway.
The function declaration is not often a macro name so there is no "expansion 
location" or the same as the original location. My concern was that if there is 
a declaration of system call function in a source file (like `void 
abort(void);` in .c file) for any reason, we may find this declaration instead 
of the one in the header file, if not looping over the declaration chain.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87449

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

[PATCH] D63640: [clang] Improve Serialization/Imporing of APValues

[Gabor Marton via Phabricator via cfe-commits]

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

Sorry for the late review, I just noticed something which is not a logical 
error, but we could make the ASTImporter code much cleaner.




Comment at: clang/lib/AST/ASTImporter.cpp:9047-9058
+llvm::Expected ImpTypeInfo = Import(QualType(
+FromValue.getLValueBase().get().getType(), 0));
+if (!ImpTypeInfo) {
+  Error = ImpTypeInfo.takeError();
+  break;
+}
+llvm::Expected ImpType =

A series of `importChecked` would result in a much cleaner code by omitting the 
second check. Also, instead of breaking out from the switch we can immediately 
return with the error.

This applies for the other cases where there are more import calls after each 
other (e.g. AddrLabelDiff, Union, ...).

Giving it more thought, you could use `importChecked` instead of `Import` 
everywhere in this function (for consistency).




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63640

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

[PATCH] D87972: [OldPM] Pass manager: run SROA after (simple) loop unrolling

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri updated this revision to Diff 295817.
lebedev.ri added a comment.
Herald added a subscriber: pengfei.

Rebased, NFC


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87972

Files:
  llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
  llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
  llvm/test/Other/opt-O2-pipeline.ll
  llvm/test/Other/opt-O3-pipeline-enable-matrix.ll
  llvm/test/Other/opt-O3-pipeline.ll
  llvm/test/Other/opt-Os-pipeline.ll
  llvm/test/Transforms/PhaseOrdering/X86/SROA-after-loop-unrolling.ll

Index: llvm/test/Transforms/PhaseOrdering/X86/SROA-after-loop-unrolling.ll
===
--- llvm/test/Transforms/PhaseOrdering/X86/SROA-after-loop-unrolling.ll
+++ llvm/test/Transforms/PhaseOrdering/X86/SROA-after-loop-unrolling.ll
@@ -22,55 +22,21 @@
 %"struct.std::array" = type { [6 x i32] }
 
 define dso_local void @_Z3fooi(i32 %cnt) {
-; OLDPM-LABEL: @_Z3fooi(
-; OLDPM-NEXT:  entry:
-; OLDPM-NEXT:[[ARR:%.*]] = alloca %"struct.std::array", align 16
-; OLDPM-NEXT:[[TMP0:%.*]] = bitcast %"struct.std::array"* [[ARR]] to i8*
-; OLDPM-NEXT:call void @llvm.lifetime.start.p0i8(i64 24, i8* nonnull [[TMP0]])
-; OLDPM-NEXT:[[ARRAYDECAY_I_I_I:%.*]] = getelementptr inbounds %"struct.std::array", %"struct.std::array"* [[ARR]], i64 0, i32 0, i64 0
-; OLDPM-NEXT:[[INCDEC_PTR:%.*]] = getelementptr inbounds %"struct.std::array", %"struct.std::array"* [[ARR]], i64 0, i32 0, i64 1
-; OLDPM-NEXT:[[INCDEC_PTR_1:%.*]] = getelementptr inbounds %"struct.std::array", %"struct.std::array"* [[ARR]], i64 0, i32 0, i64 2
-; OLDPM-NEXT:[[INCDEC_PTR_2:%.*]] = getelementptr inbounds %"struct.std::array", %"struct.std::array"* [[ARR]], i64 0, i32 0, i64 3
-; OLDPM-NEXT:[[TMP1:%.*]] = insertelement <4 x i32> undef, i32 [[CNT:%.*]], i32 0
-; OLDPM-NEXT:[[TMP2:%.*]] = shufflevector <4 x i32> [[TMP1]], <4 x i32> undef, <4 x i32> zeroinitializer
-; OLDPM-NEXT:[[TMP3:%.*]] = add nsw <4 x i32> [[TMP2]], 
-; OLDPM-NEXT:[[TMP4:%.*]] = bitcast %"struct.std::array"* [[ARR]] to <4 x i32>*
-; OLDPM-NEXT:store <4 x i32> [[TMP3]], <4 x i32>* [[TMP4]], align 16
-; OLDPM-NEXT:[[INCDEC_PTR_3:%.*]] = getelementptr inbounds %"struct.std::array", %"struct.std::array"* [[ARR]], i64 0, i32 0, i64 4
-; OLDPM-NEXT:[[INC_4:%.*]] = add nsw i32 [[CNT]], 5
-; OLDPM-NEXT:store i32 [[INC_4]], i32* [[INCDEC_PTR_3]], align 16
-; OLDPM-NEXT:[[INCDEC_PTR_4:%.*]] = getelementptr inbounds %"struct.std::array", %"struct.std::array"* [[ARR]], i64 0, i32 0, i64 5
-; OLDPM-NEXT:[[INC_5:%.*]] = add nsw i32 [[CNT]], 6
-; OLDPM-NEXT:store i32 [[INC_5]], i32* [[INCDEC_PTR_4]], align 4
-; OLDPM-NEXT:[[TMP5:%.*]] = load i32, i32* [[ARRAYDECAY_I_I_I]], align 16
-; OLDPM-NEXT:call void @_Z3usei(i32 [[TMP5]])
-; OLDPM-NEXT:[[TMP6:%.*]] = load i32, i32* [[INCDEC_PTR]], align 4
-; OLDPM-NEXT:call void @_Z3usei(i32 [[TMP6]])
-; OLDPM-NEXT:[[TMP7:%.*]] = load i32, i32* [[INCDEC_PTR_1]], align 8
-; OLDPM-NEXT:call void @_Z3usei(i32 [[TMP7]])
-; OLDPM-NEXT:[[TMP8:%.*]] = load i32, i32* [[INCDEC_PTR_2]], align 4
-; OLDPM-NEXT:call void @_Z3usei(i32 [[TMP8]])
-; OLDPM-NEXT:[[TMP9:%.*]] = load i32, i32* [[INCDEC_PTR_3]], align 16
-; OLDPM-NEXT:call void @_Z3usei(i32 [[TMP9]])
-; OLDPM-NEXT:call void @_Z3usei(i32 [[INC_5]])
-; OLDPM-NEXT:call void @llvm.lifetime.end.p0i8(i64 24, i8* nonnull [[TMP0]])
-; OLDPM-NEXT:ret void
-;
-; NEWPM-LABEL: @_Z3fooi(
-; NEWPM-NEXT:  entry:
-; NEWPM-NEXT:[[INC:%.*]] = add nsw i32 [[CNT:%.*]], 1
-; NEWPM-NEXT:[[INC_1:%.*]] = add nsw i32 [[CNT]], 2
-; NEWPM-NEXT:[[INC_2:%.*]] = add nsw i32 [[CNT]], 3
-; NEWPM-NEXT:[[INC_3:%.*]] = add nsw i32 [[CNT]], 4
-; NEWPM-NEXT:[[INC_4:%.*]] = add nsw i32 [[CNT]], 5
-; NEWPM-NEXT:[[INC_5:%.*]] = add nsw i32 [[CNT]], 6
-; NEWPM-NEXT:call void @_Z3usei(i32 [[INC]])
-; NEWPM-NEXT:call void @_Z3usei(i32 [[INC_1]])
-; NEWPM-NEXT:call void @_Z3usei(i32 [[INC_2]])
-; NEWPM-NEXT:call void @_Z3usei(i32 [[INC_3]])
-; NEWPM-NEXT:call void @_Z3usei(i32 [[INC_4]])
-; NEWPM-NEXT:call void @_Z3usei(i32 [[INC_5]])
-; NEWPM-NEXT:ret void
+; CHECK-LABEL: @_Z3fooi(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:[[INC:%.*]] = add nsw i32 [[CNT:%.*]], 1
+; CHECK-NEXT:[[INC_1:%.*]] = add nsw i32 [[CNT]], 2
+; CHECK-NEXT:[[INC_2:%.*]] = add nsw i32 [[CNT]], 3
+; CHECK-NEXT:[[INC_3:%.*]] = add nsw i32 [[CNT]], 4
+; CHECK-NEXT:[[INC_4:%.*]] = add nsw i32 [[CNT]], 5
+; CHECK-NEXT:[[INC_5:%.*]] = add nsw i32 [[CNT]], 6
+; CHECK-NEXT:call void @_Z3usei(i32 [[INC]])
+; CHECK-NEXT:call void @_Z3usei(i32 [[INC_1]])
+; CHECK-NEXT:call void @_Z3usei(i32 [[INC_2]])
+; CHECK-NEXT:call void @_Z3usei(i32 [[INC_3]])
+; CHECK-NEXT:call void @_Z3usei(i32 [[INC_4]])
+; CHECK-NEXT:call void @_Z3usei(i32 [[INC

[PATCH] D88314: Added llvm-string-referencing check

[Bogdan Serea via Phabricator via cfe-commits]

bogser01 added a comment.

@alexfh does this look alright?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88314

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

[PATCH] D88634: [clangd] Extend the rename API.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 295819.
hokein marked an inline comment as done.
hokein added a comment.

change LocalChanges type to vector


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88634

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/test/rename.test
  clang-tools-extra/clangd/unittests/RenameTests.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.h

Index: clang-tools-extra/clangd/unittests/SyncAPI.h
===
--- clang-tools-extra/clangd/unittests/SyncAPI.h
+++ clang-tools-extra/clangd/unittests/SyncAPI.h
@@ -40,9 +40,13 @@
 llvm::Expected>
 runFindDocumentHighlights(ClangdServer &Server, PathRef File, Position Pos);
 
-llvm::Expected runRename(ClangdServer &Server, PathRef File,
-Position Pos, StringRef NewName,
-const clangd::RenameOptions &RenameOpts);
+llvm::Expected runRename(ClangdServer &Server, PathRef File,
+   Position Pos, StringRef NewName,
+   const clangd::RenameOptions &RenameOpts);
+
+llvm::Expected
+runPrepareRename(ClangdServer &Server, PathRef File, Position Pos,
+ const clangd::RenameOptions &RenameOpts);
 
 llvm::Expected
 runFormatFile(ClangdServer &Server, PathRef File, StringRef Code);
Index: clang-tools-extra/clangd/unittests/SyncAPI.cpp
===
--- clang-tools-extra/clangd/unittests/SyncAPI.cpp
+++ clang-tools-extra/clangd/unittests/SyncAPI.cpp
@@ -97,14 +97,22 @@
   return std::move(*Result);
 }
 
-llvm::Expected runRename(ClangdServer &Server, PathRef File,
-Position Pos, llvm::StringRef NewName,
-const RenameOptions &RenameOpts) {
-  llvm::Optional> Result;
+llvm::Expected runRename(ClangdServer &Server, PathRef File,
+   Position Pos, llvm::StringRef NewName,
+   const RenameOptions &RenameOpts) {
+  llvm::Optional> Result;
   Server.rename(File, Pos, NewName, RenameOpts, capture(Result));
   return std::move(*Result);
 }
 
+llvm::Expected runPrepareRename(ClangdServer &Server,
+  PathRef File, Position Pos,
+  const RenameOptions &RenameOpts) {
+  llvm::Optional> Result;
+  Server.prepareRename(File, Pos, RenameOpts, capture(Result));
+  return std::move(*Result);
+}
+
 llvm::Expected
 runFormatFile(ClangdServer &Server, PathRef File, StringRef Code) {
   llvm::Optional> Result;
Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -502,9 +502,10 @@
   auto RenameResult =
   rename({RenamePos, NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
-expectedResult(Code, NewName));
+  ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
+  EXPECT_EQ(
+  applyEdits(std::move(RenameResult->GlobalChanges)).front().second,
+  expectedResult(Code, NewName));
 }
   }
 }
@@ -653,8 +654,8 @@
 } else {
   EXPECT_TRUE(bool(Results)) << "rename returned an error: "
  << llvm::toString(Results.takeError());
-  ASSERT_EQ(1u, Results->size());
-  EXPECT_EQ(applyEdits(std::move(*Results)).front().second,
+  ASSERT_EQ(1u, Results->GlobalChanges.size());
+  EXPECT_EQ(applyEdits(std::move(Results->GlobalChanges)).front().second,
 expectedResult(T, NewName));
 }
   }
@@ -683,8 +684,8 @@
   auto RenameResult =
   rename({Code.point(), NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError() << Code.point();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
+  ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
+  EXPECT_EQ(applyEdits(std::move(RenameResult->GlobalChanges)).front().second,
 expectedResult(Code, NewName));
 }
 
@@ -703,6 +704,44 @@
   testing::HasSubstr("not a supported kind"));
 }
 
+TEST(RenameTest, PrepareRename) {
+  Annotations FooH("void func();");
+  Annotations FooCC(R"cpp(
+#incl

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:33
+
+  for (const FunctionDecl *D : Node.redecls())
+if (D->getASTContext().getSourceManager().isInSystemHeader(

balazske wrote:
> aaron.ballman wrote:
> > balazske wrote:
> > > aaron.ballman wrote:
> > > > I'm not certain I understand why we're looking through the entire 
> > > > redeclaration chain to see if the function is ever mentioned in a 
> > > > system header. I was expecting we'd look at the expansion location of 
> > > > the declaration and see if that's in a system header, which is already 
> > > > handled by the `isExpansionInSystemHeader()` matcher. Similar below.
> > > This function is called from ` SignalHandlerCheck::check` when any 
> > > function call is found. So the check for system header is needed. It was 
> > > unclear to me what the "expansion location" means but it seems to work if 
> > > using that expansion location and checking for system header, instead of 
> > > this loop. I will update the code.
> > > This function is called from  SignalHandlerCheck::check when any function 
> > > call is found. So the check for system header is needed. 
> > 
> > The check for the system header isn't what I was concerned by, it was the 
> > fact that we're walking the entire redeclaration chain to see if *any* 
> > declaration is in a system header that I don't understand the purpose of.
> > 
> > > It was unclear to me what the "expansion location" means but it seems to 
> > > work if using that expansion location and checking for system header, 
> > > instead of this loop. I will update the code.
> > 
> > The spelling location is where the user wrote the code and the expansion 
> > location is where the macro name is written, but thinking on it harder, 
> > that shouldn't matter for this situation as either location would be in the 
> > system header anyway.
> The function declaration is not often a macro name so there is no "expansion 
> location" or the same as the original location. My concern was that if there 
> is a declaration of system call function in a source file (like `void 
> abort(void);` in .c file) for any reason, we may find this declaration 
> instead of the one in the header file, if not looping over the declaration 
> chain.
> The function declaration is not often a macro name so there is no "expansion 
> location" or the same as the original location.

Agreed.

> My concern was that if there is a declaration of system call function in a 
> source file (like `void abort(void);` in .c file) for any reason, we may find 
> this declaration instead of the one in the header file, if not looping over 
> the declaration chain.

Typically, when a C user does something like that, it's because they're 
explicitly *not* including the header file at all (they're just forward 
declaring the function so they can use it) and so we'd get the logic wrong for 
them anyway because we'd never find the declaration in the system header.

Using the canonical declaration is more typical and would realistically fail 
only in circumstances like forward declaring a system header function and then 
later including the system header itself. That said, I suppose your approach is 
defensible enough. Redeclaration chains are hopefully short enough that it 
isn't a performance hit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87449

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

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Jason Liu via Phabricator via cfe-commits]

jasonliu created this revision.
jasonliu added reviewers: hubert.reinterpretcast, daltenty, sfertile, 
Xiangling_L, DiggerLin.
Herald added subscribers: dang, dexonsmith, steven_wu, hiraditya, arichardson, 
sbc100, emaste.
Herald added a reviewer: espindola.
Herald added a reviewer: MaskRay.
jasonliu requested review of this revision.
Herald added a subscriber: aheejin.

This is the follow up on D88493  where we 
flipped the default for llc on AIX.
We would also want to flip the default for Clang as well.


https://reviews.llvm.org/D88737

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/function-sections.c
  lld/COFF/LTO.cpp
  lld/ELF/LTO.cpp
  lld/wasm/LTO.cpp

Index: lld/wasm/LTO.cpp
===
--- lld/wasm/LTO.cpp
+++ lld/wasm/LTO.cpp
@@ -45,6 +45,7 @@
 
   // Always emit a section per function/data with LTO.
   c.Options.FunctionSections = true;
+  c.Options.HasExplicitDataSections = true;
   c.Options.DataSections = true;
 
   c.DisableVerify = config->disableVerify;
Index: lld/ELF/LTO.cpp
===
--- lld/ELF/LTO.cpp
+++ lld/ELF/LTO.cpp
@@ -86,6 +86,7 @@
 
   // Always emit a section per function/datum with LTO.
   c.Options.FunctionSections = true;
+  c.Options.HasExplicitDataSections = true;
   c.Options.DataSections = true;
 
   // Check if basic block sections must be used.
Index: lld/COFF/LTO.cpp
===
--- lld/COFF/LTO.cpp
+++ lld/COFF/LTO.cpp
@@ -66,6 +66,7 @@
   // Always emit a section per function/datum with LTO. LLVM LTO should get most
   // of the benefit of linker GC, but there are still opportunities for ICF.
   c.Options.FunctionSections = true;
+  c.Options.HasExplicitDataSections = true;
   c.Options.DataSections = true;
 
   // Use static reloc model on 32-bit x86 because it usually results in more
Index: clang/test/Driver/function-sections.c
===
--- clang/test/Driver/function-sections.c
+++ clang/test/Driver/function-sections.c
@@ -3,13 +3,15 @@
 // CHECK-FS: -ffunction-sections
 // CHECK-NOFS-NOT: -ffunction-sections
 // CHECK-DS: -fdata-sections
-// CHECK-NODS-NOT: -fdata-sections
+// CHECK-NODS: -fno-data-sections
+// CHECK-DS-DEFAULT-NOT: -fdata-sections
+// CHECK-DS-DEFAULT-NOT: -fno-data-sections
 // CHECK-US-NOT: -fno-unique-section-names
 // CHECK-NOUS: -fno-unique-section-names
 
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
 // RUN: -target i386-unknown-linux \
-// RUN:   | FileCheck --check-prefix=CHECK-NOFS --check-prefix=CHECK-NODS %s
+// RUN:   | FileCheck --check-prefix=CHECK-NOFS --check-prefix=CHECK-DS-DEFAULT %s
 
 // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1   \
 // RUN: -target i386-unknown-linux \
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -991,6 +991,13 @@
   Args.hasArg(OPT_ffunction_sections) ||
   (Opts.BBSections != "none" && Opts.BBSections != "labels");
 
+  if (Args.getLastArg(OPT_fdata_sections) ||
+  Args.getLastArg(OPT_fno_data_sections)) {
+Opts.HasExplicitDataSections = true;
+Opts.DataSections =
+Args.hasFlag(OPT_fdata_sections, OPT_fno_data_sections, false);
+  }
+
   Opts.DataSections = Args.hasArg(OPT_fdata_sections);
   Opts.StackSizeSection = Args.hasArg(OPT_fstack_size_section);
   Opts.UniqueSectionNames = !Args.hasArg(OPT_fno_unique_section_names);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4906,8 +4906,13 @@
 }
   }
 
-  if (Args.hasFlag(options::OPT_fdata_sections, options::OPT_fno_data_sections,
-   UseSeparateSections)) {
+  if (Arg *A = Args.getLastArg(options::OPT_fdata_sections,
+   options::OPT_fno_data_sections)) {
+if (A->getOption().matches(options::OPT_fdata_sections))
+  CmdArgs.push_back("-fdata-sections");
+else
+  CmdArgs.push_back("-fno-data-sections");
+  } else if (UseSeparateSections) {
 CmdArgs.push_back("-fdata-sections");
   }
 
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -517,6 +517,7 @@
   Options.EnableMachineFunctionSplitter = CodeGenOpts.SplitMachineFunctions;
   Options.FunctionSections = CodeGenOpts.FunctionSections;
   Options.DataSections = 

[PATCH] D88590: [clangd] Add benchmark for measuring latency of DecisionForest model.

[Adam Czachorowski via Phabricator via cfe-commits]

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

Still a couple of lint warnings, otherwise LGTM




Comment at: 
clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp:74
+  for (auto _ : State) {
+srand(0);
+State.PauseTiming();

Move this out of the loop. Right now we re-generate "random" dataset, but it's 
always the same dataset ;-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88590

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

[PATCH] D63640: [clang] Improve Serialization/Imporing of APValues

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:9010
+  ToPath[Idx] =
+  cast(const_cast(ImpDecl.get()));
+}

Tyker wrote:
> rsmith wrote:
> > We want the path in an `APValue` to be canonical, but importing a canonical 
> > decl might result in a non-canonical decl.
> > but importing a canonical decl might result in a non-canonical decl.
> this is a quite surprising behavior.
> > but importing a canonical decl might result in a non-canonical decl.
> this is a quite surprising behavior.

If you already have an existing redecl chain in the destination ASTContext 
(let's say A->B->C, A is the canonical decl), then importing a canonical decl 
(let's say D) would result an A->B->C->D' chain. Where D' is the imported 
version of D.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63640

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

[clang-tools-extra] 0f0cbcc - [clangd] Extend the rename API.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2020-10-02T16:03:44+02:00
New Revision: 0f0cbcc4b166f32603371fb1d62ef3816cf8425f

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

LOG: [clangd] Extend the rename API.

several changes:
- return a structure result in rename API;
- prepareRename now returns more information (main-file occurrences);
- remove the duplicated detecting-touch-identifier code in prepareRename (which 
is implemented in rename API);

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

Added: 


Modified: 
clang-tools-extra/clangd/ClangdLSPServer.cpp
clang-tools-extra/clangd/ClangdServer.cpp
clang-tools-extra/clangd/ClangdServer.h
clang-tools-extra/clangd/SourceCode.h
clang-tools-extra/clangd/refactor/Rename.cpp
clang-tools-extra/clangd/refactor/Rename.h
clang-tools-extra/clangd/test/rename.test
clang-tools-extra/clangd/unittests/RenameTests.cpp
clang-tools-extra/clangd/unittests/SyncAPI.cpp
clang-tools-extra/clangd/unittests/SyncAPI.h

Removed: 




diff  --git a/clang-tools-extra/clangd/ClangdLSPServer.cpp 
b/clang-tools-extra/clangd/ClangdLSPServer.cpp
index c2915aeada4f..34d5a305494c 100644
--- a/clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ b/clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -793,8 +793,13 @@ void ClangdLSPServer::onWorkspaceSymbol(
 
 void ClangdLSPServer::onPrepareRename(const TextDocumentPositionParams &Params,
   Callback> Reply) {
-  Server->prepareRename(Params.textDocument.uri.file(), Params.position,
-Opts.Rename, std::move(Reply));
+  Server->prepareRename(
+  Params.textDocument.uri.file(), Params.position, Opts.Rename,
+  [Reply = std::move(Reply)](llvm::Expected Result) mutable {
+if (!Result)
+  return Reply(Result.takeError());
+return Reply(std::move(Result->Target));
+  });
 }
 
 void ClangdLSPServer::onRename(const RenameParams &Params,
@@ -806,14 +811,14 @@ void ClangdLSPServer::onRename(const RenameParams &Params,
   Server->rename(
   File, Params.position, Params.newName, Opts.Rename,
   [File, Params, Reply = std::move(Reply),
-   this](llvm::Expected Edits) mutable {
-if (!Edits)
-  return Reply(Edits.takeError());
-if (auto Err = validateEdits(DraftMgr, *Edits))
+   this](llvm::Expected R) mutable {
+if (!R)
+  return Reply(R.takeError());
+if (auto Err = validateEdits(DraftMgr, R->GlobalChanges))
   return Reply(std::move(Err));
 WorkspaceEdit Result;
 Result.changes.emplace();
-for (const auto &Rep : *Edits) {
+for (const auto &Rep : R->GlobalChanges) {
   (*Result.changes)[URI::createFile(Rep.first()).toString()] =
   Rep.second.asTextEdits();
 }

diff  --git a/clang-tools-extra/clangd/ClangdServer.cpp 
b/clang-tools-extra/clangd/ClangdServer.cpp
index 8c73b6a7d063..0840155fc8f9 100644
--- a/clang-tools-extra/clangd/ClangdServer.cpp
+++ b/clang-tools-extra/clangd/ClangdServer.cpp
@@ -400,46 +400,35 @@ void ClangdServer::formatOnType(PathRef File, 
llvm::StringRef Code,
 
 void ClangdServer::prepareRename(PathRef File, Position Pos,
  const RenameOptions &RenameOpts,
- Callback> CB) {
+ Callback CB) {
   auto Action = [Pos, File = File.str(), CB = std::move(CB), RenameOpts,
  this](llvm::Expected InpAST) mutable {
 if (!InpAST)
   return CB(InpAST.takeError());
-auto &AST = InpAST->AST;
-const auto &SM = AST.getSourceManager();
-auto Loc = sourceLocationInMainFile(SM, Pos);
-if (!Loc)
-  return CB(Loc.takeError());
-const auto *TouchingIdentifier =
-spelledIdentifierTouching(*Loc, AST.getTokens());
-if (!TouchingIdentifier)
-  return CB(llvm::None); // no rename on non-identifiers.
-
-auto Range = halfOpenToRange(
-SM, CharSourceRange::getCharRange(TouchingIdentifier->location(),
-  TouchingIdentifier->endLocation()));
-
-if (RenameOpts.AllowCrossFile)
-  // FIXME: we now assume cross-file rename always succeeds, revisit this.
-  return CB(Range);
-
-// Performing the local rename isn't substantially more expensive than
-// doing an AST-based check, so we just rename and throw away the results.
-auto Changes = clangd::rename({Pos, "dummy", AST, File, Index, RenameOpts,
-   /*GetDirtyBuffer=*/nullptr});
-if (!Changes) {
+// prepareRename is latency-sensitive:
+//  - for single-file rename, performing rename isn't substantially more
+//expensive than doing an AST-based check (the index is

[PATCH] D88634: [clangd] Extend the rename API.

[Haojian Wu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0f0cbcc4b166: [clangd] Extend the rename API. (authored by 
hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88634

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h
  clang-tools-extra/clangd/test/rename.test
  clang-tools-extra/clangd/unittests/RenameTests.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.cpp
  clang-tools-extra/clangd/unittests/SyncAPI.h

Index: clang-tools-extra/clangd/unittests/SyncAPI.h
===
--- clang-tools-extra/clangd/unittests/SyncAPI.h
+++ clang-tools-extra/clangd/unittests/SyncAPI.h
@@ -40,9 +40,13 @@
 llvm::Expected>
 runFindDocumentHighlights(ClangdServer &Server, PathRef File, Position Pos);
 
-llvm::Expected runRename(ClangdServer &Server, PathRef File,
-Position Pos, StringRef NewName,
-const clangd::RenameOptions &RenameOpts);
+llvm::Expected runRename(ClangdServer &Server, PathRef File,
+   Position Pos, StringRef NewName,
+   const clangd::RenameOptions &RenameOpts);
+
+llvm::Expected
+runPrepareRename(ClangdServer &Server, PathRef File, Position Pos,
+ const clangd::RenameOptions &RenameOpts);
 
 llvm::Expected
 runFormatFile(ClangdServer &Server, PathRef File, StringRef Code);
Index: clang-tools-extra/clangd/unittests/SyncAPI.cpp
===
--- clang-tools-extra/clangd/unittests/SyncAPI.cpp
+++ clang-tools-extra/clangd/unittests/SyncAPI.cpp
@@ -97,14 +97,22 @@
   return std::move(*Result);
 }
 
-llvm::Expected runRename(ClangdServer &Server, PathRef File,
-Position Pos, llvm::StringRef NewName,
-const RenameOptions &RenameOpts) {
-  llvm::Optional> Result;
+llvm::Expected runRename(ClangdServer &Server, PathRef File,
+   Position Pos, llvm::StringRef NewName,
+   const RenameOptions &RenameOpts) {
+  llvm::Optional> Result;
   Server.rename(File, Pos, NewName, RenameOpts, capture(Result));
   return std::move(*Result);
 }
 
+llvm::Expected runPrepareRename(ClangdServer &Server,
+  PathRef File, Position Pos,
+  const RenameOptions &RenameOpts) {
+  llvm::Optional> Result;
+  Server.prepareRename(File, Pos, RenameOpts, capture(Result));
+  return std::move(*Result);
+}
+
 llvm::Expected
 runFormatFile(ClangdServer &Server, PathRef File, StringRef Code) {
   llvm::Optional> Result;
Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -502,9 +502,10 @@
   auto RenameResult =
   rename({RenamePos, NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
-expectedResult(Code, NewName));
+  ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
+  EXPECT_EQ(
+  applyEdits(std::move(RenameResult->GlobalChanges)).front().second,
+  expectedResult(Code, NewName));
 }
   }
 }
@@ -653,8 +654,8 @@
 } else {
   EXPECT_TRUE(bool(Results)) << "rename returned an error: "
  << llvm::toString(Results.takeError());
-  ASSERT_EQ(1u, Results->size());
-  EXPECT_EQ(applyEdits(std::move(*Results)).front().second,
+  ASSERT_EQ(1u, Results->GlobalChanges.size());
+  EXPECT_EQ(applyEdits(std::move(Results->GlobalChanges)).front().second,
 expectedResult(T, NewName));
 }
   }
@@ -683,8 +684,8 @@
   auto RenameResult =
   rename({Code.point(), NewName, AST, testPath(TU.Filename)});
   ASSERT_TRUE(bool(RenameResult)) << RenameResult.takeError() << Code.point();
-  ASSERT_EQ(1u, RenameResult->size());
-  EXPECT_EQ(applyEdits(std::move(*RenameResult)).front().second,
+  ASSERT_EQ(1u, RenameResult->GlobalChanges.size());
+  EXPECT_EQ(applyEdits(std::move(RenameResult->GlobalChanges)).front().second,
 expectedResult(Code, NewName));
 }
 
@@ -703,6 +704,44 @@
   testing::HasSubstr("not a supported kind"));
 }
 
+TEST(RenameTest, PrepareRename) {
+  A

[PATCH] D88345: [CUDA] Allow local `static const {__constant__, __device__}` variables.

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: clang/test/SemaCUDA/device-var-init.cu:404
 __host__ __device__ void hd_sema() {
   static int x = 42;
 }

tra wrote:
> yaxunl wrote:
> > how does this work in device compilation? Is this equivalent to `static 
> > __device__ int x = 42`?
> Correct. 
so static variable without `__device__/__constant__` attribute in host device 
function implies `__device__` attribute in device compilation.

Is this also true in device function? We need Sema and CodeGen tests for these 
cases.

Also, can we document these changes? It is easily forgotten.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88345

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

[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-hungarian-notation.cpp:25
+// RUN: {key: readability-identifier-naming.FunctionCase   , value: 
CamelCase },   \
+// RUN: {key: readability-identifier-naming.ClassCase  , value: 
szHungarianNotation }, \
+// RUN: {key: readability-identifier-naming.TypedefCase, value: 
szHungarianNotation }, \

dougpuob wrote:
> njames93 wrote:
> > Class names shouldn't use hungarian notation.
> OK~ I have classified CheckOptions, and all test cases one by one in the next 
> diff.
> 
> ```
> // RUN:   -config='{ CheckOptions: [ \
> // RUN: { key: readability-identifier-naming.ClassMemberCase  
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ConstantCase 
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ConstantMemberCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ConstantParameterCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ConstantPointerParameterCase 
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ConstexprVariableCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.GlobalConstantCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.GlobalConstantPointerCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.GlobalVariableCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.LocalConstantCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.LocalConstantPointerCase 
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.LocalPointerCase 
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.LocalVariableCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.MemberCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.ParameterCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.PointerParameterCase 
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.PrivateMemberCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.StaticConstantCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.StaticVariableCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.StructCase   
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.UnionCase
> , value: szHungarianNotation }, \
> // RUN: { key: readability-identifier-naming.VariableCase 
> , value: szHungarianNotation }  \
> // RUN:   ]}'
> ```
> Class names shouldn't use hungarian notation.

That may be debatable as I've definitely seen `C` used as a prefix for class 
names and `I` used as a prefix for pure virtual class names (interfaces). Doing 
a quick search on Google brings up evidence that this isn't uncommon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86671

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

[clang] 36501b1 - Emit predefined macro for wavefront size for amdgcn

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2020-10-02T10:17:21-04:00
New Revision: 36501b180a4f0194f0cfb4374d096ae660182827

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

LOG: Emit predefined macro for wavefront size for amdgcn

Also fix the issue of multiple -m[no-]wavefrontsize64
options to make the last one wins.

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

Added: 
clang/test/Driver/hip-macros.hip

Modified: 
clang/lib/Basic/Targets/AMDGPU.cpp
clang/lib/Basic/Targets/AMDGPU.h
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/test/Driver/amdgpu-features.c
clang/test/Driver/amdgpu-macros.cl
clang/test/Driver/hip-toolchain-features.hip

Removed: 




diff  --git a/clang/lib/Basic/Targets/AMDGPU.cpp 
b/clang/lib/Basic/Targets/AMDGPU.cpp
index da25bf10ca07..ba9be72af971 100644
--- a/clang/lib/Basic/Targets/AMDGPU.cpp
+++ b/clang/lib/Basic/Targets/AMDGPU.cpp
@@ -316,6 +316,7 @@ AMDGPUTargetInfo::AMDGPUTargetInfo(const llvm::Triple 
&Triple,
 
   HasLegalHalfType = true;
   HasFloat16 = true;
+  WavefrontSize = GPUFeatures & llvm::AMDGPU::FEATURE_WAVE32 ? 32 : 64;
 
   // Set pointer width and alignment for target address space 0.
   PointerWidth = PointerAlign = DataLayout->getPointerSizeInBits();
@@ -388,6 +389,8 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions 
&Opts,
 Builder.defineMacro("__HAS_FP64__");
   if (hasFastFMA())
 Builder.defineMacro("FP_FAST_FMA");
+
+  Builder.defineMacro("__AMDGCN_WAVEFRONT_SIZE", Twine(WavefrontSize));
 }
 
 void AMDGPUTargetInfo::setAuxTarget(const TargetInfo *Aux) {

diff  --git a/clang/lib/Basic/Targets/AMDGPU.h 
b/clang/lib/Basic/Targets/AMDGPU.h
index 1f2fc081ae9d..a0e4c19f4fea 100644
--- a/clang/lib/Basic/Targets/AMDGPU.h
+++ b/clang/lib/Basic/Targets/AMDGPU.h
@@ -41,6 +41,7 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTargetInfo final : public 
TargetInfo {
 
   llvm::AMDGPU::GPUKind GPUKind;
   unsigned GPUFeatures;
+  unsigned WavefrontSize;
 
   /// Target ID is device name followed by optional feature name postfixed
   /// by plus or minus sign delimitted by colon, e.g. gfx908:xnack+:sram-ecc-.
@@ -407,6 +408,8 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTargetInfo final : 
public TargetInfo {
 getAllPossibleTargetIDFeatures(getTriple(), 
getArchNameAMDGCN(GPUKind));
 llvm::for_each(Features, [&](const auto &F) {
   assert(F.front() == '+' || F.front() == '-');
+  if (F == "+wavefrontsize64")
+WavefrontSize = 64;
   bool IsOn = F.front() == '+';
   StringRef Name = StringRef(F).drop_front();
   if (llvm::find(TargetIDFeatures, Name) == TargetIDFeatures.end())

diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp 
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index 61254e3eeaef..656de9dd9e1e 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -390,16 +390,9 @@ void amdgpu::getAMDGPUTargetFeatures(const Driver &D,
 }
   }
 
-  if (Args.getLastArg(options::OPT_mwavefrontsize64)) {
-Features.push_back("-wavefrontsize16");
-Features.push_back("-wavefrontsize32");
+  if (Args.hasFlag(options::OPT_mwavefrontsize64,
+   options::OPT_mno_wavefrontsize64, false))
 Features.push_back("+wavefrontsize64");
-  }
-  if (Args.getLastArg(options::OPT_mno_wavefrontsize64)) {
-Features.push_back("-wavefrontsize16");
-Features.push_back("+wavefrontsize32");
-Features.push_back("-wavefrontsize64");
-  }
 
   handleTargetFeaturesGroup(
 Args, Features, options::OPT_m_amdgpu_Features_Group);

diff  --git a/clang/test/Driver/amdgpu-features.c 
b/clang/test/Driver/amdgpu-features.c
index b97a98b90f7d..71fd63715e00 100644
--- a/clang/test/Driver/amdgpu-features.c
+++ b/clang/test/Driver/amdgpu-features.c
@@ -25,10 +25,16 @@
 // NO-SRAM-ECC: "-target-feature" "-sram-ecc"
 
 // RUN: %clang -### -target amdgcn-amdpal -mcpu=gfx1010 -mwavefrontsize64 %s 
2>&1 | FileCheck --check-prefix=WAVE64 %s
-// WAVE64: "-target-feature" "-wavefrontsize16" "-target-feature" 
"-wavefrontsize32" "-target-feature" "+wavefrontsize64"
+// RUN: %clang -### -target amdgcn-amdpal -mcpu=gfx1010 -mno-wavefrontsize64 
-mwavefrontsize64 %s 2>&1 | FileCheck --check-prefix=WAVE64 %s
+// WAVE64: "-target-feature" "+wavefrontsize64"
+// WAVE64-NOT: {{".*wavefrontsize16"}}
+// WAVE64-NOT: {{".*wavefrontsize32"}}
 
 // RUN: %clang -### -target amdgcn -mcpu=gfx1010 -mno-wavefrontsize64 %s 2>&1 
| FileCheck --check-prefix=NO-WAVE64 %s
-// NO-WAVE64: "-target-feature" "-wavefrontsize16" "-target-feature" 
"+wavefrontsize32" "-target-feature" "-wavefrontsize64"
+// RUN: %clang -### -target amdgcn -mcpu=gfx1010 -mwavefrontsize64 
-mno-wavefrontsize64 %s 2>&1 | FileCheck --check-prefix=NO-WAVE64 %s
+// NO-WAVE64-NOT: {{".*wavefrontsize16"}}
+// NO

[PATCH] D88370: Emit predefined macro for wavefront size for amdgcn

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG36501b180a4f: Emit predefined macro for wavefront size for 
amdgcn (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88370

Files:
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/test/Driver/amdgpu-features.c
  clang/test/Driver/amdgpu-macros.cl
  clang/test/Driver/hip-macros.hip
  clang/test/Driver/hip-toolchain-features.hip

Index: clang/test/Driver/hip-toolchain-features.hip
===
--- clang/test/Driver/hip-toolchain-features.hip
+++ clang/test/Driver/hip-toolchain-features.hip
@@ -37,8 +37,17 @@
 // RUN:   -mcumode -mcumode -mno-cumode -mwavefrontsize64 -mcumode \
 // RUN:   -mwavefrontsize64 -mno-wavefrontsize64 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=DUP
-// DUP: {{.*}}clang{{.*}} "-target-feature" "-wavefrontsize16"
-// DUP-SAME: "-target-feature" "+wavefrontsize32"
-// DUP-SAME: "-target-feature" "-wavefrontsize64"
-// DUP-SAME: "-target-feature" "+cumode"
-// DUP: {{.*}}lld{{.*}} "-plugin-opt=-mattr=-wavefrontsize16,+wavefrontsize32,-wavefrontsize64,+cumode"
+// DUP: {{.*}}clang{{.*}} "-target-feature" "+cumode"
+// DUP-NOT: "-target-feature" "{{.*}}wavefrontsize16"
+// DUP-NOT: "-target-feature" "{{.*}}wavefrontsize32"
+// DUP-NOT: "-target-feature" "{{.*}}wavefrontsize64"
+// DUP: {{.*}}lld{{.*}} "-plugin-opt=-mattr=+cumode"
+
+// RUN: %clang -### -target x86_64-linux-gnu -fgpu-rdc -nogpulib \
+// RUN:   --cuda-gpu-arch=gfx1010 %s \
+// RUN:   -mno-wavefrontsize64 -mwavefrontsize64 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=WAVE64
+// WAVE64: {{.*}}clang{{.*}} "-target-feature" "+wavefrontsize64"
+// WAVE64-NOT: "-target-feature" "{{.*}}wavefrontsize16"
+// WAVE64-NOT: "-target-feature" "{{.*}}wavefrontsize32"
+// WAVE64: {{.*}}lld{{.*}} "-plugin-opt=-mattr=+wavefrontsize64"
Index: clang/test/Driver/hip-macros.hip
===
--- /dev/null
+++ clang/test/Driver/hip-macros.hip
@@ -0,0 +1,20 @@
+// RUN: %clang -E -dM --offload-arch=gfx906 -mwavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s
+// RUN: %clang -E -dM --offload-arch=gfx1010 -mwavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s
+// RUN: %clang -E -dM --offload-arch=gfx906 -mwavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   -mno-wavefrontsize64 %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s
+// RUN: %clang -E -dM --offload-arch=gfx1010 -mwavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   -mno-wavefrontsize64 %s 2>&1 | FileCheck --check-prefixes=WAVE32 %s
+// RUN: %clang -E -dM --offload-arch=gfx906 -mno-wavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   -mwavefrontsize64 %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s
+// RUN: %clang -E -dM --offload-arch=gfx1010 -mno-wavefrontsize64 \
+// RUN:   --cuda-device-only -nogpuinc -nogpulib \
+// RUN:   -mwavefrontsize64 %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s
+// WAVE64-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// WAVE32-DAG: #define __AMDGCN_WAVEFRONT_SIZE 32
Index: clang/test/Driver/amdgpu-macros.cl
===
--- clang/test/Driver/amdgpu-macros.cl
+++ clang/test/Driver/amdgpu-macros.cl
@@ -346,4 +346,42 @@
 // GFX1011-DAG: #define __amdgcn_processor__ "gfx1011"
 // GFX1012-DAG: #define __amdgcn_processor__ "gfx1012"
 // GFX1030-DAG: #define __amdgcn_processor__ "gfx1030"
-// GFX1031-DAG: #define __amdgcn_processor__ "gfx1031"
\ No newline at end of file
+// GFX1031-DAG: #define __amdgcn_processor__ "gfx1031"
+
+// GFX600-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX601-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX700-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX701-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX702-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX703-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX704-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX801-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX802-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX803-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX810-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX900-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX902-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX904-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX906-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX908-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX909-DAG: #define __AMDGCN_WAVEFRONT_SIZE 64
+// GFX1010-DAG: #define __AMDGCN_WAVEFRONT_SIZE 32
+// GFX1011-DAG: #define __AMDGCN_WAVEFRONT_SIZE 32
+// GF

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Jason Liu via Phabricator via cfe-commits]

jasonliu added a comment.

Not sure if there is a better way to do this. But I have to admit this approach 
along with D88493  is a bit fragile. 
If plug-in writer forgets to set `HasExplicitDataSections` to true, then the 
final result that TargetMachine give for `getDataSections()` could be false on 
most platform even when they deliberately set `DataSections` to true.
We have other targets in LLVM that have -fdata-sections by default as well. And 
they do it differently as well, which makes this a bit more complicate to be 
consistent. 
For example, cloudABI would pass -fdata-sections through the Clang Driver by 
default. But that approach means if some user just invoke llc directly, they 
could get the wrong default on llc for that platform. 
Wasm would just overwrite the `DataSections` option to true in their 
TargetMachine. But that means you could not set it to false even if you want to.
I've thought about making the `DataSections` option in TargetOptions an enum 
instead of boolean value, where you could have `Default`, `On` and `Off` to 
represent what we actually want for the options. That's not a trivial change, 
as a lot of consumers for TargetOptions are relying it to be a boolean.
If you think it's a better way to solve this problem and I should explore, let 
me know.


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

https://reviews.llvm.org/D88737

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

[PATCH] D88680: Add ability to turn off -fpch-instantiate-templates in clang-cl

[Zachary Henkel via Phabricator via cfe-commits]

zahen added a comment.

This patch doesn't need a test case outside of the one that @rnk requested to 
make sure that the flag flows from the clang-cl driver appropriately.  
`pch-instantiate-templates` as authored doesn't match cl.exe behavior and being 
unable to turn it off will prevent our adoption of clang 11.  This is a release 
blocking issue at least for 11.1 if not 11.0 (I leave it to @hans to make the 
decision).  I suspect there are other users that will run into the same problem 
we have.

Of course we'll continue to work on a reduced repro to understand where the 
feature and msvc diverge but that will be a follow up patch or new bug.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88680

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

[clang] c87c017 - Fix failure in test hip-macros.hip

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2020-10-02T10:33:32-04:00
New Revision: c87c017a4c47c47b002b9f55f25285298cd07093

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

LOG: Fix failure in test hip-macros.hip

requires amdgpu-registered-target.

Added: 


Modified: 
clang/test/Driver/hip-macros.hip

Removed: 




diff  --git a/clang/test/Driver/hip-macros.hip 
b/clang/test/Driver/hip-macros.hip
index 00dcca17a08a..3105c25b8b9d 100644
--- a/clang/test/Driver/hip-macros.hip
+++ b/clang/test/Driver/hip-macros.hip
@@ -1,3 +1,4 @@
+// REQUIRES: clang-driver, amdgpu-registered-target
 // RUN: %clang -E -dM --offload-arch=gfx906 -mwavefrontsize64 \
 // RUN:   --cuda-device-only -nogpuinc -nogpulib \
 // RUN:   %s 2>&1 | FileCheck --check-prefixes=WAVE64 %s



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

[PATCH] D87451: add new option ignore-xcoff-visibility

[Digger via Phabricator via cfe-commits]

DiggerLin marked 5 inline comments as done.
DiggerLin added inline comments.



Comment at: clang/test/CodeGen/aix-no-xcoff-visibility.cpp:75
+
+// VISIBILITY-IR:@b = protected global i32 0
+// VISIBILITY-IR:@pramb = hidden global i32 0

jasonliu wrote:
> Not sure if the IR check is really necessary, since we haven't made any IR 
> change here. It's going to be all the same with or without the new -m option. 
IR output will not change in the new option. I think we need to check whether 
the IR be changed in the new option 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87451

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

[PATCH] D72218: [clang-tidy] new altera kernel name restriction check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/altera/KernelNameRestrictionCheck.cpp:90
+Check.diag(SM.getLocForStartOfFile(SM.getMainFileID()),
+   "Naming your OpenCL kernel source file 'kernel.cl', 
'Verilog.cl'"
+   ", or 'VHDL.cl' could cause compilation errors.");

aaron.ballman wrote:
> Similar here, I would word it something like: `compiling a source file named 
> '%0' may result in additional compilation errors due to the name of the file; 
> consider renaming the source file`
The diagnostic here doesn't look quite right. This is the case where the source 
compiland is named poorly, but the diagnostic is talking about including files. 
It looks like there's test coverage missing for this.


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

https://reviews.llvm.org/D72218

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

[PATCH] D87256: [clangd] Avoid relations being overwritten in a header shard

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

Sorry, I had a response to that comment but accidentally left it as 
unsubmitted...




Comment at: clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp:232
 
+TEST_F(BackgroundIndexTest, RelationsMultiFile) {
+  MockFS FS;

kadircet wrote:
> do we still need this test?
I think it's still useful, yes. If someone makes a change to the way relations 
are stored in the future, they could regress this use case without a test 
specifically for it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87256

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

[PATCH] D88446: docs: add documentation describing API Notes

[Saleem Abdulrasool via Phabricator via cfe-commits]

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



Comment at: clang/docs/APINotes.rst:216
+Due to a compiler bug, 'NullabilityOfRet' may change nullability of the
+parameters as well (rdar://30544062). Avoid using it and instead use
+'ResultType' and specify the return type along with a nullability

hlopko wrote:
> Could we get more context from the Apple bug tracker? Depending on the 
> details it might be reasonable to drop NullabilityOfRet attribute completely, 
> or more precisely document when it should be used.
The bug is that Nullability and Type on Parameters entries don’t really 
compose. Consider the following note:

```
  NullabilityOfRet: N
  Parameters:
  - Position: 1
Nullability: O
Type: 'NSDictionary *'
```

on a method: this parameter won’t be treated as optional. Effectively, you need 
to write the _Nullable on the type because the Nullability entry is ignored.

I think that fixing this later is preferable rather than earlier to ensure that 
we at least have a unified starting point where clang and Swift can co-evolve.  
If we try to do that while upstreaming, it will make everything far more 
difficult because you have to coordinate over multiple (3+) repositories.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88446

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

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Fangrui Song via Phabricator via cfe-commits]

MaskRay requested changes to this revision.
MaskRay added inline comments.
This revision now requires changes to proceed.



Comment at: clang/include/clang/Basic/CodeGenOptions.def:47
+CODEGENOPT(DataSections  , 1, 0) ///< Set by default, or when 
-f[no-]data-sections.
+CODEGENOPT(HasExplicitDataSections, 1, 0) ///< Set when -f[no-]data-sections 
is set.
 CODEGENOPT(UniqueSectionNames, 1, 1) ///< Set for -funique-section-names.

From the current code. I don't see HasExplicitDataSections is necessary. Please 
remove the lld changes.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4915
+  CmdArgs.push_back("-fno-data-sections");
+  } else if (UseSeparateSections) {
 CmdArgs.push_back("-fdata-sections");

You can place AIX in isUseSeparateSections instead.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:994
 
+  if (Args.getLastArg(OPT_fdata_sections) ||
+  Args.getLastArg(OPT_fno_data_sections)) {

In many cases, there is no need for having both positive and negative CC1 
options. The driver handles the default.


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

https://reviews.llvm.org/D88737

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

[PATCH] D88446: docs: add documentation describing API Notes

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd updated this revision to Diff 295835.
compnerd added a comment.

Update text based on feedback.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88446

Files:
  clang/docs/APINotes.rst
  
clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes
  clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.h
  
clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKitExplicitNullability.h
  
clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit_private.apinotes

Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit_private.apinotes
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit_private.apinotes
@@ -0,0 +1,15 @@
+Name: SomeKit
+Classes:
+  - Name: A
+Methods:
+  - Selector: "privateTransform:input:"
+MethodKind:  Instance
+NullabilityOfRet: N
+Nullability:  [ N, S ]
+Properties:
+  - Name: internalProperty
+Nullability: N
+Protocols:
+  - Name: InternalProtocol
+Availability: none
+AvailabilityMsg: "not for you"
Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKitExplicitNullability.h
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKitExplicitNullability.h
@@ -0,0 +1,4 @@
+@interface A(ExplicitNullabilityProperties)
+@property (nonatomic, readwrite, retain, nonnull) A *explicitNonnullInstance;
+@property (nonatomic, readwrite, retain, nullable) A *explicitNullableInstance;
+@end
Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.h
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.h
@@ -0,0 +1,60 @@
+#ifndef SOMEKIT_H
+#define SOMEKIT_H
+
+__attribute__((objc_root_class))
+@interface A
+-(A*)transform:(A*)input;
+-(A*)transform:(A*)input integer:(int)integer;
+
+@property (nonatomic, readonly, retain) A* someA;
+@property (nonatomic, retain) A* someOtherA;
+
+@property (nonatomic) int intValue;
+@end
+
+@interface B : A
+@end
+
+@interface C : A
+- (instancetype)init;
+- (instancetype)initWithA:(A*)a;
+@end
+
+@interface ProcessInfo : A
++(instancetype)processInfo;
+@end
+
+@interface A(NonNullProperties)
+@property (nonatomic, readwrite, retain) A *nonnullAInstance;
+@property (class, nonatomic, readwrite, retain) A *nonnullAInstance;
+
+@property (nonatomic, readwrite, retain) A *nonnullAClass;
+@property (class, nonatomic, readwrite, retain) A *nonnullAClass;
+
+@property (nonatomic, readwrite, retain) A *nonnullABoth;
+@property (class, nonatomic, readwrite, retain) A *nonnullABoth;
+@end
+
+#import 
+
+extern int *global_int_ptr;
+
+int *global_int_fun(int *ptr, int *ptr2);
+
+#define SOMEKIT_DOUBLE double
+
+__attribute__((objc_root_class))
+@interface OverriddenTypes
+-(int *)methodToMangle:(int *)ptr1 second:(int *)ptr2;
+@property int *intPropertyToMangle;
+@end
+
+@interface A(ImplicitGetterSetters)
+@property (nonatomic, readonly, retain) A *implicitGetOnlyInstance;
+@property (class, nonatomic, readonly, retain) A *implicitGetOnlyClass;
+
+@property (nonatomic, readwrite, retain) A *implicitGetSetInstance;
+@property (class, nonatomic, readwrite, retain) A *implicitGetSetClass;
+@end
+
+#endif
Index: clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes
===
--- /dev/null
+++ clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes
@@ -0,0 +1,98 @@
+Name: SomeKit
+Classes:
+  - Name: A
+Methods:
+  - Selector:"transform:"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "anything but this"
+  - Selector: "transform:integer:"
+MethodKind:  Instance
+NullabilityOfRet: N
+Nullability:  [ N, S ]
+  - Selector: "implicitGetOnlyInstance"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "implicitGetOnlyClass"
+MethodKind:  Class
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "implicitGetSetInstance"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "implicitGetSetClass"
+MethodKind:  Class
+Availability:none
+AvailabilityMsg: "getter gone"
+  - Selector: "setImplicitGetSetInstance:"
+MethodKind:  Instance
+Availability:none
+AvailabilityMsg: "setter gone"
+  - Selector: "setImplicitGetSetClass:"
+M

[PATCH] D88590: [clangd] Add benchmark for measuring latency of DecisionForest model.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 updated this revision to Diff 295837.
usaxena95 marked an inline comment as done.
usaxena95 added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88590

Files:
  clang-tools-extra/clangd/benchmarks/CMakeLists.txt
  clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
  
clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp

Index: clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
@@ -0,0 +1,85 @@
+//===--- DecisionForestBenchmark.cpp *- C++ -*-===//
+//
+// Benchmark for code completion ranking latency.
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// Usage:
+//ninja DecisionForestBenchmark && \
+//tools/clang/tools/extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark
+//===--===//
+
+#include "CompletionModel.h"
+#include "benchmark/benchmark.h"
+#include "llvm/ADT/StringRef.h"
+
+#include 
+
+namespace clang {
+namespace clangd {
+namespace {
+std::vector generateRandomDataset(int NumExamples) {
+  auto FlipCoin = [&](float Probability) {
+return rand() % 1000 <= Probability * 1000;
+  };
+  auto RandInt = [&](int Max) { return rand() % Max; };
+  auto RandFloat = [&](float Max = 1.0) {
+return rand() % 1000 / 1000.0 * Max;
+  };
+
+  std::vector Examples;
+  Examples.reserve(NumExamples);
+  for (int I = 0; I < NumExamples; ++I) {
+Example E;
+E.setIsDeprecated(FlipCoin(0.1));   // Boolean.
+E.setIsReservedName(FlipCoin(0.1)); // Boolean.
+E.setIsImplementationDetail(FlipCoin(0.3)); // Boolean.
+E.setNumReferences(RandInt(1)); // Can be large integer.
+E.setSymbolCategory(RandInt(10));   // 10 Symbol Category.
+
+E.setIsNameInContext(FlipCoin(0.5)); // Boolean.
+E.setIsForbidden(FlipCoin(0.1)); // Boolean.
+E.setIsInBaseClass(FlipCoin(0.3));   // Boolean.
+E.setFileProximityDistance(
+FlipCoin(0.1) ? 99 // Sometimes file distance is not available.
+  : RandInt(20));
+E.setSemaFileProximityScore(RandFloat(1)); // Float in range [0,1].
+E.setSymbolScopeDistance(
+FlipCoin(0.1) ? 99 // Sometimes scope distance is not available.
+  : RandInt(20));
+E.setSemaSaysInScope(FlipCoin(0.5));  // Boolean.
+E.setScope(RandInt(4));   // 4 Scopes.
+E.setContextKind(RandInt(32));// 32 Context kinds.
+E.setIsInstanceMember(FlipCoin(0.5)); // Boolean.
+E.setHadContextType(FlipCoin(0.6));   // Boolean.
+E.setHadSymbolType(FlipCoin(0.6));// Boolean.
+E.setTypeMatchesPreferred(FlipCoin(0.5)); // Boolean.
+E.setFilterLength(RandInt(15));
+Examples.push_back(E);
+  }
+  return Examples;
+}
+
+void runDecisionForestPrediciton(const std::vector Examples) {
+  for (const Example &E : Examples)
+Evaluate(E);
+}
+
+static void decisionForestPredict(benchmark::State &State) {
+  srand(0);
+  for (auto _ : State) {
+State.PauseTiming();
+const std::vector Examples = generateRandomDataset(100);
+State.ResumeTiming();
+runDecisionForestPrediciton(Examples);
+  }
+}
+BENCHMARK(decisionForestPredict);
+
+} // namespace
+} // namespace clangd
+} // namespace clang
+
+BENCHMARK_MAIN();
Index: clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
@@ -0,0 +1,9 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
+
+add_benchmark(DecisionForestBenchmark DecisionForestBenchmark.cpp)
+
+target_link_libraries(DecisionForestBenchmark
+  PRIVATE
+  clangDaemon
+  LLVMSupport
+  )
Index: clang-tools-extra/clangd/benchmarks/CMakeLists.txt
===
--- clang-tools-extra/clangd/benchmarks/CMakeLists.txt
+++ clang-tools-extra/clangd/benchmarks/CMakeLists.txt
@@ -1,5 +1,7 @@
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
 
+add_subdirectory(CompletionModel)
+
 add_benchmark(IndexBenchmark IndexBenchmark.cpp)
 
 target_link_libraries(IndexBenchmark
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88590: [clangd] Add benchmark for measuring latency of DecisionForest model.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 added inline comments.



Comment at: 
clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp:74
+  for (auto _ : State) {
+srand(0);
+State.PauseTiming();

adamcz wrote:
> Move this out of the loop. Right now we re-generate "random" dataset, but 
> it's always the same dataset ;-)
I added it inside the loop since there is only one state right now. But 
probably moving it out makes it more meaningful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88590

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

[PATCH] D87451: add new option ignore-xcoff-visibility

[Digger via Phabricator via cfe-commits]

DiggerLin updated this revision to Diff 295838.
DiggerLin marked an inline comment as done.
DiggerLin added a comment.

address comment and merger the patch https://reviews.llvm.org/D88234 into the 
patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87451

Files:
  clang/docs/ClangCommandLineReference.rst
  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/CodeGen/aix-ignore-xcoff-visibility.cpp
  clang/test/Driver/ignore-xcoff-visibility.cpp
  llvm/include/llvm/CodeGen/CommandFlags.h
  llvm/include/llvm/Target/TargetMachine.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/CommandFlags.cpp
  llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
  llvm/test/CodeGen/PowerPC/aix-ignore-xcoff-visibility.ll

Index: llvm/test/CodeGen/PowerPC/aix-ignore-xcoff-visibility.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/aix-ignore-xcoff-visibility.ll
@@ -0,0 +1,48 @@
+; RUN: llc -verify-machineinstrs -mtriple powerpc-ibm-aix-xcoff -mcpu=pwr4 \
+; RUN: -mattr=-altivec  < %s | \
+; RUN:   FileCheck --check-prefix=VISIBILITY-ASM %s
+; RUN: llc -verify-machineinstrs -mtriple powerpc-ibm-aix-xcoff -mcpu=pwr4 \
+; RUN: -mattr=-altivec -ignore-xcoff-visibility < %s | \
+; RUN:   FileCheck --check-prefix=IGNOREVISIBILITY-ASM %s
+; RUN: llc -verify-machineinstrs -mtriple powerpc64-ibm-aix-xcoff -mcpu=pwr4 \
+; RUN: -mattr=-altivec < %s | \
+; RUN:   FileCheck --check-prefix=VISIBILITY-ASM %s
+; RUN: llc -verify-machineinstrs -mtriple powerpc64-ibm-aix-xcoff -mcpu=pwr4 \
+; RUN: -mattr=-altivec -ignore-xcoff-visibility < %s | \
+; RUN:   FileCheck --check-prefix=IGNOREVISIBILITY-ASM %s
+
+@foo_p = global void ()* @zoo_extern_h, align 4
+@b = protected global i32 0, align 4
+
+define hidden void @foo_h(i32* %p) {
+entry:
+  %p.addr = alloca i32*, align 4
+  store i32* %p, i32** %p.addr, align 4
+  %0 = load i32*, i32** %p.addr, align 4
+  %1 = load i32, i32* %0, align 4
+  %inc = add nsw i32 %1, 1
+  store i32 %inc, i32* %0, align 4
+  ret void
+}
+
+declare hidden void @zoo_extern_h()
+
+define protected void @bar() {
+entry:
+  call void @foo_h(i32* @b)
+  %0 = load void ()*, void ()** @foo_p, align 4
+  call void %0()
+  ret void
+}
+
+; VISIBILITY-ASM: .globl  foo_h[DS],hidden
+; VISIBILITY-ASM: .globl  .foo_h,hidden
+; VISIBILITY-ASM: .globl  bar[DS],protected
+; VISIBILITY-ASM: .globl  .bar,protected
+; VISIBILITY-ASM: .globl  b,protected
+
+; IGNOREVISIBILITY-ASM: .globl  foo_h[DS]
+; IGNOREVISIBILITY-ASM: .globl  .foo_h
+; IGNOREVISIBILITY-ASM: .globl  bar[DS]
+; IGNOREVISIBILITY-ASM: .globl  .bar
+; IGNOREVISIBILITY-ASM: .globl  b
Index: llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
===
--- llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
+++ llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
@@ -1702,17 +1702,19 @@
   assert(LinkageAttr != MCSA_Invalid && "LinkageAttr should not MCSA_Invalid.");
 
   MCSymbolAttr VisibilityAttr = MCSA_Invalid;
-  switch (GV->getVisibility()) {
+  if (!TM.getIgnoreXCOFFVisibility()) {
+switch (GV->getVisibility()) {
 
-  // TODO: "exported" and "internal" Visibility needs to go here.
-  case GlobalValue::DefaultVisibility:
-break;
-  case GlobalValue::HiddenVisibility:
-VisibilityAttr = MAI->getHiddenVisibilityAttr();
-break;
-  case GlobalValue::ProtectedVisibility:
-VisibilityAttr = MAI->getProtectedVisibilityAttr();
-break;
+// TODO: "exported" and "internal" Visibility needs to go here.
+case GlobalValue::DefaultVisibility:
+  break;
+case GlobalValue::HiddenVisibility:
+  VisibilityAttr = MAI->getHiddenVisibilityAttr();
+  break;
+case GlobalValue::ProtectedVisibility:
+  VisibilityAttr = MAI->getProtectedVisibilityAttr();
+  break;
+}
   }
 
   OutStreamer->emitXCOFFSymbolLinkageWithVisibility(GVSym, LinkageAttr,
Index: llvm/lib/CodeGen/CommandFlags.cpp
===
--- llvm/lib/CodeGen/CommandFlags.cpp
+++ llvm/lib/CodeGen/CommandFlags.cpp
@@ -74,6 +74,7 @@
 CGOPT(bool, RelaxELFRelocations)
 CGOPT_EXP(bool, DataSections)
 CGOPT_EXP(bool, FunctionSections)
+CGOPT(bool, IgnoreXCOFFVisibility)
 CGOPT(std::string, BBSections)
 CGOPT(unsigned, TLSSize)
 CGOPT(bool, EmulatedTLS)
@@ -333,6 +334,13 @@
   cl::init(false));
   CGBINDOPT(FunctionSections);
 
+  static cl::opt IgnoreXCOFFVisibility(
+  "ignore-xcoff-visibility",
+  cl::desc("Not emit the visibility attribute for asm in AIX OS or give "
+   "all symbols 'unspecified' visibility in xcoff object file"),
+  cl::init(false));
+  CGBINDOPT(IgnoreXCOFFVisibility);
+
   static cl::opt BBSections(
   "bas

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

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

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

Updated check for system function.
Updated documentation.
Added more test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87449

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp
  clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-sig30-c.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/cert-sig30-c_cpp.h
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/signal.h
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/stdlib.h
  clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.c
  clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.cpp
@@ -0,0 +1,64 @@
+// RUN: %check_clang_tidy %s cert-sig30-c %t -- -- -isystem %S/Inputs/Headers
+
+#include "cert-sig30-c_cpp.h"
+#include "stdio.h"
+
+void handler_abort(int) {
+  std::abort();
+}
+
+void handler__Exit(int) {
+  std::_Exit(0);
+}
+
+void handler_quick_exit(int) {
+  std::quick_exit(0);
+}
+
+void handler_bad1(int) {
+  std::something(1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'something' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void handler_bad2(int) {
+  std::SysStruct S;
+  S << 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'operator<<' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void handler_signal(int) {
+  // FIXME: It is only OK to call signal with the current signal number.
+  std::signal(0, SIG_DFL);
+  std::signal(0, SIG_IGN);
+}
+
+void handler_nowarn(int) {
+  std::something(2);
+}
+
+// Function called "signal" that is not to be recognized by the checker.
+typedef void (*callback_t)(int);
+void signal(int, callback_t, int);
+
+namespace ns {
+void signal(int, callback_t);
+}
+
+struct S {
+  static void signal(int, callback_t);
+};
+
+void test() {
+  std::signal(SIGINT, handler_abort);
+  std::signal(SIGINT, handler__Exit);
+  std::signal(SIGINT, handler_quick_exit);
+  std::signal(SIGINT, handler_signal);
+  std::signal(SIGINT, handler_bad1);
+  std::signal(SIGINT, handler_bad2);
+
+  // Do not find problems here.
+  signal(SIGINT, handler_nowarn, 1);
+  ns::signal(SIGINT, handler_nowarn);
+  S::signal(SIGINT, handler_nowarn);
+  system_other::signal(SIGINT, handler_nowarn);
+}
Index: clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.c
@@ -0,0 +1,81 @@
+// RUN: %check_clang_tidy %s cert-sig30-c %t -- -- -isystem %S/Inputs/Headers
+
+// The function should be classified as system call even if there is a
+// declaration before or after the one in a system header.
+int printf(const char *, ...);
+
+typedef void (*sighandler_t)(int);
+sighandler_t signal(int signum, sighandler_t handler);
+
+#include "signal.h"
+#include "stdio.h"
+#include "stdlib.h"
+
+int printf(const char *, ...);
+
+sighandler_t signal(int signum, sighandler_t handler);
+
+void handler_abort(int) {
+  abort();
+}
+
+void handler__Exit(int) {
+  _Exit(0);
+}
+
+void handler_quick_exit(int) {
+  quick_exit(0);
+}
+
+void handler_other(int) {
+  printf("1234");
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void handler_signal(int) {
+  // FIXME: It is only OK to call signal with the current signal number.
+  signal(0, SIG_DFL);
+}
+
+void f_ok() {
+  abort();
+}
+
+void f_bad() {
+  printf("1234");
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void f_extern();
+
+void handler_ok(int) {
+  f_ok();
+}
+
+void handler_bad(int) {
+  f_bad();
+}
+
+void handler_extern(int) {
+  f_extern();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+}
+
+void test() {
+  signal(SIGINT, handler_abort);
+  signal(SIGINT, handler__Exit);
+  signal(SIGINT, handler_quick_exit);
+  signal(SIGINT, handler_signal);
+  signal(SIGINT, handler_other);
+
+  signal(SIGINT, handler_ok);
+  signal(SIGINT, handler_bad);
+  signal(SIGINT, handler_extern);
+
+  signal(SIGINT, quick_exit);
+  signal(SIGINT, other_call);
+  // CHECK-MESSAGES: :[

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

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

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



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:33
+
+  for (const FunctionDecl *D : Node.redecls())
+if (D->getASTContext().getSourceManager().isInSystemHeader(

aaron.ballman wrote:
> balazske wrote:
> > aaron.ballman wrote:
> > > balazske wrote:
> > > > aaron.ballman wrote:
> > > > > I'm not certain I understand why we're looking through the entire 
> > > > > redeclaration chain to see if the function is ever mentioned in a 
> > > > > system header. I was expecting we'd look at the expansion location of 
> > > > > the declaration and see if that's in a system header, which is 
> > > > > already handled by the `isExpansionInSystemHeader()` matcher. Similar 
> > > > > below.
> > > > This function is called from ` SignalHandlerCheck::check` when any 
> > > > function call is found. So the check for system header is needed. It 
> > > > was unclear to me what the "expansion location" means but it seems to 
> > > > work if using that expansion location and checking for system header, 
> > > > instead of this loop. I will update the code.
> > > > This function is called from  SignalHandlerCheck::check when any 
> > > > function call is found. So the check for system header is needed. 
> > > 
> > > The check for the system header isn't what I was concerned by, it was the 
> > > fact that we're walking the entire redeclaration chain to see if *any* 
> > > declaration is in a system header that I don't understand the purpose of.
> > > 
> > > > It was unclear to me what the "expansion location" means but it seems 
> > > > to work if using that expansion location and checking for system 
> > > > header, instead of this loop. I will update the code.
> > > 
> > > The spelling location is where the user wrote the code and the expansion 
> > > location is where the macro name is written, but thinking on it harder, 
> > > that shouldn't matter for this situation as either location would be in 
> > > the system header anyway.
> > The function declaration is not often a macro name so there is no 
> > "expansion location" or the same as the original location. My concern was 
> > that if there is a declaration of system call function in a source file 
> > (like `void abort(void);` in .c file) for any reason, we may find this 
> > declaration instead of the one in the header file, if not looping over the 
> > declaration chain.
> > The function declaration is not often a macro name so there is no 
> > "expansion location" or the same as the original location.
> 
> Agreed.
> 
> > My concern was that if there is a declaration of system call function in a 
> > source file (like `void abort(void);` in .c file) for any reason, we may 
> > find this declaration instead of the one in the header file, if not looping 
> > over the declaration chain.
> 
> Typically, when a C user does something like that, it's because they're 
> explicitly *not* including the header file at all (they're just forward 
> declaring the function so they can use it) and so we'd get the logic wrong 
> for them anyway because we'd never find the declaration in the system header.
> 
> Using the canonical declaration is more typical and would realistically fail 
> only in circumstances like forward declaring a system header function and 
> then later including the system header itself. That said, I suppose your 
> approach is defensible enough. Redeclaration chains are hopefully short 
> enough that it isn't a performance hit.
I changed back to the original code to search the entire redeclaration chain. 
Otherwise it can be fooled with declarations before or after inclusion of the 
system header. Such declarations were added to the test file (it did not pass 
if `isExpansionInSystemHeader` was used).



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:41
+static bool isAllowedSystemCall(const FunctionDecl *FD) {
+  if (!FD->getIdentifier())
+return true;

aaron.ballman wrote:
> A function without an identifier is not a system call, so I would have 
> expected this to return `false` based on the function name.
I would think that if the function is an operation on a std object 
(`std::vector`) it should be classified as system call, and these operations 
(or many of them) look not asynchronous-safe.



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-sig30-c.rst:13
+(for ``signal`` there are additional conditions that are not checked).
+Every other system call is considered as non asynchronous-safe by the checker.
+

aaron.ballman wrote:
> balazske wrote:
> > aaron.ballman wrote:
> > > I would document this as: `Any function that cannot be determined to be 
> > > an asynchronous-safe function call is assumed to be non-asynchronous-safe 
> > > by the checker, including function calls for which only the declaration 
> > > of the called 

[clang-tools-extra] db2a646 - [clangd] Add bencmark for measuring latency of DecisionForest model.

[Utkarsh Saxena via cfe-commits]

Author: Utkarsh Saxena
Date: 2020-10-02T18:04:31+02:00
New Revision: db2a646c5f002cc16d02d6fac0b2d715cdd4a809

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

LOG: [clangd] Add bencmark for measuring latency of DecisionForest model.

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

Added: 
clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt

clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp

Modified: 
clang-tools-extra/clangd/benchmarks/CMakeLists.txt

Removed: 




diff  --git a/clang-tools-extra/clangd/benchmarks/CMakeLists.txt 
b/clang-tools-extra/clangd/benchmarks/CMakeLists.txt
index 1f3d88b42bce..b62ffd7a1ad1 100644
--- a/clang-tools-extra/clangd/benchmarks/CMakeLists.txt
+++ b/clang-tools-extra/clangd/benchmarks/CMakeLists.txt
@@ -1,5 +1,7 @@
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
 
+add_subdirectory(CompletionModel)
+
 add_benchmark(IndexBenchmark IndexBenchmark.cpp)
 
 target_link_libraries(IndexBenchmark

diff  --git 
a/clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt 
b/clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
new file mode 100644
index ..3998aa122533
--- /dev/null
+++ b/clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
@@ -0,0 +1,9 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
+
+add_benchmark(DecisionForestBenchmark DecisionForestBenchmark.cpp)
+
+target_link_libraries(DecisionForestBenchmark
+  PRIVATE
+  clangDaemon
+  LLVMSupport
+  )

diff  --git 
a/clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
 
b/clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
new file mode 100644
index ..69ce65e08b77
--- /dev/null
+++ 
b/clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
@@ -0,0 +1,85 @@
+//===--- DecisionForestBenchmark.cpp *- C++ -*-===//
+//
+// Benchmark for code completion ranking latency.
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// Usage:
+//ninja DecisionForestBenchmark && \
+//
tools/clang/tools/extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark
+//===--===//
+
+#include "CompletionModel.h"
+#include "benchmark/benchmark.h"
+#include "llvm/ADT/StringRef.h"
+
+#include 
+
+namespace clang {
+namespace clangd {
+namespace {
+std::vector generateRandomDataset(int NumExamples) {
+  auto FlipCoin = [&](float Probability) {
+return rand() % 1000 <= Probability * 1000;
+  };
+  auto RandInt = [&](int Max) { return rand() % Max; };
+  auto RandFloat = [&](float Max = 1.0) {
+return rand() % 1000 / 1000.0 * Max;
+  };
+
+  std::vector Examples;
+  Examples.reserve(NumExamples);
+  for (int I = 0; I < NumExamples; ++I) {
+Example E;
+E.setIsDeprecated(FlipCoin(0.1));   // Boolean.
+E.setIsReservedName(FlipCoin(0.1)); // Boolean.
+E.setIsImplementationDetail(FlipCoin(0.3)); // Boolean.
+E.setNumReferences(RandInt(1)); // Can be large integer.
+E.setSymbolCategory(RandInt(10));   // 10 Symbol Category.
+
+E.setIsNameInContext(FlipCoin(0.5)); // Boolean.
+E.setIsForbidden(FlipCoin(0.1)); // Boolean.
+E.setIsInBaseClass(FlipCoin(0.3));   // Boolean.
+E.setFileProximityDistance(
+FlipCoin(0.1) ? 99 // Sometimes file distance is not available.
+  : RandInt(20));
+E.setSemaFileProximityScore(RandFloat(1)); // Float in range [0,1].
+E.setSymbolScopeDistance(
+FlipCoin(0.1) ? 99 // Sometimes scope distance is not available.
+  : RandInt(20));
+E.setSemaSaysInScope(FlipCoin(0.5));  // Boolean.
+E.setScope(RandInt(4));   // 4 Scopes.
+E.setContextKind(RandInt(32));// 32 Context kinds.
+E.setIsInstanceMember(FlipCoin(0.5)); // Boolean.
+E.setHadContextType(FlipCoin(0.6));   // Boolean.
+E.setHadSymbolType(FlipCoin(0.6));// Boolean.
+E.setTypeMatchesPreferred(FlipCoin(0.5)); // Boolean.
+E.setFilterLength(RandInt(15));
+Examples.push_back(E);
+  }
+  return Examples;
+}
+
+void runDecisionForestPrediciton(const std::vector Examples) {
+  for (const Example &E : Examples)
+Evaluate(E);
+}
+
+static void decisionForestPredict(benchmark::State &State) {
+  srand(0);
+  for (auto _ : State) {
+State.PauseTiming();
+const std::vector Examples = generateRandomDataset(100);
+State.ResumeTiming();
+runDecis

[PATCH] D88590: [clangd] Add benchmark for measuring latency of DecisionForest model.

[Utkarsh Saxena via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGdb2a646c5f00: [clangd] Add bencmark for measuring latency of 
DecisionForest model. (authored by usaxena95).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88590

Files:
  clang-tools-extra/clangd/benchmarks/CMakeLists.txt
  clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
  
clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp

Index: clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark.cpp
@@ -0,0 +1,85 @@
+//===--- DecisionForestBenchmark.cpp *- C++ -*-===//
+//
+// Benchmark for code completion ranking latency.
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+// Usage:
+//ninja DecisionForestBenchmark && \
+//tools/clang/tools/extra/clangd/benchmarks/CompletionModel/DecisionForestBenchmark
+//===--===//
+
+#include "CompletionModel.h"
+#include "benchmark/benchmark.h"
+#include "llvm/ADT/StringRef.h"
+
+#include 
+
+namespace clang {
+namespace clangd {
+namespace {
+std::vector generateRandomDataset(int NumExamples) {
+  auto FlipCoin = [&](float Probability) {
+return rand() % 1000 <= Probability * 1000;
+  };
+  auto RandInt = [&](int Max) { return rand() % Max; };
+  auto RandFloat = [&](float Max = 1.0) {
+return rand() % 1000 / 1000.0 * Max;
+  };
+
+  std::vector Examples;
+  Examples.reserve(NumExamples);
+  for (int I = 0; I < NumExamples; ++I) {
+Example E;
+E.setIsDeprecated(FlipCoin(0.1));   // Boolean.
+E.setIsReservedName(FlipCoin(0.1)); // Boolean.
+E.setIsImplementationDetail(FlipCoin(0.3)); // Boolean.
+E.setNumReferences(RandInt(1)); // Can be large integer.
+E.setSymbolCategory(RandInt(10));   // 10 Symbol Category.
+
+E.setIsNameInContext(FlipCoin(0.5)); // Boolean.
+E.setIsForbidden(FlipCoin(0.1)); // Boolean.
+E.setIsInBaseClass(FlipCoin(0.3));   // Boolean.
+E.setFileProximityDistance(
+FlipCoin(0.1) ? 99 // Sometimes file distance is not available.
+  : RandInt(20));
+E.setSemaFileProximityScore(RandFloat(1)); // Float in range [0,1].
+E.setSymbolScopeDistance(
+FlipCoin(0.1) ? 99 // Sometimes scope distance is not available.
+  : RandInt(20));
+E.setSemaSaysInScope(FlipCoin(0.5));  // Boolean.
+E.setScope(RandInt(4));   // 4 Scopes.
+E.setContextKind(RandInt(32));// 32 Context kinds.
+E.setIsInstanceMember(FlipCoin(0.5)); // Boolean.
+E.setHadContextType(FlipCoin(0.6));   // Boolean.
+E.setHadSymbolType(FlipCoin(0.6));// Boolean.
+E.setTypeMatchesPreferred(FlipCoin(0.5)); // Boolean.
+E.setFilterLength(RandInt(15));
+Examples.push_back(E);
+  }
+  return Examples;
+}
+
+void runDecisionForestPrediciton(const std::vector Examples) {
+  for (const Example &E : Examples)
+Evaluate(E);
+}
+
+static void decisionForestPredict(benchmark::State &State) {
+  srand(0);
+  for (auto _ : State) {
+State.PauseTiming();
+const std::vector Examples = generateRandomDataset(100);
+State.ResumeTiming();
+runDecisionForestPrediciton(Examples);
+  }
+}
+BENCHMARK(decisionForestPredict);
+
+} // namespace
+} // namespace clangd
+} // namespace clang
+
+BENCHMARK_MAIN();
Index: clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/benchmarks/CompletionModel/CMakeLists.txt
@@ -0,0 +1,9 @@
+include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
+
+add_benchmark(DecisionForestBenchmark DecisionForestBenchmark.cpp)
+
+target_link_libraries(DecisionForestBenchmark
+  PRIVATE
+  clangDaemon
+  LLVMSupport
+  )
Index: clang-tools-extra/clangd/benchmarks/CMakeLists.txt
===
--- clang-tools-extra/clangd/benchmarks/CMakeLists.txt
+++ clang-tools-extra/clangd/benchmarks/CMakeLists.txt
@@ -1,5 +1,7 @@
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../)
 
+add_subdirectory(CompletionModel)
+
 add_benchmark(IndexBenchmark IndexBenchmark.cpp)
 
 target_link_libraries(IndexBenchmark
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74144: [OPENMP50]Add basic support for array-shaping operation.

[Chi Chun Chen via Phabricator via cfe-commits]

cchen added a comment.

In D74144#2307494 , @ABataev wrote:

> In D74144#2307454 , @cchen wrote:
>
>> @ABataev, the below test is extracted from Sollve test suite and Clang now 
>> emit:
>>
>>   test.c:17:35: error: subscripted value is not an array or pointer
>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>> ^
>>   test.c:17:5: error: expected at least one 'to' clause or 'from' clause 
>> specified to '#pragma omp target update'
>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>>
>> This error message came from the `ActOnOMPArraySectionExpr` which is called 
>> inside `ParsePostfixExpressionSuffix`. The issue is that the base expression 
>> in `ActOnOMPArraySectionExpr` looks like:
>>
>>   ParenExpr 0x122859be0 '' lvalue
>>   `-OMPArrayShapingExpr 0x122859b98 '' lvalue
>> |-IntegerLiteral 0x122859b38 'int' 5
>> |-IntegerLiteral 0x122859b58 'int' 5
>> `-DeclRefExpr 0x122859b78 'int *' lvalue Var 0x1228599d0 'foo' 'int *'
>>
>> which is not a base that we would expect in an array section expr. I've 
>> tried relaxing the base type check in `ActOnOMPArraySectionExpr` but not 
>> sure it's the way to go. (or should I just extract the DeclReExpr from 
>> ArrayShapingExpr before calling `ActOnOMPArraySectionExpr`?)
>>
>>   #define N 5
>>   #define M 3
>>   
>>   int main(void) {
>>   int tmp[N][N];
>>   for(int i=0; i>   for(int j=0; j>   tmp[i][j] = N*i + j;
>>   
>>   int *foo = &tmp[0][0];
>>   
>>   // This compiles just fine
>>   //#pragma omp target update to( ([N][N])foo )
>>   
>>   // This is rejected by the compiler
>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>>   }
>
> I don't think it is allowed by the standard.
>
> According to the standard, The shape-operator can appear only in clauses 
> where it is explicitly allowed.
> In this case, array shaping is used as a base expression of array section (or 
> subscript) expression, which does not meet the standard. Tje array sjaping 
> operation is not used in clause, instead it is used as a base subexpression 
> of another expression.

In OpenMP 5.0 [2.12.6, target update construct, Restrictions, C/C++, p.1] The 
list items that appear in the to or from clauses may use shape-operators.
Also, in the array shaping section in https://github.com/OpenMP/Examples, the 
example is also illustrated with the same usage:

  ...
  S-17 // update boundary points (two columns of 2D array) on the host
  S-18 // pointer is shaped to 2D array using the shape-operator
  S-19 #pragma omp target update from( (([nx][ny+2])a)[0:nx][1], 
(([nx][ny+2])a)[0:nx][ny] )
  ...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74144

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

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:27
+  // Find a possible redeclaration in system header.
+  for (const FunctionDecl *D : FD->redecls())
+if (FD->getASTContext().getSourceManager().isInSystemHeader(

```
return llvm::any_of(FD->redecls(), [](const FunctionDecl *D) {
  return 
D->getASTContext().getSourceManager().isInSystemHeader(D->getLocation());
});
```



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:117-118
+FunctionCallCollector Collector{[&CalledFunctions](const CallExpr *CE) {
+  if (isa(CE->getCalleeDecl()))
+CalledFunctions.push_back(CE);
+}};

For correctness, I think you need to handle more than just calls to function 
declarations -- for instance, this should be just as problematic:
```
void some_signal_handler(int sig) {
  []{ puts("this should not be an escape hatch for the check); }();
}
```
even though the call expression in the signal handler doesn't resolve back to a 
function declaration. (Similar for blocks instead of lambdas.) WDYT?



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:134
+// At insertion we have already ensured that only function calls are there.
+const FunctionDecl *F = cast(FunctionCall->getCalleeDecl());
+

`const auto *`



Comment at: clang-tools-extra/test/clang-tidy/checkers/cert-sig30-c.cpp:52
+void test() {
+  std::signal(SIGINT, handler_abort);
+  std::signal(SIGINT, handler__Exit);

I'd also like to see a test case where the handler to `signal` call is itself 
not a function call:
```
std::signal(SIGINT, [](int sig) {
  puts("I did the bad thing this way"); // should be diagnosed, yes?
});
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87449

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

[PATCH] D87449: [clang-tidy] Add new check for SEI CERT rule SIG30-C

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/SignalHandlerCheck.cpp:41
+static bool isAllowedSystemCall(const FunctionDecl *FD) {
+  if (!FD->getIdentifier())
+return true;

balazske wrote:
> aaron.ballman wrote:
> > A function without an identifier is not a system call, so I would have 
> > expected this to return `false` based on the function name.
> I would think that if the function is an operation on a std object 
> (`std::vector`) it should be classified as system call, and these operations 
> (or many of them) look not asynchronous-safe.
Hmm, that's an interesting point I hadn't considered and I don't know what the 
correct answer is as it relates to this check. For instance, this code is bad, 
but not because of sig30-C:
```
std::vector some_global_vector;
void sig_handler(int sig) {
  int &i = some_global_vector[0];
  ...
}
```
I doubt that `operator[]()` is actually making any system calls under the hood, 
so it's fine per sig30-c, but the code is still bad (it should fail sig31-c 
about not using shared objects from signals). On the flip side:
```
std::packaged_task some_task;
void sig_handler(int sig) {
  some_task(sig); // Who knows what this will execute when it calls operator()()
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87449

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

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Jason Liu via Phabricator via cfe-commits]

jasonliu added inline comments.



Comment at: clang/include/clang/Basic/CodeGenOptions.def:47
+CODEGENOPT(DataSections  , 1, 0) ///< Set by default, or when 
-f[no-]data-sections.
+CODEGENOPT(HasExplicitDataSections, 1, 0) ///< Set when -f[no-]data-sections 
is set.
 CODEGENOPT(UniqueSectionNames, 1, 1) ///< Set for -funique-section-names.

MaskRay wrote:
> From the current code. I don't see HasExplicitDataSections is necessary. 
> Please remove the lld changes.
The reason I need `HasExplicitDataSections` goes back to D88493(which I haven't 
land yet, because I actually need to land these two patches together to avoid 
build break). In D88493, I'm trying to get the llc's default for -data-sections 
to be correct for AIX and introduced `HasExplicitDataSections`. If 
`HasExplicitDataSections` is not set, then llc would think there is 
-data-sections set, so it would just take the target triple's default, which 
makes `DataSections` setting to be useless. 
It seems there is no good way to set a certain TargetOption's default to be 
dependant on the current target triple. As I already mentioned in my own 
comment in this patch, one of the way to achieve that could be make 
DataSections an enum option in TargetOptions, so that it could have a `Default` 
enum which could mean true or false depending on the triple setting. But it 
could mean a bigger refactoring to this option. 


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

https://reviews.llvm.org/D88737

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

[PATCH] D88377: Diagnose invalid target ID for AMDGPU toolchain for assembler

[Aaron Enye Shi via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D88377

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

[PATCH] D88338: [clangd] clangd --check: standalone diagnosis of common problems

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.

In D88338#2307976 , @sammccall wrote:

> Sorry @rsmith @hoy, I've replaced the test with one without such dependencies 
> in bc18d8d9b705d31a94c51900c8b18e4feaf9c7fb 
> .

Thanks for the quick turnaround!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88338

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

[PATCH] D74144: [OPENMP50]Add basic support for array-shaping operation.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D74144#2308796 , @cchen wrote:

> In D74144#2307494 , @ABataev wrote:
>
>> In D74144#2307454 , @cchen wrote:
>>
>>> @ABataev, the below test is extracted from Sollve test suite and Clang now 
>>> emit:
>>>
>>>   test.c:17:35: error: subscripted value is not an array or pointer
>>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>>> ^
>>>   test.c:17:5: error: expected at least one 'to' clause or 'from' clause 
>>> specified to '#pragma omp target update'
>>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>>>
>>> This error message came from the `ActOnOMPArraySectionExpr` which is called 
>>> inside `ParsePostfixExpressionSuffix`. The issue is that the base 
>>> expression in `ActOnOMPArraySectionExpr` looks like:
>>>
>>>   ParenExpr 0x122859be0 '' lvalue
>>>   `-OMPArrayShapingExpr 0x122859b98 '' lvalue
>>> |-IntegerLiteral 0x122859b38 'int' 5
>>> |-IntegerLiteral 0x122859b58 'int' 5
>>> `-DeclRefExpr 0x122859b78 'int *' lvalue Var 0x1228599d0 'foo' 'int *'
>>>
>>> which is not a base that we would expect in an array section expr. I've 
>>> tried relaxing the base type check in `ActOnOMPArraySectionExpr` but not 
>>> sure it's the way to go. (or should I just extract the DeclReExpr from 
>>> ArrayShapingExpr before calling `ActOnOMPArraySectionExpr`?)
>>>
>>>   #define N 5
>>>   #define M 3
>>>   
>>>   int main(void) {
>>>   int tmp[N][N];
>>>   for(int i=0; i>>   for(int j=0; j>>   tmp[i][j] = N*i + j;
>>>   
>>>   int *foo = &tmp[0][0];
>>>   
>>>   // This compiles just fine
>>>   //#pragma omp target update to( ([N][N])foo )
>>>   
>>>   // This is rejected by the compiler
>>>   #pragma omp target update to( (([N][N])foo)[1:M] )
>>>   }
>>
>> I don't think it is allowed by the standard.
>>
>> According to the standard, The shape-operator can appear only in clauses 
>> where it is explicitly allowed.
>> In this case, array shaping is used as a base expression of array section 
>> (or subscript) expression, which does not meet the standard. Tje array 
>> sjaping operation is not used in clause, instead it is used as a base 
>> subexpression of another expression.
>
> In OpenMP 5.0 [2.12.6, target update construct, Restrictions, C/C++, p.1] The 
> list items that appear in the to or from clauses may use shape-operators.
> Also, in the array shaping section in https://github.com/OpenMP/Examples, the 
> example is also illustrated with the same usage:
>
>   ...
>   S-17 // update boundary points (two columns of 2D array) on the host
>   S-18 // pointer is shaped to 2D array using the shape-operator
>   S-19 #pragma omp target update from( (([nx][ny+2])a)[0:nx][1], 
> (([nx][ny+2])a)[0:nx][ny] )
>   ...

Then just need to fix it, if examples document has this example.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74144

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

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Jason Liu via Phabricator via cfe-commits]

jasonliu added inline comments.



Comment at: clang/include/clang/Basic/CodeGenOptions.def:47
+CODEGENOPT(DataSections  , 1, 0) ///< Set by default, or when 
-f[no-]data-sections.
+CODEGENOPT(HasExplicitDataSections, 1, 0) ///< Set when -f[no-]data-sections 
is set.
 CODEGENOPT(UniqueSectionNames, 1, 1) ///< Set for -funique-section-names.

jasonliu wrote:
> MaskRay wrote:
> > From the current code. I don't see HasExplicitDataSections is necessary. 
> > Please remove the lld changes.
> The reason I need `HasExplicitDataSections` goes back to D88493(which I 
> haven't land yet, because I actually need to land these two patches together 
> to avoid build break). In D88493, I'm trying to get the llc's default for 
> -data-sections to be correct for AIX and introduced 
> `HasExplicitDataSections`. If `HasExplicitDataSections` is not set, then llc 
> would think there is -data-sections set, so it would just take the target 
> triple's default, which makes `DataSections` setting to be useless. 
> It seems there is no good way to set a certain TargetOption's default to be 
> dependant on the current target triple. As I already mentioned in my own 
> comment in this patch, one of the way to achieve that could be make 
> DataSections an enum option in TargetOptions, so that it could have a 
> `Default` enum which could mean true or false depending on the triple 
> setting. But it could mean a bigger refactoring to this option. 
Correction:
If HasExplicitDataSections is not set, then llc would think there is **no** 
-data-sections set, so it would just take the target triple's default...


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

https://reviews.llvm.org/D88737

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

[PATCH] D87972: [OldPM] Pass manager: run SROA after (simple) loop unrolling

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D87972#2294614 , @lebedev.ri wrote:

> In D87972#2294488 , @xbolva00 wrote:
>
 Does that sound reasonable?
>>
>> Yes IMHO.
>>
 What are the next suggested steps?
>>
>> It would be great to isolate and check the cases which regressed a bit.
>
> I've rerun my benchmark, and while the results are still the same (runtime 
> geomean -0.53%/-0.40%,
> but that obviously depends on the benchmarks), there are some obvious 
> outliers:
> F13059172: image.png 
> F13059175: rsbench.txt 
> I'll try to take a look at that, assuming it's not noise.

Hmm. So i did just take a look, manually re-benchmarking each of these, and 
while i still see a few small improvements,
the regressions there are all appear to be basically noise. Not what i was 
hoping for :/

In D87972#2284060 , @MaskRay wrote:

> I have tested this patch internally and seen gains and losses. On one 
> document search related benchmark 3~5% improvement. One zippy (snappy) there 
> is 3~5% regression. Perhaps we do need a conditional extra SROA run.

Does it look like one of the scary "branch predictor got confused"/"code layout 
changed causing different alignment"?

I'm not really sure what are my potential next steps here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87972

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

[PATCH] D87451: add new option ignore-xcoff-visibility

[David Tenty via Phabricator via cfe-commits]

daltenty added inline comments.



Comment at: clang/docs/ClangCommandLineReference.rst:2622
+
+Do not emit any visibility attribute for asm on AIX or give all symbols 
'unspecified' visibility in xcoff object file(XCOFF only)
+

nit: add a space before parens



Comment at: clang/docs/ClangCommandLineReference.rst:2622
+
+Do not emit any visibility attribute for asm on AIX or give all symbols 
'unspecified' visibility in xcoff object file(XCOFF only)
+

daltenty wrote:
> nit: add a space before parens
I don't think the object file writing case was handled yet? This makes it sound 
like it is.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5242
 
+  if (const Arg *A = Args.getLastArg(options::OPT_mignore_xcoff_visibility)) {
+if (Triple.isOSAIX())

Use `Args.hasFlag` instead, since this option doesn't have a value we need to 
check.



Comment at: clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp:72
+
+// ERROR: unsupported option '-mignore-xcoff-visibility' for target 
'powerpc-unknown-linux'
+

This isn't being checked anymore, also probably belongs in the other file



Comment at: clang/test/Driver/ignore-xcoff-visibility.cpp:2
+// RUN: %clang -### -target powerpc-unknown-aix  -mignore-xcoff-visibility -S 
%s 2> %t.log
+// RUN: FileCheck -check-prefix=CHECK %s < %t.log
+// CHECK: "-mignore-xcoff-visibility"

We should check the diagnostic here



Comment at: clang/test/Driver/ignore-xcoff-visibility.cpp:3
+// RUN: FileCheck -check-prefix=CHECK %s < %t.log
+// CHECK: "-mignore-xcoff-visibility"

nit: We should constrain this to be following the cc1 invocation


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87451

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

[PATCH] D88745: [clangd][WIP] Add new code completion signals to improve MRR by 3%.

[Utkarsh Saxena via Phabricator via cfe-commits]

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

Adds two more signals.

- NumNameInContext: Strength of match of name with context.
- SemaPriority: Priority of a sema completion as given by sema.

This will potentially increase the MRR further by 3%.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88745

Files:
  clang-tools-extra/clangd/Quality.cpp
  clang-tools-extra/clangd/Quality.h
  clang-tools-extra/clangd/quality/model/features.json
  clang-tools-extra/clangd/quality/model/forest.json


Index: clang-tools-extra/clangd/quality/model/features.json
===
--- clang-tools-extra/clangd/quality/model/features.json
+++ clang-tools-extra/clangd/quality/model/features.json
@@ -23,6 +23,10 @@
 "name": "IsNameInContext",
 "kind": "NUMBER"
 },
+{
+"name": "NumNameInContext",
+"kind": "NUMBER"
+},
 {
 "name": "IsForbidden",
 "kind": "NUMBER"
@@ -63,6 +67,10 @@
 "name": "TypeMatchesPreferred",
 "kind": "NUMBER"
 },
+{
+"name": "SemaPriority",
+"kind": "NUMBER"
+},
 {
 "name": "SymbolCategory",
 "kind": "ENUM",
Index: clang-tools-extra/clangd/Quality.h
===
--- clang-tools-extra/clangd/Quality.h
+++ clang-tools-extra/clangd/Quality.h
@@ -140,6 +140,9 @@
   /// CompletionPrefix.
   unsigned FilterLength = 0;
 
+  /// Priority of the completion item as computed by Sema.
+  unsigned SemaPriority = 0;
+
   /// Set of derived signals computed by calculateDerivedSignals(). Must not be
   /// set explicitly.
   struct DerivedSignals {
Index: clang-tools-extra/clangd/Quality.cpp
===
--- clang-tools-extra/clangd/Quality.cpp
+++ clang-tools-extra/clangd/Quality.cpp
@@ -300,6 +300,8 @@
   SemaCCResult.Availability == CXAvailability_NotAccessible)
 Forbidden = true;
 
+  SemaPriority = SemaCCResult.Priority;
+
   if (SemaCCResult.Declaration) {
 SemaSaysInScope = true;
 // We boost things that have decls in the main file. We give a fixed score
@@ -499,6 +501,8 @@
   SymbolRelevanceSignals::DerivedSignals Derived =
   Relevance.calculateDerivedSignals();
   E.setIsNameInContext(Derived.NameMatchesContext);
+  // FIXME: Use number of matches of name in context here.
+  E.setNumNameInContext(Derived.NameMatchesContext);
   E.setIsForbidden(Relevance.Forbidden);
   E.setIsInBaseClass(Relevance.InBaseClass);
   E.setFileProximityDistance(Derived.FileProximityDistance);
@@ -512,6 +516,7 @@
   E.setHadSymbolType(Relevance.HadSymbolType);
   E.setTypeMatchesPreferred(Relevance.TypeMatchesPreferred);
   E.setFilterLength(Relevance.FilterLength);
+  E.setSemaPriority(Relevance.SemaPriority);
   return Evaluate(E);
 }
 


Index: clang-tools-extra/clangd/quality/model/features.json
===
--- clang-tools-extra/clangd/quality/model/features.json
+++ clang-tools-extra/clangd/quality/model/features.json
@@ -23,6 +23,10 @@
 "name": "IsNameInContext",
 "kind": "NUMBER"
 },
+{
+"name": "NumNameInContext",
+"kind": "NUMBER"
+},
 {
 "name": "IsForbidden",
 "kind": "NUMBER"
@@ -63,6 +67,10 @@
 "name": "TypeMatchesPreferred",
 "kind": "NUMBER"
 },
+{
+"name": "SemaPriority",
+"kind": "NUMBER"
+},
 {
 "name": "SymbolCategory",
 "kind": "ENUM",
Index: clang-tools-extra/clangd/Quality.h
===
--- clang-tools-extra/clangd/Quality.h
+++ clang-tools-extra/clangd/Quality.h
@@ -140,6 +140,9 @@
   /// CompletionPrefix.
   unsigned FilterLength = 0;
 
+  /// Priority of the completion item as computed by Sema.
+  unsigned SemaPriority = 0;
+
   /// Set of derived signals computed by calculateDerivedSignals(). Must not be
   /// set explicitly.
   struct DerivedSignals {
Index: clang-tools-extra/clangd/Quality.cpp
===
--- clang-tools-extra/clangd/Quality.cpp
+++ clang-tools-extra/clangd/Quality.cpp
@@ -300,6 +300,8 @@
   SemaCCResult.Availability == CXAvailability_NotAccessible)
 Forbidden = true;
 
+  SemaPriority = SemaCCResult.Priority;
+
   if (SemaCCResult.Declaration) {
 SemaSaysInScope = true;
 // We boost things that have decls in the main file. We give a fixed score
@@ -499,6 +501,8 @@
   SymbolRelevanceSignals::DerivedSignals Derived =
   Relevance.calculateDerivedSignals();
   E.setIsNameInContext(Derived.NameMatchesContext);
+  // FIXME: Use number of matches of name in context here.
+  E.setNumNameInC

[PATCH] D87972: [OldPM] Pass manager: run SROA after (simple) loop unrolling

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

xbolva00 added a comment.

>> I'm not really sure what are my potential next steps here.

Maybe just add option to disable late SROA?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87972

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

[PATCH] D36836: [clang-tidy] Implement sonarsource-function-cognitive-complexity check

[Chris Lattner via Phabricator via cfe-commits]

lattner added a comment.

Hi all,

The LLVM foundation board discussed this offline -- it looks like the 
contributor is a bit confused about the LLVM project policies towards 
copyright, license, patent stuff etc.  I really appreciate the dilligence here 
to capture the ideas that went into this code.

My understanding is that the code and documentation are not derived from anyone 
else's code or documentation -- they are fresh implementations based on a paper 
written in english prose.  If that is the case, please remove the LICENSE.TXT 
file -- it isn't necessary and it is confusing for people.I would also 
recommend replacing all the references to sonar source with a functional 
description of what this patch is doing - we aren't talking about adding a 
feature because of sonar source, my understanding is that this is adding a 
cyclomatic complexity checker.  If and when the feature evolves over time, it 
would be misleading for it to be called sonar source.

Please note that I didn't do a full code review here, others should do that.

-Chris


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D36836

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

[PATCH] D88737: [AIX] Turn -fdata-sections on by default in Clang

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/include/clang/Basic/CodeGenOptions.def:47
+CODEGENOPT(DataSections  , 1, 0) ///< Set by default, or when 
-f[no-]data-sections.
+CODEGENOPT(HasExplicitDataSections, 1, 0) ///< Set when -f[no-]data-sections 
is set.
 CODEGENOPT(UniqueSectionNames, 1, 1) ///< Set for -funique-section-names.

jasonliu wrote:
> jasonliu wrote:
> > MaskRay wrote:
> > > From the current code. I don't see HasExplicitDataSections is necessary. 
> > > Please remove the lld changes.
> > The reason I need `HasExplicitDataSections` goes back to D88493(which I 
> > haven't land yet, because I actually need to land these two patches 
> > together to avoid build break). In D88493, I'm trying to get the llc's 
> > default for -data-sections to be correct for AIX and introduced 
> > `HasExplicitDataSections`. If `HasExplicitDataSections` is not set, then 
> > llc would think there is -data-sections set, so it would just take the 
> > target triple's default, which makes `DataSections` setting to be useless. 
> > It seems there is no good way to set a certain TargetOption's default to be 
> > dependant on the current target triple. As I already mentioned in my own 
> > comment in this patch, one of the way to achieve that could be make 
> > DataSections an enum option in TargetOptions, so that it could have a 
> > `Default` enum which could mean true or false depending on the triple 
> > setting. But it could mean a bigger refactoring to this option. 
> Correction:
> If HasExplicitDataSections is not set, then llc would think there is **no** 
> -data-sections set, so it would just take the target triple's default...
D88748


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

https://reviews.llvm.org/D88737

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

[clang] eb55735 - Reland [AlwaysInliner] Update BFI when inlining

[Arthur Eubanks via cfe-commits]

Author: Arthur Eubanks
Date: 2020-10-02T10:46:57-07:00
New Revision: eb55735073d53f7816b9a4080e6f54dfeda5ae50

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

LOG: Reland [AlwaysInliner] Update BFI when inlining

Reviewed By: davidxl

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

Added: 
llvm/test/Transforms/Inline/prof-update-sample-alwaysinline.ll

Modified: 
clang/test/CodeGen/lto-newpm-pipeline.c
llvm/lib/Transforms/IPO/AlwaysInliner.cpp
llvm/test/Transforms/Inline/prof-update-sample.ll

Removed: 




diff  --git a/clang/test/CodeGen/lto-newpm-pipeline.c 
b/clang/test/CodeGen/lto-newpm-pipeline.c
index 9694cef326d5..ad3f076e5d8b 100644
--- a/clang/test/CodeGen/lto-newpm-pipeline.c
+++ b/clang/test/CodeGen/lto-newpm-pipeline.c
@@ -28,6 +28,7 @@
 // CHECK-FULL-O0: Starting llvm::Module pass manager run.
 // CHECK-FULL-O0: Running pass: AlwaysInlinerPass
 // CHECK-FULL-O0-NEXT: Running analysis: InnerAnalysisManagerProxy
+// CHECK-FULL-O0-NEXT: Running analysis: ProfileSummaryAnalysis
 // CHECK-FULL-O0-NEXT: Running pass: CanonicalizeAliasesPass
 // CHECK-FULL-O0-NEXT: Running pass: NameAnonGlobalPass
 // CHECK-FULL-O0-NEXT: Running pass: BitcodeWriterPass
@@ -36,6 +37,7 @@
 // CHECK-THIN-O0: Starting llvm::Module pass manager run.
 // CHECK-THIN-O0: Running pass: AlwaysInlinerPass
 // CHECK-THIN-O0-NEXT: Running analysis: InnerAnalysisManagerProxy
+// CHECK-THIN-O0-NEXT: Running analysis: ProfileSummaryAnalysis
 // CHECK-THIN-O0-NEXT: Running pass: CanonicalizeAliasesPass
 // CHECK-THIN-O0-NEXT: Running pass: NameAnonGlobalPass
 // CHECK-THIN-O0-NEXT: Running pass: ThinLTOBitcodeWriterPass

diff  --git a/llvm/lib/Transforms/IPO/AlwaysInliner.cpp 
b/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
index a9cf363ec98f..f3b23ea77bcd 100644
--- a/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
+++ b/llvm/lib/Transforms/IPO/AlwaysInliner.cpp
@@ -15,6 +15,7 @@
 #include "llvm/ADT/SetVector.h"
 #include "llvm/Analysis/AssumptionCache.h"
 #include "llvm/Analysis/InlineCost.h"
+#include "llvm/Analysis/ProfileSummaryInfo.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/IR/CallingConv.h"
 #include "llvm/IR/DataLayout.h"
@@ -39,7 +40,7 @@ PreservedAnalyses AlwaysInlinerPass::run(Module &M,
   auto GetAssumptionCache = [&](Function &F) -> AssumptionCache & {
 return FAM.getResult(F);
   };
-  InlineFunctionInfo IFI(/*cg=*/nullptr, GetAssumptionCache);
+  auto &PSI = MAM.getResult(M);
 
   SmallSetVector Calls;
   bool Changed = false;
@@ -67,6 +68,11 @@ PreservedAnalyses AlwaysInlinerPass::run(Module &M,
 emitInlinedInto(ORE, CB->getDebugLoc(), CB->getParent(), F, *Caller,
 *OIC, false, DEBUG_TYPE);
 
+InlineFunctionInfo IFI(
+/*cg=*/nullptr, GetAssumptionCache, &PSI,
+&FAM.getResult(*(CB->getCaller())),
+&FAM.getResult(F));
+
 InlineResult Res =
 InlineFunction(*CB, IFI, /*CalleeAAR=*/nullptr, InsertLifetime);
 assert(Res.isSuccess() && "unexpected failure to inline");

diff  --git a/llvm/test/Transforms/Inline/prof-update-sample-alwaysinline.ll 
b/llvm/test/Transforms/Inline/prof-update-sample-alwaysinline.ll
new file mode 100644
index ..5bb5834faefd
--- /dev/null
+++ b/llvm/test/Transforms/Inline/prof-update-sample-alwaysinline.ll
@@ -0,0 +1,60 @@
+; RUN: opt < %s -passes=always-inline -S | FileCheck %s
+; Checks if always-inline updates branch_weights annotation for call 
instructions.
+
+declare void @ext();
+declare void @ext1();
+@func = global void ()* null
+
+; CHECK: define void @callee(i32 %n) #0 !prof ![[ENTRY_COUNT:[0-9]*]]
+define void  @callee(i32 %n) #0 !prof !15 {
+  %cond = icmp sle i32 %n, 10
+  br i1 %cond, label %cond_true, label %cond_false
+cond_true:
+; ext1 is optimized away, thus not updated.
+; CHECK: call void @ext1(), !prof ![[COUNT_CALLEE1:[0-9]*]]
+  call void @ext1(), !prof !16
+  ret void
+cond_false:
+; ext is cloned and updated.
+; CHECK: call void @ext(), !prof ![[COUNT_CALLEE:[0-9]*]]
+  call void @ext(), !prof !16
+  %f = load void ()*, void ()** @func
+; CHECK: call void %f(), !prof ![[COUNT_IND_CALLEE:[0-9]*]] 
+  call void %f(), !prof !18
+  ret void
+}
+
+; CHECK: define void @caller()
+define void @caller() {
+; CHECK: call void @ext(), !prof ![[COUNT_CALLER:[0-9]*]]
+; CHECK: call void %f.i(), !prof ![[COUNT_IND_CALLER:[0-9]*]]
+  call void @callee(i32 15), !prof !17
+  ret void
+}
+
+!llvm.module.flags = !{!1}
+!1 = !{i32 1, !"ProfileSummary", !2}
+!2 = !{!3, !4, !5, !6, !7, !8, !9, !10}
+!3 = !{!"ProfileFormat", !"SampleProfile"}
+!4 = !{!"TotalCount", i64 1}
+!5 = !{!"MaxCount", i64 10}
+!6 = !{!"MaxInternalCount", i64 1}
+!7 = !{!"MaxFunctionCount", i64 2000}
+!8 = !{!"NumCounts", i64 2}
+!9 = !{!"N

[PATCH] D75574: RFC: Implement objc_direct_protocol attribute to remove protocol metadata

[Nathan Lanza via Phabricator via cfe-commits]

lanza added inline comments.



Comment at: clang/lib/CodeGen/CGObjC.cpp:487
+
+  // Walk both lists to get the full set of implied protocols
+  llvm::DenseSet AllImpliedProtocols;

rjmccall wrote:
> You should add something like ", including all the runtime protocols but not 
> the non-runtime protocols".
Do you anticipate a usage of `getImpliedProtocols` other than this algorithm? I 
include the non-runtime protos in the all implied list simply because it 
simplifies the collection. e.g. you insert iff it's a runtime protocol and if 
not you have to check `contains` and then potentially add a non-runtime to the 
work queue as many times as it's seen. 

Ultimately their inclusion in the all-implied list is meaningless because we 
never attempt to insert a non-runtime protocol into the `RuntimePDs` list 
anyways. So it's either extra elements in the `AllImplied` list or extra work 
in the `getImpliedProtocols` method without any behavioral differences.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75574

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