[clang] f65f06d - [NFC] [Coroutines] Add tests for looking up deallocation

[Chuanqi Xu via cfe-commits]

Author: Chuanqi Xu
Date: 2022-09-06T14:57:01+08:00
New Revision: f65f06d63f6a0e40c33a9d77eeb381f1b2a8a524

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

LOG: [NFC] [Coroutines] Add tests for looking up deallocation

According to [dcl.fct.def.coroutine]p12, the program should be
ill-formed if the promise_type contains operator delete but none of them
are available. But this behavior was not tested before. This commit adds
the tests for it.

Added: 
clang/test/SemaCXX/coroutine-dealloc.cpp
clang/test/SemaCXX/coroutine-no-valid-dealloc.cpp

Modified: 


Removed: 




diff  --git a/clang/test/SemaCXX/coroutine-dealloc.cpp 
b/clang/test/SemaCXX/coroutine-dealloc.cpp
new file mode 100644
index ..6eca1e6f42f8
--- /dev/null
+++ b/clang/test/SemaCXX/coroutine-dealloc.cpp
@@ -0,0 +1,27 @@
+// Tests that the behavior will be good if there are multiple operator delete 
in the promise_type.
+// RUN: %clang_cc1 %s -std=c++20 %s -fsyntax-only -verify
+// expected-no-diagnostics
+
+#include "Inputs/std-coroutine.h"
+
+namespace std {
+typedef __SIZE_TYPE__ size_t;
+enum class align_val_t : size_t {};
+}
+
+struct task {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+
+void operator delete(void *ptr, void *meaningless_placeholder);
+void operator delete(void *ptr);
+  };
+};
+
+task f() {
+  co_return 43;
+}

diff  --git a/clang/test/SemaCXX/coroutine-no-valid-dealloc.cpp 
b/clang/test/SemaCXX/coroutine-no-valid-dealloc.cpp
new file mode 100644
index ..a5727d6f003b
--- /dev/null
+++ b/clang/test/SemaCXX/coroutine-no-valid-dealloc.cpp
@@ -0,0 +1,26 @@
+// Test that if the compiler will emit error message if the promise_type 
contain
+// operator delete but none of them are available. This is required by the 
standard.
+// RUN: %clang_cc1 %s -std=c++20 %s -fsyntax-only -verify
+
+#include "Inputs/std-coroutine.h"
+
+namespace std {
+typedef __SIZE_TYPE__ size_t;
+enum class align_val_t : size_t {};
+}
+
+struct task {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+
+void operator delete(void *ptr, void *meaningless_placeholder); // 
expected-note {{member 'operator delete' declared here}}
+  };
+};
+
+task f() { // expected-error 1+{{no suitable member 'operator delete' in 
'promise_type'}}
+  co_return 43;
+}



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

[PATCH] D130863: [clangd] Make git ignore index directories

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

In D130863#3696419 , @sums wrote:

> Thank you for the reviews and discussion, everyone!
>
> TIL about `.git/info/exclude`. It'll let me exclude stuff without updating 
> the checked in `.gitignore`. I was achieving the same effect for clangd by 
> manually creating a `.gitignore` similar to this change.
>
> The ideal scenario would be one where all tools ignore their temporary 
> directories automatically. Will send patches whenever I encounter a case like 
> this :)
>
> @kadircet kindly take another look.

thanks! sorry for forgetting about this one. so in the end it looks like there 
are two cases:

- clangd is being used on a git-based project, and this is going to be 
"invisible" to the user
- clangd is being used on a non-git project, then the user already needs to 
ignore this directory somehow and the extra `.gitignore` we generate there will 
be ignored by that rule.

So I guess this is a win overall.

Let me know if I should land this for you (and an email address for attribution 
of the commit).




Comment at: clang-tools-extra/clangd/index/BackgroundIndexStorage.cpp:38
+  llvm::SmallString<128> ShardRootSS(ShardRoot);
+  llvm::sys::path::append(ShardRootSS, 
llvm::sys::path::filename(".gitignore"));
+  return std::string(ShardRootSS.str());

no need for `llvm::sys::path::filename`, as `.gitignore` is already a file name.



Comment at: clang-tools-extra/clangd/index/BackgroundIndexStorage.cpp:39
+  llvm::sys::path::append(ShardRootSS, 
llvm::sys::path::filename(".gitignore"));
+  return std::string(ShardRootSS.str());
+}

rather than calling out `std::string` you can do `return 
ShardRootSS.str().str();`



Comment at: clang-tools-extra/clangd/index/BackgroundIndexStorage.cpp:49
   DiskBackedIndexStorage(llvm::StringRef Directory) : DiskShardRoot(Directory) 
{
+bool CreatingNewDirectory = !llvm::sys::fs::is_directory(DiskShardRoot);
 std::error_code OK;

i don't think this check is really needed, we won't really lose much by 
overwriting it even if the directory already exists (and this is done once per 
compilation database we discover, so it isn't saving much IO).



Comment at: clang-tools-extra/clangd/index/BackgroundIndexStorage.cpp:95
+auto FilePath = getGitignorePathForShardRoot(DiskShardRoot);
+return llvm::writeFileAtomically(
+FilePath + ".tmp", FilePath,

this atomic write has the same chance of colliding with a direct write to 
`.gitignore` file by another clangd process.

can you change `.tmp` to `.tmp.` to make the collision less likely? 
(each `%` is replaced by a random hex digit).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130863

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

[PATCH] D133339: [clangd] Isolate logic for setting LSPServer options

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

Moves clangdserveropt gathering into a separate function to make sure
it's done before we take any actions based on options.

This also moves some state that controls how we handle certain requests from
LSPServer to options.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D19

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

Index: clang-tools-extra/clangd/ClangdLSPServer.h
===
--- clang-tools-extra/clangd/ClangdLSPServer.h
+++ clang-tools-extra/clangd/ClangdLSPServer.h
@@ -60,6 +60,25 @@
 
 /// Limit the number of references returned (0 means no limit).
 size_t ReferencesLimit = 0;
+
+/// Options used for diagnostics.
+ClangdDiagnosticOptions DiagOpts;
+/// Set of symbol kinds to use.
+SymbolKindBitset SymbolKinds;
+/// Set of completion item kinds to use.
+CompletionItemKindBitset CompletionItemKinds;
+/// Whether to emit code actions or commands as code action responses.
+bool EmitCodeAction = false;
+/// Whether to emit hierarchical or flat document symbol responses.
+bool HierarchicalDocumentSymbol = false;
+/// Whether to send file status updates.
+bool EmitFileStatus = false;
+/// Which kind of markup should we use in textDocument/hover responses.
+MarkupKind HoverContentFormat = MarkupKind::PlainText;
+/// Whether to have offsets for parameter info labels.
+bool OffsetsInSignatureHelp = false;
+/// LSP extension: skip WorkDoneProgressCreate, just send progress streams.
+bool BackgroundIndexSkipCreate = false;
   };
 
   ClangdLSPServer(Transport &Transp, const ThreadsafeFS &TFS,
@@ -250,22 +269,6 @@
   LSPBinder::RawHandlers Handlers;
 
   const ThreadsafeFS &TFS;
-  /// Options used for diagnostics.
-  ClangdDiagnosticOptions DiagOpts;
-  /// The supported kinds of the client.
-  SymbolKindBitset SupportedSymbolKinds;
-  /// The supported completion item kinds of the client.
-  CompletionItemKindBitset SupportedCompletionItemKinds;
-  /// Whether the client supports CodeAction response objects.
-  bool SupportsCodeAction = false;
-  /// From capabilities of textDocument/documentSymbol.
-  bool SupportsHierarchicalDocumentSymbol = false;
-  /// Whether the client supports showing file status.
-  bool SupportFileStatus = false;
-  /// Which kind of markup should we use in textDocument/hover responses.
-  MarkupKind HoverContentFormat = MarkupKind::PlainText;
-  /// Whether the client supports offsets for parameter info labels.
-  bool SupportsOffsetsInSignatureHelp = false;
   std::mutex BackgroundIndexProgressMutex;
   enum class BackgroundIndexProgress {
 // Client doesn't support reporting progress. No transitions possible.
@@ -282,8 +285,6 @@
   // The progress to send when the progress bar is created.
   // Only valid in state Creating.
   BackgroundQueue::Stats PendingBackgroundIndexProgress;
-  /// LSP extension: skip WorkDoneProgressCreate, just send progress streams.
-  bool BackgroundIndexSkipCreate = false;
 
   Options Opts;
   // The CDB is created by the "initialize" LSP method.
Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -441,8 +441,8 @@
   return Modifiers;
 }
 
-void ClangdLSPServer::onInitialize(const InitializeParams &Params,
-   Callback Reply) {
+static void setServerOptions(ClangdLSPServer::Options &Opts,
+ const InitializeParams &Params) {
   // Determine character encoding first as it affects constructed ClangdServer.
   if (Params.capabilities.offsetEncoding && !Opts.Encoding) {
 Opts.Encoding = OffsetEncoding::UTF16; // fallback
@@ -463,9 +463,6 @@
 Opts.WorkspaceRoot = std::string(Params.rootUri->file());
   else if (Params.rootPath && !Params.rootPath->empty())
 Opts.WorkspaceRoot = *Params.rootPath;
-  if (Server)
-return Reply(llvm::make_error("server already initialized",
-ErrorCode::InvalidRequest));
 
   Opts.CodeComplete.EnableSnippets = Params.capabilities.CompletionSnippets;
   Opts.CodeComplete.IncludeFixIts = Params.capabilities.CompletionFixes;
@@ -475,25 +472,34 @@
   Params.capabilities.CompletionDocumentationFormat;
   Opts.SignatureHelpDocumentationFormat =
   Params.capabilities.SignatureHelpDocumentationFormat;
-  DiagOpts.EmbedFixesInDiagnostics = Params.capabilities.DiagnosticFixes;
-  DiagOpts.SendDiagnosticCategory = Params.capabilities.DiagnosticCategor

[clang] 7179779 - [OpenMP] Mark -fopenmp-implicit-rpath as NoArgumentUnused

[Nikita Popov via cfe-commits]

Author: Nikita Popov
Date: 2022-09-06T09:44:45+02:00
New Revision: 71797797f7a759245cb39b93307e0641c511170c

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

LOG: [OpenMP] Mark -fopenmp-implicit-rpath as NoArgumentUnused

This matches the behavior for all the other -fopenmp options,
as well as -frtlib-add-rpath.

For context, Fedora passes this flag by default in case OpenMP is
used, and this results in a warning if it (usually) isn't, which
causes build failures for some programs with unnecessarily strict
build systems (like Ruby).

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index c7c34f072ba23..58a316b0180e6 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4114,7 +4114,8 @@ defm openmp_implicit_rpath: 
BoolFOption<"openmp-implicit-rpath",
   LangOpts<"OpenMP">,
   DefaultTrue,
   PosFlag,
-  NegFlag>;
+  NegFlag,
+  BothFlags<[NoArgumentUnused]>>;
 def r : Flag<["-"], "r">, Flags<[LinkerInput,NoArgumentUnused]>,
 Group;
 def save_temps_EQ : Joined<["-", "--"], "save-temps=">, Flags<[CC1Option, 
FlangOption, NoXarchOption]>,



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

[PATCH] D133316: [OpenMP] Mark -fopenmp-implicit-rpath as NoArgumentUnused

[Nikita Popov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG71797797f7a7: [OpenMP] Mark -fopenmp-implicit-rpath as 
NoArgumentUnused (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133316

Files:
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4114,7 +4114,8 @@
   LangOpts<"OpenMP">,
   DefaultTrue,
   PosFlag,
-  NegFlag>;
+  NegFlag,
+  BothFlags<[NoArgumentUnused]>>;
 def r : Flag<["-"], "r">, Flags<[LinkerInput,NoArgumentUnused]>,
 Group;
 def save_temps_EQ : Joined<["-", "--"], "save-temps=">, Flags<[CC1Option, 
FlangOption, NoXarchOption]>,


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4114,7 +4114,8 @@
   LangOpts<"OpenMP">,
   DefaultTrue,
   PosFlag,
-  NegFlag>;
+  NegFlag,
+  BothFlags<[NoArgumentUnused]>>;
 def r : Flag<["-"], "r">, Flags<[LinkerInput,NoArgumentUnused]>,
 Group;
 def save_temps_EQ : Joined<["-", "--"], "save-temps=">, Flags<[CC1Option, FlangOption, NoXarchOption]>,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D131763: [OpenMP] Add lit test for metadirective device arch inspired from sollve

[Animesh Kumar via Phabricator via cfe-commits]

animeshk-amd added a comment.

Thanks @saiislam. Since I don't have the commit access yet, I request you to 
kindly commit this on my behalf.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131763

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

[PATCH] D133341: [C++] [Coroutines] Prefer aligned (de)allocation for coroutines - implement the option2 of P2014R0

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu created this revision.
ChuanqiXu added reviewers: erichkeane, ychen, rjmccall.
ChuanqiXu added projects: clang, clang-language-wg.
Herald added a project: All.
ChuanqiXu requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.

This implements the option2 of 
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2014r0.pdf.

This also fixes https://github.com/llvm/llvm-project/issues/56671.

Although wg21 didn't get consensus for the direction of the problem, we're 
happy to have some implementation and user experience first. And from 
issue56671, the option2 should be the pursued one.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133341

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGCoroutine.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CodeGenCoroutines/coro-aligned-alloc-2.cpp
  clang/test/CodeGenCoroutines/coro-aligned-alloc.cpp
  clang/test/SemaCXX/coroutine-alloc-4.cpp

Index: clang/test/SemaCXX/coroutine-alloc-4.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/coroutine-alloc-4.cpp
@@ -0,0 +1,116 @@
+// Tests that we'll find aligned allocation funciton properly.
+// RUN: %clang_cc1 %s -std=c++20 %s -fsyntax-only -verify -fcoro-aligned-allocation
+
+#include "Inputs/std-coroutine.h"
+
+namespace std {
+typedef __SIZE_TYPE__ size_t;
+enum class align_val_t : size_t {};
+}
+
+struct task {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+void *operator new(std::size_t); // expected-warning 1+{{found non aligned allocation function for coroutine}}
+  };
+};
+
+task f() {   // expected-error {{'operator new' provided by 'std::coroutine_traits::promise_type' (aka 'task::promise_type') is not usable}}
+co_return 43;
+}
+
+struct task2 {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task2{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+void *operator new(std::size_t, std::align_val_t);
+  };
+};
+
+// no diagnostic expected
+task2 f1() {
+co_return 43;
+}
+
+struct task3 {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task3{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+void *operator new(std::size_t, std::align_val_t) noexcept;
+void *operator new(std::size_t) noexcept;
+static auto get_return_object_on_allocation_failure() { return task3{}; }
+  };
+};
+
+// no diagnostic expected
+task3 f2() {
+co_return 43;
+}
+
+struct task4 {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task4{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+void *operator new(std::size_t, std::align_val_t, int, double, int) noexcept;
+  };
+};
+
+// no diagnostic expected
+task4 f3(int, double, int) {
+co_return 43;
+}
+
+struct task5 {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task5{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+  };
+};
+
+// no diagnostic expected.
+// The aligned allocation will be declared by the compiler.
+task5 f4() {
+co_return 43;
+}
+
+namespace std {
+  struct nothrow_t {};
+  constexpr nothrow_t nothrow = {};
+}
+
+struct task6 {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task6{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+static task6 get_return_object_on_allocation_failure() { return task6{}; }
+  };
+};
+
+task6 f5() { // expected-error 1+{{unable to find '::operator new(size_t, align_val_t, nothrow_t)' for 'f5'}}
+co_return 43;
+}
+
+void *operator new(std::size_t, std::align_val_t, std::nothrow_t) noexcept; 
+
+task6 f6() {
+ 

[PATCH] D130863: [clangd] Make git ignore index directories

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/index/BackgroundIndexStorage.cpp:58
+if (CreatingNewDirectory) {
+  llvm::Error error = addGitignore(DiskShardRoot);
+  if (error) {

nit:
```
if(llvm::Error E = addGitignore(..)) {
 elog(".."), std::move(E));
}
```

`std::move` is actually important, otherwise destruction of Error on failure 
state will trigger a crash.



Comment at: clang-tools-extra/clangd/index/BackgroundIndexStorage.cpp:94
+  llvm::Error addGitignore(llvm::StringRef Directory) {
+auto FilePath = getGitignorePathForShardRoot(DiskShardRoot);
+return llvm::writeFileAtomically(

we're passing in `Directory` but using `DiskShardRoot` here. can you actually 
make `addGitignore` a free-function (same as `getGitignorePathForShardRoot`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130863

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

[PATCH] D133341: [C++] [Coroutines] Prefer aligned (de)allocation for coroutines - implement the option2 of P2014R0

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu updated this revision to Diff 458116.
ChuanqiXu added a comment.

Remove invisible character... there are always invisible characters in the 
paper..


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

https://reviews.llvm.org/D133341

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGCoroutine.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CodeGenCoroutines/coro-aligned-alloc-2.cpp
  clang/test/CodeGenCoroutines/coro-aligned-alloc.cpp
  clang/test/SemaCXX/coroutine-alloc-4.cpp

Index: clang/test/SemaCXX/coroutine-alloc-4.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/coroutine-alloc-4.cpp
@@ -0,0 +1,116 @@
+// Tests that we'll find aligned allocation funciton properly.
+// RUN: %clang_cc1 %s -std=c++20 %s -fsyntax-only -verify -fcoro-aligned-allocation
+
+#include "Inputs/std-coroutine.h"
+
+namespace std {
+typedef __SIZE_TYPE__ size_t;
+enum class align_val_t : size_t {};
+}
+
+struct task {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+void *operator new(std::size_t); // expected-warning 1+{{found non aligned allocation function for coroutine}}
+  };
+};
+
+task f() {   // expected-error {{'operator new' provided by 'std::coroutine_traits::promise_type' (aka 'task::promise_type') is not usable}}
+co_return 43;
+}
+
+struct task2 {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task2{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+void *operator new(std::size_t, std::align_val_t);
+  };
+};
+
+// no diagnostic expected
+task2 f1() {
+co_return 43;
+}
+
+struct task3 {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task3{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+void *operator new(std::size_t, std::align_val_t) noexcept;
+void *operator new(std::size_t) noexcept;
+static auto get_return_object_on_allocation_failure() { return task3{}; }
+  };
+};
+
+// no diagnostic expected
+task3 f2() {
+co_return 43;
+}
+
+struct task4 {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task4{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+void *operator new(std::size_t, std::align_val_t, int, double, int) noexcept;
+  };
+};
+
+// no diagnostic expected
+task4 f3(int, double, int) {
+co_return 43;
+}
+
+struct task5 {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task5{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+  };
+};
+
+// no diagnostic expected.
+// The aligned allocation will be declared by the compiler.
+task5 f4() {
+co_return 43;
+}
+
+namespace std {
+  struct nothrow_t {};
+  constexpr nothrow_t nothrow = {};
+}
+
+struct task6 {
+  struct promise_type {
+auto initial_suspend() { return std::suspend_always{}; }
+auto final_suspend() noexcept { return std::suspend_always{}; }
+auto get_return_object() { return task6{}; }
+void unhandled_exception() {}
+void return_value(int) {}
+static task6 get_return_object_on_allocation_failure() { return task6{}; }
+  };
+};
+
+task6 f5() { // expected-error 1+{{unable to find '::operator new(size_t, align_val_t, nothrow_t)' for 'f5'}}
+co_return 43;
+}
+
+void *operator new(std::size_t, std::align_val_t, std::nothrow_t) noexcept; 
+
+task6 f6() {
+co_return 43;
+}
Index: clang/test/CodeGenCoroutines/coro-aligned-alloc.cpp
===
--- /dev/null
+++ clang/test/CodeGenCoroutines/coro-aligned-alloc.cpp
@@ -0,0 +1,105 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -std=c++20 \
+// RUN:   -fcoro-aligned-allocation -S -emit-llvm %s -o - -disable-llvm-passes \
+// RUN:   | FileCheck %s
+
+#include "Inputs/coroutine.h"
+
+

[clang] f2c17a1 - [OpenCL] Remove argument names from atomic/fence builtins

[Sven van Haastregt via cfe-commits]

Author: Sven van Haastregt
Date: 2022-09-06T10:50:57+01:00
New Revision: f2c17a130a27cadd9d204bef09fd4ad64518c9da

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

LOG: [OpenCL] Remove argument names from atomic/fence builtins

This simplifies completeness comparisons against OpenCLBuiltins.td and
also makes the header no longer "claim" the argument name identifiers.

Continues the direction set out in D119560.

Added: 


Modified: 
clang/lib/Headers/opencl-c.h

Removed: 




diff  --git a/clang/lib/Headers/opencl-c.h b/clang/lib/Headers/opencl-c.h
index 5cadb488b06cd..8499ee0120da0 100644
--- a/clang/lib/Headers/opencl-c.h
+++ b/clang/lib/Headers/opencl-c.h
@@ -12396,11 +12396,11 @@ void __ovld vstorea_half16_rtn(double16, size_t, 
__private half *);
  * image objects and then want to read the updated data.
  */
 
-void __ovld __conv barrier(cl_mem_fence_flags flags);
+void __ovld __conv barrier(cl_mem_fence_flags);
 
 #if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_2_0)
-void __ovld __conv work_group_barrier(cl_mem_fence_flags flags, memory_scope);
-void __ovld __conv work_group_barrier(cl_mem_fence_flags flags);
+void __ovld __conv work_group_barrier(cl_mem_fence_flags, memory_scope);
+void __ovld __conv work_group_barrier(cl_mem_fence_flags);
 #endif //defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= 
CL_VERSION_2_0)
 
 // OpenCL v1.1 s6.11.9, v1.2 s6.12.9 - Explicit Memory Fence Functions
@@ -12418,7 +12418,7 @@ void __ovld __conv 
work_group_barrier(cl_mem_fence_flags flags);
  * CLK_LOCAL_MEM_FENCE
  * CLK_GLOBAL_MEM_FENCE.
  */
-void __ovld mem_fence(cl_mem_fence_flags flags);
+void __ovld mem_fence(cl_mem_fence_flags);
 
 /**
  * Read memory barrier that orders only
@@ -12430,7 +12430,7 @@ void __ovld mem_fence(cl_mem_fence_flags flags);
  * CLK_LOCAL_MEM_FENCE
  * CLK_GLOBAL_MEM_FENCE.
  */
-void __ovld read_mem_fence(cl_mem_fence_flags flags);
+void __ovld read_mem_fence(cl_mem_fence_flags);
 
 /**
  * Write memory barrier that orders only
@@ -12442,7 +12442,7 @@ void __ovld read_mem_fence(cl_mem_fence_flags flags);
  * CLK_LOCAL_MEM_FENCE
  * CLK_GLOBAL_MEM_FENCE.
  */
-void __ovld write_mem_fence(cl_mem_fence_flags flags);
+void __ovld write_mem_fence(cl_mem_fence_flags);
 
 // OpenCL v2.0 s6.13.9 - Address Space Qualifier Functions
 
@@ -12891,29 +12891,29 @@ void __ovld prefetch(const __global half16 *, size_t);
  * (old + val) and store result at location
  * pointed by p. The function returns old.
  */
-int __ovld atomic_add(volatile __global int *p, int val);
-uint __ovld atomic_add(volatile __global uint *p, uint val);
-int __ovld atomic_add(volatile __local int *p, int val);
-uint __ovld atomic_add(volatile __local uint *p, uint val);
+int __ovld atomic_add(volatile __global int *, int);
+uint __ovld atomic_add(volatile __global uint *, uint);
+int __ovld atomic_add(volatile __local int *, int);
+uint __ovld atomic_add(volatile __local uint *, uint);
 #ifdef __OPENCL_CPP_VERSION__
-int __ovld atomic_add(volatile int *p, int val);
-uint __ovld atomic_add(volatile uint *p, uint val);
+int __ovld atomic_add(volatile int *, int);
+uint __ovld atomic_add(volatile uint *, uint);
 #endif
 
 #if defined(cl_khr_global_int32_base_atomics)
-int __ovld atom_add(volatile __global int *p, int val);
-uint __ovld atom_add(volatile __global uint *p, uint val);
+int __ovld atom_add(volatile __global int *, int);
+uint __ovld atom_add(volatile __global uint *, uint);
 #endif
 #if defined(cl_khr_local_int32_base_atomics)
-int __ovld atom_add(volatile __local int *p, int val);
-uint __ovld atom_add(volatile __local uint *p, uint val);
+int __ovld atom_add(volatile __local int *, int);
+uint __ovld atom_add(volatile __local uint *, uint);
 #endif
 
 #if defined(cl_khr_int64_base_atomics)
-long __ovld atom_add(volatile __global long *p, long val);
-ulong __ovld atom_add(volatile __global ulong *p, ulong val);
-long __ovld atom_add(volatile __local long *p, long val);
-ulong __ovld atom_add(volatile __local ulong *p, ulong val);
+long __ovld atom_add(volatile __global long *, long);
+ulong __ovld atom_add(volatile __global ulong *, ulong);
+long __ovld atom_add(volatile __local long *, long);
+ulong __ovld atom_add(volatile __local ulong *, ulong);
 #endif
 
 /**
@@ -12921,29 +12921,29 @@ ulong __ovld atom_add(volatile __local ulong *p, 
ulong val);
  * Compute (old - val) and store result at location pointed by p. The function
  * returns old.
  */
-int __ovld atomic_sub(volatile __global int *p, int val);
-uint __ovld atomic_sub(volatile __global uint *p, uint val);
-int __ovld atomic_sub(volatile __local int *p, int val);
-uint __ovld atomic_sub(volatile __local uint *p, uint val);
+int __ovld atomic_sub(volatile __global int *, int);
+uint 

[PATCH] D133339: [clangd] Isolate logic for setting LSPServer options

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

rename helper & add comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D19

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

Index: clang-tools-extra/clangd/ClangdLSPServer.h
===
--- clang-tools-extra/clangd/ClangdLSPServer.h
+++ clang-tools-extra/clangd/ClangdLSPServer.h
@@ -60,6 +60,25 @@
 
 /// Limit the number of references returned (0 means no limit).
 size_t ReferencesLimit = 0;
+
+/// Options used for diagnostics.
+ClangdDiagnosticOptions DiagOpts;
+/// Set of symbol kinds to use.
+SymbolKindBitset SymbolKinds;
+/// Set of completion item kinds to use.
+CompletionItemKindBitset CompletionItemKinds;
+/// Whether to emit code actions or commands as code action responses.
+bool EmitCodeAction = false;
+/// Whether to emit hierarchical or flat document symbol responses.
+bool HierarchicalDocumentSymbol = false;
+/// Whether to send file status updates.
+bool EmitFileStatus = false;
+/// Which kind of markup should we use in textDocument/hover responses.
+MarkupKind HoverContentFormat = MarkupKind::PlainText;
+/// Whether to have offsets for parameter info labels.
+bool OffsetsInSignatureHelp = false;
+/// LSP extension: skip WorkDoneProgressCreate, just send progress streams.
+bool BackgroundIndexSkipCreate = false;
   };
 
   ClangdLSPServer(Transport &Transp, const ThreadsafeFS &TFS,
@@ -250,22 +269,6 @@
   LSPBinder::RawHandlers Handlers;
 
   const ThreadsafeFS &TFS;
-  /// Options used for diagnostics.
-  ClangdDiagnosticOptions DiagOpts;
-  /// The supported kinds of the client.
-  SymbolKindBitset SupportedSymbolKinds;
-  /// The supported completion item kinds of the client.
-  CompletionItemKindBitset SupportedCompletionItemKinds;
-  /// Whether the client supports CodeAction response objects.
-  bool SupportsCodeAction = false;
-  /// From capabilities of textDocument/documentSymbol.
-  bool SupportsHierarchicalDocumentSymbol = false;
-  /// Whether the client supports showing file status.
-  bool SupportFileStatus = false;
-  /// Which kind of markup should we use in textDocument/hover responses.
-  MarkupKind HoverContentFormat = MarkupKind::PlainText;
-  /// Whether the client supports offsets for parameter info labels.
-  bool SupportsOffsetsInSignatureHelp = false;
   std::mutex BackgroundIndexProgressMutex;
   enum class BackgroundIndexProgress {
 // Client doesn't support reporting progress. No transitions possible.
@@ -282,8 +285,6 @@
   // The progress to send when the progress bar is created.
   // Only valid in state Creating.
   BackgroundQueue::Stats PendingBackgroundIndexProgress;
-  /// LSP extension: skip WorkDoneProgressCreate, just send progress streams.
-  bool BackgroundIndexSkipCreate = false;
 
   Options Opts;
   // The CDB is created by the "initialize" LSP method.
Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -441,8 +441,9 @@
   return Modifiers;
 }
 
-void ClangdLSPServer::onInitialize(const InitializeParams &Params,
-   Callback Reply) {
+// Set server options to align with client capabilities.
+static void updateServerOptions(ClangdLSPServer::Options &Opts,
+const InitializeParams &Params) {
   // Determine character encoding first as it affects constructed ClangdServer.
   if (Params.capabilities.offsetEncoding && !Opts.Encoding) {
 Opts.Encoding = OffsetEncoding::UTF16; // fallback
@@ -463,9 +464,6 @@
 Opts.WorkspaceRoot = std::string(Params.rootUri->file());
   else if (Params.rootPath && !Params.rootPath->empty())
 Opts.WorkspaceRoot = *Params.rootPath;
-  if (Server)
-return Reply(llvm::make_error("server already initialized",
-ErrorCode::InvalidRequest));
 
   Opts.CodeComplete.EnableSnippets = Params.capabilities.CompletionSnippets;
   Opts.CodeComplete.IncludeFixIts = Params.capabilities.CompletionFixes;
@@ -475,25 +473,34 @@
   Params.capabilities.CompletionDocumentationFormat;
   Opts.SignatureHelpDocumentationFormat =
   Params.capabilities.SignatureHelpDocumentationFormat;
-  DiagOpts.EmbedFixesInDiagnostics = Params.capabilities.DiagnosticFixes;
-  DiagOpts.SendDiagnosticCategory = Params.capabilities.DiagnosticCategory;
-  DiagOpts.EmitRelatedLocations =
+  Opts.DiagOpts.EmbedFixesInDiagnostics = Params.capabilities.DiagnosticFixes;
+  Opts.DiagOpts.SendDiagnosticCategory = Params.capabilities.DiagnosticCategory;
+  Opts.DiagOpts.EmitRelatedLocations =
   Params.capabilities.DiagnosticRe

[clang] 2adf241 - [clang-format] [doc] Fix example of wrapping class definitions

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

Author: Passw
Date: 2022-09-06T12:24:18+02:00
New Revision: 2adf241592b38189994c6c9d2dfbfa391ecbe9fa

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

LOG: [clang-format] [doc] Fix example of wrapping class definitions

Example of

BraceWrapping
  AfterClass
is wrong

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

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/include/clang/Format/Format.h

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index 8bc24c81c9ec2..01ebbd72aae44 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -1439,12 +1439,12 @@ the configuration (without a prefix: ``Auto``).
 .. code-block:: c++
 
   true:
-  class foo {};
-
-  false:
   class foo
   {};
 
+  false:
+  class foo {};
+
   * ``BraceWrappingAfterControlStatementStyle AfterControlStatement``
 Wrap control statements (``if``/``for``/``while``/``switch``/..).
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index e057632cc1b02..c1e2fd54cd67d 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -1423,11 +1423,11 @@ struct FormatStyle {
 /// Wrap class definitions.
 /// \code
 ///   true:
-///   class foo {};
-///
-///   false:
 ///   class foo
 ///   {};
+///
+///   false:
+///   class foo {};
 /// \endcode
 bool AfterClass;
 



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

[clang] 2476135 - [clang-format] Change heuristic for locating lambda template arguments

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

Author: Emilia Dreamer
Date: 2022-09-06T12:24:19+02:00
New Revision: 247613548bac55b47eed88e83d5c8640fd4b200a

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

LOG: [clang-format] Change heuristic for locating lambda template arguments

Previously, the heuristic was simply to look for template argument-
specific keywords, such as typename, class, template and auto
that are preceded by a left angle bracket <.

This changes the heuristic to instead look for a left angle bracket <
preceded by a right square bracket ], since according to the C++
grammar, the template arguments must *directly* follow the introducer.
(This sort of check might just end up being *too* aggressive)

This patch also adds a bunch more token annotator tests for lambdas,
specifically for some of the stranger forms of lambdas now allowed as
of C++20 or soon-to-be-allowed as part of C++23.

Fixes https://github.com/llvm/llvm-project/issues/57093

This does NOT resolve the FIXME regarding explicit template lists, but
perhaps it gets closer

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

Added: 


Modified: 
clang/lib/Format/UnwrappedLineParser.cpp
clang/unittests/Format/FormatTest.cpp
clang/unittests/Format/TokenAnnotatorTest.cpp

Removed: 




diff  --git a/clang/lib/Format/UnwrappedLineParser.cpp 
b/clang/lib/Format/UnwrappedLineParser.cpp
index 02b13be0d92e4..7ef1e82d754fe 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -2210,21 +2210,21 @@ bool UnwrappedLineParser::tryToParseLambda() {
 case tok::l_square:
   parseSquare();
   break;
-case tok::kw_auto:
-case tok::kw_class:
-case tok::kw_template:
-case tok::kw_typename:
+case tok::less:
   assert(FormatTok->Previous);
-  if (FormatTok->Previous->is(tok::less))
+  if (FormatTok->Previous->is(tok::r_square))
 InTemplateParameterList = true;
   nextToken();
   break;
+case tok::kw_auto:
+case tok::kw_class:
+case tok::kw_template:
+case tok::kw_typename:
 case tok::amp:
 case tok::star:
 case tok::kw_const:
 case tok::kw_constexpr:
 case tok::comma:
-case tok::less:
 case tok::greater:
 case tok::identifier:
 case tok::numeric_constant:

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 88c16884d0d89..d3e657b018b77 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -21730,6 +21730,18 @@ TEST_F(FormatTest, FormatsLambdas) {
"g();\n"
"  }\n"
"};\n");
+  verifyFormat("auto L = [](T...) {\n"
+   "  {\n"
+   "f();\n"
+   "g();\n"
+   "  }\n"
+   "};");
+  verifyFormat("auto L = [](T...) {\n"
+   "  {\n"
+   "f();\n"
+   "g();\n"
+   "  }\n"
+   "};");
 
   // Multiple lambdas in the same parentheses change indentation rules. These
   // lambdas are forced to start on new lines.

diff  --git a/clang/unittests/Format/TokenAnnotatorTest.cpp 
b/clang/unittests/Format/TokenAnnotatorTest.cpp
index a839fb29115f9..a92d44be34f02 100644
--- a/clang/unittests/Format/TokenAnnotatorTest.cpp
+++ b/clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -809,18 +809,85 @@ TEST_F(TokenAnnotatorTest, UnderstandsLambdas) {
 
   Tokens = annotate("[]() -> auto {}");
   ASSERT_EQ(Tokens.size(), 9u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
   EXPECT_TOKEN(Tokens[4], tok::arrow, TT_LambdaArrow);
   EXPECT_TOKEN(Tokens[6], tok::l_brace, TT_LambdaLBrace);
 
   Tokens = annotate("[]() -> auto & {}");
   ASSERT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
   EXPECT_TOKEN(Tokens[4], tok::arrow, TT_LambdaArrow);
   EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
 
   Tokens = annotate("[]() -> auto * {}");
   ASSERT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
   EXPECT_TOKEN(Tokens[4], tok::arrow, TT_LambdaArrow);
   EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[] {}");
+  ASSERT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[] noexcept {}");
+  ASSERT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[3], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[] -> auto {}");
+  ASSERT_EQ(Tokens.size(), 7u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLS

[PATCH] D133087: [clang-format] [doc] Fix example of wrapping class definitions

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

This revision was automatically updated to reflect the committed changes.
Closed by commit rG2adf241592b3: [clang-format] [doc] Fix example of wrapping 
class definitions (authored by Passw, committed by HazardyKnusperkeks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133087

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h


Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -1423,11 +1423,11 @@
 /// Wrap class definitions.
 /// \code
 ///   true:
-///   class foo {};
-///
-///   false:
 ///   class foo
 ///   {};
+///
+///   false:
+///   class foo {};
 /// \endcode
 bool AfterClass;
 
Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -1439,12 +1439,12 @@
 .. code-block:: c++
 
   true:
-  class foo {};
-
-  false:
   class foo
   {};
 
+  false:
+  class foo {};
+
   * ``BraceWrappingAfterControlStatementStyle AfterControlStatement``
 Wrap control statements (``if``/``for``/``while``/``switch``/..).
 


Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -1423,11 +1423,11 @@
 /// Wrap class definitions.
 /// \code
 ///   true:
-///   class foo {};
-///
-///   false:
 ///   class foo
 ///   {};
+///
+///   false:
+///   class foo {};
 /// \endcode
 bool AfterClass;
 
Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -1439,12 +1439,12 @@
 .. code-block:: c++
 
   true:
-  class foo {};
-
-  false:
   class foo
   {};
 
+  false:
+  class foo {};
+
   * ``BraceWrappingAfterControlStatementStyle AfterControlStatement``
 Wrap control statements (``if``/``for``/``while``/``switch``/..).
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D132295: [clang-format] Change heuristic for locating lambda template arguments

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

This revision was automatically updated to reflect the committed changes.
Closed by commit rG247613548bac: [clang-format] Change heuristic for locating 
lambda template arguments (authored by rymiel, committed by HazardyKnusperkeks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132295

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/TokenAnnotatorTest.cpp

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -809,18 +809,85 @@
 
   Tokens = annotate("[]() -> auto {}");
   ASSERT_EQ(Tokens.size(), 9u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
   EXPECT_TOKEN(Tokens[4], tok::arrow, TT_LambdaArrow);
   EXPECT_TOKEN(Tokens[6], tok::l_brace, TT_LambdaLBrace);
 
   Tokens = annotate("[]() -> auto & {}");
   ASSERT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
   EXPECT_TOKEN(Tokens[4], tok::arrow, TT_LambdaArrow);
   EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
 
   Tokens = annotate("[]() -> auto * {}");
   ASSERT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
   EXPECT_TOKEN(Tokens[4], tok::arrow, TT_LambdaArrow);
   EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[] {}");
+  ASSERT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[] noexcept {}");
+  ASSERT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[3], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[] -> auto {}");
+  ASSERT_EQ(Tokens.size(), 7u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::arrow, TT_LambdaArrow);
+  EXPECT_TOKEN(Tokens[4], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  () {}");
+  ASSERT_EQ(Tokens.size(), 11u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[8], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  {}");
+  ASSERT_EQ(Tokens.size(), 9u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[6], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  () {}");
+  ASSERT_EQ(Tokens.size(), 12u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[9], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  {}");
+  ASSERT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  () {}");
+  ASSERT_EQ(Tokens.size(), 12u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[9], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  {}");
+  ASSERT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  () {}");
+  ASSERT_EQ(Tokens.size(), 12u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[9], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  {}");
+  ASSERT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
 }
 
 TEST_F(TokenAnnotatorTest, UnderstandsFunctionAnnotations) {
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -21730,6 +21730,18 @@
"g();\n"
"  }\n"
"};\n");
+  verifyFormat("auto L = [](T...) {\n"
+   "  {\n"
+   "f();\n"
+   "g();\n"
+   "  }\n"
+   "};");
+  verifyFormat("auto L = [](T...) {\n"
+   "  {\n"
+   "f();\n"
+   "g();\n"
+   "  }\n"
+   "};");
 
   // Multiple lambdas 

[PATCH] D133087: [clang-format] [doc] Fix example of wrapping class definitions

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

HazardyKnusperkeks added a comment.

Just a note, I had to edit your patch. Did you create it with git diff?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133087

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

[clang] 0cecc6e - [OpenMP] Add lit test for metadirective device arch inspired

[Saiyedul Islam via cfe-commits]

Author: Animesh Kumar
Date: 2022-09-06T07:10:15-05:00
New Revision: 0cecc6e8e27c9913cd2d82a77941dc3a6d11318f

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

LOG: [OpenMP] Add lit test for metadirective device arch inspired
from sollve

This lit test is added based upon the tests present in the
tests/5.0/metadirective directory of the SOLLVE repo
https://github.com/SOLLVE/sollve_vv

Reviewed By: saiislam

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

Added: 
clang/test/OpenMP/metadirective_device_arch_codegen.cpp

Modified: 
clang/test/OpenMP/metadirective_ast_print.c

Removed: 




diff  --git a/clang/test/OpenMP/metadirective_ast_print.c 
b/clang/test/OpenMP/metadirective_ast_print.c
index 6c75cb0592d6..ddd5b8633cc5 100644
--- a/clang/test/OpenMP/metadirective_ast_print.c
+++ b/clang/test/OpenMP/metadirective_ast_print.c
@@ -1,6 +1,10 @@
 // RUN: %clang_cc1 -verify -fopenmp -triple x86_64-unknown-linux-gnu -x c 
-std=c99 -ast-print %s -o - | FileCheck %s
 
 // RUN: %clang_cc1 -verify -fopenmp-simd -triple x86_64-unknown-linux-gnu -x c 
-std=c99 -ast-print %s -o - | FileCheck %s
+
+// RUN: %clang_cc1 -verify -fopenmp -triple amdgcn-amd-amdhsa -x c -std=c99 
-ast-print %s -o - | FileCheck %s --check-prefix=CHECK-AMDGCN
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -triple amdgcn-amd-amdhsa -x c 
-std=c99 -ast-print %s -o - | FileCheck %s --check-prefix=CHECK-AMDGCN
 // expected-no-diagnostics
 
 #ifndef HEADER
@@ -57,6 +61,12 @@ void foo(void) {
 for (int j = 0; j < 16; j++)
   array[i] = i;
   }
+
+#pragma omp metadirective when(device={arch("amdgcn")}: \
+teams distribute parallel for)\
+default(parallel for)
+  for (int i = 0; i < 100; i++)
+  ;
 }
 
 // CHECK: void bar(void);
@@ -83,5 +93,7 @@ void foo(void) {
 // CHECK-NEXT: for (int i = 0; i < 16; i++) {
 // CHECK-NEXT: #pragma omp simd
 // CHECK-NEXT: for (int j = 0; j < 16; j++)
+// CHECK-AMDGCN: #pragma omp teams distribute parallel for
+// CHECK-AMDGCN-NEXT: for (int i = 0; i < 100; i++)
 
 #endif

diff  --git a/clang/test/OpenMP/metadirective_device_arch_codegen.cpp 
b/clang/test/OpenMP/metadirective_device_arch_codegen.cpp
new file mode 100644
index ..eac71d0e5b5a
--- /dev/null
+++ b/clang/test/OpenMP/metadirective_device_arch_codegen.cpp
@@ -0,0 +1,65 @@
+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang_cc1 -fopenmp -x c++ -w -std=c++11 -triple 
x86_64-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o 
%t-ppc-host.bc
+// RUN: %clang_cc1 -fopenmp -x c++ -w -std=c++11 -triple amdgcn-amd-amdhsa 
-fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-ppc-host.bc -target-cpu gfx906 -o - | FileCheck %s
+// expected-no-diagnostics
+
+
+/*===---===
 
+
+Inspired from SOLLVE tests:
+ - 5.0/metadirective/test_metadirective_arch_is_nvidia.c
+
+
+======*/
+
+
+#define N 1024
+
+int metadirective1() {
+   
+   int v1[N], v2[N], v3[N];
+
+   int target_device_num, host_device_num, default_device;
+   int errors = 0;
+
+   #pragma omp target map(to:v1,v2) map(from:v3, target_device_num) 
device(default_device)
+   {
+  #pragma omp metadirective \
+   when(device={arch("amdgcn")}: teams distribute parallel 
for) \
+   default(parallel for)
+
+ for (int i = 0; i < N; i++) {
+   #pragma omp atomic write
+v3[i] = v1[i] * v2[i];
+ }
+   }
+
+   return errors;
+}
+
+// CHECK-LABEL: define weak_odr amdgpu_kernel void {{.+}}metadirective1
+// CHECK: entry:
+// CHECK: %{{[0-9]}} = call i32 @__kmpc_target_init
+// CHECK: user_code.entry:
+// CHECK: call void @__omp_outlined__
+// CHECK-NOT: call void @__kmpc_parallel_51
+// CHECK: ret void
+
+
+// CHECK-LABEL: define internal void @__omp_outlined__
+// CHECK: entry:
+// CHECK: call void @__kmpc_distribute_static_init
+// CHECK: omp.loop.exit:  
+// CHECK: call void @__kmpc_distribute_static_fini
+
+
+// CHECK-LABEL: define internal void @__omp_outlined__.{{[0-9]+}}
+// CHECK: entry:
+// CHECK: call void @__kmpc_for_static_init_4
+// CHECK: omp.inner.for.body:
+// CHECK: store atomic {{.*}} monotonic
+// CHECK: omp.loop.exit:
+// CHECK-NEXT: call void @__kmpc_distribute_static_fini
+// CHECK-NEXT: ret void
+



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

[PATCH] D131763: [OpenMP] Add lit test for metadirective device arch inspired from sollve

[Saiyedul Islam via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG0cecc6e8e27c: [OpenMP] Add lit test for metadirective device 
arch inspired (authored by animeshk-amd, committed by saiislam).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131763

Files:
  clang/test/OpenMP/metadirective_ast_print.c
  clang/test/OpenMP/metadirective_device_arch_codegen.cpp

Index: clang/test/OpenMP/metadirective_device_arch_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/metadirective_device_arch_codegen.cpp
@@ -0,0 +1,65 @@
+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang_cc1 -fopenmp -x c++ -w -std=c++11 -triple x86_64-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -fopenmp -x c++ -w -std=c++11 -triple amdgcn-amd-amdhsa -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -target-cpu gfx906 -o - | FileCheck %s
+// expected-no-diagnostics
+
+
+/*===---=== 
+
+Inspired from SOLLVE tests:
+ - 5.0/metadirective/test_metadirective_arch_is_nvidia.c
+
+
+======*/
+
+
+#define N 1024
+
+int metadirective1() {
+   
+   int v1[N], v2[N], v3[N];
+
+   int target_device_num, host_device_num, default_device;
+   int errors = 0;
+
+   #pragma omp target map(to:v1,v2) map(from:v3, target_device_num) device(default_device)
+   {
+  #pragma omp metadirective \
+   when(device={arch("amdgcn")}: teams distribute parallel for) \
+   default(parallel for)
+
+ for (int i = 0; i < N; i++) {
+	#pragma omp atomic write
+v3[i] = v1[i] * v2[i];
+ }
+   }
+
+   return errors;
+}
+
+// CHECK-LABEL: define weak_odr amdgpu_kernel void {{.+}}metadirective1
+// CHECK: entry:
+// CHECK: %{{[0-9]}} = call i32 @__kmpc_target_init
+// CHECK: user_code.entry:
+// CHECK: call void @__omp_outlined__
+// CHECK-NOT: call void @__kmpc_parallel_51
+// CHECK: ret void
+
+
+// CHECK-LABEL: define internal void @__omp_outlined__
+// CHECK: entry:
+// CHECK: call void @__kmpc_distribute_static_init
+// CHECK: omp.loop.exit:  
+// CHECK: call void @__kmpc_distribute_static_fini
+
+
+// CHECK-LABEL: define internal void @__omp_outlined__.{{[0-9]+}}
+// CHECK: entry:
+// CHECK: call void @__kmpc_for_static_init_4
+// CHECK: omp.inner.for.body:
+// CHECK: store atomic {{.*}} monotonic
+// CHECK: omp.loop.exit:
+// CHECK-NEXT: call void @__kmpc_distribute_static_fini
+// CHECK-NEXT: ret void
+
Index: clang/test/OpenMP/metadirective_ast_print.c
===
--- clang/test/OpenMP/metadirective_ast_print.c
+++ clang/test/OpenMP/metadirective_ast_print.c
@@ -1,6 +1,10 @@
 // RUN: %clang_cc1 -verify -fopenmp -triple x86_64-unknown-linux-gnu -x c -std=c99 -ast-print %s -o - | FileCheck %s
 
 // RUN: %clang_cc1 -verify -fopenmp-simd -triple x86_64-unknown-linux-gnu -x c -std=c99 -ast-print %s -o - | FileCheck %s
+
+// RUN: %clang_cc1 -verify -fopenmp -triple amdgcn-amd-amdhsa -x c -std=c99 -ast-print %s -o - | FileCheck %s --check-prefix=CHECK-AMDGCN
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -triple amdgcn-amd-amdhsa -x c -std=c99 -ast-print %s -o - | FileCheck %s --check-prefix=CHECK-AMDGCN
 // expected-no-diagnostics
 
 #ifndef HEADER
@@ -57,6 +61,12 @@
 for (int j = 0; j < 16; j++)
   array[i] = i;
   }
+
+#pragma omp metadirective when(device={arch("amdgcn")}: \
+teams distribute parallel for)\
+default(parallel for)
+  for (int i = 0; i < 100; i++)
+  ;
 }
 
 // CHECK: void bar(void);
@@ -83,5 +93,7 @@
 // CHECK-NEXT: for (int i = 0; i < 16; i++) {
 // CHECK-NEXT: #pragma omp simd
 // CHECK-NEXT: for (int j = 0; j < 16; j++)
+// CHECK-AMDGCN: #pragma omp teams distribute parallel for
+// CHECK-AMDGCN-NEXT: for (int i = 0; i < 100; i++)
 
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133349: [clang][doc] Do not keep a copy of ClangCommandLineReference.rst in tree

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

@aaron.ballman this is just a patch to start a discussion: We already have the 
cmake rule to generate this file, so removing it from tree actually doesn't 
break compilation. So I'm wondering why and if we should keep it checked in? 
Removing it would make it less likely for simple minded people like me to edit 
it (without reading the header warning)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133349

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

[PATCH] D132550: Changes to code ownership in clang and clang-tidy

[Aaron Ballman via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3c604e9f1560: Update the clang and clang-tools-extra code 
owners files (authored by aaron.ballman).

Changed prior to commit:
  https://reviews.llvm.org/D132550?vs=457289&id=458149#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132550

Files:
  clang-tools-extra/CODE_OWNERS.TXT
  clang/CODE_OWNERS.TXT
  clang/CodeOwners.rst
  clang/docs/CodeOwners.rst
  clang/docs/index.rst

Index: clang/docs/index.rst
===
--- clang/docs/index.rst
+++ clang/docs/index.rst
@@ -98,6 +98,7 @@
 .. toctree::
:maxdepth: 1
 
+   CodeOwners
InternalsManual
DriverInternals
OffloadingDesign
Index: clang/docs/CodeOwners.rst
===
--- /dev/null
+++ clang/docs/CodeOwners.rst
@@ -0,0 +1 @@
+.. include:: ../CodeOwners.rst
Index: clang/CodeOwners.rst
===
--- /dev/null
+++ clang/CodeOwners.rst
@@ -0,0 +1,256 @@
+=
+Clang Code Owners
+=
+
+This file is a list of the people responsible for ensuring that patches for a
+particular part of Clang are reviewed, either by themself or by someone else.
+They are also the gatekeepers for their part of Clang, with the final word on
+what goes in or not.
+
+.. contents::
+   :depth: 2
+   :local:
+
+Current Code Owners
+===
+The following people are the active code owners for the project. Please reach
+out to them for code reviews, questions about their area of expertise, or other
+assistance.
+
+All parts of Clang not covered by someone else
+--
+| Aaron Ballman
+| aaron\@aaronballman.com (email), aaron.ballman (Phabricator), AaronBallman (GitHub)
+
+
+Contained Components
+
+These code owners are responsible for particular high-level components within
+Clang that are typically contained to one area of the compiler.
+
+AST matchers
+
+| Manuel Klimek
+| klimek\@google.com (email), klimek (Phabricator), r4nt (GitHub)
+
+
+Clang LLVM IR generation
+
+| John McCall
+| rjmccall\@apple.com (email), rjmccall (Phabricator), rjmccall (GitHub)
+
+| Eli Friedman
+| efriedma\@quicinc.com (email), efriedma (Phabricator), efriedma-quic (GitHub)
+
+| Anton Korobeynikov
+| anton\@korobeynikov.info (email), asl (Phabricator), asl (GitHub)
+
+
+Analysis & CFG
+~~
+| Dmitri Gribenko
+| gribozavr\@gmail.com (email), gribozavr (Phabricator), gribozavr (GitHub)
+
+| Yitzhak Mandelbaum
+| yitzhakm\@google.com (email), ymandel (Phabricator), ymand (GitHub)
+
+| Stanislav Gatev
+| sgatev\@google.com (email), sgatev (Phabricator), sgatev (GitHub)
+
+
+Modules & serialization
+~~~
+| Chuanqi Xu
+| yedeng.yd\@linux.alibaba.com (email), ChuanqiXu (Phabricator), ChuanqiXu9 (GitHub)
+
+| Michael Spencer
+| bigcheesegs\@gmail.com (email), Bigcheese (Phabricator), Bigcheese (GitHub)
+
+
+Templates
+~
+| Erich Keane
+| erich.keane\@intel.com (email), ErichKeane (Phabricator), erichkeane (GitHub)
+
+
+Debug information
+~
+| Eric Christopher
+| echristo\@gmail.com (email), echristo (Phabricator), echristo (GitHub)
+
+
+Exception handling
+~~
+| Anton Korobeynikov
+| anton\@korobeynikov.info (email), asl (Phabricator), asl (GitHub)
+
+
+Clang static analyzer
+~
+| Artem Dergachev
+| adergachev\@apple.com (email), NoQ (Phabricator), haoNoQ (GitHub)
+
+| Gábor Horváth
+| xazax.hun\@gmail.com (email), xazax.hun (Phabricator), Xazax-hun (GitHub)
+
+
+Compiler options
+
+| Jan Svoboda
+| jan_svoboda\@apple.com (email), jansvoboda11 (Phabricator), jansvoboda11 (GitHub)
+
+
+OpenBSD driver
+~~
+| Brad Smith
+| brad\@comstyle.com (email), brad (Phabricator), brad0 (GitHub)
+
+
+Driver parts not covered by someone else
+
+| Fangrui Song
+| maskray\@google.com (email), MaskRay (Phabricator), MaskRay (GitHub)
+
+
+Tools
+-
+These code owners are responsible for user-facing tools under the Clang
+umbrella or components used to support such tools.
+
+Tooling library
+~~~
+| Manuel Klimek
+| klimek\@google.com (email), klimek (Phabricator), r4nt (GitHub)
+
+
+clang-format
+
+| MyDeveloperDay
+| mydeveloperday\@gmail.com (email), MyDeveloperDay (Phabricator), MyDeveloperDay (GitHub)
+
+| Owen Pan
+| owenpiano\@gmail.com (email), owenpan (Phabricator), owenca (GitHub)
+
+
+ABIs
+
+The following people are responsible for decisions involving ABI.
+
+Itanium ABI
+~~~
+| John McCall
+| rjmccall\@apple.com (email), rjmccall (Phabricator), rjmccall (GitHub)
+
+
+Microsoft ABI
+~
+| Reid Kleckner
+| rnk\@google.com (ema

[clang] 3c604e9 - Update the clang and clang-tools-extra code owners files

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2022-09-06T08:28:03-04:00
New Revision: 3c604e9f15606fa395b088ca341a232ffda2bb7d

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

LOG: Update the clang and clang-tools-extra code owners files

This also converts the Clang code owners file from a flat text file to
an RST file that is linked in to the rest of our documentation.

The RFC for this can be found at:
https://discourse.llvm.org/t/rfc-proposed-changes-to-clangs-code-ownership/

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

Added: 
clang/CodeOwners.rst
clang/docs/CodeOwners.rst

Modified: 
clang-tools-extra/CODE_OWNERS.TXT
clang/docs/index.rst

Removed: 
clang/CODE_OWNERS.TXT



diff  --git a/clang-tools-extra/CODE_OWNERS.TXT 
b/clang-tools-extra/CODE_OWNERS.TXT
index 3dc3ddd7c78d..4cf80aa2b0b8 100644
--- a/clang-tools-extra/CODE_OWNERS.TXT
+++ b/clang-tools-extra/CODE_OWNERS.TXT
@@ -4,26 +4,27 @@ also the gatekeepers for their part of Clang, with the final 
word on what goes
 in or not.
 
 The list is sorted by surname and formatted to allow easy grepping and
-beautification by scripts.  The fields are: name (N), email (E), web-address
-(W), PGP key ID and fingerprint (P), description (D), and snail-mail address
-(S).
+beautification by scripts.  The fields are: name (N), email (E), Phabricator
+handle (H), and description (D).
 
 N: Aaron Ballman
 E: aa...@aaronballman.com
+H: aaron.ballman
 D: clang-query
 
-N: Manuel Klimek
-E: kli...@google.com
-D: clang-rename, all parts of clang-tools-extra not covered by someone else
-
-N: Alexander Kornienko
-E: ale...@google.com
-D: clang-tidy
-
 N: Julie Hockett
 E: juliehock...@google.com
 D: clang-doc
 
+N: Nathan James
+E: n.jame...@hotmail.co.uk
+H: njames93
+D: clang-tidy
+
+N: Manuel Klimek
+E: kli...@google.com
+D: clang-rename, all parts of clang-tools-extra not covered by someone else
+
 N: Sam McCall
 E: sammcc...@google.com
 D: clangd

diff  --git a/clang/CODE_OWNERS.TXT b/clang/CODE_OWNERS.TXT
deleted file mode 100644
index 740aeeb7125b..
--- a/clang/CODE_OWNERS.TXT
+++ /dev/null
@@ -1,66 +0,0 @@
-This file is a list of the people responsible for ensuring that patches for a
-particular part of Clang are reviewed, either by themself or by someone else.
-They are also the gatekeepers for their part of Clang, with the final word on
-what goes in or not.
-
-The list is sorted by surname and formatted to allow easy grepping and
-beautification by scripts.  The fields are: name (N), email (E), web-address
-(W), PGP key ID and fingerprint (P), description (D), and snail-mail address
-(S).
-
-N: Alexey Bader
-E: alexey.ba...@intel.com
-D: SYCL support
-
-N: Aaron Ballman
-E: aa...@aaronballman.com
-D: Clang attributes
-
-N: Alexey Bataev
-E: a.bat...@hotmail.com
-D: OpenMP support
-
-N: Chandler Carruth
-E: chandl...@gmail.com
-E: chandl...@google.com
-D: CMake, library layering
-
-N: Eric Christopher
-E: echri...@gmail.com
-D: Debug Information, inline assembly
-
-N: Devin Coughlin
-E: dcough...@apple.com
-D: Clang Static Analyzer
-
-N: Doug Gregor
-E: dgre...@apple.com
-D: Emeritus owner
-
-N: Reid Kleckner
-E: r...@google.com
-D: Microsoft C++ ABI compatibility and general Windows support
-
-N: Manuel Klimek
-E: kli...@google.com
-D: AST matchers, LibTooling
-
-N: Anton Korobeynikov
-E: an...@korobeynikov.info
-D: Exception handling, Windows codegen, ARM EABI
-
-N: John McCall
-E: rjmcc...@apple.com
-D: Clang LLVM IR generation
-
-N: Brad Smith
-E: b...@comstyle.com
-D: OpenBSD driver
-
-N: Richard Smith
-E: rich...@metafoo.co.uk
-D: All parts of Clang not covered by someone else
-
-N: Anastasia Stulova
-E: anastasia.stul...@arm.com
-D: OpenCL support

diff  --git a/clang/CodeOwners.rst b/clang/CodeOwners.rst
new file mode 100644
index ..70662a6a580d
--- /dev/null
+++ b/clang/CodeOwners.rst
@@ -0,0 +1,256 @@
+=
+Clang Code Owners
+=
+
+This file is a list of the people responsible for ensuring that patches for a
+particular part of Clang are reviewed, either by themself or by someone else.
+They are also the gatekeepers for their part of Clang, with the final word on
+what goes in or not.
+
+.. contents::
+   :depth: 2
+   :local:
+
+Current Code Owners
+===
+The following people are the active code owners for the project. Please reach
+out to them for code reviews, questions about their area of expertise, or other
+assistance.
+
+All parts of Clang not covered by someone else
+--
+| Aaron Ballman
+| aaron\@aaronballman.com (email), aaron.ballman (Phabricator), AaronBallman 
(GitHub)
+
+
+Contained Components
+
+These code owners are responsible for particular high-level components within

[PATCH] D132843: [RISCV] Ensure target features get passed to the LTO linker for RISC-V

[Kito Cheng via Phabricator via cfe-commits]

kito-cheng added a comment.

> I'm not sure how the issues with datalayout in particular end up being an 
> issue in practice.
>
> clang shouldn't be writing out object files without a datalayout.
> The code to infer alignment on load/store/etc. only exists for compatibility 
> with old bitcode/IR; current LLVM bitcode always marks up alignment for all 
> operations.
> Or do you mean something else when you say "datalayout"?

ilp32/ilp32f/ilp32d and ilp32e(D70401 ) having 
different data layout, so when we try to merge those stuffs will run into 
trouble, although I admit build object file with ilp32/ilp32f/ilp32d then LTO 
with ilp32e is generally a bad idea.

Another issue is the LLVM isn't compatible between different ABI, e.g. ilp32 
and ilp32f having different LLVM IR when passing a struct with a int and a 
float[2].

[1] https://reviews.llvm.org/D71387#1792169

---

> On other targets, the instruction set used is encoded at a per-function 
> level. So on x86, for example, you can have an "AVX" codepath and an "SSE" 
> codepath, and use runtime CPU detection to figure out which to use.

Give an example to explain what problem we have now and what option we have:

  $ clang -target riscv64-elf -flto a.c -o a.o -march=rv64gc# a.o 
build with -march=rv64gc
  $ clang -target riscv64-elf -flto b.c -o b.o -march=rv64g # b.o 
build with -march=rv64g
  $ clang -target riscv64-elf  a.o b.o -o a.out -flto -march=rv64gc_zba # and 
LTO phase use -march=rv64gc_zba, what target feature (or ISA extensions) should 
be used for all function 

Possible solution/results:

1. All functions in `a.o` and `b.o` using same target features during the first 
build stage, `-march=rv64gc` for a.o, `-march=rv64g` for `b.o`, and `-march` 
option given in LTO CodeGen stage is ignored, it only used for ELF attribute 
use (this revision).
2. All functions in `a.o` and `b.o` using same target features during the first 
build stage, `-march=rv64gc` for a.o, `-march=rv64g` for `b.o`, and deduced 
arch info from those `.o` for ELF attribute use (D106347 
), `-march`
3. All functions in `a.o` and `b.o` re-compile with `-march=rv64gc_zba` and ELF 
attribute use `rv64gc_zba`.

Option 1: Require user use right `-march` option during LTO stage, and might 
fill wrong/unexpected ELF attribute if give wrong `-march` or not even not 
given in LTO stage.
Option 2: Should be more ideal, but D106347  
seems no progress for a while.
Option 3: This option will break IFUNC usage.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132843

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

[PATCH] D133262: [clang] Represent __make_integer_seq as alias template in the AST

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/AST/DeclTemplate.cpp:257
+return true;
+  case TemplateDecl::BuiltinTemplate: {
+const auto *BT = cast(this);

This seems strange to me that ONLY this one builtin is what makes a template a 
'type alias'.  This needs to have a more descriptive name here, IMO.



Comment at: clang/lib/AST/DeclTemplate.cpp:262
+  }
+  default:;
+  };

The semicolon after default is bizarre/unnecessary.  That said, I'd suggest 
just making the 'default' case be 'return false'.



Comment at: clang/lib/Sema/SemaTemplate.cpp:3531
 // synthetic template argument list.
-SyntheticTemplateArgs.addArgument(TemplateArgs[1]);
+auto *TTPD =
+cast(BTD->getTemplateParameters()->getParam(1));

Can you update the comment here ot accurately describe what is going on below?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133262

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

[PATCH] D133087: [clang-format] [doc] Fix example of wrapping class definitions

[passw_passw via Phabricator via cfe-commits]

Passw added a comment.

In D133087#3771637 , 
@HazardyKnusperkeks wrote:

> Just a note, I had to edit your patch. Did you create it with git diff?

Yes, I create this patch with `git diff` according to this guideline Requesting 
a review via the web interface 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133087

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

LGTM for HIP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D133248: [clang] Fix crash upon stray coloncolon token in C2x mode

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

Good catch that this was crashing! LGTM aside from the nit pointed out by 
@tbaeder. Can you also add a release note for the fix? Do you need someone to 
commit on your behalf? If so, what name and email address would you like used 
for patch attribution?




Comment at: clang/lib/Parse/ParseDecl.cpp:5340
+if (!getLangOpts().CPlusPlus)
+  return false;
 if (NextToken().is(tok::kw_new) ||// ::new

inclyc wrote:
> Maybe we can make a new `error` diagnostic definition and fire that here?
I don't think we should -- this function is used to query whether something is 
a declaration specifier or not; it'd be surprising to issue a diagnostic from 
that kind of interface.



Comment at: clang/test/Parser/c2x-attributes.c:146
+// Ensure that '::' outside of attributes does not crash and is not treated as 
scope
+double n::v; // expected-error {{expected ';' after top level declarator}}

inclyc wrote:
> Could we improve this diagnostic message? 
> ```
> expected ';' after top level declarator}
> ```
That might be possible, but it should happen as a separate patch. That said, 
I'm not certain how much improvement there is to be had there, especially in C 
mode. It really does look like the user is trying to declare a variable named 
`n` and got the wrong kind of colon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133248

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

[PATCH] D132294: [clang-tidy] Add check of sprintf with fixed size buffer

[方程 via Phabricator via cfe-commits]

Yoorkin updated this revision to Diff 458155.
Yoorkin marked 5 inline comments as done.
Yoorkin added a comment.

Maybe renamed to bugprone-sprintf-with-fixed-size-buffer would be better. I add 
another option `FlagAllCalls` to flag all calls to `sprintf` and `vsprintf`.


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

https://reviews.llvm.org/D132294

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/SprintfWithFixedSizeBufferCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SprintfWithFixedSizeBufferCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone/sprintf-with-fixed-size-buffer.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone/sprintf-with-fixed-size-buffer.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone/sprintf-with-fixed-size-buffer.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone/sprintf-with-fixed-size-buffer.cpp
@@ -0,0 +1,33 @@
+// RUN: %check_clang_tidy %s bugprone-sprintf-with-fixed-size-buffer %t
+
+#include 
+
+void f(){
+  char buff[80];
+  sprintf(buff, "Hello, %s!\n", "world");
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: string to be written may exceeds the size of buffer; use snprintf instead [bugprone-printf-with-fixed-size-buffer]
+  // CHECK-FIXES: snprintf(buff, sizeof(buff), "Hello, %s!\n", "world");
+}
+
+char sbuff[80];
+
+void f2(){
+  sprintf(sbuff, "Hello, %s!\n", "world");
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: string to be written may exceeds the size of buffer; use snprintf instead [bugprone-printf-with-fixed-size-buffer]
+  // CHECK-FIXES: snprintf(sbuff, sizeof(sbuff), "Hello, %s!\n", "world");
+}
+
+void f3(){
+char *dynamic_sized_buff = nullptr;
+sprintf(dynamic_sized_buff, "Hello, %s!\n", "world");
+}
+
+void f4(const char * format, ... ){
+  char buff[100];
+  va_list args;
+  va_start(args, format);
+  vsprintf(buff, format, args);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: string to be written may exceeds the size of buffer; use vsnprintf instead [bugprone-printf-with-fixed-size-buffer]
+  // CHECK-FIXES: vsnprintf(buff, sizeof(buff), format, args);
+  va_end(args);
+}
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
@@ -114,6 +114,7 @@
`bugprone-signed-char-misuse `_,
`bugprone-sizeof-container `_,
`bugprone-sizeof-expression `_,
+   `bugprone-sprintf-with-fixed-size-buffer `_, "Yes"
`bugprone-spuriously-wake-up-functions `_,
`bugprone-string-constructor `_, "Yes"
`bugprone-string-integer-assignment `_, "Yes"
Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/sprintf-with-fixed-size-buffer.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/sprintf-with-fixed-size-buffer.rst
@@ -0,0 +1,39 @@
+.. title:: clang-tidy - bugprone-sprintf-with-fixed-size-buffer
+
+bugprone-sprintf-with-fixed-size-buffer
+===
+
+Finds usage of ``sprintf`` or ``vsprintf``, which write output string into a fixed-size array. 
+It will suggest the counted versions instead.
+
+It's a common idiom to have a fixed-size buffer of characters allocated on 
+the stack and then to printf into the buffer. It may be leading to errors if the 
+string to be written exceeds the size of the array pointed to by buffer.
+
+Example:
+.. code-block:: c++
+
+void f(){
+  char buff[80];
+  sprintf(buff, "Hello, %s!\n", "world");
+}
+
+Becomes:
+.. code-block:: c++
+
+void f(){
+  char buff[80];
+  snprintf(buff, sizeof(buff), "Hello, %s!\n", "world");
+}
+
+Options
+---
+
+.. option:: PreferSafe
+
+  When `true`, prefer to use ``snprintf_s`` ``vsnprintf_s`` over ``snprintf`` ``vsnprintf``.
+  Default is `false`.
+
+.. option:: FlagAllCalls
+Flag all calls to ``sprintf`` and ``vsprintf``.
+Default is `false`
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -99,6 +99,11 @@
 New checks
 ^^
 
+- New :doc:`bugprone-sprintf-with-fixed-size-buffer
+  ` check.
+
+  Finds usage of ``sprintf`` or ``vsprintf``, which write output string into a fixed-size array. 
+
 - New :doc:`cppcoreguidelines-avoid-const-or-ref-data-members
   ` check.
 
Index: clang-tools-extra/clang-tidy/bugprone/SprintfWithFixedSizeBufferCheck.h
===
--- /dev/null
+++ clang-tools-ex

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

[Azat Khuzhin via Phabricator via cfe-commits]

azat added a comment.

Can someone take a look please?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133092

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

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

Thanks for your patience, this was a sizable review that it took a while to be 
able to make time for.  A handful of non-functional reviews, but the 
functionality looks fine.




Comment at: clang/lib/AST/ASTContext.cpp:12139
+return X;
+  assert(declaresSameEntity(X, Y));
+  for (const Decl *DX : X->redecls()) {

As a nit, I'd prefer this assert above the 'if' above, that way it catches 
Nulls in that case. It seems that the 'contract' for this function is no null 
values, so we want to catch this ASAP.



Comment at: clang/lib/AST/ASTContext.cpp:12154
+T *getCommonDecl(T *X, T *Y) {
+  return cast_or_null(
+  getCommonDecl(const_cast(cast_or_null(X)),

Do we REALLY need to tolerate  'null' here as well?  It seems we should do a 
normal cast and have the cast assert.



Comment at: clang/lib/AST/ASTContext.cpp:12172
+
+static auto getCommonTypeArray(ASTContext &Ctx, ArrayRef Xs,
+   ArrayRef Ys,

Please comment these functions, it isn't clear on read through what you mean by 
'Array' here.  You probably mean for this to be something like `getCommonTypes`.



Comment at: clang/lib/AST/ASTContext.cpp:12204
+  }
+  llvm_unreachable("");
+}

Please give me a message here, just anything reasonably descriptive so that 
when it shows up I have something to grep.



Comment at: clang/lib/AST/ASTContext.cpp:12241
+
+template  static auto *getCommonSizeExpr(T *X, T *Y) {
+  assert(X->getSizeExpr() == Y->getSizeExpr());

I guess I don't see the po int of the next 3 functions?  There is no sugaring 
or anything, AND they already assume they are the same expression/element/etc? 



Comment at: clang/lib/AST/ASTContext.cpp:12323
+  case EST_NoThrow:
+llvm_unreachable("handled above");
+

something a little more unique in this (and others!) would be appreciated.



Comment at: clang/lib/AST/ASTContext.cpp:12116
+// If we reach the canonical declaration, then Y is older.
+if (DX->isCanonicalDecl())
+  return Y;

davrec wrote:
> I think "canonical" should be replaced with "first" here and 
> `isCanonicalDecl()` with `isFirstDecl()`.  So far as I can tell 
> `getCanonicalDecl()` returns `getFirstDecl()` everywhere for now, but that 
> could conceivably change, and in any case the goal of this code is to find 
> which is older, so "first" would be clearer as well.
For class types, canonical decl is usually the definition if one exists.  So I 
assume we do mean 'first' here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111283

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

[PATCH] D130308: [clang] extend getCommonSugaredType to merge sugar nodes

[Erich Keane via Phabricator via cfe-commits]

erichkeane accepted this revision.
erichkeane added a comment.

I've got concerns about the interface not being clear on null-ability, and THIS 
patch seems to move us toward nulls being disallowed, so I'd like that 
formalized when possible (either via asserts or, better, by switching to 
references when possible).  Otherwise, LG.




Comment at: clang/lib/AST/ASTContext.cpp:12141
 static Decl *getCommonDecl(Decl *X, Decl *Y) {
-  if (X == Y)
-return X;
-  assert(declaresSameEntity(X, Y));
+  if (!declaresSameEntity(X, Y))
+return nullptr;

same concerns about null here.  I find myself wondering if this 'getCommonX' 
should take/return references when possible.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130308

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

[clang] e1ebe47 - Fix Clang Sphinx docs build

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2022-09-06T09:52:22-04:00
New Revision: e1ebe476e45a677535f8cae3cc9f7fb84f477fdd

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

LOG: Fix Clang Sphinx docs build

The CodeOwners.rst file needs to live in the same directory as the rest
of the documentation. This copies the file to the correct place when
making a Sphinx build but continues to leave the .rst file at the root
directory where it's easier for developers to find. This also ensures
that local doc builds using `make html` work as expected.

Added: 


Modified: 
clang/docs/CMakeLists.txt

Removed: 




diff  --git a/clang/docs/CMakeLists.txt b/clang/docs/CMakeLists.txt
index 2d3ac5dbdd19..532907385df4 100644
--- a/clang/docs/CMakeLists.txt
+++ b/clang/docs/CMakeLists.txt
@@ -114,8 +114,12 @@ if (LLVM_ENABLE_SPHINX)
   # directory before we run sphinx.
   add_custom_target(copy-clang-rst-docs
 COMMAND "${CMAKE_COMMAND}" -E copy_directory
-"${CMAKE_CURRENT_SOURCE_DIR}"
-"${CMAKE_CURRENT_BINARY_DIR}")
+"${CMAKE_CURRENT_SOURCE_DIR}" "${CMAKE_CURRENT_BINARY_DIR}"
+
+COMMAND "${CMAKE_COMMAND}" -E copy_if_
diff erent
+"${CMAKE_CURRENT_SOURCE_DIR}/../CodeOwners.rst"
+"${CMAKE_CURRENT_BINARY_DIR}"
+  )
   add_dependencies(docs-clang-html copy-clang-rst-docs)
 
   add_custom_command(TARGET docs-clang-html POST_BUILD



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

[PATCH] D133341: [C++] [Coroutines] Prefer aligned (de)allocation for coroutines - implement the option2 of P2014R0

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

I'm not a great reviewer for coroutines as I don't quite get them, so a vastly 
better commit/review message would be GREATLY appreciated.

Code seems fine, but I'd love for someone better at coroutines to take a look 
too.




Comment at: clang/lib/CodeGen/CGCoroutine.cpp:688
+auto &Context = getContext();
+auto SizeTy = Context.getSizeType();
+auto T = Builder.getIntNTy(Context.getTypeSize(SizeTy));

Don't use 'auto' unless the RHS has the type in it clearly.  SO this should be 
QualType I think?  I also see you've broken that coding standard rule above.



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:689
+auto SizeTy = Context.getSizeType();
+auto T = Builder.getIntNTy(Context.getTypeSize(SizeTy));
+llvm::Function *F = CGM.getIntrinsic(llvm::Intrinsic::coro_align, T);

Same here.  ALSO, even when using 'auto', we need ot keep the '*' around.


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

https://reviews.llvm.org/D133341

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

[PATCH] D132689: [Object] Refactor code for extracting offload binaries

[Joseph Huber via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5dbc7cf7cac4: [Object] Refactor code for extracting offload 
binaries (authored by jhuber6).

Changed prior to commit:
  https://reviews.llvm.org/D132689?vs=455659&id=458162#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132689

Files:
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
  llvm/include/llvm/Object/OffloadBinary.h
  llvm/lib/Object/CMakeLists.txt
  llvm/lib/Object/OffloadBinary.cpp

Index: llvm/lib/Object/OffloadBinary.cpp
===
--- llvm/lib/Object/OffloadBinary.cpp
+++ llvm/lib/Object/OffloadBinary.cpp
@@ -10,14 +10,147 @@
 
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/BinaryFormat/Magic.h"
+#include "llvm/IR/Constants.h"
+#include "llvm/IR/Module.h"
+#include "llvm/IRReader/IRReader.h"
 #include "llvm/MC/StringTableBuilder.h"
+#include "llvm/Object/Archive.h"
+#include "llvm/Object/ArchiveWriter.h"
+#include "llvm/Object/Binary.h"
+#include "llvm/Object/ELFObjectFile.h"
 #include "llvm/Object/Error.h"
+#include "llvm/Object/IRObjectFile.h"
+#include "llvm/Object/ObjectFile.h"
 #include "llvm/Support/Alignment.h"
 #include "llvm/Support/FileOutputBuffer.h"
+#include "llvm/Support/SourceMgr.h"
 
 using namespace llvm;
 using namespace llvm::object;
 
+namespace {
+
+/// Attempts to extract all the embedded device images contained inside the
+/// buffer \p Contents. The buffer is expected to contain a valid offloading
+/// binary format.
+Error extractOffloadFiles(MemoryBufferRef Contents,
+  SmallVectorImpl &Binaries) {
+  uint64_t Offset = 0;
+  // There could be multiple offloading binaries stored at this section.
+  while (Offset < Contents.getBuffer().size()) {
+std::unique_ptr Buffer =
+MemoryBuffer::getMemBuffer(Contents.getBuffer().drop_front(Offset), "",
+   /*RequiresNullTerminator*/ false);
+auto BinaryOrErr = OffloadBinary::create(*Buffer);
+if (!BinaryOrErr)
+  return BinaryOrErr.takeError();
+OffloadBinary &Binary = **BinaryOrErr;
+
+// Create a new owned binary with a copy of the original memory.
+std::unique_ptr BufferCopy = MemoryBuffer::getMemBufferCopy(
+Binary.getData().take_front(Binary.getSize()),
+Contents.getBufferIdentifier());
+auto NewBinaryOrErr = OffloadBinary::create(*BufferCopy);
+if (!NewBinaryOrErr)
+  return NewBinaryOrErr.takeError();
+Binaries.emplace_back(std::move(*NewBinaryOrErr), std::move(BufferCopy));
+
+Offset += Binary.getSize();
+  }
+
+  return Error::success();
+}
+
+// Extract offloading binaries from an Object file \p Obj.
+Error extractFromBinary(const ObjectFile &Obj,
+SmallVectorImpl &Binaries) {
+  for (ELFSectionRef Sec : Obj.sections()) {
+if (Sec.getType() != ELF::SHT_LLVM_OFFLOADING)
+  continue;
+
+Expected Buffer = Sec.getContents();
+if (!Buffer)
+  return Buffer.takeError();
+
+MemoryBufferRef Contents(*Buffer, Obj.getFileName());
+if (Error Err = extractOffloadFiles(Contents, Binaries))
+  return Err;
+  }
+
+  return Error::success();
+}
+
+Error extractFromBitcode(MemoryBufferRef Buffer,
+ SmallVectorImpl &Binaries) {
+  LLVMContext Context;
+  SMDiagnostic Err;
+  std::unique_ptr M = getLazyIRModule(
+  MemoryBuffer::getMemBuffer(Buffer, /*RequiresNullTerminator=*/false), Err,
+  Context);
+  if (!M)
+return createStringError(inconvertibleErrorCode(),
+ "Failed to create module");
+
+  // Extract offloading data from globals referenced by the
+  // `llvm.embedded.object` metadata with the `.llvm.offloading` section.
+  auto *MD = M->getNamedMetadata("llvm.embedded.objects");
+  if (!MD)
+return Error::success();
+
+  for (const MDNode *Op : MD->operands()) {
+if (Op->getNumOperands() < 2)
+  continue;
+
+MDString *SectionID = dyn_cast(Op->getOperand(1));
+if (!SectionID || SectionID->getString() != ".llvm.offloading")
+  continue;
+
+GlobalVariable *GV =
+mdconst::dyn_extract_or_null(Op->getOperand(0));
+if (!GV)
+  continue;
+
+auto *CDS = dyn_cast(GV->getInitializer());
+if (!CDS)
+  continue;
+
+MemoryBufferRef Contents(CDS->getAsString(), M->getName());
+if (Error Err = extractOffloadFiles(Contents, Binaries))
+  return Err;
+  }
+
+  return Error::success();
+}
+
+Error extractFromArchive(const Archive &Library,
+ SmallVectorImpl &Binaries) {
+  // Try to extract device code from each file stored in the static archive.
+  Error Err = Error::success();
+  for (auto Child : Library.children(Err)) {
+auto ChildBufferOrErr = Child.getMemoryBufferRef();
+if (!ChildBufferOrErr)
+  return ChildBufferOrErr.takeError();
+std::uniq

[clang] 5dbc7cf - [Object] Refactor code for extracting offload binaries

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-09-06T08:55:16-05:00
New Revision: 5dbc7cf7cac4428e0876a94a4fca10fe60af7328

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

LOG: [Object] Refactor code for extracting offload binaries

We currently extract offload binaries inside of the linker wrapper.
Other tools may wish to do the same extraction operation. This patch
simply factors out this handling into the `OffloadBinary.h` interface.

Reviewed By: yaxunl

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

Added: 


Modified: 
clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
llvm/include/llvm/Object/OffloadBinary.h
llvm/lib/Object/CMakeLists.txt
llvm/lib/Object/OffloadBinary.cpp

Removed: 




diff  --git a/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp 
b/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
index f9d2c7710c77d..d29c4f93d60f7 100644
--- a/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ b/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -86,22 +86,6 @@ static std::atomic LTOError;
 
 using OffloadingImage = OffloadBinary::OffloadingImage;
 
-/// A class to contain the binary information for a single OffloadBinary.
-class OffloadFile : public OwningBinary {
-public:
-  using TargetID = std::pair;
-
-  OffloadFile(std::unique_ptr Binary,
-  std::unique_ptr Buffer)
-  : OwningBinary(std::move(Binary), std::move(Buffer)) {}
-
-  /// We use the Triple and Architecture pair to group linker inputs together.
-  /// This conversion function lets us use these files in a hash-map.
-  operator TargetID() const {
-return std::make_pair(getBinary()->getTriple(), getBinary()->getArch());
-  }
-};
-
 namespace llvm {
 // Provide DenseMapInfo so that OffloadKind can be used in a DenseMap.
 template <> struct DenseMapInfo {
@@ -162,9 +146,6 @@ const OptTable &getOptTable() {
   return *Table;
 }
 
-Error extractFromBuffer(std::unique_ptr Buffer,
-SmallVectorImpl &DeviceFiles);
-
 void printCommands(ArrayRef CmdArgs) {
   if (CmdArgs.empty())
 return;
@@ -284,150 +265,6 @@ void printVersion(raw_ostream &OS) {
   OS << clang::getClangToolFullVersion("clang-linker-wrapper") << '\n';
 }
 
-/// Attempts to extract all the embedded device images contained inside the
-/// buffer \p Contents. The buffer is expected to contain a valid offloading
-/// binary format.
-Error extractOffloadFiles(MemoryBufferRef Contents,
-  SmallVectorImpl &DeviceFiles) {
-  uint64_t Offset = 0;
-  // There could be multiple offloading binaries stored at this section.
-  while (Offset < Contents.getBuffer().size()) {
-std::unique_ptr Buffer =
-MemoryBuffer::getMemBuffer(Contents.getBuffer().drop_front(Offset), "",
-   /*RequiresNullTerminator*/ false);
-auto BinaryOrErr = OffloadBinary::create(*Buffer);
-if (!BinaryOrErr)
-  return BinaryOrErr.takeError();
-OffloadBinary &Binary = **BinaryOrErr;
-
-// Create a new owned binary with a copy of the original memory.
-std::unique_ptr BufferCopy = MemoryBuffer::getMemBufferCopy(
-Binary.getData().take_front(Binary.getSize()),
-Contents.getBufferIdentifier());
-auto NewBinaryOrErr = OffloadBinary::create(*BufferCopy);
-if (!NewBinaryOrErr)
-  return NewBinaryOrErr.takeError();
-DeviceFiles.emplace_back(std::move(*NewBinaryOrErr), 
std::move(BufferCopy));
-
-Offset += Binary.getSize();
-  }
-
-  return Error::success();
-}
-
-// Extract offloading binaries from an Object file \p Obj.
-Error extractFromBinary(const ObjectFile &Obj,
-SmallVectorImpl &DeviceFiles) {
-  for (ELFSectionRef Sec : Obj.sections()) {
-if (Sec.getType() != ELF::SHT_LLVM_OFFLOADING)
-  continue;
-
-Expected Buffer = Sec.getContents();
-if (!Buffer)
-  return Buffer.takeError();
-
-MemoryBufferRef Contents(*Buffer, Obj.getFileName());
-if (Error Err = extractOffloadFiles(Contents, DeviceFiles))
-  return Err;
-  }
-
-  return Error::success();
-}
-
-Error extractFromBitcode(std::unique_ptr Buffer,
- SmallVectorImpl &DeviceFiles) {
-  LLVMContext Context;
-  SMDiagnostic Err;
-  std::unique_ptr M = getLazyIRModule(std::move(Buffer), Err, Context);
-  if (!M)
-return createStringError(inconvertibleErrorCode(),
- "Failed to create module");
-
-  // Extract offloading data from globals referenced by the
-  // `llvm.embedded.object` metadata with the `.llvm.offloading` section.
-  auto *MD = M->getNamedMetadata("llvm.embedded.objects");
-  if (!MD)
-return Error::success();
-
-  for (const MDNode *Op : MD->operands()) {
-if (Op->getNumOperands() < 2)
-  contin

[clang] a69404c - [OffloadPackager] Add ability to extract images from other file types

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-09-06T08:55:17-05:00
New Revision: a69404c0a294ce65432ce67d5f3e7dce28106496

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

LOG: [OffloadPackager] Add ability to extract images from other file types

A previous patch added support for extracting images from offloading
binaries. Users may wish to extract these files from the file types they
are most commonly emebedded in, such as an ELF or bitcode. This can be
difficult for the user to do manually, as these could be stored in
different section names potentially. This patch addsp support for
extracting these file types.

Reviewed By: saiislam

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

Added: 


Modified: 
clang/test/Driver/offload-packager.c
clang/tools/clang-offload-packager/ClangOffloadPackager.cpp

Removed: 




diff  --git a/clang/test/Driver/offload-packager.c 
b/clang/test/Driver/offload-packager.c
index c4617d06e93d3..8d6ee50f2a190 100644
--- a/clang/test/Driver/offload-packager.c
+++ b/clang/test/Driver/offload-packager.c
@@ -29,3 +29,25 @@
 // RUN: 
diff  *-amdgcn-amd-amdhsa-gfx908.2.o %S/Inputs/dummy-elf.o; rm 
*-amdgcn-amd-amdhsa-gfx908.2.o
 // RUN: 
diff  *-amdgcn-amd-amdhsa-gfx90a.3.o %S/Inputs/dummy-elf.o; rm 
*-amdgcn-amd-amdhsa-gfx90a.3.o
 // RUN: not 
diff  *-amdgcn-amd-amdhsa-gfx90c.4.o %S/Inputs/dummy-elf.o
+
+// Check that we can extract from an ELF object file
+// RUN: clang-offload-packager -o %t.out \
+// RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=openmp,triple=amdgcn-amd-amdhsa,arch=gfx908
 \
+// RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=openmp,triple=nvptx64-nvidia-cuda,arch=sm_70
+// RUN: %clang -cc1 %s -triple x86_64-unknown-linux-gnu -emit-obj -o %t.o 
-fembed-offload-object=%t.out
+// RUN: clang-offload-packager %t.out \
+// RUN:   
--image=file=%t-sm_70.o,kind=openmp,triple=nvptx64-nvidia-cuda,arch=sm_70 \
+// RUN:   
--image=file=%t-gfx908.o,kind=openmp,triple=amdgcn-amd-amdhsa,arch=gfx908
+// RUN: 
diff  %t-sm_70.o %S/Inputs/dummy-elf.o
+// RUN: 
diff  %t-gfx908.o %S/Inputs/dummy-elf.o
+
+// Check that we can extract from a bitcode file
+// RUN: clang-offload-packager -o %t.out \
+// RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=openmp,triple=amdgcn-amd-amdhsa,arch=gfx908
 \
+// RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=openmp,triple=nvptx64-nvidia-cuda,arch=sm_70
+// RUN: %clang -cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -o %t.bc 
-fembed-offload-object=%t.out
+// RUN: clang-offload-packager %t.out \
+// RUN:   
--image=file=%t-sm_70.o,kind=openmp,triple=nvptx64-nvidia-cuda,arch=sm_70 \
+// RUN:   
--image=file=%t-gfx908.o,kind=openmp,triple=amdgcn-amd-amdhsa,arch=gfx908
+// RUN: 
diff  %t-sm_70.o %S/Inputs/dummy-elf.o
+// RUN: 
diff  %t-gfx908.o %S/Inputs/dummy-elf.o

diff  --git a/clang/tools/clang-offload-packager/ClangOffloadPackager.cpp 
b/clang/tools/clang-offload-packager/ClangOffloadPackager.cpp
index c9c722e0a5b5c..47ef155ef2783 100644
--- a/clang/tools/clang-offload-packager/ClangOffloadPackager.cpp
+++ b/clang/tools/clang-offload-packager/ClangOffloadPackager.cpp
@@ -14,8 +14,7 @@
 
 #include "clang/Basic/Version.h"
 
-#include "llvm/Object/Binary.h"
-#include "llvm/Object/ObjectFile.h"
+#include "llvm/BinaryFormat/Magic.h"
 #include "llvm/Object/OffloadBinary.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileOutputBuffer.h"
@@ -123,29 +122,6 @@ static Error bundleImages() {
   return Error::success();
 }
 
-static Expected>>
-extractOffloadFiles(MemoryBufferRef Contents) {
-  if (identify_magic(Contents.getBuffer()) != file_magic::offload_binary)
-return createStringError(inconvertibleErrorCode(),
- "Input buffer not an offloading binary");
-  SmallVector> Binaries;
-  uint64_t Offset = 0;
-  // There could be multiple offloading binaries stored at this section.
-  while (Offset < Contents.getBuffer().size()) {
-std::unique_ptr Buffer =
-MemoryBuffer::getMemBuffer(Contents.getBuffer().drop_front(Offset), "",
-   /*RequiresNullTerminator*/ false);
-auto BinaryOrErr = OffloadBinary::create(*Buffer);
-if (!BinaryOrErr)
-  return BinaryOrErr.takeError();
-
-Offset += (*BinaryOrErr)->getSize();
-Binaries.emplace_back(std::move(*BinaryOrErr));
-  }
-
-  return std::move(Binaries);
-}
-
 static Error unbundleImages() {
   ErrorOr> BufferOrErr =
   MemoryBuffer::getFileOrSTDIN(InputFile);
@@ -159,9 +135,9 @@ static Error unbundleImages() {
 Buffer = MemoryBuffer::getMemBufferCopy(Buffer->getBuffer(),
 Buffer->getBufferIdentifier());
 
-  auto BinariesOrErr = extractOffloadFiles(*Buffer);
-  if (!BinariesOrErr)
-return BinariesOrErr.takeError();

[PATCH] D132607: [OffloadPackager] Add ability to extract images from other file types

[Joseph Huber via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa69404c0a294: [OffloadPackager] Add ability to extract 
images from other file types (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132607

Files:
  clang/test/Driver/offload-packager.c
  clang/tools/clang-offload-packager/ClangOffloadPackager.cpp


Index: clang/tools/clang-offload-packager/ClangOffloadPackager.cpp
===
--- clang/tools/clang-offload-packager/ClangOffloadPackager.cpp
+++ clang/tools/clang-offload-packager/ClangOffloadPackager.cpp
@@ -14,8 +14,7 @@
 
 #include "clang/Basic/Version.h"
 
-#include "llvm/Object/Binary.h"
-#include "llvm/Object/ObjectFile.h"
+#include "llvm/BinaryFormat/Magic.h"
 #include "llvm/Object/OffloadBinary.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileOutputBuffer.h"
@@ -123,29 +122,6 @@
   return Error::success();
 }
 
-static Expected>>
-extractOffloadFiles(MemoryBufferRef Contents) {
-  if (identify_magic(Contents.getBuffer()) != file_magic::offload_binary)
-return createStringError(inconvertibleErrorCode(),
- "Input buffer not an offloading binary");
-  SmallVector> Binaries;
-  uint64_t Offset = 0;
-  // There could be multiple offloading binaries stored at this section.
-  while (Offset < Contents.getBuffer().size()) {
-std::unique_ptr Buffer =
-MemoryBuffer::getMemBuffer(Contents.getBuffer().drop_front(Offset), "",
-   /*RequiresNullTerminator*/ false);
-auto BinaryOrErr = OffloadBinary::create(*Buffer);
-if (!BinaryOrErr)
-  return BinaryOrErr.takeError();
-
-Offset += (*BinaryOrErr)->getSize();
-Binaries.emplace_back(std::move(*BinaryOrErr));
-  }
-
-  return std::move(Binaries);
-}
-
 static Error unbundleImages() {
   ErrorOr> BufferOrErr =
   MemoryBuffer::getFileOrSTDIN(InputFile);
@@ -159,9 +135,9 @@
 Buffer = MemoryBuffer::getMemBufferCopy(Buffer->getBuffer(),
 Buffer->getBufferIdentifier());
 
-  auto BinariesOrErr = extractOffloadFiles(*Buffer);
-  if (!BinariesOrErr)
-return BinariesOrErr.takeError();
+  SmallVector Binaries;
+  if (Error Err = extractOffloadBinaries(*Buffer, Binaries))
+return Err;
 
   // Try to extract each device image specified by the user from the input 
file.
   for (StringRef Image : DeviceImages) {
@@ -169,8 +145,8 @@
 StringSaver Saver(Alloc);
 auto Args = getImageArguments(Image, Saver);
 
-for (uint64_t I = 0, E = BinariesOrErr->size(); I != E; ++I) {
-  const auto &Binary = (*BinariesOrErr)[I];
+for (uint64_t I = 0, E = Binaries.size(); I != E; ++I) {
+  const auto *Binary = Binaries[I].getBinary();
   // We handle the 'file' and 'kind' identifiers differently.
   bool Match = llvm::all_of(Args, [&](auto &Arg) {
 const auto [Key, Value] = Arg;
Index: clang/test/Driver/offload-packager.c
===
--- clang/test/Driver/offload-packager.c
+++ clang/test/Driver/offload-packager.c
@@ -29,3 +29,25 @@
 // RUN: diff *-amdgcn-amd-amdhsa-gfx908.2.o %S/Inputs/dummy-elf.o; rm 
*-amdgcn-amd-amdhsa-gfx908.2.o
 // RUN: diff *-amdgcn-amd-amdhsa-gfx90a.3.o %S/Inputs/dummy-elf.o; rm 
*-amdgcn-amd-amdhsa-gfx90a.3.o
 // RUN: not diff *-amdgcn-amd-amdhsa-gfx90c.4.o %S/Inputs/dummy-elf.o
+
+// Check that we can extract from an ELF object file
+// RUN: clang-offload-packager -o %t.out \
+// RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=openmp,triple=amdgcn-amd-amdhsa,arch=gfx908
 \
+// RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=openmp,triple=nvptx64-nvidia-cuda,arch=sm_70
+// RUN: %clang -cc1 %s -triple x86_64-unknown-linux-gnu -emit-obj -o %t.o 
-fembed-offload-object=%t.out
+// RUN: clang-offload-packager %t.out \
+// RUN:   
--image=file=%t-sm_70.o,kind=openmp,triple=nvptx64-nvidia-cuda,arch=sm_70 \
+// RUN:   
--image=file=%t-gfx908.o,kind=openmp,triple=amdgcn-amd-amdhsa,arch=gfx908
+// RUN: diff %t-sm_70.o %S/Inputs/dummy-elf.o
+// RUN: diff %t-gfx908.o %S/Inputs/dummy-elf.o
+
+// Check that we can extract from a bitcode file
+// RUN: clang-offload-packager -o %t.out \
+// RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=openmp,triple=amdgcn-amd-amdhsa,arch=gfx908
 \
+// RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=openmp,triple=nvptx64-nvidia-cuda,arch=sm_70
+// RUN: %clang -cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -o %t.bc 
-fembed-offload-object=%t.out
+// RUN: clang-offload-packager %t.out \
+// RUN:   
--image=file=%t-sm_70.o,kind=openmp,triple=nvptx64-nvidia-cuda,arch=sm_70 \
+// RUN:   
--image=file=%t-gfx908.o,kind=openmp,triple=amdgcn-amd-amdhsa,arch=gfx908
+// RUN: diff %t-sm_70.o %S/Inputs/dummy-elf.o
+// RUN: diff %t-gfx908.o %S/Inputs/dummy-elf.o


Index: clang/tools/clang-of

[PATCH] D132294: [clang-tidy] Add check of sprintf with fixed size buffer

[方程 via Phabricator via cfe-commits]

Yoorkin added a comment.

I want to enable this check in both c and c++, but didn't find option 
`LangOpt.C`. For c++, we have option `LangOpt.CPlusPlus`. There is only some 
specific c standard option like `C99` `C11` `C17` and `C2X` defined in 
`LangOptions.def`. Could you tell me how to do this?


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

https://reviews.llvm.org/D132294

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

[PATCH] D133354: [Clang]: Diagnose deprecated copy operations also in MSVC compatibility mode

[Julius via Phabricator via cfe-commits]

ningvin created this revision.
ningvin added a reviewer: rsmith.
ningvin added a project: clang.
Herald added a project: All.
ningvin requested review of this revision.
Herald added a subscriber: cfe-commits.

When running in MSVC compatibility mode, previously no deprecated copy 
operation warnings (enabled by `-Wdeprecated-copy`) were raised. This 
restriction was already in place when the deprecated copy warning was first 
introduced 
.

This patch removes said restriction so that deprecated copy warnings, if 
enabled, are also raised in MSVC compatibility mode. The reasoning here being 
that these warnings are still useful when running in MSVC compatibility mode 
and also have to be semi-explicitly enabled in the first place (using 
`-Wdeprecated-copy`, `-Wdeprecated` or `-Wextra`).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133354

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/SemaCXX/deprecated-copy-msvc.cpp


Index: clang/test/SemaCXX/deprecated-copy-msvc.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/deprecated-copy-msvc.cpp
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 %s -std=c++11 %s -Wdeprecated-copy -verify 
-fms-compatibility
+
+struct A {
+  A& operator=(const A&) = default; // expected-warning {{definition of 
implicit copy constructor for 'A' is deprecated because it has a user-declared 
copy assignment operator}}
+};
+
+struct B {
+  B& operator=(const B&) = delete; // expected-warning {{definition of 
implicit copy constructor for 'B' is deprecated because it has a user-declared 
copy assignment operator}}
+};
+
+void test() {
+  A a1;
+  A a2(a1); // expected-note {{implicit copy constructor for 'A' first 
required here}}
+
+  B b1;
+  B b2(b1); // expected-note {{implicit copy constructor for 'B' first 
required here}}
+}
+
+// PR45634
+struct S {
+  int i;
+  S& operator=(const S&) = delete; // expected-warning {{definition of 
implicit copy constructor for 'S' is deprecated because it has a user-declared 
copy assignment operator}}
+};
+
+S test(const S &s) { return S(s); } // expected-note {{implicit copy 
constructor for 'S' first required here}}
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -14429,13 +14429,10 @@
   CXXRecordDecl *RD = CopyOp->getParent();
   CXXMethodDecl *UserDeclaredOperation = nullptr;
 
-  // In Microsoft mode, assignment operations don't affect constructors and
-  // vice versa.
   if (RD->hasUserDeclaredDestructor()) {
 UserDeclaredOperation = RD->getDestructor();
   } else if (!isa(CopyOp) &&
- RD->hasUserDeclaredCopyConstructor() &&
- !S.getLangOpts().MSVCCompat) {
+ RD->hasUserDeclaredCopyConstructor()) {
 // Find any user-declared copy constructor.
 for (auto *I : RD->ctors()) {
   if (I->isCopyConstructor()) {
@@ -14445,8 +14442,7 @@
 }
 assert(UserDeclaredOperation);
   } else if (isa(CopyOp) &&
- RD->hasUserDeclaredCopyAssignment() &&
- !S.getLangOpts().MSVCCompat) {
+ RD->hasUserDeclaredCopyAssignment()) {
 // Find any user-declared move assignment operator.
 for (auto *I : RD->methods()) {
   if (I->isCopyAssignmentOperator()) {


Index: clang/test/SemaCXX/deprecated-copy-msvc.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/deprecated-copy-msvc.cpp
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 %s -std=c++11 %s -Wdeprecated-copy -verify -fms-compatibility
+
+struct A {
+  A& operator=(const A&) = default; // expected-warning {{definition of implicit copy constructor for 'A' is deprecated because it has a user-declared copy assignment operator}}
+};
+
+struct B {
+  B& operator=(const B&) = delete; // expected-warning {{definition of implicit copy constructor for 'B' is deprecated because it has a user-declared copy assignment operator}}
+};
+
+void test() {
+  A a1;
+  A a2(a1); // expected-note {{implicit copy constructor for 'A' first required here}}
+
+  B b1;
+  B b2(b1); // expected-note {{implicit copy constructor for 'B' first required here}}
+}
+
+// PR45634
+struct S {
+  int i;
+  S& operator=(const S&) = delete; // expected-warning {{definition of implicit copy constructor for 'S' is deprecated because it has a user-declared copy assignment operator}}
+};
+
+S test(const S &s) { return S(s); } // expected-note {{implicit copy constructor for 'S' first required here}}
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -14429,13 +14429,10 @@
   CXXRecordDecl *RD = CopyOp->getParent();
   CXXMethodDecl *UserDeclaredOperation = nullptr;
 
-  // In Microsoft mode, assignment opera

[PATCH] D133349: [clang][doc] Do not keep a copy of ClangCommandLineReference.rst in tree

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D133349#3771780 , 
@serge-sans-paille wrote:

> @aaron.ballman this is just a patch to start a discussion: We already have 
> the cmake rule to generate this file, so removing it from tree actually 
> doesn't break compilation. So I'm wondering why and if we should keep it 
> checked in? Removing it would make it less likely for simple minded people 
> like me to edit it (without reading the header warning)

I think it's a good idea to remove it from the tree. We already removed the 
attribute and diagnostic references, both of which are generated files as well. 
When I remove the command line reference locally and do a non-cmake-based build 
(the old `make html`-style of doing local builds) and I get very reasonable 
behavior:

  F:\source\llvm-project\clang\docs>make html
  Running Sphinx v5.0.1
  loading pickled environment... done
  building [mo]: targets for 0 po files that are out of date
  building [html]: targets for 6 source files that are out of date
  updating environment: 0 added, 10 changed, 1 removed
  reading sources... [100%] index
  F:\source\llvm-project\clang\docs\index.rst:16: WARNING: toctree contains 
reference to nonexisting document 'ClangCommandLineReference'
  F:\source\llvm-project\clang\docs\index.rst:16: WARNING: toctree contains 
reference to nonexisting document 'AttributeReference'
  F:\source\llvm-project\clang\docs\index.rst:16: WARNING: toctree contains 
reference to nonexisting document 'DiagnosticsReference'
  looking for now-outdated files... none found
  pickling environment... done
  checking consistency... done
  preparing documents... done
  writing output... [100%] index
  generating indices... genindex done
  writing additional pages... search done
  copying static files... done
  copying extra files... done
  dumping search index in English (code: en)... done
  dumping object inventory... done
  build succeeded, 3 warnings.
  
  The HTML pages are in _build\html.
  
  Build finished. The HTML pages are in _build/html.

Those three links are broken in the local docs, but that's fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133349

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

[PATCH] D133357: [Lex/DependencyDirectivesScanner] Keep track of the presence of tokens between the last scanned directive and EOF

[Argyrios Kyrtzidis via Phabricator via cfe-commits]

akyrtzi created this revision.
Herald added a subscriber: mgorny.
Herald added a project: All.
akyrtzi requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Directive `dependency_directives_scan::tokens_present_before_eof` is introduced 
to indicate there were tokens present before
the last scanned dependency directive and EOF.
This is useful to ensure we correctly identify the macro guards when lexing 
using the dependency directives.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133357

Files:
  clang/include/clang/Lex/DependencyDirectivesScanner.h
  clang/lib/Lex/DependencyDirectivesScanner.cpp
  clang/lib/Lex/Lexer.cpp
  clang/unittests/Lex/CMakeLists.txt
  clang/unittests/Lex/DependencyDirectivesScannerTest.cpp
  clang/unittests/Lex/PPDependencyDirectivesTest.cpp

Index: clang/unittests/Lex/PPDependencyDirectivesTest.cpp
===
--- /dev/null
+++ clang/unittests/Lex/PPDependencyDirectivesTest.cpp
@@ -0,0 +1,150 @@
+//===- unittests/Lex/PPDependencyDirectivesTest.cpp -=//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticOptions.h"
+#include "clang/Basic/FileManager.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TargetInfo.h"
+#include "clang/Basic/TargetOptions.h"
+#include "clang/Lex/DependencyDirectivesScanner.h"
+#include "clang/Lex/HeaderSearch.h"
+#include "clang/Lex/HeaderSearchOptions.h"
+#include "clang/Lex/ModuleLoader.h"
+#include "clang/Lex/Preprocessor.h"
+#include "clang/Lex/PreprocessorOptions.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+
+// The test fixture.
+class PPDependencyDirectivesTest : public ::testing::Test {
+protected:
+  PPDependencyDirectivesTest()
+  : FileMgr(FileMgrOpts), DiagID(new DiagnosticIDs()),
+Diags(DiagID, new DiagnosticOptions, new IgnoringDiagConsumer()),
+SourceMgr(Diags, FileMgr), TargetOpts(new TargetOptions) {
+TargetOpts->Triple = "x86_64-apple-macos12";
+Target = TargetInfo::CreateTargetInfo(Diags, TargetOpts);
+  }
+
+  FileSystemOptions FileMgrOpts;
+  FileManager FileMgr;
+  IntrusiveRefCntPtr DiagID;
+  DiagnosticsEngine Diags;
+  SourceManager SourceMgr;
+  LangOptions LangOpts;
+  std::shared_ptr TargetOpts;
+  IntrusiveRefCntPtr Target;
+};
+
+class IncludeCollector : public PPCallbacks {
+public:
+  Preprocessor &PP;
+  SmallVectorImpl &IncludedFiles;
+
+  IncludeCollector(Preprocessor &PP, SmallVectorImpl &IncludedFiles)
+  : PP(PP), IncludedFiles(IncludedFiles) {}
+
+  void LexedFileChanged(FileID FID, LexedFileChangeReason Reason,
+SrcMgr::CharacteristicKind FileType, FileID PrevFID,
+SourceLocation Loc) override {
+if (Reason != LexedFileChangeReason::EnterFile)
+  return;
+if (FID == PP.getPredefinesFileID())
+  return;
+StringRef Filename =
+PP.getSourceManager().getSLocEntry(FID).getFile().getName();
+IncludedFiles.push_back(Filename);
+  }
+};
+
+TEST_F(PPDependencyDirectivesTest, MacroGuard) {
+  // "head1.h" has a macro guard and should only be included once.
+  // "head2.h" and "head3.h" have tokens following the macro check, they should
+  // be included multiple times.
+
+  auto VFS = new llvm::vfs::InMemoryFileSystem();
+  VFS->addFile(
+  "head1.h", 0,
+  llvm::MemoryBuffer::getMemBuffer("#ifndef H1_H\n#define H1_H\n#endif\n"));
+  VFS->addFile(
+  "head2.h", 0,
+  llvm::MemoryBuffer::getMemBuffer("#ifndef H2_H\n#define H2_H\n#endif\n\n"
+   "extern int foo;\n"));
+  VFS->addFile("head3.h", 0,
+   llvm::MemoryBuffer::getMemBuffer(
+   "#ifndef H3_H\n#define H3_H\n#endif\n\n"
+   "#ifdef SOMEMAC\nextern int foo;\n#endif\n"));
+  VFS->addFile("main.c", 0,
+   llvm::MemoryBuffer::getMemBuffer(
+   "#include \"head1.h\"\n#include \"head1.h\"\n"
+   "#include \"head2.h\"\n#include \"head2.h\"\n"
+   "#include \"head3.h\"\n#include \"head3.h\"\n"));
+  FileMgr.setVirtualFileSystem(VFS);
+
+  Optional FE;
+  ASSERT_THAT_ERROR(FileMgr.getFileRef("main.c").moveInto(FE),
+llvm::Succeeded());
+  SourceMgr.setMainFileID(
+  SourceMgr.createFileID(*FE, SourceLocation(), SrcMgr::C_User));
+
+  struct DepDirectives {
+SmallVector Tokens;
+SmallVector Directives;
+  };
+  SmallVector> DepDirectivesObjects;
+
+  auto getDependencyDirectives = [&](FileEntryRef File)
+

[PATCH] D133357: [Lex/DependencyDirectivesScanner] Keep track of the presence of tokens between the last scanned directive and EOF

[Argyrios Kyrtzidis via Phabricator via cfe-commits]

akyrtzi updated this revision to Diff 458173.
akyrtzi added a comment.

Remove a couple of unused local variables.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133357

Files:
  clang/include/clang/Lex/DependencyDirectivesScanner.h
  clang/lib/Lex/DependencyDirectivesScanner.cpp
  clang/lib/Lex/Lexer.cpp
  clang/unittests/Lex/CMakeLists.txt
  clang/unittests/Lex/DependencyDirectivesScannerTest.cpp
  clang/unittests/Lex/PPDependencyDirectivesTest.cpp

Index: clang/unittests/Lex/PPDependencyDirectivesTest.cpp
===
--- /dev/null
+++ clang/unittests/Lex/PPDependencyDirectivesTest.cpp
@@ -0,0 +1,148 @@
+//===- unittests/Lex/PPDependencyDirectivesTest.cpp -=//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticOptions.h"
+#include "clang/Basic/FileManager.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Basic/TargetInfo.h"
+#include "clang/Basic/TargetOptions.h"
+#include "clang/Lex/DependencyDirectivesScanner.h"
+#include "clang/Lex/HeaderSearch.h"
+#include "clang/Lex/HeaderSearchOptions.h"
+#include "clang/Lex/ModuleLoader.h"
+#include "clang/Lex/Preprocessor.h"
+#include "clang/Lex/PreprocessorOptions.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+
+// The test fixture.
+class PPDependencyDirectivesTest : public ::testing::Test {
+protected:
+  PPDependencyDirectivesTest()
+  : FileMgr(FileMgrOpts), DiagID(new DiagnosticIDs()),
+Diags(DiagID, new DiagnosticOptions, new IgnoringDiagConsumer()),
+SourceMgr(Diags, FileMgr), TargetOpts(new TargetOptions) {
+TargetOpts->Triple = "x86_64-apple-macos12";
+Target = TargetInfo::CreateTargetInfo(Diags, TargetOpts);
+  }
+
+  FileSystemOptions FileMgrOpts;
+  FileManager FileMgr;
+  IntrusiveRefCntPtr DiagID;
+  DiagnosticsEngine Diags;
+  SourceManager SourceMgr;
+  LangOptions LangOpts;
+  std::shared_ptr TargetOpts;
+  IntrusiveRefCntPtr Target;
+};
+
+class IncludeCollector : public PPCallbacks {
+public:
+  Preprocessor &PP;
+  SmallVectorImpl &IncludedFiles;
+
+  IncludeCollector(Preprocessor &PP, SmallVectorImpl &IncludedFiles)
+  : PP(PP), IncludedFiles(IncludedFiles) {}
+
+  void LexedFileChanged(FileID FID, LexedFileChangeReason Reason,
+SrcMgr::CharacteristicKind FileType, FileID PrevFID,
+SourceLocation Loc) override {
+if (Reason != LexedFileChangeReason::EnterFile)
+  return;
+if (FID == PP.getPredefinesFileID())
+  return;
+StringRef Filename =
+PP.getSourceManager().getSLocEntry(FID).getFile().getName();
+IncludedFiles.push_back(Filename);
+  }
+};
+
+TEST_F(PPDependencyDirectivesTest, MacroGuard) {
+  // "head1.h" has a macro guard and should only be included once.
+  // "head2.h" and "head3.h" have tokens following the macro check, they should
+  // be included multiple times.
+
+  auto VFS = new llvm::vfs::InMemoryFileSystem();
+  VFS->addFile(
+  "head1.h", 0,
+  llvm::MemoryBuffer::getMemBuffer("#ifndef H1_H\n#define H1_H\n#endif\n"));
+  VFS->addFile(
+  "head2.h", 0,
+  llvm::MemoryBuffer::getMemBuffer("#ifndef H2_H\n#define H2_H\n#endif\n\n"
+   "extern int foo;\n"));
+  VFS->addFile("head3.h", 0,
+   llvm::MemoryBuffer::getMemBuffer(
+   "#ifndef H3_H\n#define H3_H\n#endif\n\n"
+   "#ifdef SOMEMAC\nextern int foo;\n#endif\n"));
+  VFS->addFile("main.c", 0,
+   llvm::MemoryBuffer::getMemBuffer(
+   "#include \"head1.h\"\n#include \"head1.h\"\n"
+   "#include \"head2.h\"\n#include \"head2.h\"\n"
+   "#include \"head3.h\"\n#include \"head3.h\"\n"));
+  FileMgr.setVirtualFileSystem(VFS);
+
+  Optional FE;
+  ASSERT_THAT_ERROR(FileMgr.getFileRef("main.c").moveInto(FE),
+llvm::Succeeded());
+  SourceMgr.setMainFileID(
+  SourceMgr.createFileID(*FE, SourceLocation(), SrcMgr::C_User));
+
+  struct DepDirectives {
+SmallVector Tokens;
+SmallVector Directives;
+  };
+  SmallVector> DepDirectivesObjects;
+
+  auto getDependencyDirectives = [&](FileEntryRef File)
+  -> Optional> {
+DepDirectivesObjects.push_back(std::make_unique());
+StringRef Input = (*FileMgr.getBufferForFile(File))->getBuffer();
+bool Err = scanSourceForDependencyDirectives(
+Input, DepDirectivesObjects.back()->Tokens,
+DepDirectivesObjects.back()->Directives);
+EX

[PATCH] D133358: [compiler-rt] [test] Handle missing ld.gold gracefully

[Michał Górny via Phabricator via cfe-commits]

mgorny created this revision.
mgorny added reviewers: MaskRay, myhsu, vsk.
Herald added subscribers: Enna1, StephenFan, dberris.
Herald added a project: All.
mgorny requested review of this revision.

Fix the is_binutils_lto_supported() function to handle missing
executables gracefully.  Currently, the function does not catch
exceptions from subprocess.Popen() and therefore causes lit to crash
if config.gold_executable does not specify a valid executable:

  lit: /usr/lib/python3.11/site-packages/lit/TestingConfig.py:136: fatal: 
unable to parse config file '/tmp/portage/sys-libs/compiler-rt-
  15.0.0/work/compiler-rt/test/lit.common.cfg.py', traceback: Traceback (most 
recent call last):
File "/usr/lib/python3.11/site-packages/lit/TestingConfig.py", line 125, in 
load_from_path
  exec(compile(data, path, 'exec'), cfg_globals, None)
File 
"/tmp/portage/sys-libs/compiler-rt-15.0.0/work/compiler-rt/test/lit.common.cfg.py",
 line 561, in 
  if is_binutils_lto_supported():
 ^^^
File 
"/tmp/portage/sys-libs/compiler-rt-15.0.0/work/compiler-rt/test/lit.common.cfg.py",
 line 543, in is_binutils_lto_supported
  ld_cmd = subprocess.Popen([exe, '--help'], stdout=subprocess.PIPE, 
env={'LANG': 'C'})
   

File "/usr/lib/python3.11/subprocess.py", line 1022, in __init__
  self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.11/subprocess.py", line 1899, in _execute_child
  raise child_exception_type(errno_num, err_msg, err_filename)
  FileNotFoundError: [Errno 2] No such file or directory: 
'GOLD_EXECUTABLE-NOTFOUND'


https://reviews.llvm.org/D133358

Files:
  compiler-rt/test/lit.common.cfg.py


Index: compiler-rt/test/lit.common.cfg.py
===
--- compiler-rt/test/lit.common.cfg.py
+++ compiler-rt/test/lit.common.cfg.py
@@ -538,9 +538,12 @@
   # We require both ld.bfd and ld.gold exist and support plugins. They are in
   # the same repository 'binutils-gdb' and usually built together.
   for exe in (config.gnu_ld_executable, config.gold_executable):
-ld_cmd = subprocess.Popen([exe, '--help'], stdout=subprocess.PIPE, 
env={'LANG': 'C'})
-ld_out = ld_cmd.stdout.read().decode()
-ld_cmd.wait()
+try:
+  ld_cmd = subprocess.Popen([exe, '--help'], stdout=subprocess.PIPE, 
env={'LANG': 'C'})
+  ld_out = ld_cmd.stdout.read().decode()
+  ld_cmd.wait()
+except OSError:
+  return False
 if not '-plugin' in ld_out:
   return False
 


Index: compiler-rt/test/lit.common.cfg.py
===
--- compiler-rt/test/lit.common.cfg.py
+++ compiler-rt/test/lit.common.cfg.py
@@ -538,9 +538,12 @@
   # We require both ld.bfd and ld.gold exist and support plugins. They are in
   # the same repository 'binutils-gdb' and usually built together.
   for exe in (config.gnu_ld_executable, config.gold_executable):
-ld_cmd = subprocess.Popen([exe, '--help'], stdout=subprocess.PIPE, env={'LANG': 'C'})
-ld_out = ld_cmd.stdout.read().decode()
-ld_cmd.wait()
+try:
+  ld_cmd = subprocess.Popen([exe, '--help'], stdout=subprocess.PIPE, env={'LANG': 'C'})
+  ld_out = ld_cmd.stdout.read().decode()
+  ld_cmd.wait()
+except OSError:
+  return False
 if not '-plugin' in ld_out:
   return False
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133358: [compiler-rt] [test] Handle missing ld.gold gracefully

[Michał Górny via Phabricator via cfe-commits]

mgorny added a comment.

After reviewing this, please also approve backport to 15.x in 
https://github.com/llvm/llvm-project/issues/57580.


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

https://reviews.llvm.org/D133358

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

[PATCH] D132131: [clang-format] Adds a formatter for aligning trailing comments over empty lines

[Yusuke Kadowaki via Phabricator via cfe-commits]

yusuke-kadowaki updated this revision to Diff 458176.
yusuke-kadowaki marked 7 inline comments as done.
yusuke-kadowaki added a comment.

- Introduce new struct
- Update document

This change should be ok for everyone (I hope). BTW, please correct my English 
if any or create a whole new one for me since I'm not so sure what I wrote 
delivers well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132131

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/WhitespaceManager.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/FormatTestComments.cpp

Index: clang/unittests/Format/FormatTestComments.cpp
===
--- clang/unittests/Format/FormatTestComments.cpp
+++ clang/unittests/Format/FormatTestComments.cpp
@@ -2858,6 +2858,182 @@
"int a; //\n");
 }
 
+TEST_F(FormatTestComments, AlignTrailingCommentsAcrossEmptyLines) {
+  FormatStyle Style = getLLVMStyle();
+  Style.AlignTrailingComments = FormatStyle::TCAS_AlignAcrossEmptyLines;
+  verifyFormat("#include \"a.h\"  // simple\n"
+   "\n"
+   "#include \"aa.h\" // example case\n",
+   Style);
+
+  verifyFormat("#include \"a.h\"   // align across\n"
+   "\n"
+   "#include \"aa.h\"  // two empty lines\n"
+   "\n"
+   "#include \"aaa.h\" // in a row\n",
+   Style);
+
+  verifyFormat("#include \"a.h\"  // align\n"
+   "#include \"aa.h\" // comment\n"
+   "#include \"aaa.h\"// blocks\n"
+   "\n"
+   "#include \".h\"   // across\n"
+   "#include \"a.h\"  // one\n"
+   "#include \"aa.h\" // empty line\n",
+   Style);
+
+  verifyFormat("#include \"a.h\"  // align trailing comments\n"
+   "#include \"a.h\"\n"
+   "#include \"aa.h\" // across a line without comment\n",
+   Style);
+
+  verifyFormat("#include \"a.h\"   // align across\n"
+   "#include \"a.h\"\n"
+   "#include \"aa.h\"  // two lines without comment\n"
+   "#include \"a.h\"\n"
+   "#include \"aaa.h\" // in a row\n",
+   Style);
+
+  verifyFormat("#include \"a.h\"  // align\n"
+   "#include \"aa.h\" // comment\n"
+   "#include \"aaa.h\"// blocks\n"
+   "#include \"a.h\"\n"
+   "#include \".h\"   // across\n"
+   "#include \"a.h\"  // a line without\n"
+   "#include \"aa.h\" // comment\n",
+   Style);
+
+  // Start of testing the combination with MaxEmptyLinesToKeep
+  Style.MaxEmptyLinesToKeep = 0;
+  verifyFormat("#include \"a.h\"  // comment\n"
+   "#include \"aa.h\" // comment\n",
+   Style);
+
+  Style.MaxEmptyLinesToKeep = 1;
+  verifyFormat("#include \"a.h\"  // comment\n"
+   "\n"
+   "#include \"aa.h\" // comment\n",
+   Style);
+
+  Style.MaxEmptyLinesToKeep = 2;
+  verifyFormat("#include \"a.h\"  // comment\n"
+   "\n"
+   "\n"
+   "#include \"aa.h\" // comment\n",
+   Style);
+
+  // Reset the setting
+  Style.MaxEmptyLinesToKeep = 1;
+  // End of testing the combination with MaxEmptyLinesToKeep
+
+  Style.ColumnLimit = 15;
+  EXPECT_EQ("int ab; // line\n"
+"int a;  // long\n"
+"// long\n"
+"\n"
+"// long",
+format("int ab; // line\n"
+   "int a; // long long\n"
+   "\n"
+   "// long",
+   Style));
+
+  Style.ColumnLimit = 15;
+  EXPECT_EQ("int ab; // line\n"
+"\n"
+"int a;  // long\n"
+"// long\n",
+format("int ab; // line\n"
+   "\n"
+   "int a; // long long\n",
+   Style));
+
+  Style.ColumnLimit = 30;
+  EXPECT_EQ("int foo = 12345; // comment\n"
+"int bar =\n"
+"1234;  // This is a very\n"
+"   // long comment\n"
+"   // which is wrapped\n"
+"   // arround.\n"
+"\n"
+"int x = 2; // Is this still\n"
+"   // aligned?\n",
+format("int foo = 12345; // comment\n"
+   "int bar = 1234; // This is a very long comment\n"
+   "// which is wrapped arround.\n"
+   "\n"
+   "int x = 2; // Is this still aligned?\n",
+   Style));
+
+  Style.ColumnLimit = 35;
+  EXPECT_EQ("int foo = 12345; // comment\n"
+"int bar =\n"
+"1234; // This is a very l

[PATCH] D131469: [Clang] change default storing path of `-ftime-trace`

[dongjunduo via Phabricator via cfe-commits]

dongjunduo updated this revision to Diff 458177.
dongjunduo added a comment.

Rewrite test by checking output of -###


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131469

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/check-time-trace.cpp
  clang/tools/driver/cc1_main.cpp

Index: clang/tools/driver/cc1_main.cpp
===
--- clang/tools/driver/cc1_main.cpp
+++ clang/tools/driver/cc1_main.cpp
@@ -256,17 +256,10 @@
   llvm::TimerGroup::clearAll();
 
   if (llvm::timeTraceProfilerEnabled()) {
-SmallString<128> Path(Clang->getFrontendOpts().OutputFile);
-llvm::sys::path::replace_extension(Path, "json");
-if (!Clang->getFrontendOpts().TimeTracePath.empty()) {
-  // replace the suffix to '.json' directly
-  SmallString<128> TracePath(Clang->getFrontendOpts().TimeTracePath);
-  if (llvm::sys::fs::is_directory(TracePath))
-llvm::sys::path::append(TracePath, llvm::sys::path::filename(Path));
-  Path.assign(TracePath);
-}
+SmallString<128> TracePath(Clang->getFrontendOpts().TimeTracePath);
+assert(!TracePath.empty() && "`-ftime-trace=` is empty");
 if (auto profilerOutput = Clang->createOutputFile(
-Path.str(), /*Binary=*/false, /*RemoveFileOnSignal=*/false,
+TracePath.str(), /*Binary=*/false, /*RemoveFileOnSignal=*/false,
 /*useTemporary=*/false)) {
   llvm::timeTraceProfilerWrite(*profilerOutput);
   profilerOutput.reset();
Index: clang/test/Driver/check-time-trace.cpp
===
--- clang/test/Driver/check-time-trace.cpp
+++ clang/test/Driver/check-time-trace.cpp
@@ -1,3 +1,6 @@
+// RUN: rm -rf %T/exe && mkdir %T/exe
+// RUN: %clangxx -### -ftime-trace -ftime-trace-granularity=0 -o %T/exe/check-time-trace %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-OPT %s
 // RUN: %clangxx -S -ftime-trace -ftime-trace-granularity=0 -o %T/check-time-trace %s
 // RUN: cat %T/check-time-trace.json \
 // RUN:   | %python -c 'import json, sys; json.dump(json.loads(sys.stdin.read()), sys.stdout, sort_keys=True, indent=2)' \
@@ -17,6 +20,7 @@
 // RUN:   | %python -c 'import json, sys; json.dump(json.loads(sys.stdin.read()), sys.stdout, sort_keys=True, indent=2)' \
 // RUN:   | FileCheck %s
 
+// CHECK-OPT:  "-ftime-trace={{.*}}/exe/check-time-trace{{.*}}.json"
 // CHECK:  "beginningOfTime": {{[0-9]{16},}}
 // CHECK-NEXT: "traceEvents": [
 // CHECK:  "args":
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -4510,6 +4510,102 @@
   llvm_unreachable("invalid phase in ConstructPhaseAction");
 }
 
+// Infer data storing path of the options `-ftime-trace`, `-ftime-trace=`
+void InferTimeTracePath(Compilation &C) {
+  bool HasTimeTrace =
+  C.getArgs().getLastArg(options::OPT_ftime_trace) != nullptr;
+  bool HasTimeTraceFile =
+  C.getArgs().getLastArg(options::OPT_ftime_trace_EQ) != nullptr;
+  // Whether `-ftime-trace` or `-ftime-trace=` are specified
+  if (!HasTimeTrace && !HasTimeTraceFile)
+return;
+
+  // If `-ftime-trace=` is specified, TracePath is the .
+  // Else if there is a linking job, TracePath is the parent path of .exe,
+  // then the OutputFile's name may be appended to it.
+  // Else, TracePath is "",
+  // then the full OutputFile's path may be appended to it.
+  SmallString<128> TracePath("");
+
+  if (HasTimeTraceFile) {
+TracePath = SmallString<128>(
+C.getArgs().getLastArg(options::OPT_ftime_trace_EQ)->getValue());
+  } else {
+// Get linking executable file's parent path as TracePath's parent path,
+// default is ".". Filename may be determined and added into TracePath then.
+//
+// e.g. executable file's path: /usr/local/a.out
+//  its parent's path:  /usr/local
+for (auto &J : C.getJobs()) {
+  if (J.getSource().getKind() == Action::LinkJobClass) {
+assert(!J.getOutputFilenames().empty() &&
+   "linking output filename is empty");
+auto OutputFilePath =
+SmallString<128>(J.getOutputFilenames()[0].c_str());
+if (llvm::sys::path::has_parent_path(OutputFilePath)) {
+  TracePath = llvm::sys::path::parent_path(OutputFilePath);
+} else {
+  TracePath = SmallString<128>(".");
+}
+break;
+  }
+}
+  }
+
+  // Add or replace the modified -ftime-trace=` to all clang jobs
+  for (auto &J : C.getJobs()) {
+if (J.getSource().getKind() == Action::AssembleJobClass ||
+J.getSource().getKind() == Action::BackendJobClass ||
+J.getSource().getKind() == Action::CompileJobClass) {
+  SmallString<128> TracePathReal = TracePath;
+  SmallString<128> OutputPath(J.getOutputFilenames()[0].c_str());
+  st

[PATCH] D132131: [clang-format] Adds a formatter for aligning trailing comments over empty lines

[Yusuke Kadowaki via Phabricator via cfe-commits]

yusuke-kadowaki added inline comments.



Comment at: clang/unittests/Format/FormatTestComments.cpp:2930
+  Style.ColumnLimit = 15;
+  EXPECT_EQ("int ab; // line\n"
+"int a;  // long\n"

MyDeveloperDay wrote:
> Why not verifyFormat here too and below?
To test the ColumnLimit behavior.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132131

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

[PATCH] D127284: [clang-repl] Support statements on global scope in incremental mode.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/ASTConsumer.h:54-59
+  /// HandleTopLevelStmts - Handle the specified top-level statements. This is
+  /// called by the parser to process every top-level Stmt* in incremental
+  /// compilation mode.
+  ///
+  /// \returns true to continue parsing, or false to abort parsing.
+  virtual bool HandleTopLevelStmts(const llvm::SmallVectorImpl &Stmts) 
{

v.g.vassilev wrote:
> aaron.ballman wrote:
> > In C and C++, the only thing that's at file scope (that the parser sees) 
> > are declarations, not statements, so the phrasing here seems off. I suspect 
> > this is because you don't *know* you're only going to get declarations 
> > (because it could be that we're trying to parse in the context of an 
> > imaginary function body)? If so, perhaps the comments could be updated to 
> > clarify that.
> I am a bit confused. Could you clarify what wording changes you had in mind?
It wasn't clear to me whether this was misnamed  (`HandleTopLevelDecls()`) or 
whether the comments didn't make it clear that this is actually "statements 
and/or declarations and we don't know whether they're at file scope or not."



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:5107-5111
+  static unsigned id = 0;
+  ASTContext &C = getContext();
+  TranslationUnitDecl *TUDecl = C.getTranslationUnitDecl();
+
+  IdentifierInfo *name = &C.Idents.get("_stmts" + std::to_string(id++));

v.g.vassilev wrote:
> aaron.ballman wrote:
> > You should fix the other identifiers in this function to match the usual 
> > coding style.
> I have not paid too much attention in the coding style here as it was mostly 
> for initiating a design discussion.
> 
> The body of this function breaks the design of clang which assumes AST to be 
> created by the frontend and be essentially immutable in `CodeGen`. This 
> `FunctionDecl` needs to be treated as a global initializer. That is, it needs 
> to be run in a particular order to the other initializer following the 
> lexical occurrence of the statement block. That leaves us with two options, 
> either to expose the registration of global initializers outside of CodeGen, 
> or we need to create that here.
> 
> Alternatively, we could make `HandleTopLevelStmts` take a `FunctionDecl` and 
> we can create it in the `IncrementalParser`. That blurs the responsibility 
> and coherence of the interfaces. We will have public interface 
> `HandleTopLevelStmts` (or similar) which handles top-level statements but 
> take a `FunctionDecl` as a parameter which is created by the user...
> I have not paid too much attention in the coding style here as it was mostly 
> for initiating a design discussion.

No worries, so long as you run clang-format over the patch before landing, 
it'll be fine.

> either to expose the registration of global initializers outside of CodeGen, 
> or we need to create that here.

Ideally, this should be generated outside of CodeGen. It seems to me that this 
could perhaps be done once the TU has finished but before codegen has started 
(in `ActOnEndOfTranslationUnit()` or `ActOnEndOfTranslationUnitFragment()`)?



Comment at: clang/lib/Parse/ParseTentative.cpp:54
+case tok::semi:
+  return true; // Not a stmt but can be extra terminator in `namespace{};`
+case tok::kw_template:

v.g.vassilev wrote:
> aaron.ballman wrote:
> > http://eel.is/c++draft/dcl.dcl#nt:empty-declaration
> IIUC, clang models the `;` as a `NullStmt`.
That depends on where the `;` is: https://godbolt.org/z/Kz9zjjKoe



Comment at: clang/lib/Parse/Parser.cpp:729-730
 
+  // FIXME: Remove the incremental processing pre-condition and verify clang
+  // still can pass its test suite, which will harden `isDeclarationStatement`.
+  // Parse a block of top-level-stmts.

v.g.vassilev wrote:
> aaron.ballman wrote:
> > How close are we to having this fixme fixed?
> 2000 tests away. The tests are mostly in OpenCL, OpenMP, etc, which just need 
> adding more entries in places such as `isCXXDeclarationSpecifier`. I've 
> decided to keep the patch small and then add that once we merge this one.
LOL, okay, so a ways away still. :-D



Comment at: clang/test/Interpreter/disambiguate-decl-stmt.cpp:28-33
+namespace Ns {namespace Ns { void Ns(); void Fs();}}
+void Ns::Ns::Ns() { printf("void Ns::Ns::Ns()\n"); }
+void Ns::Ns::Fs() {}
+
+Ns::Ns::Fs();
+Ns::Ns::Ns();

v.g.vassilev wrote:
> aaron.ballman wrote:
> > This behavior is very confusing to me -- you cannot declare a namespace at 
> > function scope and you cannot call a function at file scope, so one of 
> > these two seems like it should not work.
> > 
> > (Same kinds of confusion happen elsewhere in the tests.)
> The mental model has been that we have a mix of statements and declarations 
> on the global scope. The sequence of statements are only c

[PATCH] D131469: [Clang] change default storing path of `-ftime-trace`

[dongjunduo via Phabricator via cfe-commits]

dongjunduo added a comment.

@dyung @steven_wu A newer diff has been submitted just now.

Agree with @dyung. The test has been changed into checking the output of "-###".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131469

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Precomit CI found valid failures that seem plausibly related to your changes, 
but Windows and Debian found different failures which is a bit of a surprise to 
me. Can you check those?




Comment at: clang/test/lit.site.cfg.py.in:27
 config.clang_enable_opaque_pointers = @CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL@
+config.clang_default_std_cxx = "@CLANG_DEFAULT_STD_CXX@"
 config.clang_default_cxx_stdlib = "@CLANG_DEFAULT_CXX_STDLIB@"

Should we add some documentation for this in a follow-up? (I know 
`CLANG_DEFAULT_STD_CXX` already exists, but it seems like it'd be helpful to 
tell users about it too.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D132952: [Sema] disable -Wvla for function array parameters

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/Sema/warn-vla.c:8-12
+void test2(int n, int v[n]) { // c99 no-warning
+#if __STDC_VERSION__ < 199901L
+// expected-warning@-2{{variable length arrays are a C99 feature}}
+#endif
 }

inclyc wrote:
> aaron.ballman wrote:
> > The diagnostic there is rather unfortunate because we're not using a 
> > variable-length array in this case.
> Emm, I'm not clear about whether we should consider this a VLA, and generates 
> `-Wvla-extensions`. Is `v[n]` literally a variable-length array? (in source 
> code) So it seems to me that we should still report c89 incompatibility 
> warnings?
> 
C89's grammar only allowed for an integer constant expression to (optionally) 
appear as the array extent in an array declarator, so there is a compatibility 
warning needed for that. But I don't think we should issue a warning about this 
being a VLA in C99 or later. The array *is* a VLA in terms of the form written 
in the source, but C adjusts the parameter to be a pointer parameter, so as far 
as the function's type is concerned, it's not a VLA (it's just a 
self-documenting interface).

Because self-documenting code is nice and because people are worried about 
accidental use of VLAs that cause stack allocations (which this does not), I 
think we don't want to scare people off from this construct. But I'm curious 
what others think as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132952

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

[PATCH] D132952: [Sema] disable -Wvla for function array parameters

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/Sema/warn-vla.c:8-12
+void test2(int n, int v[n]) { // c99 no-warning
+#if __STDC_VERSION__ < 199901L
+// expected-warning@-2{{variable length arrays are a C99 feature}}
+#endif
 }

aaron.ballman wrote:
> inclyc wrote:
> > aaron.ballman wrote:
> > > The diagnostic there is rather unfortunate because we're not using a 
> > > variable-length array in this case.
> > Emm, I'm not clear about whether we should consider this a VLA, and 
> > generates `-Wvla-extensions`. Is `v[n]` literally a variable-length array? 
> > (in source code) So it seems to me that we should still report c89 
> > incompatibility warnings?
> > 
> C89's grammar only allowed for an integer constant expression to (optionally) 
> appear as the array extent in an array declarator, so there is a 
> compatibility warning needed for that. But I don't think we should issue a 
> warning about this being a VLA in C99 or later. The array *is* a VLA in terms 
> of the form written in the source, but C adjusts the parameter to be a 
> pointer parameter, so as far as the function's type is concerned, it's not a 
> VLA (it's just a self-documenting interface).
> 
> Because self-documenting code is nice and because people are worried about 
> accidental use of VLAs that cause stack allocations (which this does not), I 
> think we don't want to scare people off from this construct. But I'm curious 
> what others think as well.
> But I'm curious what others think as well.

(Specifically, I'm wondering if others agree that the only warning that should 
be issued there is a C89 compatibility warning under `-Wvla-extensions` when in 
C89 mode and via a new `CPre99Compat` diagnostic group when enabled in C99 and 
later modes.)




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132952

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

[PATCH] D132192: [RISCV] Add '32bit' feature to rv32 only builtins.

[Kito Cheng via Phabricator via cfe-commits]

kito-cheng accepted this revision.
kito-cheng added a comment.
This revision is now accepted and ready to land.

LGTM, and +1 for the error message improvement, but could be separated patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132192

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

[PATCH] D132779: Enforce module decl-use restrictions and private header restrictions in textual headers

[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 with a suggestion to also document the command line reference. Thanks!




Comment at: clang/include/clang/Driver/Options.td:2290
+  
MarshallingInfoNegativeFlag>,
+  HelpText<"Do not enforce -fmodules-decluse and private header restrictions 
for textual headers.">;
 




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132779

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

[PATCH] D132977: [HLSL] Call global constructors inside entry

[Chris Bieneman via Phabricator via cfe-commits]

beanz added inline comments.



Comment at: clang/lib/CodeGen/CGHLSLRuntime.cpp:151
+  llvm::Module &M = CGM.getModule();
+  const auto *GlobalCtors = M.getNamedGlobal("llvm.global_ctors");
+  if (!GlobalCtors)

python3kgae wrote:
> beanz wrote:
> > python3kgae wrote:
> > > Don't need to generate CtorCalls for lib profile in clang codeGen.
> > > Have to do this when linking anyway.
> > Are you sure? The global constructors contain the `createHandle` calls for 
> > resources, and DXC does currently generate those inside shader entries for 
> > lib shaders.
> > 
> > I'm sure we're not generating those _correctly_ with this change, but I 
> > think we still need the constructor calls inside any function annotated 
> > with the `[shader(...)]` attribute.
> I saw dxc did call ctor for all entries. Maybe to match the behavior, we need 
> to do the same thing.
> But I don't understand why we must do that except to match what dxc does.
> Maybe we can also have a test for lib profile to make understanding things 
> easier?
I can (and should) add a library shader test too.

In addition to the cases where DXC generates global constructors, we need them 
in clang in more cases, because I'm using global constructors to reduce the 
scope of changes HLSL needs in CodeGen.

In the case of global resource variables (as shown in the test in this PR), DXC 
generates the handle creation calls with a bunch of custom code in clang 
CodeGen, and inserts that code into the entry functions.

To avoid needing special code for handle creation in Clang, I've put handle 
creation calls inside the constructors for the resource object. For global 
definitions, the constructors then get called by the global initialization 
function automatically, which we can inline into the entry.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132977

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

[PATCH] D130096: [Clang][AMDGPU] Emit AMDGPU library control constants in clang

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 458186.
jhuber6 added a comment.

Changing to `linkonce` linkage. According to the LLVM spec this should have the
expected behaviour where a single definition is kept at link-time for each
module. I tested this with a sample `HIP` program and it had the desired
behaviour. I could add a test attempting to show this if needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130096

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/test/CodeGen/amdgcn-control-constants.c

Index: clang/test/CodeGen/amdgcn-control-constants.c
===
--- /dev/null
+++ clang/test/CodeGen/amdgcn-control-constants.c
@@ -0,0 +1,49 @@
+// Check that we generate all the expected default features for the target.
+// RUN: %clang_cc1 -x hip -triple amdgcn-amd-amdhsa -target-cpu gfx90a -S -emit-llvm -o - %s | FileCheck %s --check-prefix=GFX90A
+// RUN: %clang_cc1 -x hip -triple amdgcn-amd-amdhsa -target-cpu gfx1030 -S -emit-llvm -o - %s | FileCheck %s --check-prefix=GFX1030
+
+// GFX90A: @__oclc_wavefrontsize64 = linkonce hidden local_unnamed_addr addrspace(4) constant i8 1
+// GFX90A: @__oclc_daz_opt = linkonce hidden local_unnamed_addr addrspace(4) constant i8 0
+// GFX90A: @__oclc_finite_only_opt = linkonce hidden local_unnamed_addr addrspace(4) constant i8 0
+// GFX90A: @__oclc_unsafe_math_opt = linkonce hidden local_unnamed_addr addrspace(4) constant i8 0
+// GFX90A: @__oclc_correctly_rounded_sqrt32 = linkonce hidden local_unnamed_addr addrspace(4) constant i8 1
+// GFX90A: @__oclc_ISA_version = linkonce hidden local_unnamed_addr addrspace(4) constant i32 9010
+// GFX90A: @__oclc_ABI_version = linkonce hidden local_unnamed_addr addrspace(4) constant i32 400
+
+// GFX1030: @__oclc_wavefrontsize64 = linkonce hidden local_unnamed_addr addrspace(4) constant i8 0
+// GFX1030: @__oclc_daz_opt = linkonce hidden local_unnamed_addr addrspace(4) constant i8 0
+// GFX1030: @__oclc_finite_only_opt = linkonce hidden local_unnamed_addr addrspace(4) constant i8 0
+// GFX1030: @__oclc_unsafe_math_opt = linkonce hidden local_unnamed_addr addrspace(4) constant i8 0
+// GFX1030: @__oclc_correctly_rounded_sqrt32 = linkonce hidden local_unnamed_addr addrspace(4) constant i8 1
+// GFX1030: @__oclc_ISA_version = linkonce hidden local_unnamed_addr addrspace(4) constant i32 10048
+// GFX1030: @__oclc_ABI_version = linkonce hidden local_unnamed_addr addrspace(4) constant i32 400
+
+// Check that we can override the wavefront features.
+// RUN: %clang_cc1 -x hip -triple amdgcn-amd-amdhsa -target-cpu gfx1030 -target-feature +wavefrontsize64 \
+// RUN:   -S -emit-llvm -o - %s | FileCheck %s --check-prefix=WAVEFRONT
+// WAVEFRONT: @__oclc_wavefrontsize64 = linkonce hidden local_unnamed_addr addrspace(4) constant i8 1
+
+// Check that we can enable denormalization at zero.
+// RUN: %clang_cc1 -x hip -triple amdgcn-amd-amdhsa -target-cpu gfx90a -fdenormal-fp-math-f32=preserve-sign,preserve-sign \
+// RUN:   -S -emit-llvm -o - %s | FileCheck %s --check-prefix=DENORM-AT-ZERO
+// DENORM-AT-ZERO: @__oclc_daz_opt = linkonce hidden local_unnamed_addr addrspace(4) constant i8 1
+
+// Check that we can enable finite math.
+// RUN: %clang_cc1 -x hip -triple amdgcn-amd-amdhsa -target-cpu gfx90a -ffinite-math-only \
+// RUN:   -S -emit-llvm -o - %s | FileCheck %s --check-prefix=FINITE-MATH
+// FINITE-MATH: @__oclc_finite_only_opt = linkonce hidden local_unnamed_addr addrspace(4) constant i8 1
+// FINITE-MATH: @__oclc_unsafe_math_opt = linkonce hidden local_unnamed_addr addrspace(4) constant i8 0
+
+// Check that we can enable unsafe math.
+// RUN: %clang_cc1 -x hip -triple amdgcn-amd-amdhsa -target-cpu gfx90a -menable-unsafe-fp-math \
+// RUN:   -S -emit-llvm -o - %s | FileCheck %s --check-prefix=UNSAFE-MATH
+// UNSAFE-MATH: @__oclc_finite_only_opt = linkonce hidden local_unnamed_addr addrspace(4) constant i8 0
+// UNSAFE-MATH: @__oclc_unsafe_math_opt = linkonce hidden local_unnamed_addr addrspace(4) constant i8 1
+
+// Check that we can disable/enable correctly rounded square roots.
+// RUN: %clang_cc1 -x hip -triple amdgcn-amd-amdhsa -target-cpu gfx90a -fno-hip-fp32-correctly-rounded-divide-sqrt \
+// RUN:   -S -emit-llvm -o - %s | FileCheck %s --check-prefix=CORRECT-SQRT
+// CORRECT-SQRT: @__oclc_correctly_rounded_sqrt32 = linkonce hidden local_unnamed_addr addrspace(4) constant i8 0
+// RUN: %clang_cc1 -x cl -triple amdgcn-amd-amdhsa -target-cpu gfx90a -cl-fp32-correctly-rounded-divide-sqrt \
+// RUN:   -disable-llvm-optzns -S -emit-llvm -o - %s | FileCheck %s --check-prefix=CL-CORRECT-SQRT
+// CL-CORRECT-SQRT: @__oclc_correctly_rounded_sqrt32 = linkonce hidden local_unnamed_addr addrspace(4) constant i8 1
Index: clang/lib/CodeGen/TargetInfo.h
===
--- clang/

[PATCH] D132952: [Sema] disable -Wvla for function array parameters

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/test/Sema/warn-vla.c:8-12
+void test2(int n, int v[n]) { // c99 no-warning
+#if __STDC_VERSION__ < 199901L
+// expected-warning@-2{{variable length arrays are a C99 feature}}
+#endif
 }

aaron.ballman wrote:
> aaron.ballman wrote:
> > inclyc wrote:
> > > aaron.ballman wrote:
> > > > The diagnostic there is rather unfortunate because we're not using a 
> > > > variable-length array in this case.
> > > Emm, I'm not clear about whether we should consider this a VLA, and 
> > > generates `-Wvla-extensions`. Is `v[n]` literally a variable-length 
> > > array? (in source code) So it seems to me that we should still report c89 
> > > incompatibility warnings?
> > > 
> > C89's grammar only allowed for an integer constant expression to 
> > (optionally) appear as the array extent in an array declarator, so there is 
> > a compatibility warning needed for that. But I don't think we should issue 
> > a warning about this being a VLA in C99 or later. The array *is* a VLA in 
> > terms of the form written in the source, but C adjusts the parameter to be 
> > a pointer parameter, so as far as the function's type is concerned, it's 
> > not a VLA (it's just a self-documenting interface).
> > 
> > Because self-documenting code is nice and because people are worried about 
> > accidental use of VLAs that cause stack allocations (which this does not), 
> > I think we don't want to scare people off from this construct. But I'm 
> > curious what others think as well.
> > But I'm curious what others think as well.
> 
> (Specifically, I'm wondering if others agree that the only warning that 
> should be issued there is a C89 compatibility warning under 
> `-Wvla-extensions` when in C89 mode and via a new `CPre99Compat` diagnostic 
> group when enabled in C99 and later modes.)
> 
> 
I imagine people working with codebases that are also built with compilers that 
don't support VLAs would still want some form of warning on any VLA type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132952

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

[clang] acb767f - [clang] fix profiling of template arguments of template and declaration kind

[Matheus Izvekov via cfe-commits]

Author: Matheus Izvekov
Date: 2022-09-06T18:27:39+02:00
New Revision: acb767f5cda59302aa9100afcf6133d66779d42c

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

LOG: [clang] fix profiling of template arguments of template and declaration 
kind

Template arguments of template and declaration kind were being profiled
only by their canonical properties, which would cause incorrect
uniquing of constrained AutoTypes, leading to a crash in some cases.

This exposed some places in CheckTemplateArgumentList where non-canonical
arguments where being pushed into the resulting converted list.

We also throw in some asserts to catch early and explain the crashes.

Note that the fix for the 'declaration' kind is untestable at this point,
because there should be no cases right now in the AST where we try
to unique a non-canonical converted template argument.

This fixes GH55567.

Signed-off-by: Matheus Izvekov 

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

Added: 


Modified: 
clang/lib/AST/ASTContext.cpp
clang/lib/AST/TemplateBase.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/test/SemaTemplate/concepts.cpp

Removed: 




diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index 20fcc8fea4b79..28f4e19893326 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -5116,7 +5116,9 @@ ASTContext::getDependentTemplateSpecializationType(
CanonArgs);
 
 // Find the insert position again.
-DependentTemplateSpecializationTypes.FindNodeOrInsertPos(ID, InsertPos);
+[[maybe_unused]] auto *Nothing =
+DependentTemplateSpecializationTypes.FindNodeOrInsertPos(ID, 
InsertPos);
+assert(!Nothing && "canonical type broken");
   }
 
   void *Mem = Allocate((sizeof(DependentTemplateSpecializationType) +
@@ -5731,7 +5733,9 @@ QualType ASTContext::getAutoTypeInternal(
 Canon = getAutoTypeInternal(QualType(), Keyword, IsDependent, IsPack,
 TypeConstraintConcept, CanonArgs, true);
 // Find the insert position again.
-AutoTypes.FindNodeOrInsertPos(ID, InsertPos);
+[[maybe_unused]] auto *Nothing =
+AutoTypes.FindNodeOrInsertPos(ID, InsertPos);
+assert(!Nothing && "canonical type broken");
   }
 } else {
   Canon = DeducedType.getCanonicalType();

diff  --git a/clang/lib/AST/TemplateBase.cpp b/clang/lib/AST/TemplateBase.cpp
index e0f5916a9a0b7..6d9ab2b8ca718 100644
--- a/clang/lib/AST/TemplateBase.cpp
+++ b/clang/lib/AST/TemplateBase.cpp
@@ -321,26 +321,15 @@ void TemplateArgument::Profile(llvm::FoldingSetNodeID &ID,
 
   case Declaration:
 getParamTypeForDecl().Profile(ID);
-ID.AddPointer(getAsDecl()? getAsDecl()->getCanonicalDecl() : nullptr);
+ID.AddPointer(getAsDecl());
 break;
 
+  case TemplateExpansion:
+ID.AddInteger(TemplateArg.NumExpansions);
+LLVM_FALLTHROUGH;
   case Template:
-  case TemplateExpansion: {
-TemplateName Template = getAsTemplateOrTemplatePattern();
-if (TemplateTemplateParmDecl *TTP
-  = dyn_cast_or_null(
-Template.getAsTemplateDecl())) 
{
-  ID.AddBoolean(true);
-  ID.AddInteger(TTP->getDepth());
-  ID.AddInteger(TTP->getPosition());
-  ID.AddBoolean(TTP->isParameterPack());
-} else {
-  ID.AddBoolean(false);
-  ID.AddPointer(Context.getCanonicalTemplateName(Template)
-  .getAsVoidPointer());
-}
+getAsTemplateOrTemplatePattern().Profile(ID);
 break;
-  }
 
   case Integral:
 getAsIntegral().Profile(ID);

diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index b06612d02797b..e9076bb6633af 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -5643,7 +5643,8 @@ bool Sema::CheckTemplateArgument(NamedDecl *Param,
 if (CheckTemplateTemplateArgument(TempParm, Params, Arg))
   return true;
 
-Converted.push_back(Arg.getArgument());
+Converted.push_back(
+Context.getCanonicalTemplateArgument(Arg.getArgument()));
 break;
 
   case TemplateArgument::Expression:
@@ -5813,13 +5814,14 @@ bool Sema::CheckTemplateArgumentList(
 if (!ArgumentPack.empty()) {
   // If we were part way through filling in an expanded parameter pack,
   // fall back to just producing individual arguments.
-  Converted.insert(Converted.end(),
-   ArgumentPack.begin(), ArgumentPack.end());
+  for (const TemplateArgument &I : ArgumentPack)
+Converted.push_back(Context.getCanonicalTemplateArgument(I));
   ArgumentPack.clear();
 }
 
 

[PATCH] D133072: [clang] fix profiling of template arguments of template and declaration kind

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/lib/Sema/SemaTemplate.cpp:5817
   // fall back to just producing individual arguments.
-  Converted.insert(Converted.end(),
-   ArgumentPack.begin(), ArgumentPack.end());
+  for (const TemplateArgument &I : ArgumentPack)
+Converted.push_back(Context.getCanonicalTemplateArgument(I));

mizvekov wrote:
> erichkeane wrote:
> > mizvekov wrote:
> > > erichkeane wrote:
> > > > Ooh, thats a transform!  
> > > > 
> > > > `llvm::transform(ArgumentPack, std::back_inserter(Converted), [](const 
> > > > auto &I) { return Context.getCanonicalTemplateArgument(I));`
> > > That is true, though unless we can come up with a clearer spelling for 
> > > that, it looks less readable to me.
> > But I like transform :(
> I will think of something, even if we have to add a new helper :)
I'll try to address this concern, about having a helper which returns a 
transformed copy of a container, in a way that reads better than the pure 
transform as suggested, in a follow up patch. Meanwhile I'll offload this 
patch, as my stack is too big right now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133072

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

[PATCH] D133072: [clang] fix profiling of template arguments of template and declaration kind

[Matheus Izvekov via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGacb767f5cda5: [clang] fix profiling of template arguments of 
template and declaration kind (authored by mizvekov).

Changed prior to commit:
  https://reviews.llvm.org/D133072?vs=457819&id=458191#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133072

Files:
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/TemplateBase.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaTemplate/concepts.cpp

Index: clang/test/SemaTemplate/concepts.cpp
===
--- clang/test/SemaTemplate/concepts.cpp
+++ clang/test/SemaTemplate/concepts.cpp
@@ -256,3 +256,9 @@
 C auto **&j2 = g();  // expected-error {{deduced type 'int' does not satisfy 'C'}}
 C auto **&&j3 = g(); // expected-error {{deduced type 'int' does not satisfy 'C'}}
 }
+
+namespace GH55567 {
+template class> concept C = true;
+template  struct S {};
+void f(C auto);
+} // namespace GH55567
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -5643,7 +5643,8 @@
 if (CheckTemplateTemplateArgument(TempParm, Params, Arg))
   return true;
 
-Converted.push_back(Arg.getArgument());
+Converted.push_back(
+Context.getCanonicalTemplateArgument(Arg.getArgument()));
 break;
 
   case TemplateArgument::Expression:
@@ -5813,13 +5814,14 @@
 if (!ArgumentPack.empty()) {
   // If we were part way through filling in an expanded parameter pack,
   // fall back to just producing individual arguments.
-  Converted.insert(Converted.end(),
-   ArgumentPack.begin(), ArgumentPack.end());
+  for (const TemplateArgument &I : ArgumentPack)
+Converted.push_back(Context.getCanonicalTemplateArgument(I));
   ArgumentPack.clear();
 }
 
 while (ArgIdx < NumArgs) {
-  Converted.push_back(NewArgs[ArgIdx].getArgument());
+  Converted.push_back(Context.getCanonicalTemplateArgument(
+  NewArgs[ArgIdx].getArgument()));
   ++ArgIdx;
 }
 
@@ -5952,7 +5954,8 @@
   if (ArgIdx < NumArgs && CurrentInstantiationScope &&
   CurrentInstantiationScope->getPartiallySubstitutedPack()) {
 while (ArgIdx < NumArgs && NewArgs[ArgIdx].getArgument().isPackExpansion())
-  Converted.push_back(NewArgs[ArgIdx++].getArgument());
+  Converted.push_back(Context.getCanonicalTemplateArgument(
+  NewArgs[ArgIdx++].getArgument()));
   }
 
   // If we have any leftover arguments, then there were too many arguments.
Index: clang/lib/AST/TemplateBase.cpp
===
--- clang/lib/AST/TemplateBase.cpp
+++ clang/lib/AST/TemplateBase.cpp
@@ -321,26 +321,15 @@
 
   case Declaration:
 getParamTypeForDecl().Profile(ID);
-ID.AddPointer(getAsDecl()? getAsDecl()->getCanonicalDecl() : nullptr);
+ID.AddPointer(getAsDecl());
 break;
 
+  case TemplateExpansion:
+ID.AddInteger(TemplateArg.NumExpansions);
+LLVM_FALLTHROUGH;
   case Template:
-  case TemplateExpansion: {
-TemplateName Template = getAsTemplateOrTemplatePattern();
-if (TemplateTemplateParmDecl *TTP
-  = dyn_cast_or_null(
-Template.getAsTemplateDecl())) {
-  ID.AddBoolean(true);
-  ID.AddInteger(TTP->getDepth());
-  ID.AddInteger(TTP->getPosition());
-  ID.AddBoolean(TTP->isParameterPack());
-} else {
-  ID.AddBoolean(false);
-  ID.AddPointer(Context.getCanonicalTemplateName(Template)
-  .getAsVoidPointer());
-}
+getAsTemplateOrTemplatePattern().Profile(ID);
 break;
-  }
 
   case Integral:
 getAsIntegral().Profile(ID);
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -5116,7 +5116,9 @@
CanonArgs);
 
 // Find the insert position again.
-DependentTemplateSpecializationTypes.FindNodeOrInsertPos(ID, InsertPos);
+[[maybe_unused]] auto *Nothing =
+DependentTemplateSpecializationTypes.FindNodeOrInsertPos(ID, InsertPos);
+assert(!Nothing && "canonical type broken");
   }
 
   void *Mem = Allocate((sizeof(DependentTemplateSpecializationType) +
@@ -5731,7 +5733,9 @@
 Canon = getAutoTypeInternal(QualType(), Keyword, IsDependent, IsPack,
 TypeConstraintConcept, CanonArgs, true);
 // Find the insert position again.
-AutoTypes.FindNodeOrInsertPos(ID, InsertPos);
+

[PATCH] D132952: [Sema] disable -Wvla for function array parameters

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/Sema/warn-vla.c:8-12
+void test2(int n, int v[n]) { // c99 no-warning
+#if __STDC_VERSION__ < 199901L
+// expected-warning@-2{{variable length arrays are a C99 feature}}
+#endif
 }

efriedma wrote:
> aaron.ballman wrote:
> > aaron.ballman wrote:
> > > inclyc wrote:
> > > > aaron.ballman wrote:
> > > > > The diagnostic there is rather unfortunate because we're not using a 
> > > > > variable-length array in this case.
> > > > Emm, I'm not clear about whether we should consider this a VLA, and 
> > > > generates `-Wvla-extensions`. Is `v[n]` literally a variable-length 
> > > > array? (in source code) So it seems to me that we should still report 
> > > > c89 incompatibility warnings?
> > > > 
> > > C89's grammar only allowed for an integer constant expression to 
> > > (optionally) appear as the array extent in an array declarator, so there 
> > > is a compatibility warning needed for that. But I don't think we should 
> > > issue a warning about this being a VLA in C99 or later. The array *is* a 
> > > VLA in terms of the form written in the source, but C adjusts the 
> > > parameter to be a pointer parameter, so as far as the function's type is 
> > > concerned, it's not a VLA (it's just a self-documenting interface).
> > > 
> > > Because self-documenting code is nice and because people are worried 
> > > about accidental use of VLAs that cause stack allocations (which this 
> > > does not), I think we don't want to scare people off from this construct. 
> > > But I'm curious what others think as well.
> > > But I'm curious what others think as well.
> > 
> > (Specifically, I'm wondering if others agree that the only warning that 
> > should be issued there is a C89 compatibility warning under 
> > `-Wvla-extensions` when in C89 mode and via a new `CPre99Compat` diagnostic 
> > group when enabled in C99 and later modes.)
> > 
> > 
> I imagine people working with codebases that are also built with compilers 
> that don't support VLAs would still want some form of warning on any VLA type.
The tricky part is: that's precisely what WG14 N2992 
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2992.pdf) is clarifying. If 
your implementation doesn't support VLAs, it's still required to support this 
syntactic form. So the question becomes: do we want a portability warning to 
compilers that don't conform to the standard? Maybe we do (if we can find 
evidence of compilers in such a state), but probably under a specific 
diagnostic flag rather than -Wvla.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132952

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

[PATCH] D133357: [Lex/DependencyDirectivesScanner] Keep track of the presence of tokens between the last scanned directive and EOF

[Ben Langmuir via Phabricator via cfe-commits]

benlangmuir added inline comments.



Comment at: clang/include/clang/Lex/DependencyDirectivesScanner.h:131
+/// \p dependency_directives_scan::tokens_present_before_eof, otherwise this
+/// directive will be ignored.
 ///

Why would you want to print without this? It seems important for correctness of 
the output.  I would have expected we would always print it.



Comment at: clang/lib/Lex/DependencyDirectivesScanner.cpp:868
+PrintMarkerForTokensBeforeEOF)
+  OS << "";
 Optional PrevTokenKind;

How about "TokBeforeEOF"?  I think "BEOF" is too cryptic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133357

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

[PATCH] D133082: [clang] Implement setting crash_diagnostics_dir through env variable

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

@aaron.ballman I think all of your concerns are addressed now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133082

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

[PATCH] D133349: [clang][doc] Do not keep a copy of ClangCommandLineReference.rst in tree

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

That's sounds like an "OK" to me, right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133349

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

[PATCH] D132952: [Sema] disable -Wvla for function array parameters

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/test/Sema/warn-vla.c:8-12
+void test2(int n, int v[n]) { // c99 no-warning
+#if __STDC_VERSION__ < 199901L
+// expected-warning@-2{{variable length arrays are a C99 feature}}
+#endif
 }

aaron.ballman wrote:
> efriedma wrote:
> > aaron.ballman wrote:
> > > aaron.ballman wrote:
> > > > inclyc wrote:
> > > > > aaron.ballman wrote:
> > > > > > The diagnostic there is rather unfortunate because we're not using 
> > > > > > a variable-length array in this case.
> > > > > Emm, I'm not clear about whether we should consider this a VLA, and 
> > > > > generates `-Wvla-extensions`. Is `v[n]` literally a variable-length 
> > > > > array? (in source code) So it seems to me that we should still report 
> > > > > c89 incompatibility warnings?
> > > > > 
> > > > C89's grammar only allowed for an integer constant expression to 
> > > > (optionally) appear as the array extent in an array declarator, so 
> > > > there is a compatibility warning needed for that. But I don't think we 
> > > > should issue a warning about this being a VLA in C99 or later. The 
> > > > array *is* a VLA in terms of the form written in the source, but C 
> > > > adjusts the parameter to be a pointer parameter, so as far as the 
> > > > function's type is concerned, it's not a VLA (it's just a 
> > > > self-documenting interface).
> > > > 
> > > > Because self-documenting code is nice and because people are worried 
> > > > about accidental use of VLAs that cause stack allocations (which this 
> > > > does not), I think we don't want to scare people off from this 
> > > > construct. But I'm curious what others think as well.
> > > > But I'm curious what others think as well.
> > > 
> > > (Specifically, I'm wondering if others agree that the only warning that 
> > > should be issued there is a C89 compatibility warning under 
> > > `-Wvla-extensions` when in C89 mode and via a new `CPre99Compat` 
> > > diagnostic group when enabled in C99 and later modes.)
> > > 
> > > 
> > I imagine people working with codebases that are also built with compilers 
> > that don't support VLAs would still want some form of warning on any VLA 
> > type.
> The tricky part is: that's precisely what WG14 N2992 
> (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2992.pdf) is clarifying. 
> If your implementation doesn't support VLAs, it's still required to support 
> this syntactic form. So the question becomes: do we want a portability 
> warning to compilers that don't conform to the standard? Maybe we do (if we 
> can find evidence of compilers in such a state), but probably under a 
> specific diagnostic flag rather than -Wvla.
That only applies to C23, though, right?  None of that wording is there for 
C11.  (In particular, MSVC claims C11 conformance without any support for VLA 
types.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132952

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

[PATCH] D132952: [Sema] disable -Wvla for function array parameters

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/Sema/warn-vla.c:8-12
+void test2(int n, int v[n]) { // c99 no-warning
+#if __STDC_VERSION__ < 199901L
+// expected-warning@-2{{variable length arrays are a C99 feature}}
+#endif
 }

efriedma wrote:
> aaron.ballman wrote:
> > efriedma wrote:
> > > aaron.ballman wrote:
> > > > aaron.ballman wrote:
> > > > > inclyc wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > The diagnostic there is rather unfortunate because we're not 
> > > > > > > using a variable-length array in this case.
> > > > > > Emm, I'm not clear about whether we should consider this a VLA, and 
> > > > > > generates `-Wvla-extensions`. Is `v[n]` literally a variable-length 
> > > > > > array? (in source code) So it seems to me that we should still 
> > > > > > report c89 incompatibility warnings?
> > > > > > 
> > > > > C89's grammar only allowed for an integer constant expression to 
> > > > > (optionally) appear as the array extent in an array declarator, so 
> > > > > there is a compatibility warning needed for that. But I don't think 
> > > > > we should issue a warning about this being a VLA in C99 or later. The 
> > > > > array *is* a VLA in terms of the form written in the source, but C 
> > > > > adjusts the parameter to be a pointer parameter, so as far as the 
> > > > > function's type is concerned, it's not a VLA (it's just a 
> > > > > self-documenting interface).
> > > > > 
> > > > > Because self-documenting code is nice and because people are worried 
> > > > > about accidental use of VLAs that cause stack allocations (which this 
> > > > > does not), I think we don't want to scare people off from this 
> > > > > construct. But I'm curious what others think as well.
> > > > > But I'm curious what others think as well.
> > > > 
> > > > (Specifically, I'm wondering if others agree that the only warning that 
> > > > should be issued there is a C89 compatibility warning under 
> > > > `-Wvla-extensions` when in C89 mode and via a new `CPre99Compat` 
> > > > diagnostic group when enabled in C99 and later modes.)
> > > > 
> > > > 
> > > I imagine people working with codebases that are also built with 
> > > compilers that don't support VLAs would still want some form of warning 
> > > on any VLA type.
> > The tricky part is: that's precisely what WG14 N2992 
> > (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2992.pdf) is clarifying. 
> > If your implementation doesn't support VLAs, it's still required to support 
> > this syntactic form. So the question becomes: do we want a portability 
> > warning to compilers that don't conform to the standard? Maybe we do (if we 
> > can find evidence of compilers in such a state), but probably under a 
> > specific diagnostic flag rather than -Wvla.
> That only applies to C23, though, right?  None of that wording is there for 
> C11.  (In particular, MSVC claims C11 conformance without any support for VLA 
> types.)
In a strict sense, yes, this is a C23 change. There are no changes to older 
standards as far as ISO is concerned (and there never have been).

In a practical sense, no, this is clarifying how VLAs have always been intended 
to work. C23 is in a really weird spot in that we had to stop our "defect 
report" process at the end of C17 because the ISO definition of a defect did 
not match the WG14 definition of a defect, and ISO got upset. Towards the tail 
end of the C23 cycle, we introduced a list of extensions to obsolete versions 
of C (https://www.open-std.org/jtc1/sc22/wg14/www/previous.html) as a stopgap, 
but the convener would not allow us to retroactively add papers to it. The 
committee still hasn't gotten used to this new process and as a result, not 
many papers have made it to the list. We've also not had the chance to discuss 
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3002.pdf on having a more 
reasonable issue tracking process.

The end result is that there's a whole pile of papers in C23 that we would have 
normally treated via the old defect report process but couldn't, and if we had 
treated them via the old DR process, it would have been more clear why I think 
this should be a retroactive change back to C99 instead of a C23-only change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132952

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

[PATCH] D133349: [clang][doc] Do not keep a copy of ClangCommandLineReference.rst in tree

[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 D133349#3772353 , 
@serge-sans-paille wrote:

> That's sounds like an "OK" to me, right?

Yeah, this LGTM, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133349

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

[PATCH] D133082: [clang] Implement setting crash_diagnostics_dir through env variable

[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, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133082

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

[PATCH] D132867: [Clang] Use virtual FS in processing config files

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff updated this revision to Diff 458205.
sepavloff added a comment.

Add a release note


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132867

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Driver/Driver.cpp
  clang/unittests/Driver/ToolChainTest.cpp
  llvm/include/llvm/Support/CommandLine.h
  llvm/lib/Support/CommandLine.cpp

Index: llvm/lib/Support/CommandLine.cpp
===
--- llvm/lib/Support/CommandLine.cpp
+++ llvm/lib/Support/CommandLine.cpp
@@ -1264,10 +1264,17 @@
 // always have an absolute path deduced from the containing file.
 SmallString<128> CurrDir;
 if (llvm::sys::path::is_relative(FName)) {
-  if (!CurrentDir)
-llvm::sys::fs::current_path(CurrDir);
-  else
+  if (!CurrentDir) {
+if (auto CWD = FS.getCurrentWorkingDirectory()) {
+  CurrDir = *CWD;
+} else {
+  // TODO: The error should be propagated up the stack.
+  llvm::consumeError(llvm::errorCodeToError(CWD.getError()));
+  return false;
+}
+  } else {
 CurrDir = *CurrentDir;
+  }
   llvm::sys::path::append(CurrDir, FName);
   FName = CurrDir.c_str();
 }
@@ -1357,24 +1364,26 @@
 }
 
 bool cl::readConfigFile(StringRef CfgFile, StringSaver &Saver,
-SmallVectorImpl &Argv) {
+SmallVectorImpl &Argv,
+llvm::vfs::FileSystem &FS) {
   SmallString<128> AbsPath;
   if (sys::path::is_relative(CfgFile)) {
-llvm::sys::fs::current_path(AbsPath);
-llvm::sys::path::append(AbsPath, CfgFile);
+AbsPath.assign(CfgFile);
+if (std::error_code EC = FS.makeAbsolute(AbsPath))
+  return false;
 CfgFile = AbsPath.str();
   }
-  if (llvm::Error Err = ExpandResponseFile(
-  CfgFile, Saver, cl::tokenizeConfigFile, Argv,
-  /*MarkEOLs=*/false, /*RelativeNames=*/true, /*ExpandBasePath=*/true,
-  *llvm::vfs::getRealFileSystem())) {
+  if (llvm::Error Err =
+  ExpandResponseFile(CfgFile, Saver, cl::tokenizeConfigFile, Argv,
+ /*MarkEOLs=*/false, /*RelativeNames=*/true,
+ /*ExpandBasePath=*/true, FS)) {
 // TODO: The error should be propagated up the stack.
 llvm::consumeError(std::move(Err));
 return false;
   }
   return ExpandResponseFiles(Saver, cl::tokenizeConfigFile, Argv,
  /*MarkEOLs=*/false, /*RelativeNames=*/true,
- /*ExpandBasePath=*/true, llvm::None);
+ /*ExpandBasePath=*/true, llvm::None, FS);
 }
 
 static void initCommonOptions();
Index: llvm/include/llvm/Support/CommandLine.h
===
--- llvm/include/llvm/Support/CommandLine.h
+++ llvm/include/llvm/Support/CommandLine.h
@@ -2078,7 +2078,8 @@
 /// current config file.
 ///
 bool readConfigFile(StringRef CfgFileName, StringSaver &Saver,
-SmallVectorImpl &Argv);
+SmallVectorImpl &Argv,
+llvm::vfs::FileSystem &FS);
 
 /// Expand response files on a command line recursively using the given
 /// StringSaver and tokenization strategy.  Argv should contain the command line
@@ -2099,7 +2100,7 @@
 /// the current response file.
 /// \param [in] FS File system used for all file access when running the tool.
 /// \param [in] CurrentDir Path used to resolve relative rsp files. If set to
-/// None, process' cwd is used instead.
+/// None, the file system current directory is used instead.
 /// \return true if all @files were expanded successfully or there were none.
 bool ExpandResponseFiles(StringSaver &Saver, TokenizerCallback Tokenizer,
  SmallVectorImpl &Argv, bool MarkEOLs,
Index: clang/unittests/Driver/ToolChainTest.cpp
===
--- clang/unittests/Driver/ToolChainTest.cpp
+++ clang/unittests/Driver/ToolChainTest.cpp
@@ -484,4 +484,61 @@
   }
 }
 
+TEST(ToolChainTest, ConfigFileSearch) {
+  IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
+  IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
+  struct TestDiagnosticConsumer : public DiagnosticConsumer {};
+  DiagnosticsEngine Diags(DiagID, &*DiagOpts, new TestDiagnosticConsumer);
+  IntrusiveRefCntPtr FS(
+  new llvm::vfs::InMemoryFileSystem);
+
+#ifdef _WIN32
+  const char *TestRoot = "C:\\";
+#else
+  const char *TestRoot = "/";
+#endif
+  FS->setCurrentWorkingDirectory(TestRoot);
+
+  FS->addFile(
+  "/opt/sdk/root.cfg", 0,
+  llvm::MemoryBuffer::getMemBuffer("--sysroot=/opt/sdk/platform0\n"));
+  FS->addFile(
+  "/home/test/sdk/root.cfg", 0,
+  llvm::MemoryBuffer::getMemBuffer("--sysroot=/opt/sdk/platform1\n"));
+  FS->addFile(
+  "/home/test/bin/root.cfg", 0,
+  llvm::MemoryBuffer::getMemBu

[PATCH] D132867: [Clang] Use virtual FS in processing config files

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

In D132867#3771004 , @sammccall wrote:

>> Strictly speaking this is incorrect behavior because file system object must 
>> be used for all operations on files, according to documentation.
>
> I don't think this is a strong argument against documenting the change (is 
> that what we're disagreeing about?)

No problem to add documentation. I added a release note, if you mean that.

> - in practice many users who rely on these details work it out by trial and 
> error

Absolutely!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132867

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

[clang] 94c6dfb - [clang] Implement setting crash_diagnostics_dir through env variable

[Matheus Izvekov via cfe-commits]

Author: Matheus Izvekov
Date: 2022-09-06T19:27:37+02:00
New Revision: 94c6dfbaebbd5b9474794b2437757dfb6aedefc3

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

LOG: [clang] Implement setting crash_diagnostics_dir through env variable

This implements setting the equivalent of `-fcrash-diagnostics-dir`
through the environment variable `CLANG_CRASH_DIAGNOSTICS_DIR`.
If present, the flag still takes precedence.

This helps integration with test frameworks and pipelines.

With this feature, we change the libcxx bootstrapping build
pipeline to produce clang crash reproducers as artifacts.

Signed-off-by: Matheus Izvekov 

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

Added: 
clang/test/Driver/crash-diagnostics-dir-3.c

Modified: 
clang/docs/ReleaseNotes.rst
clang/docs/UsersManual.rst
clang/lib/Driver/Driver.cpp
libcxx/utils/ci/buildkite-pipeline.yml

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 146b2149f9d7e..1d381649b6bb4 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -135,6 +135,9 @@ Improvements to Clang's diagnostics
 
 Non-comprehensive list of changes in this release
 -
+- It's now possible to set the crash diagnostics directory through
+  the environment variable ``CLANG_CRASH_DIAGNOSTICS_DIR``.
+  The ``-fcrash-diagnostics-dir`` flag takes precedence.
 
 New Compiler Flags
 --

diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index bf17677274e0c..8afe5cab64cb5 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -687,6 +687,11 @@ of generating a delta reduced test case.
   Specify where to write the crash diagnostics files; defaults to the
   usual location for temporary files.
 
+.. envvar:: CLANG_CRASH_DIAGNOSTICS_DIR=
+
+   Like :option:`-fcrash-diagnostics-dir=`, specifies where to write the
+   crash diagnostics files, but with lower precedence than the option.
+
 Clang is also capable of generating preprocessed source file(s) and associated
 run script(s) even without a crash. This is specially useful when trying to
 generate a reproducer for warnings or errors while using modules.

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 0a61b5e2d62d4..3743515d3d43f 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -5413,15 +5413,18 @@ const char *Driver::CreateTempFile(Compilation &C, 
StringRef Prefix,
StringRef BoundArch) const {
   SmallString<128> TmpName;
   Arg *A = C.getArgs().getLastArg(options::OPT_fcrash_diagnostics_dir);
-  if (CCGenDiagnostics && A) {
-SmallString<128> CrashDirectory(A->getValue());
-if (!getVFS().exists(CrashDirectory))
-  llvm::sys::fs::create_directories(CrashDirectory);
-llvm::sys::path::append(CrashDirectory, Prefix);
+  Optional CrashDirectory =
+  CCGenDiagnostics && A
+  ? std::string(A->getValue())
+  : llvm::sys::Process::GetEnv("CLANG_CRASH_DIAGNOSTICS_DIR");
+  if (CrashDirectory) {
+if (!getVFS().exists(*CrashDirectory))
+  llvm::sys::fs::create_directories(*CrashDirectory);
+SmallString<128> Path(*CrashDirectory);
+llvm::sys::path::append(Path, Prefix);
 const char *Middle = !Suffix.empty() ? "-%%." : "-%%";
-std::error_code EC = llvm::sys::fs::createUniqueFile(
-CrashDirectory + Middle + Suffix, TmpName);
-if (EC) {
+if (std::error_code EC =
+llvm::sys::fs::createUniqueFile(Path + Middle + Suffix, TmpName)) {
   Diag(clang::diag::err_unable_to_make_temp) << EC.message();
   return "";
 }

diff  --git a/clang/test/Driver/crash-diagnostics-dir-3.c 
b/clang/test/Driver/crash-diagnostics-dir-3.c
new file mode 100644
index 0..9529e30021045
--- /dev/null
+++ b/clang/test/Driver/crash-diagnostics-dir-3.c
@@ -0,0 +1,5 @@
+// RUN: rm -rf %t
+// RUN: not env CLANG_CRASH_DIAGNOSTICS_DIR=%t %clang -c %s -o - 2>&1 | 
FileCheck %s
+#pragma clang __debug parser_crash
+// CHECK: Preprocessed source(s) and associated run script(s) are located at:
+// CHECK: diagnostic msg: 
{{.*}}{{/|\\}}crash-diagnostics-dir-3.c.tmp{{(/|\\).*}}.c

diff  --git a/libcxx/utils/ci/buildkite-pipeline.yml 
b/libcxx/utils/ci/buildkite-pipeline.yml
index d15172980e612..61951720ef650 100644
--- a/libcxx/utils/ci/buildkite-pipeline.yml
+++ b/libcxx/utils/ci/buildkite-pipeline.yml
@@ -369,10 +369,12 @@ steps:
 artifact_paths:
   - "**/test-results.xml"
   - "**/*.abilist"
+  - "**/crash_diagnostics/*"
 env:
 CC: "clang-${LLVM_HEAD_VERSION}"
 CXX: "clang++-${LLVM_HEAD_VERSION}"
 LLVM_SYMBOLIZER_PATH: "/usr/bin/llvm-sy

[PATCH] D133082: [clang] Implement setting crash_diagnostics_dir through env variable

[Matheus Izvekov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG94c6dfbaebbd: [clang] Implement setting 
crash_diagnostics_dir through env variable (authored by mizvekov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133082

Files:
  clang/docs/ReleaseNotes.rst
  clang/docs/UsersManual.rst
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/crash-diagnostics-dir-3.c
  libcxx/utils/ci/buildkite-pipeline.yml


Index: libcxx/utils/ci/buildkite-pipeline.yml
===
--- libcxx/utils/ci/buildkite-pipeline.yml
+++ libcxx/utils/ci/buildkite-pipeline.yml
@@ -369,10 +369,12 @@
 artifact_paths:
   - "**/test-results.xml"
   - "**/*.abilist"
+  - "**/crash_diagnostics/*"
 env:
 CC: "clang-${LLVM_HEAD_VERSION}"
 CXX: "clang++-${LLVM_HEAD_VERSION}"
 LLVM_SYMBOLIZER_PATH: "/usr/bin/llvm-symbolizer-${LLVM_HEAD_VERSION}"
+CLANG_CRASH_DIAGNOSTICS_DIR: "crash_diagnostics"
 agents:
   queue: "libcxx-builders"
   os: "linux"
Index: clang/test/Driver/crash-diagnostics-dir-3.c
===
--- /dev/null
+++ clang/test/Driver/crash-diagnostics-dir-3.c
@@ -0,0 +1,5 @@
+// RUN: rm -rf %t
+// RUN: not env CLANG_CRASH_DIAGNOSTICS_DIR=%t %clang -c %s -o - 2>&1 | 
FileCheck %s
+#pragma clang __debug parser_crash
+// CHECK: Preprocessed source(s) and associated run script(s) are located at:
+// CHECK: diagnostic msg: 
{{.*}}{{/|\\}}crash-diagnostics-dir-3.c.tmp{{(/|\\).*}}.c
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -5413,15 +5413,18 @@
StringRef BoundArch) const {
   SmallString<128> TmpName;
   Arg *A = C.getArgs().getLastArg(options::OPT_fcrash_diagnostics_dir);
-  if (CCGenDiagnostics && A) {
-SmallString<128> CrashDirectory(A->getValue());
-if (!getVFS().exists(CrashDirectory))
-  llvm::sys::fs::create_directories(CrashDirectory);
-llvm::sys::path::append(CrashDirectory, Prefix);
+  Optional CrashDirectory =
+  CCGenDiagnostics && A
+  ? std::string(A->getValue())
+  : llvm::sys::Process::GetEnv("CLANG_CRASH_DIAGNOSTICS_DIR");
+  if (CrashDirectory) {
+if (!getVFS().exists(*CrashDirectory))
+  llvm::sys::fs::create_directories(*CrashDirectory);
+SmallString<128> Path(*CrashDirectory);
+llvm::sys::path::append(Path, Prefix);
 const char *Middle = !Suffix.empty() ? "-%%." : "-%%";
-std::error_code EC = llvm::sys::fs::createUniqueFile(
-CrashDirectory + Middle + Suffix, TmpName);
-if (EC) {
+if (std::error_code EC =
+llvm::sys::fs::createUniqueFile(Path + Middle + Suffix, TmpName)) {
   Diag(clang::diag::err_unable_to_make_temp) << EC.message();
   return "";
 }
Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -687,6 +687,11 @@
   Specify where to write the crash diagnostics files; defaults to the
   usual location for temporary files.
 
+.. envvar:: CLANG_CRASH_DIAGNOSTICS_DIR=
+
+   Like :option:`-fcrash-diagnostics-dir=`, specifies where to write the
+   crash diagnostics files, but with lower precedence than the option.
+
 Clang is also capable of generating preprocessed source file(s) and associated
 run script(s) even without a crash. This is specially useful when trying to
 generate a reproducer for warnings or errors while using modules.
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -135,6 +135,9 @@
 
 Non-comprehensive list of changes in this release
 -
+- It's now possible to set the crash diagnostics directory through
+  the environment variable ``CLANG_CRASH_DIAGNOSTICS_DIR``.
+  The ``-fcrash-diagnostics-dir`` flag takes precedence.
 
 New Compiler Flags
 --


Index: libcxx/utils/ci/buildkite-pipeline.yml
===
--- libcxx/utils/ci/buildkite-pipeline.yml
+++ libcxx/utils/ci/buildkite-pipeline.yml
@@ -369,10 +369,12 @@
 artifact_paths:
   - "**/test-results.xml"
   - "**/*.abilist"
+  - "**/crash_diagnostics/*"
 env:
 CC: "clang-${LLVM_HEAD_VERSION}"
 CXX: "clang++-${LLVM_HEAD_VERSION}"
 LLVM_SYMBOLIZER_PATH: "/usr/bin/llvm-symbolizer-${LLVM_HEAD_VERSION}"
+CLANG_CRASH_DIAGNOSTICS_DIR: "crash_diagnostics"
 agents:
   queue: "libcxx-builders"
   os: "linux"
Index: clang/test/Driver/crash-diagnostics-dir-3.c
===

[PATCH] D133325: [Driver] Allow search of included response files as configuration files

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff updated this revision to Diff 458216.
sepavloff added a comment.

Change help message


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133325

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/Inputs/config/config-3.cfg
  clang/test/Driver/config-file.c
  clang/unittests/Driver/ToolChainTest.cpp
  llvm/include/llvm/Support/CommandLine.h
  llvm/lib/Support/CommandLine.cpp

Index: llvm/lib/Support/CommandLine.cpp
===
--- llvm/lib/Support/CommandLine.cpp
+++ llvm/lib/Support/CommandLine.cpp
@@ -1184,6 +1184,15 @@
 
   if (!RelativeNames)
 return Error::success();
+
+  if (InConfigFile) {
+if (std::find_if(NewArgv.begin(), NewArgv.end(),
+ [](const char *Arg) -> bool {
+   return StringRef("--search-config-dirs") == Arg;
+ }) != NewArgv.end())
+  setSearchAsConfig(true);
+  }
+
   llvm::StringRef BasePath = llvm::sys::path::parent_path(FName);
   // If names of nested response files should be resolved relative to including
   // file, replace the included response file names with their full paths
@@ -1207,8 +1216,17 @@
 
 SmallString<128> ResponseFile;
 ResponseFile.push_back('@');
-ResponseFile.append(BasePath);
-llvm::sys::path::append(ResponseFile, FileName);
+if (SearchAsConfig) {
+  std::string FilePath;
+  if (!findConfigFile(FileName, FilePath))
+return llvm::createStringError(
+std::make_error_code(std::errc::no_such_file_or_directory),
+"Could not find config file: " + FileName);
+  ResponseFile.append(FilePath);
+} else {
+  ResponseFile.append(BasePath);
+  llvm::sys::path::append(ResponseFile, FileName);
+}
 Arg = Saver.save(ResponseFile.str()).data();
   }
   return Error::success();
@@ -1350,15 +1368,48 @@
llvm::vfs::FileSystem *FS)
 : Saver(S), Tokenizer(T), FS(FS ? FS : vfs::getRealFileSystem().get()) {}
 
-bool ExpansionContext::readConfigFile(StringRef CfgFile,
-  SmallVectorImpl &Argv) {
-  SmallString<128> AbsPath;
-  if (sys::path::is_relative(CfgFile)) {
-AbsPath.assign(CfgFile);
-if (std::error_code EC = FS->makeAbsolute(AbsPath))
+bool ExpansionContext::findConfigFile(StringRef FileName,
+  std::string &FilePath) {
+  SmallString<128> CfgFilePath;
+  const auto FileExists = [this](SmallString<128> Path) -> bool {
+auto Status = FS->status(Path);
+return Status &&
+   Status->getType() == llvm::sys::fs::file_type::regular_file;
+  };
+
+  // If file name contains directory separator, treat it as a path to
+  // configuration file.
+  if (llvm::sys::path::has_parent_path(FileName)) {
+CfgFilePath = FileName;
+if (llvm::sys::path::is_relative(FileName)) {
+  if (FS->makeAbsolute(CfgFilePath))
+return false;
+}
+if (!FileExists(CfgFilePath))
   return false;
-CfgFile = AbsPath.str();
+FilePath = CfgFilePath.str();
+return true;
+  }
+
+  // Look for the file in search directories.
+  for (const StringRef &Dir : SearchDirs) {
+if (Dir.empty())
+  continue;
+CfgFilePath.assign(Dir);
+llvm::sys::path::append(CfgFilePath, FileName);
+llvm::sys::path::native(CfgFilePath);
+if (FileExists(CfgFilePath)) {
+  FilePath = CfgFilePath.str();
+  return true;
+}
   }
+
+  return false;
+}
+
+bool ExpansionContext::readConfigFile(StringRef CfgFile,
+  SmallVectorImpl &Argv) {
+  assert(llvm::sys::path::is_absolute(CfgFile));
   InConfigFile = true;
   RelativeNames = true;
   if (llvm::Error Err = expandResponseFile(CfgFile, Argv)) {
Index: llvm/include/llvm/Support/CommandLine.h
===
--- llvm/include/llvm/Support/CommandLine.h
+++ llvm/include/llvm/Support/CommandLine.h
@@ -2080,6 +2080,9 @@
   /// used instead.
   StringRef CurrentDir;
 
+  /// Directories used for search of config files.
+  ArrayRef SearchDirs;
+
   /// True if names of nested response files must be resolved relative to
   /// including file.
   bool RelativeNames = false;
@@ -2091,6 +2094,10 @@
   /// If true, body of config file is expanded.
   bool InConfigFile = false;
 
+  /// If true, the file included by '@file' is searched for as a config file, in
+  /// the config search directories.
+  bool SearchAsConfig = false;
+
   llvm::Error expandResponseFile(StringRef FName,
  SmallVectorImpl &NewArgv);
 
@@ -2116,6 +2123,29 @@
 return *this;
   }
 
+  ArrayRef getSearchDirs() const { return SearchDirs; }
+  ExpansionContext &setSearchDirs(ArrayRef X) {
+SearchDirs

[PATCH] D133367: [OpenMP] Remove use of removed '-f[no-]openmp-new-driver' flag

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, tianshilei1992, JonChesterfield, ronlieb, 
tra, yaxunl.
Herald added subscribers: kosarev, kerbowa, guansong, jvesely.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1, MaskRay.
Herald added a project: clang.

The changes in D130020  removed all support 
for the old method of
compiling OpenMP offloading programs. This means that
`-fopenmp-new-driver` has no effect and `-fno-openmp-new-driver` does
not work. This patch removes the use and documentation of this flag.
Note that the `--offload-new-driver` flag still exists for using the new
driver optionally with CUDA and HIP.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133367

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/amdgpu-openmp-toolchain.c


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -49,5 +49,5 @@
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -emit-llvm -S -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-EMIT-LLVM-IR
 // CHECK-EMIT-LLVM-IR: "-cc1" "-triple" "amdgcn-amd-amdhsa"{{.*}}"-emit-llvm"
 
-// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode 
-fopenmp-new-driver %s 2>&1 | FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
+// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode %s 2>&1 
| FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
 // CHECK-LIB-DEVICE-NEW: 
{{.*}}clang-linker-wrapper{{.*}}--bitcode-library=openmp-amdgcn-amd-amdhsa-gfx803={{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4459,9 +4459,7 @@
   bool IsDeviceOffloadAction = !(JA.isDeviceOffloading(Action::OFK_None) ||
  JA.isDeviceOffloading(Action::OFK_Host));
   bool IsHostOffloadingAction =
-  (JA.isHostOffloading(Action::OFK_OpenMP) &&
-   Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true)) ||
+  JA.isHostOffloading(Action::OFK_OpenMP) ||
   (JA.isHostOffloading(C.getActiveOffloadKinds()) &&
Args.hasFlag(options::OPT_offload_new_driver,
 options::OPT_no_offload_new_driver, false));
@@ -4762,9 +4760,7 @@
 
 if (IsUsingLTO) {
   // Only AMDGPU supports device-side LTO.
-  if (IsDeviceOffloadAction &&
-  !Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true) &&
+  if (IsDeviceOffloadAction && !JA.isHostOffloading(Action::OFK_OpenMP) &&
   !Args.hasFlag(options::OPT_offload_new_driver,
 options::OPT_no_offload_new_driver, false) &&
   !Triple.isAMDGPU()) {
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -3902,9 +3902,7 @@
   OffloadingActionBuilder OffloadBuilder(C, Args, Inputs);
 
   bool UseNewOffloadingDriver =
-  (C.isOffloadingHostKind(Action::OFK_OpenMP) &&
-   Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true)) ||
+  C.isOffloadingHostKind(Action::OFK_OpenMP) ||
   Args.hasFlag(options::OPT_offload_new_driver,
options::OPT_no_offload_new_driver, false);
 
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -2181,10 +2181,6 @@
 
 Set rpath on OpenMP executables
 
-.. option:: -fopenmp-new-driver
-
-Use the new driver for OpenMP offloading.
-
 .. option:: -fopenmp-offload-mandatory
 
 Do not create a host fallback if offloading to the device fails.


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-ope

[PATCH] D133249: [libc++] Documents details of the pre-commit CI.

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.

This is awesome. I have some comments, but I have not done an in-depth pass at 
this yet.




Comment at: libcxx/docs/Contributing.rst:139
+
+.. [#] There's `Dev meeting talk 
`__
+   explaining the benefits of libc++'s pre-commit CI.





Comment at: libcxx/docs/Contributing.rst:142
+
+Builds
+--

It feels like this whole section might be prone to becoming out of date. I'm 
not sure how useful it is since the jobs are pretty self-explanatory. Perhaps 
it is sufficient to link to `run-buildbot` and `buildkite-pipeline.yml`?



Comment at: libcxx/docs/Contributing.rst:145
+
+Below a short description of the most interesting CI builds [#]_:
+




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133249

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

[PATCH] D132797: [clangd] Support renaming virtual methods

[Tom Praschan via Phabricator via cfe-commits]

tom-anders updated this revision to Diff 458221.
tom-anders added a comment.

Add test case that triggers assertion, limit recursion


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132797

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

Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -886,12 +886,6 @@
  @end
)cpp",
"not a supported kind", HeaderFile},
-  {R"cpp(// FIXME: rename virtual/override methods is not supported yet.
- struct A {
-  virtual void f^oo() {}
- };
-  )cpp",
-   "not a supported kind", !HeaderFile},
   {R"cpp(
  void foo(int);
  void foo(char);
@@ -1490,6 +1484,44 @@
 }
   )cpp",
   },
+  {
+  // virtual methods.
+  R"cpp(
+class Base {
+  virtual void [[foo]]();
+};
+class Derived1 : public Base {
+  void [[f^oo]]() override;
+};
+class NotDerived {
+  void foo() {};
+}
+  )cpp",
+  R"cpp(
+#include "foo.h"
+void Base::[[foo]]() {}
+void Derived1::[[foo]]() {}
+
+class Derived2 : public Derived1 {
+  void [[foo]]() override {};
+};
+
+void func(Base* b, Derived1* d1, 
+  Derived2* d2, NotDerived* nd) {
+  b->[[foo]]();
+  d1->[[foo]]();
+  d2->[[foo]]();
+  nd->foo();
+}
+  )cpp",
+  },
+  {
+  // virtual templated method
+  R"cpp(
+template  class Foo { virtual void [[m]](); };
+class Bar : Foo { void [[^m]]() override; };
+  )cpp", ""
+  },
   {
   // rename on constructor and destructor.
   R"cpp(
Index: clang-tools-extra/clangd/refactor/Rename.cpp
===
--- clang-tools-extra/clangd/refactor/Rename.cpp
+++ clang-tools-extra/clangd/refactor/Rename.cpp
@@ -214,13 +214,6 @@
   IsMainFileOnly))
 return ReasonToReject::NonIndexable;
 
-
-  // FIXME: Renaming virtual methods requires to rename all overridens in
-  // subclasses, our index doesn't have this information.
-  if (const auto *S = llvm::dyn_cast(&RenameDecl)) {
-if (S->isVirtual())
-  return ReasonToReject::UnsupportedSymbol;
-  }
   return None;
 }
 
@@ -551,6 +544,35 @@
   return R;
 }
 
+// Walk down from a virtual method to overriding methods, we rename them as a
+// group. Note that canonicalRenameDecl() ensures we're starting from the base
+// method.
+void recursivelyInsertOverrides(SymbolID Base, llvm::DenseSet &IDs,
+const SymbolIndex &Index,
+llvm::DenseSet &Pending) {
+  // By keeping track of symbols we've already visited (Pending), the number of
+  // requests is bounded by the length of the shortest chain to the most
+  // distance SymbolID
+  while (!Pending.empty()) {
+RelationsRequest Req;
+Req.Predicate = RelationKind::OverriddenBy;
+Req.Subjects = Pending;
+Pending.clear();
+
+Index.relations(Req, [&](const SymbolID &, const Symbol &Override) {
+  IDs.insert(Override.ID);
+  Pending.insert(Override.ID);
+  recursivelyInsertOverrides(Override.ID, IDs, Index, Pending);
+});
+  }
+}
+
+void recursivelyInsertOverrides(SymbolID Base, llvm::DenseSet &IDs,
+const SymbolIndex &Index) {
+  llvm::DenseSet Pending = {Base};
+  recursivelyInsertOverrides(Base, IDs, Index, Pending);
+}
+
 // Return all rename occurrences (using the index) outside of the main file,
 // grouped by the absolute file path.
 llvm::Expected>>
@@ -561,6 +583,10 @@
   RefsRequest RQuest;
   RQuest.IDs.insert(getSymbolID(&RenameDecl));
 
+  if (const auto *MethodDecl = llvm::dyn_cast(&RenameDecl))
+if (MethodDecl->isVirtual())
+  recursivelyInsertOverrides(*RQuest.IDs.begin(), RQuest.IDs, Index);
+
   // Absolute file path => rename occurrences in that file.
   llvm::StringMap> AffectedFiles;
   bool HasMore = Index.refs(RQuest, [&](const Ref &R) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133367: [OpenMP] Remove use of removed '-f[no-]openmp-new-driver' flag

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:3906
-  (C.isOffloadingHostKind(Action::OFK_OpenMP) &&
-   Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true)) ||

The option still exists in the `Options.td` file. Should it be removed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133367

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

[PATCH] D132797: [clangd] Support renaming virtual methods

[Tom Praschan via Phabricator via cfe-commits]

tom-anders marked 6 inline comments as done.
tom-anders added inline comments.



Comment at: clang-tools-extra/clangd/refactor/Rename.cpp:245
   trace::Span Tracer("FindOccurrencesWithinFile");
   assert(canonicalRenameDecl(&ND) == &ND &&
  "ND should be already canonicalized.");

sammccall wrote:
> Unfortunately we've uncovered a bug: this assertion fires (after this patch) 
> on the following code:
> 
> ```
> template  class Foo { virtual void m(); };
> class Bar : Foo { void ^m() override; };
> ```
> 
> `canonicalRenameDecl` is supposed to be idempotent. 
> However:`canonicalRenameDecl(Bar::m)` is `Foo::m`, but 
> `canonicalRenameDecl(Foo::m)` is `Foo::m`.
> 
> I think this is because the `getInstantiatedFromMemberFunction` check comes 
> before the `overridden_methods` check, so if the override points to a member 
> of an instantiation then it's too late to map it back to the member of the 
> template.
> 
> Probably the best fix is to change line 103 to a recursive `return 
> canonicalRenameDecl(...)`, as is done elsewhere in the function.
> 
> (Can you please add this case to the tests?)
I added the test case for this. However, your suggested fix doesn't seem to 
stop the assertion from being triggered. I'd be grateful if you can take a 
closer look at this in a separate review - Should I leave the test case in 
anyway? Is it okay if the test fails for a while until you found the fix?



Comment at: clang-tools-extra/clangd/refactor/Rename.cpp:554
+  Req.Subjects = {Base};
+  Index.relations(Req, [&](const SymbolID &, const Symbol &Override) {
+IDs.insert(Override.ID);

ilya-biryukov wrote:
> sammccall wrote:
> > ilya-biryukov wrote:
> > > Should we put a limit on the number of requests we send during recursion 
> > > here?
> > > 
> > > I see a few obvious failure modes:
> > > - infinite recursion in the relations due to parts of index being stale, 
> > > corrupted input data or other reasons,
> > > - exponential blow up in hierarchies with multiple inheritance,
> > > - sending a lot of network requests in case of deep inheritance 
> > > hierarchies for remote index implementations. Since all requests are 
> > > sequential, the network latency might add up to substantial numbers.
> > > 
> > > We could address these in some other manner, this just seems to be the 
> > > simplest option to protect against catastrophic outcomes (running the 
> > > request indefinitely, crashing due to infinite recursion, etc).
> > > exponential blow up in hierarchies with multiple inheritance,
> > 
> > It seems with little loss of readability we could provide some useful 
> > bounds:
> > 
> > ```
> > DenseSet Pending = {Base};
> > while (!Pending.empty()) {
> >   Req = {.Subjects = Pending};
> >   Pending.clear();
> >   Index.relations(Req, { IDs.insert(ID); Pending.insert(ID) });
> > }
> > ```
> > in this case the #requests is clearly bounded by the length of the shortest 
> > chain to the most distant SymbolID, and is IMO safe with no numeric cap.
> > 
> > whereas the current version could potentially get the same ID in multiple 
> > branches and so the bound on #requests is harder to determine.
> This looks good! Also avoids infinite recursion.
> Having a potentially large number of sequential network requests still looks 
> unfortunate, but I doubt this will bite us in practice (at least not for 
> remote indicies for LLVM and Chrome).
> 
> To solve it, we could allow recursive requests and implement the recursion 
> inside the index, but this could be done with a follow-up when we actually 
> hit this issue.
Done, hope I interpreted your sketch correctly


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132797

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

[PATCH] D133367: [OpenMP] Remove use of removed '-f[no-]openmp-new-driver' flag

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:3906
-  (C.isOffloadingHostKind(Action::OFK_OpenMP) &&
-   Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true)) ||

tra wrote:
> The option still exists in the `Options.td` file. Should it be removed?
Generally we don't remove the options once they've been defined (between 
releases), as this would result in some applications failing to compile after 
switching from LLVM 15 to LLVM 16 for example. If we just leave it there then 
it will exist as a warning saying that the flag was unused.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133367

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

[PATCH] D133367: [OpenMP] Remove use of removed '-f[no-]openmp-new-driver' flag

[Artem Belevich via Phabricator via cfe-commits]

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



Comment at: clang/lib/Driver/Driver.cpp:3906
-  (C.isOffloadingHostKind(Action::OFK_OpenMP) &&
-   Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true)) ||

jhuber6 wrote:
> tra wrote:
> > The option still exists in the `Options.td` file. Should it be removed?
> Generally we don't remove the options once they've been defined (between 
> releases), as this would result in some applications failing to compile after 
> switching from LLVM 15 to LLVM 16 for example. If we just leave it there then 
> it will exist as a warning saying that the flag was unused.
SGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133367

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

[clang] 57ef29f - [OpenMP] Remove use of removed '-f[no-]openmp-new-driver' flag

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-09-06T13:40:05-05:00
New Revision: 57ef29f2835eb594bc2ad4793df05188be4c2ef6

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

LOG: [OpenMP] Remove use of removed '-f[no-]openmp-new-driver' flag

The changes in D130020 removed all support for the old method of
compiling OpenMP offloading programs. This means that
`-fopenmp-new-driver` has no effect and `-fno-openmp-new-driver` does
not work. This patch removes the use and documentation of this flag.
Note that the `--offload-new-driver` flag still exists for using the new
driver optionally with CUDA and HIP.

Reviewed By: tra

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

Added: 


Modified: 
clang/docs/ClangCommandLineReference.rst
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/amdgpu-openmp-toolchain.c

Removed: 




diff  --git a/clang/docs/ClangCommandLineReference.rst 
b/clang/docs/ClangCommandLineReference.rst
index 141c1464638a5..a7dc0634e97c0 100644
--- a/clang/docs/ClangCommandLineReference.rst
+++ b/clang/docs/ClangCommandLineReference.rst
@@ -2181,10 +2181,6 @@ Enable all Clang extensions for OpenMP directives and 
clauses
 
 Set rpath on OpenMP executables
 
-.. option:: -fopenmp-new-driver
-
-Use the new driver for OpenMP offloading.
-
 .. option:: -fopenmp-offload-mandatory
 
 Do not create a host fallback if offloading to the device fails.

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 3743515d3d43f..36fba5d91eaf4 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -3902,9 +3902,7 @@ void Driver::BuildActions(Compilation &C, DerivedArgList 
&Args,
   OffloadingActionBuilder OffloadBuilder(C, Args, Inputs);
 
   bool UseNewOffloadingDriver =
-  (C.isOffloadingHostKind(Action::OFK_OpenMP) &&
-   Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true)) ||
+  C.isOffloadingHostKind(Action::OFK_OpenMP) ||
   Args.hasFlag(options::OPT_offload_new_driver,
options::OPT_no_offload_new_driver, false);
 

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 99a8642cfd85b..d39f8715c7a19 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4459,9 +4459,7 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
   bool IsDeviceOffloadAction = !(JA.isDeviceOffloading(Action::OFK_None) ||
  JA.isDeviceOffloading(Action::OFK_Host));
   bool IsHostOffloadingAction =
-  (JA.isHostOffloading(Action::OFK_OpenMP) &&
-   Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true)) ||
+  JA.isHostOffloading(Action::OFK_OpenMP) ||
   (JA.isHostOffloading(C.getActiveOffloadKinds()) &&
Args.hasFlag(options::OPT_offload_new_driver,
 options::OPT_no_offload_new_driver, false));
@@ -4762,9 +4760,7 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
 
 if (IsUsingLTO) {
   // Only AMDGPU supports device-side LTO.
-  if (IsDeviceOffloadAction &&
-  !Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true) &&
+  if (IsDeviceOffloadAction && !JA.isHostOffloading(Action::OFK_OpenMP) &&
   !Args.hasFlag(options::OPT_offload_new_driver,
 options::OPT_no_offload_new_driver, false) &&
   !Triple.isAMDGPU()) {

diff  --git a/clang/test/Driver/amdgpu-openmp-toolchain.c 
b/clang/test/Driver/amdgpu-openmp-toolchain.c
index 1551917ea50f0..50ce8e5d1b1fe 100644
--- a/clang/test/Driver/amdgpu-openmp-toolchain.c
+++ b/clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -49,5 +49,5 @@
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -emit-llvm -S -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-EMIT-LLVM-IR
 // CHECK-EMIT-LLVM-IR: "-cc1" "-triple" "amdgcn-amd-amdhsa"{{.*}}"-emit-llvm"
 
-// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode 
-fopenmp-new-driver %s 2>&1 | FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
+// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode %s 2>&1 
| FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
 // CHECK-LIB-DEVICE-NEW: 
{{.*}}clang-linker-wrapper{{.*}}-

[PATCH] D133367: [OpenMP] Remove use of removed '-f[no-]openmp-new-driver' flag

[Joseph Huber via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG57ef29f2835e: [OpenMP] Remove use of removed 
'-f[no-]openmp-new-driver' flag (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133367

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/amdgpu-openmp-toolchain.c


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -49,5 +49,5 @@
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -emit-llvm -S -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-EMIT-LLVM-IR
 // CHECK-EMIT-LLVM-IR: "-cc1" "-triple" "amdgcn-amd-amdhsa"{{.*}}"-emit-llvm"
 
-// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode 
-fopenmp-new-driver %s 2>&1 | FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
+// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -lm --rocm-device-lib-path=%S/Inputs/rocm/amdgcn/bitcode %s 2>&1 
| FileCheck %s --check-prefix=CHECK-LIB-DEVICE-NEW
 // CHECK-LIB-DEVICE-NEW: 
{{.*}}clang-linker-wrapper{{.*}}--bitcode-library=openmp-amdgcn-amd-amdhsa-gfx803={{.*}}ocml.bc"{{.*}}ockl.bc"{{.*}}oclc_daz_opt_on.bc"{{.*}}oclc_unsafe_math_off.bc"{{.*}}oclc_finite_only_off.bc"{{.*}}oclc_correctly_rounded_sqrt_on.bc"{{.*}}oclc_wavefrontsize64_on.bc"{{.*}}oclc_isa_version_803.bc"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4459,9 +4459,7 @@
   bool IsDeviceOffloadAction = !(JA.isDeviceOffloading(Action::OFK_None) ||
  JA.isDeviceOffloading(Action::OFK_Host));
   bool IsHostOffloadingAction =
-  (JA.isHostOffloading(Action::OFK_OpenMP) &&
-   Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true)) ||
+  JA.isHostOffloading(Action::OFK_OpenMP) ||
   (JA.isHostOffloading(C.getActiveOffloadKinds()) &&
Args.hasFlag(options::OPT_offload_new_driver,
 options::OPT_no_offload_new_driver, false));
@@ -4762,9 +4760,7 @@
 
 if (IsUsingLTO) {
   // Only AMDGPU supports device-side LTO.
-  if (IsDeviceOffloadAction &&
-  !Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true) &&
+  if (IsDeviceOffloadAction && !JA.isHostOffloading(Action::OFK_OpenMP) &&
   !Args.hasFlag(options::OPT_offload_new_driver,
 options::OPT_no_offload_new_driver, false) &&
   !Triple.isAMDGPU()) {
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -3902,9 +3902,7 @@
   OffloadingActionBuilder OffloadBuilder(C, Args, Inputs);
 
   bool UseNewOffloadingDriver =
-  (C.isOffloadingHostKind(Action::OFK_OpenMP) &&
-   Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_no_offload_new_driver, true)) ||
+  C.isOffloadingHostKind(Action::OFK_OpenMP) ||
   Args.hasFlag(options::OPT_offload_new_driver,
options::OPT_no_offload_new_driver, false);
 
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -2181,10 +2181,6 @@
 
 Set rpath on OpenMP executables
 
-.. option:: -fopenmp-new-driver
-
-Use the new driver for OpenMP offloading.
-
 .. option:: -fopenmp-offload-mandatory
 
 Do not create a host fallback if offloading to the device fails.


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -49,5 +49,5 @@
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -emit-llvm -S -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-EMIT-LLVM-IR
 // CHECK-EMIT-LLVM-IR: "-cc1" "-triple" "amdgcn-amd-amdhsa"{{.*}}"-emit-llvm"
 
-// RUN: %clang -### -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx803 -lm --

[PATCH] D133289: [C2X] N3007 Type inference for object definitions

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added a comment.

The proposal has several nice tests and I don't they are all covered here e.g.:

  {
double a = 7;
double b = 9;
{
  double b = b * b;   // undefined, uses uninitialized variable without 
address


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133289

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

[PATCH] D133249: [libc++] Documents details of the pre-commit CI.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Thank you for working on this!




Comment at: clang/www/hacking.html:33
 Testing on the Command Line
+Testing changes affecting libcxx
   

Similar capitalization is used in the file.



Comment at: clang/www/hacking.html:292
+  https://buildkite.com/llvm-project/libcxx-ci";>pre-commit CI.
+  This can simply be done by adding a dummy file in the libcxx directory before
+  submitting or updating a patch in Phabricator. This change in the libxx





Comment at: clang/www/hacking.html:293
+  This can simply be done by adding a dummy file in the libcxx directory before
+  submitting or updating a patch in Phabricator. This change in the libxx
+  directory will cause the update of the diff to start a CI run. This dummy





Comment at: clang/www/hacking.html:295-296
+  directory will cause the update of the diff to start a CI run. This dummy
+  file will also add the libc++ group to the list of reviewers. The status of
+  the build will be available in Phabricator.
+

I am guessing the dummy file should then be removed before landing the commit 
and we should document that?

(FWIW, adding a dummy file feels really unclean as a design -- it's mysterious 
behavior for new contributors, which the documentation helps with a bit, but 
also it's a risk for checking in files that are never intended to be in the 
tree. If there's a way to improve this somehow so we don't need to trick the 
precommit CI into running, that would be really nice and totally outside of the 
scope of this review.)



Comment at: clang/www/hacking.html:300
+  CI lacks the resources to build every Clang diff. A single run takes about
+  one hour. Secondly most changes of Clang won't affect libc++.
+

philnik wrote:
> Having a secondly without a firstly seems weird.
+1 to the "secondly" being a bit weird, but also pushing back a bit on the 
assertion that most changes in Clang won't affect libc++: we change the output 
of Clang's diagnostics on an almost-daily basis.

I think it's honest to say: "It is difficult to determine which changes in 
Clang will affect libc++ and running the precommit CI in all circumstances is 
prohibitively resource intensive given how actively the project is updated." or 
something along those lines.



Comment at: clang/www/hacking.html:311-312
+  Unlike Clang, libc++ supports multiple versions of Clang. Therefore when a
+  patch changes the diagnostics it might be required to use a regex in the
+  "expected" tests to make it pass the CI.
+

Should we document the expectation that breaking libc++ due to conforming 
changes in Clang (in terms of diagnostics and bug fixes, not so much in terms 
of introducing new language extensions) are generally the responsibility of 
libc++ maintainers to address, but Clang contributors should attempt to reduce 
disruptions as much as possible by collaborating with libc++ maintainers when 
this situation comes up?



Comment at: libcxx/docs/Contributing.rst:87
 
-* C++20 for the Linux platform.
-* MacOS C++20 for the Apple platform.
+* C++XX for the Linux platform (where XX is the latest C++ version).
+* MacOS X86_64 and MacOS arm64 for the Apple platform.

philnik wrote:
> Complete nit, but `XX` reads to me like the digits have to be the same. I'd 
> suggest `XY` to make it obvious that they can be different.
Or you could go with something along the lines of `C++`.



Comment at: libcxx/docs/Contributing.rst:107
+
+The CI tests libc++ for all :ref:`supported platforms `.
+The build is started for every diff uploaded. A complete CI run takes

philnik wrote:
> Not really currently. We still claim FreeBSD support without a CI runner.
Also, do I remember correctly that Windows testing is not done on a CI runner 
for libc++?



Comment at: libcxx/docs/Contributing.rst:114
+
+Typically the libc++ jobs use a Ubuntu Docker image. This image contains
+recent `nightly builds `__ of all supported versions of





Comment at: libcxx/docs/Contributing.rst:119-121
+Unless specified otherwise the ``main`` version of Clang is used.
+
+Unless specified otherwise the tests are executed for the latest C++

mstorsjo wrote:
> Mordante wrote:
> > mstorsjo wrote:
> > > I don't understand this paragraph - each CI run is run through the 
> > > configured set of supported Clang versions - not only `main`? Or does 
> > > this talk about specifics about manually running tests with the Docker 
> > > image?
> > This is the version of Clang in the main branch. How about:
> > `Unless specified otherwise the nightly build of Clang from the ``main`` 
> > branch is used.`
> I still don't quite understand what this tries to say.

[PATCH] D133371: [clang-tidy][WIP] create API for extracting option types.

[Nathan James via Phabricator via cfe-commits]

njames93 created this revision.
njames93 added reviewers: aaron.ballman, LegalizeAdulthood, gribozavr2, 
JonasToth.
Herald added subscribers: carlosgalvezp, mgrang, kbarton, xazax.hun, nemanjai.
Herald added a project: All.
njames93 requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

Create an API as well as a command line option that dump all available check 
options as well as allowed values.
This infrastructure should drastically simplify 3rd party tools that would like 
to use clang-tidy but would prefer to handle options themselves, rather than 
letting users write their own .clang-tidy configuration files.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133371

Files:
  clang-tools-extra/clang-tidy/ClangTidy.cpp
  clang-tools-extra/clang-tidy/ClangTidy.h
  clang-tools-extra/clang-tidy/ClangTidyCheck.cpp
  clang-tools-extra/clang-tidy/ClangTidyCheck.h
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h
  clang-tools-extra/clang-tidy/abseil/StringFindStartswithCheck.cpp
  clang-tools-extra/clang-tidy/abseil/StringFindStrContainsCheck.cpp
  clang-tools-extra/clang-tidy/android/ComparisonInTempFailureRetryCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/AssertSideEffectCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/DanglingHandleCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/DynamicStaticInitializersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/ReservedIdentifierCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SignedCharMisuseCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/StringConstructorCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SuspiciousIncludeCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SuspiciousStringCompareCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/UnusedReturnValueCheck.cpp
  clang-tools-extra/clang-tidy/cert/NonTrivialTypesLibcMemoryCallsCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/NarrowingConversionsCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/NoMallocCheck.h
  clang-tools-extra/clang-tidy/cppcoreguidelines/OwningMemoryCheck.h
  clang-tools-extra/clang-tidy/google/GlobalNamesInHeadersCheck.cpp
  clang-tools-extra/clang-tidy/google/UnnamedNamespaceInHeaderCheck.cpp
  clang-tools-extra/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseEmplaceCheck.cpp
  clang-tools-extra/clang-tidy/objc/ForbiddenSubclassingCheck.cpp
  clang-tools-extra/clang-tidy/performance/FasterStringFindCheck.cpp
  clang-tools-extra/clang-tidy/performance/ForRangeCopyCheck.cpp
  clang-tools-extra/clang-tidy/performance/InefficientVectorOperationCheck.cpp
  clang-tools-extra/clang-tidy/performance/NoAutomaticMoveCheck.cpp
  clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
  clang-tools-extra/clang-tidy/performance/UnnecessaryValueParamCheck.cpp
  clang-tools-extra/clang-tidy/readability/MagicNumbersCheck.cpp
  clang-tools-extra/clang-tidy/readability/RedundantStringInitCheck.cpp
  clang-tools-extra/clang-tidy/readability/SimplifySubscriptExprCheck.cpp
  clang-tools-extra/clang-tidy/readability/SuspiciousCallArgumentCheck.cpp
  clang-tools-extra/clang-tidy/readability/UppercaseLiteralSuffixCheck.cpp
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
  clang-tools-extra/clang-tidy/utils/HeaderGuard.h

Index: clang-tools-extra/clang-tidy/utils/HeaderGuard.h
===
--- clang-tools-extra/clang-tidy/utils/HeaderGuard.h
+++ clang-tools-extra/clang-tidy/utils/HeaderGuard.h
@@ -28,7 +28,7 @@
 public:
   HeaderGuardCheck(StringRef Name, ClangTidyContext *Context)
   : ClangTidyCheck(Name, Context),
-RawStringHeaderFileExtensions(Options.getLocalOrGlobal(
+RawStringHeaderFileExtensions(Options.getLocalOrGlobalList(
 "HeaderFileExtensions", utils::defaultHeaderFileExtensions())) {
 utils::parseFileExtensions(RawStringHeaderFileExtensions,
HeaderFileExtensions,
Index: clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
@@ -19,6 +19,7 @@
 #include "../ClangTidyForceLinker.h"
 #include "../GlobList.h"
 #include "clang/Tooling/CommonOptionsParser.h"
+#include "clang/Tooling/Syntax/Nodes.h"
 #include "llvm/ADT/StringSet.h"
 #include "llvm/Support/InitLLVM.h"
 #include "llvm/Support/PluginLoader.h"
@@ -26,6 +27,7 @@
 #include "llvm/Support/Signals.h"
 #include "llvm/Support/TargetSelect.h"
 #include "llvm/Support/WithColor.h"
+#include "llvm/Support/raw_ostream.h"
 
 using namespace clang::tooling;
 using namespace llvm;
@@ -262,6 +264,17 @@
 )"),
   cl::init(false), cl::cat(ClangTidyCategory));
 
+static cl::opt

[clang] 3a62399 - [OpenMP] Fix logic error when building offloading applications

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-09-06T13:56:24-05:00
New Revision: 3a623999f3ff96843f97ee300e0c94b8cbc88a9f

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

LOG: [OpenMP] Fix logic error when building offloading applications

Summary:
A previous patch removed support for the `-fopenmp-new-driver` and
accidentally used the `isHostOffloading` flag instead of
`isDeviceOffloading` which lead to some build errors when compiling for
the offloading device. This patch addresses that.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index d39f8715c7a1..d3b5f82cb5c2 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4760,7 +4760,7 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
 
 if (IsUsingLTO) {
   // Only AMDGPU supports device-side LTO.
-  if (IsDeviceOffloadAction && !JA.isHostOffloading(Action::OFK_OpenMP) &&
+  if (IsDeviceOffloadAction && !JA.isDeviceOffloading(Action::OFK_OpenMP) 
&&
   !Args.hasFlag(options::OPT_offload_new_driver,
 options::OPT_no_offload_new_driver, false) &&
   !Triple.isAMDGPU()) {



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

[PATCH] D132952: [Sema] disable -Wvla for function array parameters

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/test/Sema/warn-vla.c:8-12
+void test2(int n, int v[n]) { // c99 no-warning
+#if __STDC_VERSION__ < 199901L
+// expected-warning@-2{{variable length arrays are a C99 feature}}
+#endif
 }

aaron.ballman wrote:
> efriedma wrote:
> > aaron.ballman wrote:
> > > efriedma wrote:
> > > > aaron.ballman wrote:
> > > > > aaron.ballman wrote:
> > > > > > inclyc wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > The diagnostic there is rather unfortunate because we're not 
> > > > > > > > using a variable-length array in this case.
> > > > > > > Emm, I'm not clear about whether we should consider this a VLA, 
> > > > > > > and generates `-Wvla-extensions`. Is `v[n]` literally a 
> > > > > > > variable-length array? (in source code) So it seems to me that we 
> > > > > > > should still report c89 incompatibility warnings?
> > > > > > > 
> > > > > > C89's grammar only allowed for an integer constant expression to 
> > > > > > (optionally) appear as the array extent in an array declarator, so 
> > > > > > there is a compatibility warning needed for that. But I don't think 
> > > > > > we should issue a warning about this being a VLA in C99 or later. 
> > > > > > The array *is* a VLA in terms of the form written in the source, 
> > > > > > but C adjusts the parameter to be a pointer parameter, so as far as 
> > > > > > the function's type is concerned, it's not a VLA (it's just a 
> > > > > > self-documenting interface).
> > > > > > 
> > > > > > Because self-documenting code is nice and because people are 
> > > > > > worried about accidental use of VLAs that cause stack allocations 
> > > > > > (which this does not), I think we don't want to scare people off 
> > > > > > from this construct. But I'm curious what others think as well.
> > > > > > But I'm curious what others think as well.
> > > > > 
> > > > > (Specifically, I'm wondering if others agree that the only warning 
> > > > > that should be issued there is a C89 compatibility warning under 
> > > > > `-Wvla-extensions` when in C89 mode and via a new `CPre99Compat` 
> > > > > diagnostic group when enabled in C99 and later modes.)
> > > > > 
> > > > > 
> > > > I imagine people working with codebases that are also built with 
> > > > compilers that don't support VLAs would still want some form of warning 
> > > > on any VLA type.
> > > The tricky part is: that's precisely what WG14 N2992 
> > > (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2992.pdf) is 
> > > clarifying. If your implementation doesn't support VLAs, it's still 
> > > required to support this syntactic form. So the question becomes: do we 
> > > want a portability warning to compilers that don't conform to the 
> > > standard? Maybe we do (if we can find evidence of compilers in such a 
> > > state), but probably under a specific diagnostic flag rather than -Wvla.
> > That only applies to C23, though, right?  None of that wording is there for 
> > C11.  (In particular, MSVC claims C11 conformance without any support for 
> > VLA types.)
> In a strict sense, yes, this is a C23 change. There are no changes to older 
> standards as far as ISO is concerned (and there never have been).
> 
> In a practical sense, no, this is clarifying how VLAs have always been 
> intended to work. C23 is in a really weird spot in that we had to stop our 
> "defect report" process at the end of C17 because the ISO definition of a 
> defect did not match the WG14 definition of a defect, and ISO got upset. 
> Towards the tail end of the C23 cycle, we introduced a list of extensions to 
> obsolete versions of C 
> (https://www.open-std.org/jtc1/sc22/wg14/www/previous.html) as a stopgap, but 
> the convener would not allow us to retroactively add papers to it. The 
> committee still hasn't gotten used to this new process and as a result, not 
> many papers have made it to the list. We've also not had the chance to 
> discuss https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3002.pdf on having 
> a more reasonable issue tracking process.
> 
> The end result is that there's a whole pile of papers in C23 that we would 
> have normally treated via the old defect report process but couldn't, and if 
> we had treated them via the old DR process, it would have been more clear why 
> I think this should be a retroactive change back to C99 instead of a C23-only 
> change.
Even if the committee can make retroactive changes to standards, that doesn't 
change the fact that MSVC doesn't support VLAs, and that codebases exist which 
need to be compiled with both clang and MSVC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132952

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

[clang] 28bc410 - [DOC][Clang] Update cxx_status.html after the 15 release and fix a broken link in release notes

[Roy Jacobson via cfe-commits]

Author: Roy Jacobson
Date: 2022-09-06T21:59:27+03:00
New Revision: 28bc41099970f5cdab0addc60cc96b115ce657f8

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

LOG: [DOC][Clang] Update cxx_status.html after the 15 release and fix a broken 
link in release notes

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/www/cxx_status.html

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 1d381649b6bb4..4a418e976bd4f 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -215,7 +215,7 @@ C++20 Feature Support
   `GH55216 `_.
 - Correctly set expression evaluation context as 'immediate function context' 
in
   consteval functions.
-  This fixes `GH51182 `
+  This fixes `GH51182 `_.
 
 - Fixes an assert crash caused by looking up missing vtable information on 
``consteval``
   virtual functions. Fixes `GH55065 
`_.

diff  --git a/clang/www/cxx_status.html b/clang/www/cxx_status.html
index 5876e39a0b536..e9a71bba7a0b8 100755
--- a/clang/www/cxx_status.html
+++ b/clang/www/cxx_status.html
@@ -1128,7 +1128,7 @@ C++20 implementation status
 
   Immediate functions (consteval)
   https://wg21.link/p1073r3";>P1073R3
-  Clang 15
+  Clang 15
 

 https://wg21.link/p1937r2";>P1937R2
@@ -1172,7 +1172,7 @@ C++20 implementation status
 
   Modules
   https://wg21.link/p1103r3";>P1103R3
-  Clang 15
+  Clang 15
 

 https://wg21.link/p1766r1";>P1766R1 (DR)
@@ -1188,7 +1188,7 @@ C++20 implementation status
   

 https://wg21.link/p1874r1";>P1874R1
-Clang 15
+Clang 15
   

 https://wg21.link/p1979r0";>P1979R0
@@ -1196,7 +1196,7 @@ C++20 implementation status
   

 https://wg21.link/p1779r3";>P1779R3
-Clang 15
+Clang 15
   
   
 https://wg21.link/p1857r3";>P1857R3
@@ -1370,12 +1370,12 @@ C++2b implementation status
 
   Multidimensional subscript operator
   https://wg21.link/P2128R6";>P2128R6
-  Clang 15
+  Clang 15
 
 
   Non-literal variables (and labels and gotos) in constexpr 
functions
   https://wg21.link/P2242R3";>P2242R3
-  Clang 15
+  Clang 15
 
 
   Character encoding of diagnostic text
@@ -1405,7 +1405,7 @@ C++2b implementation status
 
   auto(x): decay-copy in the language
   https://wg21.link/P0849R8";>P0849R8
-  Clang 15
+  Clang 15
 
 
 
@@ -1441,7 +1441,7 @@ C++2b implementation status
 
   De-deprecating volatile compound operations
   https://wg21.link/P2327R1";>P2327R1
-  Clang 15
+  Clang 15
 
 
   Support for #warning
@@ -1461,12 +1461,12 @@ C++2b implementation status
 
   Delimited escape sequences
   https://wg21.link/P2290R3";>P2290R3
-  Clang 15
+  Clang 15
 
 
   Named universal character escapes
   https://wg21.link/P2071R2";>P2071R2
-  Clang 15
+  Clang 15
 
 
   Relaxing some constexpr restrictions
@@ -1501,7 +1501,7 @@ C++2b implementation status
 
   Support for UTF-8 as a portable source file encoding
   https://wg21.link/P2295R6";>P2295R6
-  Clang 15
+  Clang 15
 
 
   char8_t Compatibility and Portability Fix



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

[PATCH] D131939: [clang-tidy] Add performance-expensive-flat-container-operation check

[Nicolas van Kempen via Phabricator via cfe-commits]

nicovank added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131939

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

[PATCH] D133249: [libc++] Documents details of the pre-commit CI.

[Nikolas Klauser via Phabricator via cfe-commits]

philnik added inline comments.



Comment at: clang/www/hacking.html:295-296
+  directory will cause the update of the diff to start a CI run. This dummy
+  file will also add the libc++ group to the list of reviewers. The status of
+  the build will be available in Phabricator.
+

aaron.ballman wrote:
> I am guessing the dummy file should then be removed before landing the commit 
> and we should document that?
> 
> (FWIW, adding a dummy file feels really unclean as a design -- it's 
> mysterious behavior for new contributors, which the documentation helps with 
> a bit, but also it's a risk for checking in files that are never intended to 
> be in the tree. If there's a way to improve this somehow so we don't need to 
> trick the precommit CI into running, that would be really nice and totally 
> outside of the scope of this review.)
It would be great if just the bootstrapping build could be run on all clang 
reviews. That should show most problems with changes in clang. If there are any 
problems in libc++, fixing them would result in a full CI run. Having libc++ 
run against the patch would probably also be awesome as a smoke test for any 
clang changes.



Comment at: clang/www/hacking.html:311-312
+  Unlike Clang, libc++ supports multiple versions of Clang. Therefore when a
+  patch changes the diagnostics it might be required to use a regex in the
+  "expected" tests to make it pass the CI.
+

aaron.ballman wrote:
> Should we document the expectation that breaking libc++ due to conforming 
> changes in Clang (in terms of diagnostics and bug fixes, not so much in terms 
> of introducing new language extensions) are generally the responsibility of 
> libc++ maintainers to address, but Clang contributors should attempt to 
> reduce disruptions as much as possible by collaborating with libc++ 
> maintainers when this situation comes up?
That's definitely a good idea. Maybe mention that clang contributors should 
ping the #libc group to get the attention of libc++ contributors so we can 
prepare a follow-up patch or, if the author is comfortable with it, also fix 
libc++ in the same patch (and hopefully get fast approval). Most breakages 
should be relatively simple to fix.



Comment at: libcxx/docs/Contributing.rst:107
+
+The CI tests libc++ for all :ref:`supported platforms `.
+The build is started for every diff uploaded. A complete CI run takes

aaron.ballman wrote:
> philnik wrote:
> > Not really currently. We still claim FreeBSD support without a CI runner.
> Also, do I remember correctly that Windows testing is not done on a CI runner 
> for libc++?
Nope, we have full Windows coverage in the CI. This might have been the case 
some time before I started working on libc++, but it's definitely not the case 
anymore.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133249

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

[PATCH] D132952: [Sema] disable -Wvla for function array parameters

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/Sema/warn-vla.c:8-12
+void test2(int n, int v[n]) { // c99 no-warning
+#if __STDC_VERSION__ < 199901L
+// expected-warning@-2{{variable length arrays are a C99 feature}}
+#endif
 }

efriedma wrote:
> aaron.ballman wrote:
> > efriedma wrote:
> > > aaron.ballman wrote:
> > > > efriedma wrote:
> > > > > aaron.ballman wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > inclyc wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > The diagnostic there is rather unfortunate because we're not 
> > > > > > > > > using a variable-length array in this case.
> > > > > > > > Emm, I'm not clear about whether we should consider this a VLA, 
> > > > > > > > and generates `-Wvla-extensions`. Is `v[n]` literally a 
> > > > > > > > variable-length array? (in source code) So it seems to me that 
> > > > > > > > we should still report c89 incompatibility warnings?
> > > > > > > > 
> > > > > > > C89's grammar only allowed for an integer constant expression to 
> > > > > > > (optionally) appear as the array extent in an array declarator, 
> > > > > > > so there is a compatibility warning needed for that. But I don't 
> > > > > > > think we should issue a warning about this being a VLA in C99 or 
> > > > > > > later. The array *is* a VLA in terms of the form written in the 
> > > > > > > source, but C adjusts the parameter to be a pointer parameter, so 
> > > > > > > as far as the function's type is concerned, it's not a VLA (it's 
> > > > > > > just a self-documenting interface).
> > > > > > > 
> > > > > > > Because self-documenting code is nice and because people are 
> > > > > > > worried about accidental use of VLAs that cause stack allocations 
> > > > > > > (which this does not), I think we don't want to scare people off 
> > > > > > > from this construct. But I'm curious what others think as well.
> > > > > > > But I'm curious what others think as well.
> > > > > > 
> > > > > > (Specifically, I'm wondering if others agree that the only warning 
> > > > > > that should be issued there is a C89 compatibility warning under 
> > > > > > `-Wvla-extensions` when in C89 mode and via a new `CPre99Compat` 
> > > > > > diagnostic group when enabled in C99 and later modes.)
> > > > > > 
> > > > > > 
> > > > > I imagine people working with codebases that are also built with 
> > > > > compilers that don't support VLAs would still want some form of 
> > > > > warning on any VLA type.
> > > > The tricky part is: that's precisely what WG14 N2992 
> > > > (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2992.pdf) is 
> > > > clarifying. If your implementation doesn't support VLAs, it's still 
> > > > required to support this syntactic form. So the question becomes: do we 
> > > > want a portability warning to compilers that don't conform to the 
> > > > standard? Maybe we do (if we can find evidence of compilers in such a 
> > > > state), but probably under a specific diagnostic flag rather than -Wvla.
> > > That only applies to C23, though, right?  None of that wording is there 
> > > for C11.  (In particular, MSVC claims C11 conformance without any support 
> > > for VLA types.)
> > In a strict sense, yes, this is a C23 change. There are no changes to older 
> > standards as far as ISO is concerned (and there never have been).
> > 
> > In a practical sense, no, this is clarifying how VLAs have always been 
> > intended to work. C23 is in a really weird spot in that we had to stop our 
> > "defect report" process at the end of C17 because the ISO definition of a 
> > defect did not match the WG14 definition of a defect, and ISO got upset. 
> > Towards the tail end of the C23 cycle, we introduced a list of extensions 
> > to obsolete versions of C 
> > (https://www.open-std.org/jtc1/sc22/wg14/www/previous.html) as a stopgap, 
> > but the convener would not allow us to retroactively add papers to it. The 
> > committee still hasn't gotten used to this new process and as a result, not 
> > many papers have made it to the list. We've also not had the chance to 
> > discuss https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3002.pdf on 
> > having a more reasonable issue tracking process.
> > 
> > The end result is that there's a whole pile of papers in C23 that we would 
> > have normally treated via the old defect report process but couldn't, and 
> > if we had treated them via the old DR process, it would have been more 
> > clear why I think this should be a retroactive change back to C99 instead 
> > of a C23-only change.
> Even if the committee can make retroactive changes to standards, that doesn't 
> change the fact that MSVC doesn't support VLAs, and that codebases exist 
> which need to be compiled with both clang and MSVC.
Such code bases are already supported: https://godbolt.org/z/7n768WKW7 but I 
take your point that not everyone writes portable code when trying to port 
between compilers, and so some form of diagnostic woul

[PATCH] D132977: [HLSL] Call global constructors inside entry

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/CodeGenHLSL/GlobalConstructors.hlsl:3
+
+RWBuffer Buffer;
+

Can you also add a test using `__attribute__((constructor))`? And probably one 
using `__attribute__((destructor))` at some point as well?

https://godbolt.org/z/jqedf1qGa

I see the docs said that global destructors are not supported, which is fine, 
but then what's the behavior when a user tries one anyway? (I would expect we'd 
get reasonable errors about it not being supported). Feel free to handle the 
dtor bits in a follow-up though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132977

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Fangrui Song via Phabricator via cfe-commits]

MaskRay updated this revision to Diff 458241.
MaskRay added a subscriber: sammccall.
MaskRay added a comment.
Herald added subscribers: kadircet, arphaman.
Herald added a project: clang-tools-extra.

Rebase. This shall fix a clang/test test.

Update clang-tools-extra/clangd/unittests/SelectionTests.cpp @sammccall


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

Files:
  clang-tools-extra/clangd/unittests/SelectionTests.cpp
  clang/docs/ReleaseNotes.rst
  clang/lib/Basic/LangStandards.cpp
  clang/test/Preprocessor/lang-std.cpp
  clang/test/Preprocessor/lang-std.cu
  clang/test/lit.cfg.py
  clang/test/lit.site.cfg.py.in

Index: clang/test/lit.site.cfg.py.in
===
--- clang/test/lit.site.cfg.py.in
+++ clang/test/lit.site.cfg.py.in
@@ -24,6 +24,7 @@
 config.clang_arcmt = @CLANG_ENABLE_ARCMT@
 config.clang_default_pie_on_linux = @CLANG_DEFAULT_PIE_ON_LINUX@
 config.clang_enable_opaque_pointers = @CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL@
+config.clang_default_std_cxx = "@CLANG_DEFAULT_STD_CXX@"
 config.clang_default_cxx_stdlib = "@CLANG_DEFAULT_CXX_STDLIB@"
 config.clang_staticanalyzer = @CLANG_ENABLE_STATIC_ANALYZER@
 config.clang_staticanalyzer_z3 = @LLVM_WITH_Z3@
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -131,6 +131,9 @@
 if config.clang_enable_opaque_pointers:
 config.available_features.add('enable-opaque-pointers')
 
+if config.clang_default_std_cxx != '':
+config.available_features.add('default-std-cxx')
+
 # Set available features we allow tests to conditionalize on.
 #
 if config.clang_default_cxx_stdlib != '':
Index: clang/test/Preprocessor/lang-std.cu
===
--- clang/test/Preprocessor/lang-std.cu
+++ /dev/null
@@ -1,7 +0,0 @@
-// RUN: %clang_cc1 -dM -E -x hip %s | FileCheck -check-prefix=CXX14 %s
-// RUN: %clang_cc1 -dM -E %s | FileCheck -check-prefix=CXX14 %s
-// RUN: %clang_cc1 -dM -E -std=c++98 -x hip %s | FileCheck -check-prefix=CXX98 %s
-// RUN: %clang_cc1 -dM -E -std=c++98 %s | FileCheck -check-prefix=CXX98 %s
-
-// CXX98: #define __cplusplus 199711L
-// CXX14: #define __cplusplus 201402L
Index: clang/test/Preprocessor/lang-std.cpp
===
--- /dev/null
+++ clang/test/Preprocessor/lang-std.cpp
@@ -0,0 +1,14 @@
+// UNSUPPORTED: default-std-cxx, ps4, ps5
+/// Test default standards when CLANG_DEFAULT_STD_CXX is unspecified.
+/// PS4/PS5 default to gnu++14.
+
+// RUN: %clang_cc1 -dM -E %s | FileCheck --check-prefix=CXX17 %s
+// RUN: %clang_cc1 -dM -E -x cuda %s | FileCheck --check-prefix=CXX14 %s
+// RUN: %clang_cc1 -dM -E -x hip %s | FileCheck --check-prefix=CXX14 %s
+
+// RUN: %clang_cc1 -dM -E -x cuda -std=c++14 %s | FileCheck --check-prefix=CXX14 %s
+// RUN: %clang_cc1 -dM -E -x hip -std=c++98 %s | FileCheck --check-prefix=CXX98 %s
+
+// CXX98: #define __cplusplus 199711L
+// CXX14: #define __cplusplus 201402L
+// CXX17: #define __cplusplus 201703L
Index: clang/lib/Basic/LangStandards.cpp
===
--- clang/lib/Basic/LangStandards.cpp
+++ clang/lib/Basic/LangStandards.cpp
@@ -75,10 +75,9 @@
 if (CLANG_DEFAULT_STD_CXX != LangStandard::lang_unspecified)
   return CLANG_DEFAULT_STD_CXX;
 
-if (T.isDriverKit())
-  return LangStandard::lang_gnucxx17;
-else
+if (T.isPS())
   return LangStandard::lang_gnucxx14;
+return LangStandard::lang_gnucxx17;
   case Language::RenderScript:
 return LangStandard::lang_c99;
   case Language::HIP:
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -188,6 +188,10 @@
 
 - Implemented DR692, DR1395 and DR1432. Use the ``-fclang-abi-compat=15`` option
   to get the old partial ordering behavior regarding packs.
+* Clang's default C++ dialect is now ``gnu++17`` instead of ``gnu++14``. This
+  means Clang will by default accept code using features from C++17 and
+  conforming GNU extensions. Projects incompatible with C++17 can add
+  ``-std=gnu++14`` to their build settings to restore the previous behaviour.
 
 C++20 Feature Support
 ^
Index: clang-tools-extra/clangd/unittests/SelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SelectionTests.cpp
@@ -726,7 +726,7 @@
   EXPECT_EQ(Str, &Str->Parent->Parent->ignoreImplicit())
   << "Didn't unwrap " << nodeKind(&Str->Parent->Parent->ignoreImplicit());
 
-  EXPECT_EQ("CXXConstructExpr", nodeKind(&Str->outerImplicit()));
+  EXPECT_EQ("ImplicitCastExpr", nodeKind(&Str->outerImplic

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a subscriber: mgorny.
MaskRay added inline comments.



Comment at: clang/test/lit.site.cfg.py.in:27
 config.clang_enable_opaque_pointers = @CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL@
+config.clang_default_std_cxx = "@CLANG_DEFAULT_STD_CXX@"
 config.clang_default_cxx_stdlib = "@CLANG_DEFAULT_CXX_STDLIB@"

aaron.ballman wrote:
> Should we add some documentation for this in a follow-up? (I know 
> `CLANG_DEFAULT_STD_CXX` already exists, but it seems like it'd be helpful to 
> tell users about it too.)
Where shall we place the documentation? My understanding is that we don't 
document lit.* config changes.

Personally I think we probably should get rid of `CLANG_DEFAULT_STD_CXX` 
(D34365 @mgorny), which may require improvements to Clang configuration file 
(https://discourse.llvm.org/t/configuration-files/42529 
https://clang.llvm.org/docs/UsersManual.html#configuration-files).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D132952: [Sema] disable -Wvla for function array parameters

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/test/Sema/warn-vla.c:8-12
+void test2(int n, int v[n]) { // c99 no-warning
+#if __STDC_VERSION__ < 199901L
+// expected-warning@-2{{variable length arrays are a C99 feature}}
+#endif
 }

aaron.ballman wrote:
> efriedma wrote:
> > aaron.ballman wrote:
> > > efriedma wrote:
> > > > aaron.ballman wrote:
> > > > > efriedma wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > inclyc wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > The diagnostic there is rather unfortunate because we're 
> > > > > > > > > > not using a variable-length array in this case.
> > > > > > > > > Emm, I'm not clear about whether we should consider this a 
> > > > > > > > > VLA, and generates `-Wvla-extensions`. Is `v[n]` literally a 
> > > > > > > > > variable-length array? (in source code) So it seems to me 
> > > > > > > > > that we should still report c89 incompatibility warnings?
> > > > > > > > > 
> > > > > > > > C89's grammar only allowed for an integer constant expression 
> > > > > > > > to (optionally) appear as the array extent in an array 
> > > > > > > > declarator, so there is a compatibility warning needed for 
> > > > > > > > that. But I don't think we should issue a warning about this 
> > > > > > > > being a VLA in C99 or later. The array *is* a VLA in terms of 
> > > > > > > > the form written in the source, but C adjusts the parameter to 
> > > > > > > > be a pointer parameter, so as far as the function's type is 
> > > > > > > > concerned, it's not a VLA (it's just a self-documenting 
> > > > > > > > interface).
> > > > > > > > 
> > > > > > > > Because self-documenting code is nice and because people are 
> > > > > > > > worried about accidental use of VLAs that cause stack 
> > > > > > > > allocations (which this does not), I think we don't want to 
> > > > > > > > scare people off from this construct. But I'm curious what 
> > > > > > > > others think as well.
> > > > > > > > But I'm curious what others think as well.
> > > > > > > 
> > > > > > > (Specifically, I'm wondering if others agree that the only 
> > > > > > > warning that should be issued there is a C89 compatibility 
> > > > > > > warning under `-Wvla-extensions` when in C89 mode and via a new 
> > > > > > > `CPre99Compat` diagnostic group when enabled in C99 and later 
> > > > > > > modes.)
> > > > > > > 
> > > > > > > 
> > > > > > I imagine people working with codebases that are also built with 
> > > > > > compilers that don't support VLAs would still want some form of 
> > > > > > warning on any VLA type.
> > > > > The tricky part is: that's precisely what WG14 N2992 
> > > > > (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2992.pdf) is 
> > > > > clarifying. If your implementation doesn't support VLAs, it's still 
> > > > > required to support this syntactic form. So the question becomes: do 
> > > > > we want a portability warning to compilers that don't conform to the 
> > > > > standard? Maybe we do (if we can find evidence of compilers in such a 
> > > > > state), but probably under a specific diagnostic flag rather than 
> > > > > -Wvla.
> > > > That only applies to C23, though, right?  None of that wording is there 
> > > > for C11.  (In particular, MSVC claims C11 conformance without any 
> > > > support for VLA types.)
> > > In a strict sense, yes, this is a C23 change. There are no changes to 
> > > older standards as far as ISO is concerned (and there never have been).
> > > 
> > > In a practical sense, no, this is clarifying how VLAs have always been 
> > > intended to work. C23 is in a really weird spot in that we had to stop 
> > > our "defect report" process at the end of C17 because the ISO definition 
> > > of a defect did not match the WG14 definition of a defect, and ISO got 
> > > upset. Towards the tail end of the C23 cycle, we introduced a list of 
> > > extensions to obsolete versions of C 
> > > (https://www.open-std.org/jtc1/sc22/wg14/www/previous.html) as a stopgap, 
> > > but the convener would not allow us to retroactively add papers to it. 
> > > The committee still hasn't gotten used to this new process and as a 
> > > result, not many papers have made it to the list. We've also not had the 
> > > chance to discuss 
> > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3002.pdf on having a 
> > > more reasonable issue tracking process.
> > > 
> > > The end result is that there's a whole pile of papers in C23 that we 
> > > would have normally treated via the old defect report process but 
> > > couldn't, and if we had treated them via the old DR process, it would 
> > > have been more clear why I think this should be a retroactive change back 
> > > to C99 instead of a C23-only change.
> > Even if the committee can make retroactive changes to standards, that 
> > doesn't change the fact that MSVC doesn't support VLAs, and that codebases 
> > exist which need to be compiled wit

[PATCH] D132131: [clang-format] Adds a formatter for aligning trailing comments over empty lines

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/unittests/Format/FormatTestComments.cpp:2930
+  Style.ColumnLimit = 15;
+  EXPECT_EQ("int ab; // line\n"
+"int a;  // long\n"

yusuke-kadowaki wrote:
> MyDeveloperDay wrote:
> > Why not verifyFormat here too and below?
> To test the ColumnLimit behavior.
pretty sure you can pass in a style


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132131

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

[PATCH] D132131: [clang-format] Adds a formatter for aligning trailing comments over empty lines

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/docs/ClangFormatStyleOptions.rst:865
+
+  * ``TCAS_DontAlign`` (in configuration: ``DontAlign``)
+Don't align trailing comments.

Is Don'tAlign the same as Leave that other options support  (for options it 
best if we try and use the same terminiology

Always,Never,Leave (if that fits)



Comment at: clang/include/clang/Format/Format.h:373
+  /// Different styles for aligning trailing comments.
+  enum TrailingCommentsAlignmentStyle : int8_t {
+/// Don't align trailing comments.

all options have a life cycle

bool -> enum -> struct

One of the thing I ask you before, would we want to align across N empty lines, 
if ever so they I think
we should go straight to a struct


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132131

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/test/lit.site.cfg.py.in:27
 config.clang_enable_opaque_pointers = @CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL@
+config.clang_default_std_cxx = "@CLANG_DEFAULT_STD_CXX@"
 config.clang_default_cxx_stdlib = "@CLANG_DEFAULT_CXX_STDLIB@"

MaskRay wrote:
> aaron.ballman wrote:
> > Should we add some documentation for this in a follow-up? (I know 
> > `CLANG_DEFAULT_STD_CXX` already exists, but it seems like it'd be helpful 
> > to tell users about it too.)
> Where shall we place the documentation? My understanding is that we don't 
> document lit.* config changes.
> 
> Personally I think we probably should get rid of `CLANG_DEFAULT_STD_CXX` 
> (D34365 @mgorny), which may require improvements to Clang configuration file 
> (https://discourse.llvm.org/t/configuration-files/42529 
> https://clang.llvm.org/docs/UsersManual.html#configuration-files).
Oh, I thought this was a CMake variable that users could set, so I was thinking 
it would have gone into 
https://llvm.org/docs/CMake.html#rarely-used-cmake-variables. Is this not 
something users set to try test out in a different language standard mode than 
the default?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D133209: [clang] Document environment variables used by the driver

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added inline comments.



Comment at: clang/docs/ClangCommandLineReference.rst:2-5
   ---
   NOTE: This file is automatically generated by running clang-tblgen
   -gen-opt-docs. Do not edit this file by hand!!
   ---

aaron.ballman wrote:
> mizvekov wrote:
> > aaron.ballman wrote:
> > > I think you might have missed this bit. ;-)
> > > 
> > > @jansvoboda11 -- do you know of an ergonomic way for people to associate 
> > > extra documentation along with the command line reference to support 
> > > adding documentation like this? This is the second time in the past hour 
> > > I've seen people adding documentation directly to this file and the docs 
> > > would be kind of onerous to put in `HelpText<>` directly. I'm wondering 
> > > if the FE options can support something along the lines of AttrDocs.td 
> > > where we can specify some out-of-line documentation in another .td for 
> > > things that are nontrivial to document?
> > Ooops!
> > 
> > Why do we even commit this file then? :-)
> +1 -- we automatically generate the document from the cmake sphinx target, so 
> I think it's reasonable to remove this file from version control (same as we 
> did for AttributeReference.rst and DiagnosticReference.rst).
We don't have good place for extra documentation. Doing something similar to 
`AttrDocs.td` for command-line options is a good direction IMO.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133209

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

[PATCH] D133202: [Clang][CodeGen] Avoid __builtin_assume_aligned crash when the 1st arg is array type

[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, but can you add a release note to clang/docs/ReleaseNotes.rst for the 
fix? Also, do you need someone to commit this on your behalf? If so, what name 
and email address would you like used for patch attribution?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133202

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

[clang-tools-extra] 4450348 - [clang-tidy] Skip union-like classes in use-equals-default

[Alexander Shaposhnikov via cfe-commits]

Author: Alexander Shaposhnikov
Date: 2022-09-06T20:19:47Z
New Revision: 44503482e0af189d3a7fc57b80238ea4151992b9

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

LOG: [clang-tidy] Skip union-like classes in use-equals-default

Skip unions/union-like classes since in this case constructors
with empty bodies behave differently in comparison with regular
structs/classes.

Test plan: ninja check-clang-tools

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/modernize/UseEqualsDefaultCheck.cpp
clang-tools-extra/docs/ReleaseNotes.rst

clang-tools-extra/test/clang-tidy/checkers/modernize/use-equals-default-copy.cpp
clang-tools-extra/test/clang-tidy/checkers/modernize/use-equals-default.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/modernize/UseEqualsDefaultCheck.cpp 
b/clang-tools-extra/clang-tidy/modernize/UseEqualsDefaultCheck.cpp
index 2de677d2735fe..d5c402c4bdeb7 100644
--- a/clang-tools-extra/clang-tidy/modernize/UseEqualsDefaultCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/UseEqualsDefaultCheck.cpp
@@ -218,17 +218,20 @@ void 
UseEqualsDefaultCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) {
 }
 
 void UseEqualsDefaultCheck::registerMatchers(MatchFinder *Finder) {
-  // Skip unions since constructors with empty bodies behave 
diff erently
-  // in comparison with structs/classes.
+  // Skip unions/union-like classes since their constructors behave 
diff erently
+  // when defaulted vs. empty.
+  auto IsUnionLikeClass = recordDecl(
+  anyOf(isUnion(),
+has(fieldDecl(isImplicit(), hasType(cxxRecordDecl(isUnion()));
 
   // Destructor.
-  
Finder->addMatcher(cxxDestructorDecl(unless(hasParent(recordDecl(isUnion(,
-   isDefinition())
- .bind(SpecialFunction),
- this);
+  Finder->addMatcher(
+  cxxDestructorDecl(unless(hasParent(IsUnionLikeClass)), isDefinition())
+  .bind(SpecialFunction),
+  this);
   Finder->addMatcher(
   cxxConstructorDecl(
-  unless(hasParent(recordDecl(isUnion(, isDefinition(),
+  unless(hasParent(IsUnionLikeClass)), isDefinition(),
   anyOf(
   // Default constructor.
   allOf(unless(hasAnyConstructorInitializer(isWritten())),
@@ -243,7 +246,7 @@ void UseEqualsDefaultCheck::registerMatchers(MatchFinder 
*Finder) {
   this);
   // Copy-assignment operator.
   Finder->addMatcher(
-  cxxMethodDecl(unless(hasParent(recordDecl(isUnion(, isDefinition(),
+  cxxMethodDecl(unless(hasParent(IsUnionLikeClass)), isDefinition(),
 isCopyAssignmentOperator(),
 // isCopyAssignmentOperator() allows the parameter to be
 // passed by value, and in this case it cannot be

diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 7c91ea00dca84..89dd7e746e587 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -144,9 +144,10 @@ Changes in existing checks
 - Improved :doc:`modernize-use-equals-default 
`
   check.
 
-  The check now skips unions since in this case a default constructor with 
empty body
-  is not equivalent to the explicitly defaulted one. The check also skips copy 
assignment
-  operators with nonstandard return types. The check is restricted to 
c++11-or-later.
+  The check now skips unions/union-like classes since in this case a default 
constructor
+  with empty body is not equivalent to the explicitly defaulted one. The check 
also skips
+  copy assignment operators with nonstandard return types. The check is 
restricted to
+  c++11-or-later.
 
 Removed checks
 ^^

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/modernize/use-equals-default-copy.cpp
 
b/clang-tools-extra/test/clang-tidy/checkers/modernize/use-equals-default-copy.cpp
index 70fc521ebb7ae..eaa600ad86438 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/modernize/use-equals-default-copy.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/modernize/use-equals-default-copy.cpp
@@ -44,6 +44,20 @@ union NU {
   IL Field;
 };
 
+// Skip structs/classes containing anonymous unions.
+struct SU {
+  SU(const SU &Other) : Field(Other.Field) {}
+  // CHECK-FIXES: SU(const SU &Other) :
+  SU &operator=(const SU &Other) {
+Field = Other.Field;
+return *this;
+  }
+  // CHECK-FIXES: SU &operator=(const SU &Other) {
+  union {
+IL Field;
+  };
+};
+
 // Wrong type.
 struct WT {
   WT(const IL &Other) {}

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/modernize/use-equals-default.cpp 
b/clang-tools-extra/test/clang-tidy/