[clang-tools-extra] 355dbd3 - [test][clangd] Try to unbrake bots after 72142fbac4

[Vitaly Buka via cfe-commits]

Author: Vitaly Buka
Date: 2022-09-11T01:20:31-07:00
New Revision: 355dbd3b2aa28d479170c4e43265de186317dd86

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

LOG: [test][clangd] Try to unbrake bots after 72142fbac4

Added: 


Modified: 
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp 
b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
index 4e95fcfea91c1..66260ab64fbe6 100644
--- a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -169,6 +169,7 @@ class TUSchedulerTests : public ::testing::Test {
 
   MockFS FS;
   MockCompilationDatabase CDB;
+  Deadline BlockTimeout = timeoutSeconds(60);
 };
 
 Key)>>
@@ -241,7 +242,7 @@ TEST_F(TUSchedulerTests, WantDiagnostics) {
 [&](std::vector) { ++CallbackCount; });
 Ready.notify();
 
-ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
   }
   EXPECT_EQ(2, CallbackCount);
 }
@@ -264,7 +265,7 @@ TEST_F(TUSchedulerTests, Debounce) {
   Notification N;
   updateWithDiags(S, Path, "auto (timed out)", WantDiagnostics::Auto,
   [&](std::vector) { N.notify(); });
-  EXPECT_TRUE(N.wait(timeoutSeconds(5)));
+  EXPECT_TRUE(N.wait(BlockTimeout));
 
   // Once we start shutting down the TUScheduler, this one becomes a dead 
write.
   updateWithDiags(S, Path, "auto (discarded)", WantDiagnostics::Auto,
@@ -330,7 +331,7 @@ TEST_F(TUSchedulerTests, Cancellation) {
 Read("R3")();
 Proceed.notify();
 
-ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
   }
   EXPECT_THAT(DiagsSeen, ElementsAre("U2", "U3"))
   << "U1 and all dependent reads were cancelled. "
@@ -351,7 +352,7 @@ TEST_F(TUSchedulerTests, InvalidationNoCrash) {
   // We expect invalidation logic to not crash by trying to invalidate a 
running
   // request.
   S.update(Path, getInputs(Path, ""), WantDiagnostics::Auto);
-  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
   S.runWithAST(
   "invalidatable-but-running", Path,
   [&](llvm::Expected AST) {
@@ -363,7 +364,7 @@ TEST_F(TUSchedulerTests, InvalidationNoCrash) {
   StartedRunning.wait();
   S.update(Path, getInputs(Path, ""), WantDiagnostics::Auto);
   ScheduledChange.notify();
-  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
 }
 
 TEST_F(TUSchedulerTests, Invalidation) {
@@ -419,7 +420,7 @@ TEST_F(TUSchedulerTests, Invalidation) {
   },
   TUScheduler::InvalidateOnUpdate);
   Start.notify();
-  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
 
   EXPECT_EQ(2, Builds.load()) << "Middle build should be skipped";
   EXPECT_EQ(4, Actions.load()) << "All actions should run (some with error)";
@@ -452,7 +453,7 @@ TEST_F(TUSchedulerTests, InvalidationUnchanged) {
 ADD_FAILURE() << "Shouldn't build, identical to previous";
   });
   Start.notify();
-  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
 
   EXPECT_EQ(1, Actions.load()) << "All actions should run";
 }
@@ -559,7 +560,7 @@ TEST_F(TUSchedulerTests, ManyUpdates) {
 }
   }
 }
-ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
   } // TUScheduler destructor waits for all operations to finish.
 
   std::lock_guard Lock(Mut);
@@ -601,7 +602,7 @@ TEST_F(TUSchedulerTests, EvictedAST) {
   // one that the cache will evict.
   updateWithCallback(S, Foo, SourceContents, WantDiagnostics::Yes,
  [&BuiltASTCounter]() { ++BuiltASTCounter; });
-  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
   ASSERT_EQ(BuiltASTCounter.load(), 1);
   EXPECT_THAT(Tracer.takeMetric("ast_access_diag", "hit"), SizeIs(0));
   EXPECT_THAT(Tracer.takeMetric("ast_access_diag", "miss"), SizeIs(1));
@@ -612,7 +613,7 @@ TEST_F(TUSchedulerTests, EvictedAST) {
  [&BuiltASTCounter]() { ++BuiltASTCounter; });
   updateWithCallback(S, Baz, SourceContents, WantDiagnostics::Yes,
  [&BuiltASTCounter]() { ++BuiltASTCounter; });
-  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
   ASSERT_EQ(BuiltASTCounter.load(), 3);
   EXPECT_THAT(Tracer.takeMetric("ast_access_diag", "hit"), SizeIs(0));
   EXPECT_THAT(Tracer.takeMetric("ast_access_diag", "miss"), SizeIs(2));
@@ -623,7 +624,7 @@ TEST_F(TUSchedulerTests, EvictedAST) {
   // Access the old file again.
   upda

[PATCH] D133662: [Clang] Change -ftime-trace storing path and support multiple compilation jobs

[Mészáros Gergely via Phabricator via cfe-commits]

Maetveis created this revision.
Maetveis added a reviewer: clang.
Herald added a project: All.
Maetveis requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

This is an alternative approach for [D131469 
](https://reviews.llvm.org/D131469].

The difference in behavior compared to D131469 
 is that instead of looking for linking jobs, 
here if a "main" output is available ('-o ' is given) the directory of 
it is used for '-ftime-trace'.
Another is that time traces in offloading tool-chain (e.g. CUDA or HIP) 
compilation steps are also supported by saving them to the  same directory as 
the host trace, with naming similar to '-save-temps'.
If save temps the file type suffix is also included to keep the trace from e.g 
the front-end compilation overwriting the back-end trace.

The final behavior is this:

- if '-ftime-trace=path/to/trace.json' is given, then use it for the final 
compilation, and use the directory where it is for the rest (offloading or 
'-save-temps')
- if '-ftime-trace=path/to/trace/folder' is given:
  - for the main output use 'path/to/trace/folder/,json' if '-o 
.o' is given
  - if no output path is specified or for the rest of the files use 
'path/to/trace/folder/.json' similar to '-save-temps'
- if '-ftime-trace' is given and there is a main output ('-o output') use the 
directory of it to store the traces
- if '-ftime-trace' but no '-o ' use the current working directory


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133662

Files:
  clang/include/clang/Driver/Compilation.h
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/Tool.h
  clang/include/clang/Frontend/FrontendOptions.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Clang.h
  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
@@ -212,9 +212,7 @@
   bool Success = CompilerInvocation::CreateFromArgs(Clang->getInvocation(),
 Argv, Diags, Argv0);
 
-  if (Clang->getFrontendOpts().TimeTrace ||
-  !Clang->getFrontendOpts().TimeTracePath.empty()) {
-Clang->getFrontendOpts().TimeTrace = 1;
+  if (!Clang->getFrontendOpts().TimeTracePath.empty()) {
 llvm::timeTraceProfilerInitialize(
 Clang->getFrontendOpts().TimeTraceGranularity, Argv0);
   }
@@ -256,17 +254,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);
-}
+const StringRef TracePath = Clang->getFrontendOpts().TimeTracePath;
+assert(!TracePath.empty() && "`-ftime-trace=` is empty");
 if (auto profilerOutput = Clang->createOutputFile(
-Path.str(), /*Binary=*/false, /*RemoveFileOnSignal=*/false,
+TracePath, /*Binary=*/false, /*RemoveFileOnSignal=*/false,
 /*useTemporary=*/false)) {
   llvm::timeTraceProfilerWrite(*profilerOutput);
   profilerOutput.reset();
Index: clang/lib/Driver/ToolChains/Clang.h
===
--- clang/lib/Driver/ToolChains/Clang.h
+++ clang/lib/Driver/ToolChains/Clang.h
@@ -113,6 +113,7 @@
   bool hasIntegratedBackend() const override { return HasBackend; }
   bool hasIntegratedCPP() const override { return true; }
   bool canEmitIR() const override { return true; }
+  bool supportsTimeTrace() const override { return true; }
 
   void ConstructJob(Compilation &C, const JobAction &JA,
 const InputInfo &Output, const InputInfoList &Inputs,
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6230,9 +6230,11 @@
   Args.AddLastArg(CmdArgs, options::OPT_fdiagnostics_parseable_fixits);
   Args.AddLastArg(CmdArgs, options::OPT_ftime_report);
   Args.AddLastArg(CmdArgs, options::OPT_ftime_report_EQ);
-  Args.AddLastArg(CmdArgs, options::OPT_ftime_trace);
   Args.AddLastArg(CmdArgs, options::OPT_ftime_trace_granularity_EQ);
-  Args.AddLastArg(CmdArgs, options::OPT_ftime_trace_EQ);
+
+  if (const char *Name = C.getTimeTraceFileForJob(&JA))
+CmdArgs.push_back(Args.MakeArgString("-ftime-trace=" + Twine(Name)));
+
   Args.Add

[PATCH] D133664: [clangd] Fix hover on symbol introduced by using declaration

[Tom Praschan via Phabricator via cfe-commits]

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

This fixes https://github.com/clangd/clangd/issues/1284. The example
there was C++20's "using enum", but I noticed that we had the same issue
for other using-declarations.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133664

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp


Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -1630,6 +1630,26 @@
 HI.Type = "int";
 HI.Definition = "int foo";
   }},
+  {
+  R"cpp(// Function definition via using declaration
+namespace ns { 
+  void foo(); 
+}
+int main() {
+  using ns::foo;
+  ^[[foo]]();
+}
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "foo";
+HI.Kind = index::SymbolKind::Function;
+HI.NamespaceScope = "ns::";
+HI.Type = "void ()";
+HI.Definition = "void foo()";
+HI.Documentation = "";
+HI.ReturnType = "void";
+HI.Parameters = std::vector{};
+  }},
   {
   R"cpp(// Macro
 #define MACRO 0
@@ -1734,6 +1754,25 @@
 HI.Definition = "ONE";
 HI.Value = "0";
   }},
+  {
+  R"cpp(// C++20's using enum
+enum class Hello {
+  ONE, TWO, THREE,
+};
+void foo() {
+  using enum Hello;
+  Hello hello = [[O^NE]];
+}
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "ONE";
+HI.Kind = index::SymbolKind::EnumConstant;
+HI.NamespaceScope = "";
+HI.LocalScope = "Hello::";
+HI.Type = "enum Hello";
+HI.Definition = "ONE";
+HI.Value = "0";
+  }},
   {
   R"cpp(// Enumerator in anonymous enum
 enum {
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -1082,10 +1082,22 @@
   auto Decls = explicitReferenceTargets(N->ASTNode, DeclRelation::Alias,
 AST.getHeuristicResolver());
   if (!Decls.empty()) {
-HI = getHoverContents(Decls.front(), PP, Index, TB);
+// For using-declarations, e.g.
+// namespace ns { void foo(); }
+// void bar() { using ns::foo; f^oo(); }
+// The first declaration in Decls will refer to the using declaration,
+// which isn't really useful for Hover. So check if we have something
+// better, which in this example would be the actual declaration of 
foo.
+auto *DeclToUse = Decls.begin();
+while (llvm::isa(*DeclToUse) &&
+   std::next(DeclToUse) != Decls.end()) {
+  ++DeclToUse;
+}
+
+HI = getHoverContents(*DeclToUse, PP, Index, TB);
 // Layout info only shown when hovering on the field/class itself.
-if (Decls.front() == N->ASTNode.get())
-  addLayoutInfo(*Decls.front(), *HI);
+if (*DeclToUse == N->ASTNode.get())
+  addLayoutInfo(**DeclToUse, *HI);
 // Look for a close enclosing expression to show the value of.
 if (!HI->Value)
   HI->Value = printExprValue(N, AST.getASTContext());


Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -1630,6 +1630,26 @@
 HI.Type = "int";
 HI.Definition = "int foo";
   }},
+  {
+  R"cpp(// Function definition via using declaration
+namespace ns { 
+  void foo(); 
+}
+int main() {
+  using ns::foo;
+  ^[[foo]]();
+}
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "foo";
+HI.Kind = index::SymbolKind::Function;
+HI.NamespaceScope = "ns::";
+HI.Type = "void ()";
+HI.Definition = "void foo()";
+HI.Documentation = "";
+HI.ReturnType = "void";
+HI.Parameters = std::vector{};
+  }},
   {
   R"cpp(// Macro
 #define MACRO 0
@@ -1734,6 +1754,25 @@
 HI.Definition = "ONE";
 HI.Value = "0";
  

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

[Mark de Wever via Phabricator via cfe-commits]

Mordante updated this revision to Diff 459347.
Mordante marked 15 inline comments as done.
Mordante added a comment.

Addresses review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133249

Files:
  clang/www/hacking.html
  libcxx/docs/Contributing.rst
  libcxx/docs/index.rst

Index: libcxx/docs/index.rst
===
--- libcxx/docs/index.rst
+++ libcxx/docs/index.rst
@@ -93,6 +93,7 @@
   Further, both projects are apparently abandoned: STLport 5.2.1 was
   released in Oct'08, and STDCXX 4.2.1 in May'08.
 
+.. _SupportedPlatforms:
 
 Platform and Compiler Support
 =
Index: libcxx/docs/Contributing.rst
===
--- libcxx/docs/Contributing.rst
+++ libcxx/docs/Contributing.rst
@@ -84,5 +84,151 @@
 Look for the failed build and select the ``artifacts`` tab. There, download the
 abilist for the platform, e.g.:
 
-* C++20 for the Linux platform.
-* MacOS C++20 for the Apple platform.
+* C++.
+* MacOS X86_64 and MacOS arm64 for the Apple platform.
+
+
+.. comments The new part got longer than expected, would it make sense to move
+   it to its own page?
+
+
+Pre-commit CI
+=
+
+Introduction
+
+
+Unlike most parts of the LLVM project, libc++ uses a pre-commit CI [#]_. This
+CI is hosted on `Buildkite `__ and
+the build results are visible in the review on Phabricator. Before committing a
+patch please make sure the CI is green.
+
+
+The CI tests libc++ for all :ref:`supported platforms `.
+The build is started for every diff uploaded. A complete CI run takes
+approximately one hour. To reduce the load:
+
+* The build is cancelled when a new diff for the same revision is uploaded.
+* The build is done in several stages and cancelled when a stage fails.
+
+Typically, the libc++ jobs use a Ubuntu Docker image. This image contains
+recent `nightly builds `__ of all supported versions of
+Clang and the current version of the ``main`` branch. These versions of Clang
+are used to build libc++ and execute its tests.
+
+Unless specified otherwise, the configurations:
+
+* use a nightly build of the ``main`` branch of Clang,
+* execute the tests using the language C++. This is the version
+  "developed" by the C++ committee.
+
+.. note:: Updating the Clang nightly builds in the Docker image is a manual
+   process and is done at an irregular interval. When you need to have the
+   latest nightly build to test recent Clang changes best ask at the
+   ``#libcxx`` channel on
+   `LLVM's Discord server `__.
+
+.. comments ``irregular`` is used on purpose. Committing to a schedule seems
+   unwanted; people might be unavailable to update the image, the nightly
+   builds fail and are not uploaded for multiple days (this is not uncommon).
+
+.. [#] There's `LLVM Dev Meeting talk `__
+   explaining the benefits of libc++'s pre-commit CI.
+
+Builds
+--
+
+Below is a short description of the most interesting CI builds [#]_:
+
+* ``Format`` runs ``clang-format`` and uploads its output as an artifact. At the
+  moment this build is a soft error and doesn't fail the build.
+* ``Generated output`` runs the ``libcxx-generate-files`` build target and
+  tests for non-ASCII characters in libcxx. Some files are excluded since they
+  use Unicode, mainly tests. The output of these commands are uploaded as
+  artifact.
+* ``Documentation`` builds the documentation. (This is done early in the build
+  process since it is cheap to run.)
+* ``C++`` these build steps test the various C++ versions, making sure all
+  C++ language versions work with the changes made.
+* ``Clang `` these build steps test whether the changes work with all
+  supported Clang versions.
+* ``Booststrapping build`` builds Clang using the revision of the patch and
+  uses that Clang version to build and test libc++. This validates the current
+  Clang and lib++ are compatible. When making changes in Clang that affect
+  libc++ this is the build to validate all is well.
+
+  When a crash occurs in this build, the crash reproducer is available as an
+  artifact.
+
+* ``Modular build`` tests libc++ using Clang modules [#]_.
+* ``GCC `` tests libc++ with the latest stable GCC version. Only C++11
+  and the latest C++ version are tested.
+* ``Santitizers`` tests libc++ using the Clang sanitizers.
+* ``Parts disabled`` tests libc++ with certain libc++ features disabled.
+* ``Windows`` tests libc++ using MinGW and clang-cl.
+* ``Apple`` tests libc++ on MacOS.
+* ``ARM`` tests libc++ on various Linux ARM platforms.
+* ``AIX`` tests libc++ on AIX.
+
+.. [#] Not all all steps are listed: steps are added and removed when the need
+   arises.
+.. [#] Clang modules are not the sa

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

[Mark de Wever via Phabricator via cfe-commits]

Mordante added inline comments.



Comment at: libcxx/docs/Contributing.rst:88
+* 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:
> 
They are synonyms, since use the underscore in the CI I prefer to use that name.



Comment at: libcxx/docs/Contributing.rst:119
+
+Unless specified otherwise the ``main`` version of Clang is used.
+

aaron.ballman wrote:
> 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. "Unless specified 
> > otherwise" - where would I specify a different preference, when I upload a 
> > patch and it gets run through CI?
> > 
> > There's three different concepts involved here:
> > - The CI build matrix (buildkite-pipeline.yml) which specifies a bunch of 
> > different versions of tools and standards to run the tests on. Here you 
> > can't specify a different preference - all of them are run (unless you edit 
> > the file in your patch).
> > - The Docker images, where the default `clang` executable is a recent 
> > nightly build, but older releases are available as `clang-`
> > - The `run-buildbot` script, which just uses whatever compiler is set as 
> > default (via e.g. the `CXX` env var).
> > 
> > So, what about these three concepts is this paragraph trying to say - the 
> > second or the third point? This really needs to specify what it talks about 
> > - build matrix, docker images or run-buildbot script.
> > 
> > The same thing goes for the following paragraph.
> (mostly trying to get rid of the duplicate "Unless specified otherwise".)
I've reworded it, please have a look whether the new wording is clear.



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

ldionne wrote:
> 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`?
The documentation for these files is already available in this document, more 
at the end.

I tried to mainly describe the special parts and tried to keep it generic. I 
could prune a bit more, but I feel some explanation would be good since there 
are some "suprises" like, formatting allowed to fail, modular build has nothing 
to do with C++20 modules.



Comment at: libcxx/docs/Contributing.rst:231-233
+  export CC=clang-14
+  export CXX=clang++-14
+  run-buildbot generic-cxx17

philnik wrote:
> Complete nit, but I think `CC=clang-14 CXX=clang++-14 run-builtbot 
> generic-cxx17` as an example would be better to avoid polluting people's 
> environment if they're unfamiliar with a terminal.
Good point.


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] D133249: [libc++] Documents details of the pre-commit CI.

[Mark de Wever via Phabricator via cfe-commits]

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

Rebased to fix CI failure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133249

Files:
  clang/www/hacking.html
  libcxx/docs/Contributing.rst
  libcxx/docs/index.rst

Index: libcxx/docs/index.rst
===
--- libcxx/docs/index.rst
+++ libcxx/docs/index.rst
@@ -93,6 +93,7 @@
   Further, both projects are apparently abandoned: STLport 5.2.1 was
   released in Oct'08, and STDCXX 4.2.1 in May'08.
 
+.. _SupportedPlatforms:
 
 Platform and Compiler Support
 =
Index: libcxx/docs/Contributing.rst
===
--- libcxx/docs/Contributing.rst
+++ libcxx/docs/Contributing.rst
@@ -84,5 +84,151 @@
 Look for the failed build and select the ``artifacts`` tab. There, download the
 abilist for the platform, e.g.:
 
-* C++20 for the Linux platform.
-* MacOS C++20 for the Apple platform.
+* C++.
+* MacOS X86_64 and MacOS arm64 for the Apple platform.
+
+
+.. comments The new part got longer than expected, would it make sense to move
+   it to its own page?
+
+
+Pre-commit CI
+=
+
+Introduction
+
+
+Unlike most parts of the LLVM project, libc++ uses a pre-commit CI [#]_. This
+CI is hosted on `Buildkite `__ and
+the build results are visible in the review on Phabricator. Before committing a
+patch please make sure the CI is green.
+
+
+The CI tests libc++ for all :ref:`supported platforms `.
+The build is started for every diff uploaded. A complete CI run takes
+approximately one hour. To reduce the load:
+
+* The build is cancelled when a new diff for the same revision is uploaded.
+* The build is done in several stages and cancelled when a stage fails.
+
+Typically, the libc++ jobs use a Ubuntu Docker image. This image contains
+recent `nightly builds `__ of all supported versions of
+Clang and the current version of the ``main`` branch. These versions of Clang
+are used to build libc++ and execute its tests.
+
+Unless specified otherwise, the configurations:
+
+* use a nightly build of the ``main`` branch of Clang,
+* execute the tests using the language C++. This is the version
+  "developed" by the C++ committee.
+
+.. note:: Updating the Clang nightly builds in the Docker image is a manual
+   process and is done at an irregular interval. When you need to have the
+   latest nightly build to test recent Clang changes best ask at the
+   ``#libcxx`` channel on
+   `LLVM's Discord server `__.
+
+.. comments ``irregular`` is used on purpose. Committing to a schedule seems
+   unwanted; people might be unavailable to update the image, the nightly
+   builds fail and are not uploaded for multiple days (this is not uncommon).
+
+.. [#] There's `LLVM Dev Meeting talk `__
+   explaining the benefits of libc++'s pre-commit CI.
+
+Builds
+--
+
+Below is a short description of the most interesting CI builds [#]_:
+
+* ``Format`` runs ``clang-format`` and uploads its output as an artifact. At the
+  moment this build is a soft error and doesn't fail the build.
+* ``Generated output`` runs the ``libcxx-generate-files`` build target and
+  tests for non-ASCII characters in libcxx. Some files are excluded since they
+  use Unicode, mainly tests. The output of these commands are uploaded as
+  artifact.
+* ``Documentation`` builds the documentation. (This is done early in the build
+  process since it is cheap to run.)
+* ``C++`` these build steps test the various C++ versions, making sure all
+  C++ language versions work with the changes made.
+* ``Clang `` these build steps test whether the changes work with all
+  supported Clang versions.
+* ``Booststrapping build`` builds Clang using the revision of the patch and
+  uses that Clang version to build and test libc++. This validates the current
+  Clang and lib++ are compatible. When making changes in Clang that affect
+  libc++ this is the build to validate all is well.
+
+  When a crash occurs in this build, the crash reproducer is available as an
+  artifact.
+
+* ``Modular build`` tests libc++ using Clang modules [#]_.
+* ``GCC `` tests libc++ with the latest stable GCC version. Only C++11
+  and the latest C++ version are tested.
+* ``Santitizers`` tests libc++ using the Clang sanitizers.
+* ``Parts disabled`` tests libc++ with certain libc++ features disabled.
+* ``Windows`` tests libc++ using MinGW and clang-cl.
+* ``Apple`` tests libc++ on MacOS.
+* ``ARM`` tests libc++ on various Linux ARM platforms.
+* ``AIX`` tests libc++ on AIX.
+
+.. [#] Not all all steps are listed: steps are added and removed when the need
+   arises.
+.. [#] Clang modules are not the same as C++20's modules.
+
+Infrastructure
+--

[PATCH] D133659: [Clang] P1169R4: static operator()

[Roy Jacobson via Phabricator via cfe-commits]

royjacobson created this revision.
Herald added a project: All.
royjacobson updated this revision to Diff 459334.
royjacobson added a comment.
royjacobson updated this revision to Diff 459349.
royjacobson updated this revision to Diff 459355.
royjacobson retitled this revision from "[Clang] Implement static operator()" 
to "[Clang] P1169R4: static operator()".
royjacobson edited the summary of this revision.
royjacobson added a reviewer: clang-language-wg.
royjacobson published this revision for review.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

missing newline


royjacobson added a comment.

Fix the tests, add a CodeGen test.


royjacobson added a comment.

Fix diagnosing static operators that are not call.


Implements 'P1169R4: static operator()' from C++2b.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133659

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/OperatorKinds.def
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/over/over.oper/over.literal/p7.cpp
  clang/test/CodeGenCXX/cxx2b-static-call-operator.cpp
  clang/test/Parser/cxx2b-lambdas-ext-warns.cpp
  clang/test/Parser/cxx2b-lambdas.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1481,7 +1481,7 @@
 
   static operator()
   https://wg21.link/P1169R4";>P1169R4
-  No
+  Clang 16
 
 
   Extended floating-point types and standard names
Index: clang/test/Parser/cxx2b-lambdas.cpp
===
--- clang/test/Parser/cxx2b-lambdas.cpp
+++ clang/test/Parser/cxx2b-lambdas.cpp
@@ -38,3 +38,16 @@
 auto XL4 = [] requires true {}; // expected-error{{expected body}}
 auto XL5 = [] requires true requires true {}; // expected-error{{expected body}}
 auto XL6 = [] requires true noexcept requires true {}; // expected-error{{expected body}}
+
+auto XL7 = []() static static {}; // expected-error {{cannot appear multiple times}}
+auto XL8 = []() static mutable {}; // expected-error {{cannot be both mutable and static}}
+
+auto XL9 = [] static {};
+auto XL10 = []() static {};
+
+void static_captures() {
+  int x;
+  auto SC1 = [&]() static {}; // expected-error {{a static lambda cannot capture}}
+  auto SC2 = [&x]() static {}; // expected-error {{a static lambda cannot capture}}
+  auto SC3 = [=]() static {}; // expected-error {{a static lambda cannot capture}}
+}
Index: clang/test/Parser/cxx2b-lambdas-ext-warns.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx2b-lambdas-ext-warns.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -std=c++20 %s -verify=expected,cxx20
+// RUN: %clang_cc1 -std=c++2b %s -verify=expected,cxx2b
+
+//cxx2b-no-diagnostics
+
+auto L1 = [] constexpr {}; // cxx20-warning {{lambda without a parameter clause is a C++2b extension}}
+auto L2 = []() static {}; // cxx20-warning {{static lambdas is a C++2b extension}}
+auto L3 = [] static {}; // cxx20-warning {{static lambdas is a C++2b extension}} // cxx20-warning {{lambda without a parameter clause is a C++2b extension}}
Index: clang/test/CodeGenCXX/cxx2b-static-call-operator.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/cxx2b-static-call-operator.cpp
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -std=c++2b %s -emit-llvm -o - | FileCheck %s
+
+struct Functor {
+  static int operator()(int x, int y) {
+return x + y;
+  }
+};
+
+auto GetALambda() {
+  return [](int x, int y) static {
+return x + y;
+  };
+}
+
+void CallsTheLambda() {
+  GetALambda()(1, 2);
+}
+
+// CHECK:  define dso_local void @_Z14CallsTheLambdav() {{.*}} {
+// CHECK-NEXT: entry:
+// CHECK-NEXT:   %call = call noundef i32 @"_ZZ10GetALambdavEN3$_0clEii"(i32 noundef 1, i32 noundef 2)
+// CHECK-NEXT:   ret void
+// CHECK-NEXT: }
+
+void call_static_call_operator() {
+  Functor f;
+  f(101, 102);
+  f.operator()(201, 202);
+  Functor{}(301, 302);
+}
+
+// CHECK:  define dso_local void @_Z25call_static_call_operatorv() {{.*}} {
+// CHECK-NEXT: entry:
+// CHECK:%call = call noundef i32 @_ZN7FunctorclEii(i32 noundef 101, i32 noundef 102)
+// CHECK-NEXT:   %call1 = call noundef i32 @_ZN7FunctorclEii(i32 noundef 201, i32 noundef 202)
+// CHECK-NEXT:   %call2 = call noundef i32 @_ZN7FunctorclEii(i32 noundef 301, i32 noundef 302)
+// CHECK-NEXT:   ret void
+// CHECK-NEXT: }
Index: clang/test/CXX/over/over.oper/over.literal/p7.cpp
===

[PATCH] D131858: [clang] Track the templated entity in type substitution.

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/lib/Serialization/ASTWriterDecl.cpp:623-626
+  VisitDeclaratorDecl(D);
+  Record.AddDeclarationNameLoc(D->DNLoc, D->getDeclName());
+  Record.push_back(D->getIdentifierNamespace());
+

mizvekov wrote:
> ChuanqiXu wrote:
> > mizvekov wrote:
> > > ChuanqiXu wrote:
> > > > ChuanqiXu wrote:
> > > > > ChuanqiXu wrote:
> > > > > > mizvekov wrote:
> > > > > > > ChuanqiXu wrote:
> > > > > > > > I still don't get the reason for the move. What's the benefit? 
> > > > > > > > Or why is it necessary?
> > > > > > > Yeah, now the type can reference the template decl, so without 
> > > > > > > moving this, it can happen during import of the type that we try 
> > > > > > > to read this function template bits without having imported them 
> > > > > > > yet.
> > > > > > Oh, I guess I met the problem before (D129748 ) and I made a 
> > > > > > workaround for it (https://reviews.llvm.org/D130331). If I 
> > > > > > understood right, the patch will solve that problem. I'll check it 
> > > > > > out later.
> > > > > > 
> > > > > > (This kind of code move looks dangerous you know and I'll take a 
> > > > > > double check)
> > > > > After looking into the detailed change for the serialization part, I 
> > > > > feel it is a not-so-good workaround indeed.. It looks like we need a 
> > > > > better method to delay reading the type in the serializer. And I'm 
> > > > > looking at it. @mizvekov would you like to rebase the series of 
> > > > > patches to the main branch so that I can test it actually.
> > > > Or would it be simpler to rebase and squash them into a draft revision?
> > > I had given this some thought, and it made sense to me that we should 
> > > deal with the template bits first, since these are closer to the 
> > > introducer for these declarations, and so that it would be harder to have 
> > > a dependence the other way around.
> > > 
> > > But I would like to hear your thoughts on this after you have taken a 
> > > better look.
> > > I am working on a bunch of things right now, I should be able to rebase 
> > > this on the next few days, but otherwise
> > > I last rebased about 4 days ago, so you can also check that out at 
> > > https://github.com/mizvekov/llvm-project/tree/resugar
> > > That link has the whole stack, you probably should check out just the 
> > > commit for this patch, as you are probably going to encounter issues with 
> > > the resugarer if you try it on substantial code bases.
> > > It will carry other changes with it, but I think those should be safe.
> > I won't say it is bad to deal with template bits first. I just feel it is a 
> > workaround to avoid the circular dependent problem in deserialization. Or 
> > in another word, here the method works due to you put some decls* in the 
> > template parameter types. And we avoid the circular dependent problem by 
> > adjusting the order we deserializes. The reasons why I don't feel it is 
> > good include:
> > (1) Although we touched template function decl and template var decl, we 
> > don't touched template var decl. I guess it'll be a problem now or later.
> > (2) The solution here can't solve the similar circular dependent problem I 
> > sawed in attributes. So the method only workarounds some resulting of the 
> > same problem.
> > 
> > Or in one shorter explanation, it should be greater to solve the root 
> > problems. I have an idea and I am going to to do a proof-of-concept 
> > implementation first since I feel like nobody are happy about an 
> > unimplementable idea. Generally I don't like to block patches due to such 
> > reasons since it is completely not your fault but I guess it may be better 
> > to wait some time. Since if we want to allow workarounds first and clear 
> > the workarounds, things will be harder. If you want a timeline, I guess 2 
> > months may be reasonable choices. I mean if I can't make it in 2 months and 
> > other reviewers feel this is good (what I am seeing), I feel bad to block 
> > this. (But if we're more patient, it'll be better). How do you think about 
> > this?
> Well we touch FunctionTemplates and VariableTemplates in this patch, because 
> they were not doing template first.
> For whatever reason, class templates were already doing template first, so no 
> need to fix that.
> 
> So this patch at least puts that into consistency.
> 
> Also, this patch is a pre-requisite for the template resugaring 
> specialization project I am working on, and the deadline for the whole 
> project is about two months from now.
> 
> If I leave merging this patch until the end, it seems impossible that I will 
> finish in time, as we will leave field testing this to the very end.
> 
> So while I understand the need for a better approach, it is indeed putting me 
> in an impossible situation.
> Also, this patch is a pre-requisite for the template resugaring 
> specialization project I am working on, and the deadline for the whole 
> p

[PATCH] D131858: [clang] Track the templated entity in type substitution.

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added inline comments.



Comment at: clang/lib/Serialization/ASTWriterDecl.cpp:623-626
+  VisitDeclaratorDecl(D);
+  Record.AddDeclarationNameLoc(D->DNLoc, D->getDeclName());
+  Record.push_back(D->getIdentifierNamespace());
+

ChuanqiXu wrote:
> mizvekov wrote:
> > ChuanqiXu wrote:
> > > mizvekov wrote:
> > > > ChuanqiXu wrote:
> > > > > ChuanqiXu wrote:
> > > > > > ChuanqiXu wrote:
> > > > > > > mizvekov wrote:
> > > > > > > > ChuanqiXu wrote:
> > > > > > > > > I still don't get the reason for the move. What's the 
> > > > > > > > > benefit? Or why is it necessary?
> > > > > > > > Yeah, now the type can reference the template decl, so without 
> > > > > > > > moving this, it can happen during import of the type that we 
> > > > > > > > try to read this function template bits without having imported 
> > > > > > > > them yet.
> > > > > > > Oh, I guess I met the problem before (D129748 ) and I made a 
> > > > > > > workaround for it (https://reviews.llvm.org/D130331). If I 
> > > > > > > understood right, the patch will solve that problem. I'll check 
> > > > > > > it out later.
> > > > > > > 
> > > > > > > (This kind of code move looks dangerous you know and I'll take a 
> > > > > > > double check)
> > > > > > After looking into the detailed change for the serialization part, 
> > > > > > I feel it is a not-so-good workaround indeed.. It looks like we 
> > > > > > need a better method to delay reading the type in the serializer. 
> > > > > > And I'm looking at it. @mizvekov would you like to rebase the 
> > > > > > series of patches to the main branch so that I can test it actually.
> > > > > Or would it be simpler to rebase and squash them into a draft 
> > > > > revision?
> > > > I had given this some thought, and it made sense to me that we should 
> > > > deal with the template bits first, since these are closer to the 
> > > > introducer for these declarations, and so that it would be harder to 
> > > > have a dependence the other way around.
> > > > 
> > > > But I would like to hear your thoughts on this after you have taken a 
> > > > better look.
> > > > I am working on a bunch of things right now, I should be able to rebase 
> > > > this on the next few days, but otherwise
> > > > I last rebased about 4 days ago, so you can also check that out at 
> > > > https://github.com/mizvekov/llvm-project/tree/resugar
> > > > That link has the whole stack, you probably should check out just the 
> > > > commit for this patch, as you are probably going to encounter issues 
> > > > with the resugarer if you try it on substantial code bases.
> > > > It will carry other changes with it, but I think those should be safe.
> > > I won't say it is bad to deal with template bits first. I just feel it is 
> > > a workaround to avoid the circular dependent problem in deserialization. 
> > > Or in another word, here the method works due to you put some decls* in 
> > > the template parameter types. And we avoid the circular dependent problem 
> > > by adjusting the order we deserializes. The reasons why I don't feel it 
> > > is good include:
> > > (1) Although we touched template function decl and template var decl, we 
> > > don't touched template var decl. I guess it'll be a problem now or later.
> > > (2) The solution here can't solve the similar circular dependent problem 
> > > I sawed in attributes. So the method only workarounds some resulting of 
> > > the same problem.
> > > 
> > > Or in one shorter explanation, it should be greater to solve the root 
> > > problems. I have an idea and I am going to to do a proof-of-concept 
> > > implementation first since I feel like nobody are happy about an 
> > > unimplementable idea. Generally I don't like to block patches due to such 
> > > reasons since it is completely not your fault but I guess it may be 
> > > better to wait some time. Since if we want to allow workarounds first and 
> > > clear the workarounds, things will be harder. If you want a timeline, I 
> > > guess 2 months may be reasonable choices. I mean if I can't make it in 2 
> > > months and other reviewers feel this is good (what I am seeing), I feel 
> > > bad to block this. (But if we're more patient, it'll be better). How do 
> > > you think about this?
> > Well we touch FunctionTemplates and VariableTemplates in this patch, 
> > because they were not doing template first.
> > For whatever reason, class templates were already doing template first, so 
> > no need to fix that.
> > 
> > So this patch at least puts that into consistency.
> > 
> > Also, this patch is a pre-requisite for the template resugaring 
> > specialization project I am working on, and the deadline for the whole 
> > project is about two months from now.
> > 
> > If I leave merging this patch until the end, it seems impossible that I 
> > will finish in time, as we will leave field testing this to the very end.
> > 
> > So while I understand the need for a better approach, it is indeed

[PATCH] D131858: [clang] Track the templated entity in type substitution.

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/lib/Serialization/ASTWriterDecl.cpp:623-626
+  VisitDeclaratorDecl(D);
+  Record.AddDeclarationNameLoc(D->DNLoc, D->getDeclName());
+  Record.push_back(D->getIdentifierNamespace());
+

mizvekov wrote:
> ChuanqiXu wrote:
> > mizvekov wrote:
> > > ChuanqiXu wrote:
> > > > mizvekov wrote:
> > > > > ChuanqiXu wrote:
> > > > > > ChuanqiXu wrote:
> > > > > > > ChuanqiXu wrote:
> > > > > > > > mizvekov wrote:
> > > > > > > > > ChuanqiXu wrote:
> > > > > > > > > > I still don't get the reason for the move. What's the 
> > > > > > > > > > benefit? Or why is it necessary?
> > > > > > > > > Yeah, now the type can reference the template decl, so 
> > > > > > > > > without moving this, it can happen during import of the type 
> > > > > > > > > that we try to read this function template bits without 
> > > > > > > > > having imported them yet.
> > > > > > > > Oh, I guess I met the problem before (D129748 ) and I made a 
> > > > > > > > workaround for it (https://reviews.llvm.org/D130331). If I 
> > > > > > > > understood right, the patch will solve that problem. I'll check 
> > > > > > > > it out later.
> > > > > > > > 
> > > > > > > > (This kind of code move looks dangerous you know and I'll take 
> > > > > > > > a double check)
> > > > > > > After looking into the detailed change for the serialization 
> > > > > > > part, I feel it is a not-so-good workaround indeed.. It looks 
> > > > > > > like we need a better method to delay reading the type in the 
> > > > > > > serializer. And I'm looking at it. @mizvekov would you like to 
> > > > > > > rebase the series of patches to the main branch so that I can 
> > > > > > > test it actually.
> > > > > > Or would it be simpler to rebase and squash them into a draft 
> > > > > > revision?
> > > > > I had given this some thought, and it made sense to me that we should 
> > > > > deal with the template bits first, since these are closer to the 
> > > > > introducer for these declarations, and so that it would be harder to 
> > > > > have a dependence the other way around.
> > > > > 
> > > > > But I would like to hear your thoughts on this after you have taken a 
> > > > > better look.
> > > > > I am working on a bunch of things right now, I should be able to 
> > > > > rebase this on the next few days, but otherwise
> > > > > I last rebased about 4 days ago, so you can also check that out at 
> > > > > https://github.com/mizvekov/llvm-project/tree/resugar
> > > > > That link has the whole stack, you probably should check out just the 
> > > > > commit for this patch, as you are probably going to encounter issues 
> > > > > with the resugarer if you try it on substantial code bases.
> > > > > It will carry other changes with it, but I think those should be safe.
> > > > I won't say it is bad to deal with template bits first. I just feel it 
> > > > is a workaround to avoid the circular dependent problem in 
> > > > deserialization. Or in another word, here the method works due to you 
> > > > put some decls* in the template parameter types. And we avoid the 
> > > > circular dependent problem by adjusting the order we deserializes. The 
> > > > reasons why I don't feel it is good include:
> > > > (1) Although we touched template function decl and template var decl, 
> > > > we don't touched template var decl. I guess it'll be a problem now or 
> > > > later.
> > > > (2) The solution here can't solve the similar circular dependent 
> > > > problem I sawed in attributes. So the method only workarounds some 
> > > > resulting of the same problem.
> > > > 
> > > > Or in one shorter explanation, it should be greater to solve the root 
> > > > problems. I have an idea and I am going to to do a proof-of-concept 
> > > > implementation first since I feel like nobody are happy about an 
> > > > unimplementable idea. Generally I don't like to block patches due to 
> > > > such reasons since it is completely not your fault but I guess it may 
> > > > be better to wait some time. Since if we want to allow workarounds 
> > > > first and clear the workarounds, things will be harder. If you want a 
> > > > timeline, I guess 2 months may be reasonable choices. I mean if I can't 
> > > > make it in 2 months and other reviewers feel this is good (what I am 
> > > > seeing), I feel bad to block this. (But if we're more patient, it'll be 
> > > > better). How do you think about this?
> > > Well we touch FunctionTemplates and VariableTemplates in this patch, 
> > > because they were not doing template first.
> > > For whatever reason, class templates were already doing template first, 
> > > so no need to fix that.
> > > 
> > > So this patch at least puts that into consistency.
> > > 
> > > Also, this patch is a pre-requisite for the template resugaring 
> > > specialization project I am working on, and the deadline for the whole 
> > > project is about two months from now.
> > > 
> > > If I leave merging this pat

[PATCH] D133668: [HLSL] Use _BitInt(16) for int16_t to avoid promote to int.

[Xiang Li via Phabricator via cfe-commits]

python3kgae created this revision.
python3kgae added reviewers: beanz, pow2clk, Anastasia, aaron.ballman, bogner.
Herald added a project: All.
python3kgae requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

short will be promited to int in UsualUnaryConversions.
To avoid it, switch to _BitInt(16) for int16_t.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133668

Files:
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/Basic/Targets/DirectX.h
  clang/lib/Headers/hlsl/hlsl_basic_types.h
  clang/test/CodeGenHLSL/int16_t_add.hlsl


Index: clang/test/CodeGenHLSL/int16_t_add.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/int16_t_add.hlsl
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -D__HLSL_ENABLE_16_BIT \
+// RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
+
+// Make sure generate i16 add.
+// CHECK: add nsw i16 %
+int16_t add(int16_t a, int16_t b) {
+  return a + b;
+}
+// CHECK: define noundef <2 x i16> @
+// CHECK: add <2 x i16>
+int16_t2 add(int16_t2 a, int16_t2 b) {
+  return a + b;
+}
+// CHECK: define noundef <3 x i16> @
+// CHECK: add <3 x i16>
+int16_t3 add(int16_t3 a, int16_t3 b) {
+  return a + b;
+}
+// CHECK: define noundef <4 x i16> @
+// CHECK: add <4 x i16>
+int16_t4 add(int16_t4 a, int16_t4 b) {
+  return a + b;
+}
Index: clang/lib/Headers/hlsl/hlsl_basic_types.h
===
--- clang/lib/Headers/hlsl/hlsl_basic_types.h
+++ clang/lib/Headers/hlsl/hlsl_basic_types.h
@@ -13,8 +13,8 @@
 
 #ifdef __HLSL_ENABLE_16_BIT
 // 16-bit integer.
-typedef unsigned short uint16_t;
-typedef short int16_t;
+typedef unsigned _BitInt(16) uint16_t;
+typedef _BitInt(16) int16_t;
 #endif
 
 // unsigned 32-bit integer.
Index: clang/lib/Basic/Targets/DirectX.h
===
--- clang/lib/Basic/Targets/DirectX.h
+++ clang/lib/Basic/Targets/DirectX.h
@@ -63,6 +63,7 @@
   void getTargetDefines(const LangOptions &Opts,
 MacroBuilder &Builder) const override;
 
+  bool hasBitIntType() const override { return true; }
   bool hasFeature(StringRef Feature) const override {
 return Feature == "directx";
   }
Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -3073,14 +3073,17 @@
 
 void MicrosoftCXXNameMangler::mangleType(const VectorType *T, Qualifiers Quals,
  SourceRange Range) {
-  const BuiltinType *ET = T->getElementType()->getAs();
-  assert(ET && "vectors with non-builtin elements are unsupported");
+  QualType EltTy = T->getElementType();
+  const BuiltinType *ET = EltTy->getAs();
+  const BitIntType *BitIntTy = EltTy->getAs();
+  assert((ET || BitIntTy) &&
+ "vectors with non-builtin/_BitInt elements are unsupported");
   uint64_t Width = getASTContext().getTypeSize(T);
   // Pattern match exactly the typedefs in our intrinsic headers.  Anything 
that
   // doesn't match the Intel types uses a custom mangling below.
   size_t OutSizeBefore = Out.tell();
   if (!isa(T)) {
-if (getASTContext().getTargetInfo().getTriple().isX86()) {
+if (getASTContext().getTargetInfo().getTriple().isX86() && ET) {
   if (Width == 64 && ET->getKind() == BuiltinType::LongLong) {
 mangleArtificialTagType(TTK_Union, "__m64");
   } else if (Width >= 128) {
@@ -3105,7 +3108,11 @@
 MicrosoftCXXNameMangler Extra(Context, Stream);
 Stream << "?$";
 Extra.mangleSourceName("__vector");
-Extra.mangleType(QualType(ET, 0), Range, QMM_Escape);
+if (ET)
+  Extra.mangleType(QualType(ET, 0), Range, QMM_Escape);
+else
+  Extra.mangleType(QualType(BitIntTy, 0), Range, QMM_Escape);
+
 Extra.mangleIntegerLiteral(llvm::APSInt::getUnsigned(T->getNumElements()));
 
 mangleArtificialTagType(TTK_Union, TemplateMangling, {"__clang"});


Index: clang/test/CodeGenHLSL/int16_t_add.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/int16_t_add.hlsl
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -D__HLSL_ENABLE_16_BIT \
+// RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
+
+// Make sure generate i16 add.
+// CHECK: add nsw i16 %
+int16_t add(int16_t a, int16_t b) {
+  return a + b;
+}
+// CHECK: define noundef <2 x i16> @
+// CHECK: add <2 x i16>
+int16_t2 add(int16_t2 a, int16_t2 b) {
+  return a + b;
+}
+// CHECK: define noundef <3 x i16> @
+// CHECK: add <3 x i16>
+int16_t3 add(int16_t3 a, int16_t3 b) {
+  return a + b;
+}
+// CHECK: define noundef <4 x i16> @
+// CHECK: add <4 x i16>
+int16_t4 add(int

[PATCH] D133634: [clang] Allow vector of BitInt

[Xiang Li via Phabricator via cfe-commits]

python3kgae updated this revision to Diff 459359.
python3kgae added a comment.

Update test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133634

Files:
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/Sema/builtin-classify-type.c
  clang/test/SemaCXX/ext-int.cpp


Index: clang/test/SemaCXX/ext-int.cpp
===
--- clang/test/SemaCXX/ext-int.cpp
+++ clang/test/SemaCXX/ext-int.cpp
@@ -83,11 +83,6 @@
   static constexpr bool value = true;
 };
 
-// Reject vector types:
-// expected-error@+1{{invalid vector element type '_BitInt(32)'}}
-typedef _BitInt(32) __attribute__((vector_size(16))) VecTy;
-// expected-error@+1{{invalid vector element type '_BitInt(32)'}}
-typedef _BitInt(32) __attribute__((ext_vector_type(32))) OtherVecTy;
 
 // Allow _Complex:
 _Complex _BitInt(3) Cmplx;
Index: clang/test/Sema/builtin-classify-type.c
===
--- clang/test/Sema/builtin-classify-type.c
+++ clang/test/Sema/builtin-classify-type.c
@@ -29,6 +29,8 @@
   __attribute__((vector_size(16))) int vec;
   typedef __attribute__((ext_vector_type(4))) int evec_t;
   evec_t evec;
+  typedef _BitInt(16) int16_t3 __attribute__((ext_vector_type(3)));
+  int16_t3 t3;
   _Atomic int atomic_i;
   _Atomic double atomic_d;
   _Complex int complex_i;
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2707,7 +2707,7 @@
   // We explictly allow bool elements in ext_vector_type for C/C++.
   bool IsNoBoolVecLang = getLangOpts().OpenCL || getLangOpts().OpenCLCPlusPlus;
   if ((!T->isDependentType() && !T->isIntegerType() &&
-   !T->isRealFloatingType()) || T->isBitIntType() ||
+   !T->isRealFloatingType()) ||
   (IsNoBoolVecLang && T->isBooleanType())) {
 Diag(AttrLoc, diag::err_attribute_invalid_vector_type) << T;
 return QualType();
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -4080,9 +4080,10 @@
 
 /// getExtVectorType - Return the unique reference to an extended vector type 
of
 /// the specified element type and size. VectorType must be a built-in type.
-QualType
-ASTContext::getExtVectorType(QualType vecType, unsigned NumElts) const {
-  assert(vecType->isBuiltinType() || vecType->isDependentType());
+QualType ASTContext::getExtVectorType(QualType vecType,
+  unsigned NumElts) const {
+  assert(vecType->isBuiltinType() || vecType->isDependentType() ||
+ vecType->isBitIntType());
 
   // Check if we've already instantiated a vector of this type.
   llvm::FoldingSetNodeID ID;


Index: clang/test/SemaCXX/ext-int.cpp
===
--- clang/test/SemaCXX/ext-int.cpp
+++ clang/test/SemaCXX/ext-int.cpp
@@ -83,11 +83,6 @@
   static constexpr bool value = true;
 };
 
-// Reject vector types:
-// expected-error@+1{{invalid vector element type '_BitInt(32)'}}
-typedef _BitInt(32) __attribute__((vector_size(16))) VecTy;
-// expected-error@+1{{invalid vector element type '_BitInt(32)'}}
-typedef _BitInt(32) __attribute__((ext_vector_type(32))) OtherVecTy;
 
 // Allow _Complex:
 _Complex _BitInt(3) Cmplx;
Index: clang/test/Sema/builtin-classify-type.c
===
--- clang/test/Sema/builtin-classify-type.c
+++ clang/test/Sema/builtin-classify-type.c
@@ -29,6 +29,8 @@
   __attribute__((vector_size(16))) int vec;
   typedef __attribute__((ext_vector_type(4))) int evec_t;
   evec_t evec;
+  typedef _BitInt(16) int16_t3 __attribute__((ext_vector_type(3)));
+  int16_t3 t3;
   _Atomic int atomic_i;
   _Atomic double atomic_d;
   _Complex int complex_i;
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2707,7 +2707,7 @@
   // We explictly allow bool elements in ext_vector_type for C/C++.
   bool IsNoBoolVecLang = getLangOpts().OpenCL || getLangOpts().OpenCLCPlusPlus;
   if ((!T->isDependentType() && !T->isIntegerType() &&
-   !T->isRealFloatingType()) || T->isBitIntType() ||
+   !T->isRealFloatingType()) ||
   (IsNoBoolVecLang && T->isBooleanType())) {
 Diag(AttrLoc, diag::err_attribute_invalid_vector_type) << T;
 return QualType();
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -4080,9 +4080,10 @@
 
 /// getExtVectorType - Return the unique reference to an extended vector type of
 /// the specified element type and size. VectorType must be a built-in type.

[PATCH] D133659: [Clang] P1169R4: static operator()

[Roy Jacobson via Phabricator via cfe-commits]

royjacobson updated this revision to Diff 459361.
royjacobson edited the summary of this revision.
royjacobson added a comment.

Fix codegen test on windows, rebase on main.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133659

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/OperatorKinds.def
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/over/over.oper/over.literal/p7.cpp
  clang/test/CodeGenCXX/cxx2b-static-call-operator.cpp
  clang/test/Parser/cxx2b-lambdas-ext-warns.cpp
  clang/test/Parser/cxx2b-lambdas.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1481,7 +1481,7 @@
 
   static operator()
   https://wg21.link/P1169R4";>P1169R4
-  No
+  Clang 16
 
 
   Extended floating-point types and standard names
Index: clang/test/Parser/cxx2b-lambdas.cpp
===
--- clang/test/Parser/cxx2b-lambdas.cpp
+++ clang/test/Parser/cxx2b-lambdas.cpp
@@ -38,3 +38,16 @@
 auto XL4 = [] requires true {}; // expected-error{{expected body}}
 auto XL5 = [] requires true requires true {}; // expected-error{{expected body}}
 auto XL6 = [] requires true noexcept requires true {}; // expected-error{{expected body}}
+
+auto XL7 = []() static static {}; // expected-error {{cannot appear multiple times}}
+auto XL8 = []() static mutable {}; // expected-error {{cannot be both mutable and static}}
+
+auto XL9 = [] static {};
+auto XL10 = []() static {};
+
+void static_captures() {
+  int x;
+  auto SC1 = [&]() static {}; // expected-error {{a static lambda cannot capture}}
+  auto SC2 = [&x]() static {}; // expected-error {{a static lambda cannot capture}}
+  auto SC3 = [=]() static {}; // expected-error {{a static lambda cannot capture}}
+}
Index: clang/test/Parser/cxx2b-lambdas-ext-warns.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx2b-lambdas-ext-warns.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -std=c++20 %s -verify=expected,cxx20
+// RUN: %clang_cc1 -std=c++2b %s -verify=expected,cxx2b
+
+//cxx2b-no-diagnostics
+
+auto L1 = [] constexpr {}; // cxx20-warning {{lambda without a parameter clause is a C++2b extension}}
+auto L2 = []() static {}; // cxx20-warning {{static lambdas is a C++2b extension}}
+auto L3 = [] static {}; // cxx20-warning {{static lambdas is a C++2b extension}} // cxx20-warning {{lambda without a parameter clause is a C++2b extension}}
Index: clang/test/CodeGenCXX/cxx2b-static-call-operator.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/cxx2b-static-call-operator.cpp
@@ -0,0 +1,39 @@
+// RUN: %clang_cc1 -std=c++2b %s -emit-llvm -triple x86_64-linux -o - | FileCheck %s
+// RUN: %clang_cc1 -std=c++2b %s -emit-llvm -triple x86_64-windows-msvc -o - | FileCheck %s
+
+struct Functor {
+  static int operator()(int x, int y) {
+return x + y;
+  }
+};
+
+auto GetALambda() {
+  return [](int x, int y) static {
+return x + y;
+  };
+}
+
+void CallsTheLambda() {
+  GetALambda()(1, 2);
+}
+
+// CHECK:  define {{.*}}CallsTheLambda{{.*}}
+// CHECK-NEXT: entry:
+// CHECK-NEXT:   %call = call noundef i32 {{.*}}(i32 noundef 1, i32 noundef 2)
+// CHECK-NEXT:   ret void
+// CHECK-NEXT: }
+
+void call_static_call_operator() {
+  Functor f;
+  f(101, 102);
+  f.operator()(201, 202);
+  Functor{}(301, 302);
+}
+
+// CHECK:  define {{.*}}call_static_call_operator{{.*}}
+// CHECK-NEXT: entry:
+// CHECK:{{.*}} = call noundef i32 {{.*}}Functor{{.*}}(i32 noundef 101, i32 noundef 102)
+// CHECK-NEXT:   {{.*}} = call noundef i32 {{.*}}Functor{{.*}}(i32 noundef 201, i32 noundef 202)
+// CHECK-NEXT:   {{.*}} = call noundef i32 {{.*}}Functor{{.*}}(i32 noundef 301, i32 noundef 302)
+// CHECK-NEXT:   ret void
+// CHECK-NEXT: }
Index: clang/test/CXX/over/over.oper/over.literal/p7.cpp
===
--- clang/test/CXX/over/over.oper/over.literal/p7.cpp
+++ clang/test/CXX/over/over.oper/over.literal/p7.cpp
@@ -1,5 +1,8 @@
-// RUN: %clang_cc1 -std=c++11 %s -verify
-// expected-no-diagnostics
+// RUN: %clang_cc1 -std=c++11 %s -verify=expected,cxx11
+// RUN: %clang_cc1 -std=c++2b %s -verify=expected,cxx2b
+
+//cxx2b-no-diagnostics
+
 
 constexpr int operator "" _a(const char *c) {
   return c[0];
@@ -15,3 +18,8 @@
   operator "" _puts("f

[PATCH] D111509: [clang] use getCommonSugar in an assortment of places

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 459362.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111509

Files:
  clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/narrowing-conversions-ignoreconversionfromtypes-option.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/AST/ast-dump-fpfeatures.cpp
  clang/test/CodeGen/compound-assign-overflow.c
  clang/test/Sema/complex-int.c
  clang/test/Sema/matrix-type-operators.c
  clang/test/Sema/nullability.c
  clang/test/Sema/sugar-common-types.c
  clang/test/SemaCXX/complex-conversion.cpp
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaCXX/sugar-common-types.cpp
  clang/test/SemaCXX/sugared-auto.cpp
  clang/test/SemaObjC/format-strings-objc.m
  compiler-rt/test/ubsan/TestCases/Integer/add-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/no-recover.cpp
  compiler-rt/test/ubsan/TestCases/Integer/sub-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
  lldb/test/API/commands/expression/rdar42038760/main.c
  lldb/test/API/commands/expression/rdar44436068/main.c

Index: lldb/test/API/commands/expression/rdar44436068/main.c
===
--- lldb/test/API/commands/expression/rdar44436068/main.c
+++ lldb/test/API/commands/expression/rdar44436068/main.c
@@ -3,6 +3,6 @@
 __int128_t n = 1;
 n = n + n;
 return n; //%self.expect("p n", substrs=['(__int128_t) $0 = 2'])
-  //%self.expect("p n + 6", substrs=['(__int128) $1 = 8'])
-  //%self.expect("p n + n", substrs=['(__int128) $2 = 4'])
+  //%self.expect("p n + 6", substrs=['(__int128_t) $1 = 8'])
+  //%self.expect("p n + n", substrs=['(__int128_t) $2 = 4'])
 }
Index: lldb/test/API/commands/expression/rdar42038760/main.c
===
--- lldb/test/API/commands/expression/rdar42038760/main.c
+++ lldb/test/API/commands/expression/rdar42038760/main.c
@@ -10,7 +10,7 @@
   struct S0 l_19;
   l_19.f2 = 419;
   uint32_t l_4037 = 4294967295UL;
-  l_19.f2 = g_463; //%self.expect("expr ((l_4037 % (-(g_463))) | l_19.f2)", substrs=['(unsigned int) $0 = 358717883'])
+  l_19.f2 = g_463; //%self.expect("expr ((l_4037 % (-(g_463))) | l_19.f2)", substrs=['(uint32_t) $0 = 358717883'])
 }
 int main()
 {
Index: compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
@@ -12,12 +12,12 @@
 
 #ifdef SUB_I32
   (void)(uint32_t(1) - uint32_t(2));
-  // CHECK-SUB_I32: usub-overflow.cpp:[[@LINE-1]]:22: runtime error: unsigned integer overflow: 1 - 2 cannot be represented in type 'unsigned int'
+  // CHECK-SUB_I32: usub-overflow.cpp:[[@LINE-1]]:22: runtime error: unsigned integer overflow: 1 - 2 cannot be represented in type '{{uint32_t|unsigned int}}'
 #endif
 
 #ifdef SUB_I64
   (void)(uint64_t(800ll) - uint64_t(900ll));
-  // CHECK-SUB_I64: 800 - 900 cannot be represented in type 'unsigned {{long( long)?}}'
+  // CHECK-SUB_I64: 800 - 900 cannot be represented in type '{{uint64_t|unsigned long( long)?}}'
 #endif
 
 #ifdef SUB_I128
@@ -26,6 +26,6 @@
 # else
   puts("__int128 not supported\n");
 # endif
-  // CHECK-SUB_I128: {{0x4000 - 0x8000 cannot be represented in type 'unsigned __int128'|__int128 not supported}}
+  // CHECK-SUB_I128: {{0x4000 - 0x8000 cannot be represented in type '__uint128_t'|__int128 not supported}}
 #endif
 }
Index: compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
@@ -13,7 +13,7 @@
   (void)(uint16_t(0x) * uint16_t(0x8001));
 
   (void)(uint32_t(0x) * uint32_t(0x2));
-  // CHECK: umul-overflow.cpp:15:31: runtime error: unsigned integer overflow: 4294967295 * 2 cannot be represented in type 'unsigned int'
+  // CHECK: umul-overflow.cpp:15:31: runtime error: unsigned integer overflow: 4294967295 * 2 cannot be represented in type '{{uint32_t|unsigned int}}'
 
   return 0;
 }
Index: compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/In

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

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 459363.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130308

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/SemaCXX/sugar-common-types.cpp

Index: clang/test/SemaCXX/sugar-common-types.cpp
===
--- clang/test/SemaCXX/sugar-common-types.cpp
+++ clang/test/SemaCXX/sugar-common-types.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++20 -fenable-matrix
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++20 -fenable-matrix -triple i686-pc-win32
 
 enum class N {};
 
@@ -38,3 +38,77 @@
 N t7 = X4() + Y4(); // expected-error {{rvalue of type 'B4'}}
 N t8 = X4() * Y4(); // expected-error {{rvalue of type 'B4'}}
 N t9 = X5() * Y5(); // expected-error {{rvalue of type 'A4 __attribute__((matrix_type(3, 3)))'}}
+
+template  struct S1 {
+  template  struct S2 {};
+};
+
+N t10 = 0 ? S1() : S1(); // expected-error {{from 'S1' (aka 'S1')}}
+N t11 = 0 ? S1::S2() : S1::S2(); // expected-error {{from 'S1::S2' (aka 'S2')}}
+
+template  using Al = S1;
+
+N t12 = 0 ? Al() : Al(); // expected-error {{from 'Al' (aka 'S1')}}
+
+#define AS1 __attribute__((address_space(1)))
+#define AS2 __attribute__((address_space(1)))
+using AS1X1 = AS1 B1;
+using AS1Y1 = AS1 B1;
+using AS2Y1 = AS2 B1;
+N t13 = 0 ? (AS1X1){} : (AS1Y1){}; // expected-error {{rvalue of type 'AS1 B1' (aka '__attribute__((address_space(1))) int')}}
+N t14 = 0 ? (AS1X1){} : (AS2Y1){}; // expected-error {{rvalue of type '__attribute__((address_space(1))) B1' (aka '__attribute__((address_space(1))) int')}}
+
+using FX1 = X1 ();
+using FY1 = Y1 ();
+N t15 = 0 ? (FX1*){} : (FY1*){}; // expected-error {{rvalue of type 'B1 (*)()' (aka 'int (*)()')}}
+
+struct SS1 {};
+using SB1 = SS1;
+using SX1 = SB1;
+using SY1 = SB1;
+
+using MFX1 = X1 SX1::*();
+using MFY1 = Y1 SY1::*();
+
+N t16 = 0 ? (MFX1*){} : (MFY1*){}; // expected-error {{rvalue of type 'B1 SB1::*(*)()'}}
+
+N t17 = 0 ? (FX1 SX1::*){} : (FY1 SY1::*){}; // expected-error {{rvalue of type 'B1 (SB1::*)() __attribute__((thiscall))'}}
+
+N t18 = 0 ? (__typeof(X1*)){} : (__typeof(Y1*)){}; // expected-error {{rvalue of type 'typeof(B1 *)' (aka 'int *')}}
+
+struct Enums {
+  enum X : B1;
+  enum Y : ::B1;
+};
+using EnumsB = Enums;
+using EnumsX = EnumsB;
+using EnumsY = EnumsB;
+
+N t19 = 0 ? (__underlying_type(EnumsX::X)){} : (__underlying_type(EnumsY::Y)){};
+// expected-error@-1 {{rvalue of type 'B1' (aka 'int')}}
+
+N t20 = 0 ? (__underlying_type(EnumsX::X)){} : (__underlying_type(EnumsY::X)){};
+// expected-error@-1 {{rvalue of type '__underlying_type(Enums::X)' (aka 'int')}}
+
+using SBTF1 = SS1 [[clang::btf_type_tag("1")]];
+using SBTF2 = ::SS1 [[clang::btf_type_tag("1")]];
+using SBTF3 = ::SS1 [[clang::btf_type_tag("2")]];
+
+N t21 = 0 ? (SBTF1){} : (SBTF3){}; // expected-error {{from 'SS1'}}
+N t22 = 0 ? (SBTF1){} : (SBTF2){}; // expected-error {{from 'SS1 btf_type_tag(1)' (aka 'SS1')}}
+
+using QX = const SB1 *;
+using QY = const ::SB1 *;
+N t23 = 0 ? (QX){} : (QY){}; // expected-error {{rvalue of type 'const SB1 *' (aka 'const SS1 *')}}
+
+template  using Alias = short;
+N t24 = 0 ? (Alias){} : (Alias){}; // expected-error {{rvalue of type 'Alias' (aka 'short')}}
+N t25 = 0 ? (Alias){} : (Alias){}; // expected-error {{rvalue of type 'short'}}
+
+template  concept C1 = true;
+template  concept C2 = true;
+C1 auto t26_1 = (SB1){};
+C1 auto t26_2 = (::SB1){};
+C2 auto t26_3 = (::SB1){};
+N t26 = 0 ? t26_1 : t26_2; // expected-error {{from 'SB1' (aka 'SS1')}}
+N t27 = 0 ? t26_1 : t26_3; // expected-error {{from 'SB1' (aka 'SS1')}}
Index: clang/lib/Sema/SemaTemplateDeduction.cpp
===
--- clang/lib/Sema/SemaTemplateDeduction.cpp
+++ clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -3825,13 +3825,11 @@
 //   - If A is an array type, the pointer type produced by the
 // array-to-pointer standard conversion (4.2) is used in place of
 // A for type deduction; otherwise,
-if (ArgType->isArrayType())
-  ArgType = S.Context.getArrayDecayedType(ArgType);
 //   - If A is a function type, the pointer type produced by the
 // function-to-pointer standard conversion (4.3) is used in place
 // of A for type deduction; otherwise,
-else if (ArgType->isFunctionType())
-  ArgType = S.Context.getPointerType(ArgType);
+if (ArgType->canDecayToPointerType())
+  ArgType = S.Context.getDecayedType(ArgType);
 else {
   // - If A is a cv-qualified type, the top level cv-qualifiers of A's
   //   type are ignored for type deduction.
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -3332,6 +333

[PATCH] D133261: NFC: [clang] add template AST test for make_integer_seq and type_pack_element

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 459364.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133261

Files:
  clang/test/SemaTemplate/make_integer_seq.cpp
  clang/test/SemaTemplate/type_pack_element.cpp

Index: clang/test/SemaTemplate/type_pack_element.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/type_pack_element.cpp
@@ -0,0 +1,68 @@
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -triple x86_64-linux-gnu -ast-dump -verify -xc++ < %s | FileCheck %s
+
+using test1 = __type_pack_element<0, int>;
+//  CHECK: |-TypeAliasDecl 0x{{[0-9A-Fa-f]+}} <:3:1, col:41> col:7 test1 '__type_pack_element<0, int>':'int'
+// CHECK-NEXT:   `-ElaboratedType 0x{{[0-9A-Fa-f]+}} '__type_pack_element<0, int>' sugar
+// CHECK-NEXT: `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__type_pack_element<0, int>' sugar __type_pack_element
+// CHECK-NEXT:   |-TemplateArgument expr
+// CHECK-NEXT:   | `-ConstantExpr 0x{{[0-9A-Fa-f]+}}  'unsigned long'
+// CHECK-NEXT:   |   |-value: Int 0
+// CHECK-NEXT:   |   `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'unsigned long' 
+// CHECK-NEXT:   | `-IntegerLiteral 0x{{[0-9A-Fa-f]+}}  'int' 0
+// CHECK-NEXT:   |-TemplateArgument type 'int'
+// CHECK-NEXT:   | `-BuiltinType 0x{{[0-9A-Fa-f]+}} 'int'
+// CHECK-NEXT:   `-BuiltinType 0x{{[0-9A-Fa-f]+}} 'int'
+
+template struct A {
+  using test2 = __type_pack_element;
+//  CHECK: |-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test2 '__type_pack_element':'__type_pack_element'
+// CHECK-NEXT:   `-ElaboratedType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' sugar dependent
+// CHECK-NEXT: `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' dependent __type_pack_element
+// CHECK-NEXT:   |-TemplateArgument expr
+// CHECK-NEXT:   | `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'unsigned long' 
+// CHECK-NEXT:   |   `-DeclRefExpr 0x{{[0-9A-Fa-f]+}}  'int' NonTypeTemplateParm 0x{{[0-9A-Fa-f]+}} 'N' 'int'
+// CHECK-NEXT:   `-TemplateArgument type 'Ts...'
+// CHECK-NEXT: `-PackExpansionType 0x{{[0-9A-Fa-f]+}} 'Ts...' dependent
+// CHECK-NEXT:   `-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'Ts' dependent contains_unexpanded_pack depth 0 index 1 pack
+// CHECK-NEXT: `-TemplateTypeParm 0x{{[0-9A-Fa-f]+}} 'Ts'
+
+  using test3 = __type_pack_element<0, Ts...>;
+//  CHECK: |-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test3 '__type_pack_element<0, Ts...>':'__type_pack_element<0, Ts...>'
+// CHECK-NEXT:   `-ElaboratedType 0x{{[0-9A-Fa-f]+}} '__type_pack_element<0, Ts...>' sugar dependent
+// CHECK-NEXT: `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__type_pack_element<0, Ts...>' dependent __type_pack_element
+// CHECK-NEXT:   |-TemplateArgument expr
+// CHECK-NEXT:   | `-ConstantExpr 0x{{[0-9A-Fa-f]+}}  'unsigned long'
+// CHECK-NEXT:   |   |-value: Int 0
+// CHECK-NEXT:   |   `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'unsigned long' 
+// CHECK-NEXT:   | `-IntegerLiteral 0x{{[0-9A-Fa-f]+}}  'int' 0
+// CHECK-NEXT:   `-TemplateArgument type 'Ts...'
+// CHECK-NEXT: `-PackExpansionType 0x{{[0-9A-Fa-f]+}} 'Ts...' dependent
+// CHECK-NEXT:   `-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'Ts' dependent contains_unexpanded_pack depth 0 index 1 pack
+// CHECK-NEXT: `-TemplateTypeParm 0x{{[0-9A-Fa-f]+}} 'Ts'
+
+  using test4 = __type_pack_element;
+//  CHECK: `-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test4 '__type_pack_element':'__type_pack_element'
+// CHECK-NEXT:   `-ElaboratedType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' sugar dependent
+// CHECK-NEXT: `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' dependent __type_pack_element
+// CHECK-NEXT:   |-TemplateArgument expr
+// CHECK-NEXT:   | `-ImplicitCastExpr 0x{{[0-9A-Fa-f]+}}  'unsigned long' 
+// CHECK-NEXT:   |   `-DeclRefExpr 0x{{[0-9A-Fa-f]+}}  'int' NonTypeTemplateParm 0x{{[0-9A-Fa-f]+}} 'N' 'int'
+// CHECK-NEXT:   `-TemplateArgument type 'int'
+// CHECK-NEXT: `-BuiltinType 0x{{[0-9A-Fa-f]+}} 'int'
+};
+
+template  struct B; // expected-note {{template is declared here}}
+template  struct B> {};
+template struct B; // expected-error {{explicit instantiation of undefined template}}
+
+template  struct C; // expected-note {{template is declared here}}
+template  struct C> {};
+template struct C; // expected-error {{explicit instantiation of undefined template}}
+
+template  struct D;
+template  struct D<__type_pack_element<0, T, U>> {};
+template  struct D<__type_pack_element<0, U, T>> {};
+
+template  struct E;
+template  struct E<__type_pack_element<0, T>> {};
+template  struct E<__type_pack_element<0, T, U>> {};
Index: clang/test/SemaTemplate/make_integer_seq.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/m

[PATCH] D133262: [clang] Fixes how we represent / emulate builtin templates

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 459365.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133262

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/DeclTemplate.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/DeclTemplate.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/SemaTemplate/make_integer_seq.cpp
  clang/test/SemaTemplate/type_pack_element.cpp
  libcxx/DELETE.ME
  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
@@ -59,19 +59,6 @@
   limit: 2
 timeout_in_minutes: 120
 
-  - label: "Documentation"
-command: "libcxx/utils/ci/run-buildbot documentation"
-artifact_paths:
-  - "**/test-results.xml"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
   #
   # General testing with the default configuration, under all the supported
   # Standard modes, with Clang and GCC. This catches most issues upfront.
@@ -79,273 +66,6 @@
   #
   - wait
 
-  - label: "C++2b"
-command: "libcxx/utils/ci/run-buildbot generic-cxx2b"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "C++11"
-command: "libcxx/utils/ci/run-buildbot generic-cxx11"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "C++03"
-command: "libcxx/utils/ci/run-buildbot generic-cxx03"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "Modular build"
-command: "libcxx/utils/ci/run-buildbot generic-modules"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "GCC ${GCC_STABLE_VERSION} / C++latest"
-command: "libcxx/utils/ci/run-buildbot generic-gcc"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "gcc-${GCC_STABLE_VERSION}"
-CXX: "g++-${GCC_STABLE_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  #
-  # All other supported configurations of libc++.
-  #
-  - wait
-
-  - label: "C++20"
-command: "libcxx/utils/ci/run-buildbot generic-cxx20"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "C++17"
-command: "libcxx/utils/ci/run-buildbot generic-cxx17"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-# TODO (mordante) use head
-#CC: "clang-${LLVM_HEAD_VERSION}"
-#CXX: "clang++-${LLVM_HEAD_VERSION}"
-CC: "clang-15"
-CXX: "clang++-15"
-agents:
-  queue: "libcxx-builders"
-  os: "linux"
-retry:
-  automatic:
-- exit_status: -1  # Agent was lost
-  limit: 2
-timeout_in_minutes: 120
-
-  - label: "C++14"
-command: "libcxx/utils/ci/run-buildbot generic-cxx14"
-artifact_paths:
-  - "**/test-results.xml"
-  - "**/*.abilist"
-env:
-CC: "clang-${LLVM_HEAD_VERSION}"
-CXX: "clang++-${LLVM_HEAD_VERSION}"
-agents:
-  queu

[PATCH] D131858: [clang] Track the templated entity in type substitution.

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 459366.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131858

Files:
  clang-tools-extra/clang-tidy/hicpp/ExceptionBaseclassCheck.cpp
  clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
  clang-tools-extra/clangd/AST.cpp
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/include/clang/AST/JSONNodeDumper.h
  clang/include/clang/AST/TextNodeDumper.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Sema/Template.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/ODRHash.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/lib/StaticAnalyzer/Checkers/MismatchedIteratorChecker.cpp
  clang/test/AST/ast-dump-openmp-begin-declare-variant_reference.cpp
  clang/test/AST/ast-dump-template-decls.cpp
  clang/test/AST/deduction-guides.cpp
  clang/test/SemaTemplate/deduction-guide.cpp
  clang/test/SemaTemplate/make_integer_seq.cpp
  clang/test/SemaTemplate/type_pack_element.cpp
  libcxx/DELETE.ME

Index: libcxx/DELETE.ME
===
--- libcxx/DELETE.ME
+++ libcxx/DELETE.ME
@@ -1 +1,2 @@
 D133262
+D131858
Index: clang/test/SemaTemplate/type_pack_element.cpp
===
--- clang/test/SemaTemplate/type_pack_element.cpp
+++ clang/test/SemaTemplate/type_pack_element.cpp
@@ -11,14 +11,13 @@
 // CHECK-NEXT:   | `-IntegerLiteral 0x{{[0-9A-Fa-f]+}}  'int' 0
 // CHECK-NEXT:   |-TemplateArgument type 'int'
 // CHECK-NEXT:   | `-BuiltinType 0x{{[0-9A-Fa-f]+}} 'int'
-// CHECK-NEXT:   `-SubstTemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'int' sugar
-// CHECK-NEXT: |-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'auto' dependent depth 0 index 1
-// CHECK-NEXT: | `-TemplateTypeParm 0x{{[0-9A-Fa-f]+}} ''
+// CHECK-NEXT:   `-SubstTemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'int' sugar typename depth 0 index 1 ...
+// CHECK-NEXT: |-BuiltinTemplate 0x{{[0-9A-Fa-f]+}} '__type_pack_element'
 // CHECK-NEXT: `-BuiltinType 0x{{[0-9A-Fa-f]+}} 'int'
 
 template struct A {
   using test2 = __type_pack_element;
-//  CHECK: |-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test2 '__type_pack_element':'__type_pack_element'
+//  CHECK: |-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test2 '__type_pack_element':'__type_pack_element'
 // CHECK-NEXT:   `-ElaboratedType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' sugar dependent
 // CHECK-NEXT: `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' sugar dependent alias __type_pack_element
 // CHECK-NEXT:   |-TemplateArgument expr
@@ -38,7 +37,7 @@
 // CHECK-NEXT:   `-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'type-parameter-0-1' dependent contains_unexpanded_pack depth 0 index 1 pack
 
   using test3 = __type_pack_element<0, Ts...>;
-//  CHECK: |-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test3 '__type_pack_element<0, Ts...>':'__type_pack_element<0, type-parameter-0-1...>'
+//  CHECK: |-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test3 '__type_pack_element<0, Ts...>':'__type_pack_element<0, type-parameter-0-1...>'
 // CHECK-NEXT:   `-ElaboratedType 0x{{[0-9A-Fa-f]+}} '__type_pack_element<0, Ts...>' sugar dependent
 // CHECK-NEXT: `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__type_pack_element<0, Ts...>' sugar dependent alias __type_pack_element
 // CHECK-NEXT:   |-TemplateArgument expr
@@ -58,7 +57,7 @@
 // CHECK-NEXT:   `-TemplateTypeParmType 0x{{[0-9A-Fa-f]+}} 'type-parameter-0-1' dependent contains_unexpanded_pack depth 0 index 1 pack
 
   using test4 = __type_pack_element;
-//  CHECK: `-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test4 '__type_pack_element':'__type_pack_element'
+//  CHECK: `-TypeAliasDecl 0x{{[0-9A-Fa-f]+}}  col:9 test4 '__type_pack_element':'__type_pack_element'
 // CHECK-NEXT:   `-ElaboratedType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' sugar dependent
 // CHECK-NEXT: `-TemplateSpecializationType 0x{{[0-9A-Fa-f]+}} '__type_pack_element' sugar dependent alias __type_pack_element
 // CHECK-NEXT:   |-TemplateArgument expr
Index: clang/test/SemaTemplate/make_integer_seq.cpp
===
--- clang/test/SemaTemplate/make_integer_seq.cp

[PATCH] D132816: [clang] AST: SubstTemplateTypeParmType support for non-canonical underlying type

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 459367.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132816

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Sema/SemaTemplate.cpp

Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -3506,8 +3506,8 @@
 
   // Wrap the type in substitution sugar.
   auto getSubstType = [&](unsigned IndexReplaced, QualType Replacement) {
-return SemaRef.Context.getSubstTemplateTypeParmType(
-Replacement.getCanonicalType(), BTD, IndexReplaced);
+return SemaRef.Context.getSubstTemplateTypeParmType(Replacement, BTD,
+IndexReplaced);
   };
 
   switch (BTD->getBuiltinTemplateKind()) {
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -3718,6 +3718,11 @@
 : Type(SubstTemplateTypeParm, Replacement.getCanonicalType(),
Replacement->getDependence()),
   ReplacedDecl(ReplacedDecl) {
+  SubstTemplateTypeParmTypeBits.HasNonCanonicalUnderlyingType =
+  Replacement != getCanonicalTypeInternal();
+  if (SubstTemplateTypeParmTypeBits.HasNonCanonicalUnderlyingType)
+*getTrailingObjects() = Replacement;
+
   SubstTemplateTypeParmTypeBits.Index = Index;
   assert(ReplacedDecl != nullptr);
   assert(getReplacedParameter() != nullptr);
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -1529,8 +1529,7 @@
 return ToReplacementTypeOrErr.takeError();
 
   return Importer.getToContext().getSubstTemplateTypeParmType(
-  ToReplacementTypeOrErr->getCanonicalType(), *ReplacedOrErr,
-  T->getIndex());
+  *ToReplacementTypeOrErr, *ReplacedOrErr, T->getIndex());
 }
 
 ExpectedType ASTNodeImporter::VisitSubstTemplateTypeParmPackType(
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -4752,9 +4752,6 @@
 QualType ASTContext::getSubstTemplateTypeParmType(QualType Replacement,
   Decl *ReplacedDecl,
   unsigned Index) const {
-  assert(Replacement.isCanonical()
- && "replacement types must always be canonical");
-
   llvm::FoldingSetNodeID ID;
   SubstTemplateTypeParmType::Profile(ID, Replacement, ReplacedDecl, Index);
   void *InsertPos = nullptr;
@@ -4762,8 +4759,11 @@
   SubstTemplateTypeParmTypes.FindNodeOrInsertPos(ID, InsertPos);
 
   if (!SubstParm) {
-SubstParm = new (*this, TypeAlignment)
-SubstTemplateTypeParmType(Replacement, ReplacedDecl, Index);
+void *Mem = Allocate(SubstTemplateTypeParmType::totalSizeToAlloc(
+ !Replacement.isCanonical()),
+ TypeAlignment);
+SubstParm =
+new (Mem) SubstTemplateTypeParmType(Replacement, ReplacedDecl, Index);
 Types.push_back(SubstParm);
 SubstTemplateTypeParmTypes.InsertNode(SubstParm, InsertPos);
   }
Index: clang/include/clang/AST/TypeProperties.td
===
--- clang/include/clang/AST/TypeProperties.td
+++ clang/include/clang/AST/TypeProperties.td
@@ -741,7 +741,7 @@
   // The call to getCanonicalType here existed in ASTReader.cpp, too.
   def : Creator<[{
 return ctx.getSubstTemplateTypeParmType(
-ctx.getCanonicalType(replacementType), replacedDecl, Index);
+replacementType, replacedDecl, Index);
   }]>;
 }
 
Index: clang/include/clang/AST/Type.h
===
--- clang/include/clang/AST/Type.h
+++ clang/include/clang/AST/Type.h
@@ -1798,8 +1798,10 @@
 
 unsigned : NumTypeBits;
 
+unsigned HasNonCanonicalUnderlyingType : 1;
+
 // The index of the template parameter this substitution represents.
-unsigned Index;
+unsigned Index : 16;
   };
 
   class SubstTemplateTypeParmPackTypeBitfields {
@@ -4981,8 +4983,12 @@
 /// been replaced with these.  They are used solely to record that a
 /// type was originally written as a template type parameter;
 /// therefore they are never canonical.
-class SubstTemplateTypeParmType : public Type, public llvm::FoldingSetNode {
+class SubstTemplateTypeParmType final
+: public Type,
+  public llvm::FoldingSetNode,
+  private llvm::TrailingObjects {
   friend class ASTContext;
+  friend class llvm::TrailingObjects;
 
   Decl *ReplacedDecl;
 
@@ -4992,7 +4998,11 @@
 public:
   /// 

[PATCH] D133468: [clang] Implement divergence for TypedefType and UsingType

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 459368.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133468

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/JSONNodeDumper.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/AST/Type.cpp
  clang/test/SemaCXX/sugar-common-types.cpp

Index: clang/test/SemaCXX/sugar-common-types.cpp
===
--- clang/test/SemaCXX/sugar-common-types.cpp
+++ clang/test/SemaCXX/sugar-common-types.cpp
@@ -112,3 +112,22 @@
 C2 auto t26_3 = (::SB1){};
 N t26 = 0 ? t26_1 : t26_2; // expected-error {{from 'SB1' (aka 'SS1')}}
 N t27 = 0 ? t26_1 : t26_3; // expected-error {{from 'SB1' (aka 'SS1')}}
+
+using RPB1 = X1*;
+using RPX1 = RPB1;
+using RPB1 = Y1*; // redeclared
+using RPY1 = RPB1;
+N t28 = *(RPB1){}; // expected-error {{lvalue of type 'Y1' (aka 'int')}}
+auto t29 = 0 ? (RPX1){} : (RPY1){};
+N t30 = t29;  // expected-error {{lvalue of type 'RPB1' (aka 'int *')}}
+N t31 = *t29; // expected-error {{lvalue of type 'B1' (aka 'int')}}
+
+namespace A { using type1 = X1*; };
+namespace C { using A::type1; };
+using UPX1 = C::type1;
+namespace A { using type1 = Y1*; };  // redeclared
+namespace C { using A::type1; }; // redeclared
+using UPY1 = C::type1;
+auto t32 = 0 ? (UPX1){} : (UPY1){};
+N t33 = t32;  // expected-error {{lvalue of type 'C::type1' (aka 'int *')}}
+N t34 = *t32; // expected-error {{lvalue of type 'B1' (aka 'int')}}
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -3434,25 +3434,34 @@
 }
 
 TypedefType::TypedefType(TypeClass tc, const TypedefNameDecl *D,
- QualType underlying, QualType can)
-: Type(tc, can, toSemanticDependence(underlying->getDependence())),
+ QualType Underlying, QualType can)
+: Type(tc, can, toSemanticDependence(can->getDependence())),
   Decl(const_cast(D)) {
   assert(!isa(can) && "Invalid canonical type");
+  TypedefBits.isDivergent = !Underlying.isNull();
+  if (isDivergent())
+*reinterpret_cast(this + 1) = Underlying;
 }
 
 QualType TypedefType::desugar() const {
-  return getDecl()->getUnderlyingType();
+  return isDivergent() ? *getTrailingObjects()
+   : Decl->getUnderlyingType();
 }
 
 UsingType::UsingType(const UsingShadowDecl *Found, QualType Underlying,
  QualType Canon)
-: Type(Using, Canon, toSemanticDependence(Underlying->getDependence())),
+: Type(Using, Canon, toSemanticDependence(Canon->getDependence())),
   Found(const_cast(Found)) {
-  assert(Underlying == getUnderlyingType());
+  UsingBits.isDivergent = !Underlying.isNull();
+  if (isDivergent())
+*reinterpret_cast(this + 1) = Underlying;
 }
 
 QualType UsingType::getUnderlyingType() const {
-  return QualType(cast(Found->getTargetDecl())->getTypeForDecl(), 0);
+  return isDivergent()
+ ? *getTrailingObjects()
+ : QualType(
+   cast(Found->getTargetDecl())->getTypeForDecl(), 0);
 }
 
 QualType MacroQualifiedType::desugar() const { return getUnderlyingType(); }
Index: clang/lib/AST/TextNodeDumper.cpp
===
--- clang/lib/AST/TextNodeDumper.cpp
+++ clang/lib/AST/TextNodeDumper.cpp
@@ -1543,10 +1543,14 @@
 
 void TextNodeDumper::VisitUsingType(const UsingType *T) {
   dumpDeclRef(T->getFoundDecl());
+  if (T->isDivergent())
+OS << " divergent";
 }
 
 void TextNodeDumper::VisitTypedefType(const TypedefType *T) {
   dumpDeclRef(T->getDecl());
+  if (T->isDivergent())
+OS << " divergent";
 }
 
 void TextNodeDumper::VisitUnaryTransformType(const UnaryTransformType *T) {
Index: clang/lib/AST/JSONNodeDumper.cpp
===
--- clang/lib/AST/JSONNodeDumper.cpp
+++ clang/lib/AST/JSONNodeDumper.cpp
@@ -531,6 +531,14 @@
 
 void JSONNodeDumper::VisitTypedefType(const TypedefType *TT) {
   JOS.attribute("decl", createBareDeclRef(TT->getDecl()));
+  if (TT->isDivergent())
+JOS.attribute("type", createQualType(TT->desugar()));
+}
+
+void JSONNodeDumper::VisitUsingType(const UsingType *TT) {
+  JOS.attribute("decl", createBareDeclRef(TT->getFoundDecl()));
+  if (TT->isDivergent())
+JOS.attribute("type", createQualType(TT->desugar()));
 }
 
 void JSONNodeDumper::VisitFunctionType(const FunctionType *T) {
Index: clang/lib/AST/ASTStructuralEquivalence.cpp
===
--- clang/lib/AST/ASTStructuralEquivalence.cpp
+++ clang/lib/AST/ASTStructuralEquivalence.cpp
@@ -957,11 +957,

[PATCH] D111509: [clang] use getCommonSugar in an assortment of places

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 459369.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111509

Files:
  clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/narrowing-conversions-ignoreconversionfromtypes-option.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/AST/ast-dump-fpfeatures.cpp
  clang/test/CodeGen/compound-assign-overflow.c
  clang/test/Sema/complex-int.c
  clang/test/Sema/matrix-type-operators.c
  clang/test/Sema/nullability.c
  clang/test/Sema/sugar-common-types.c
  clang/test/SemaCXX/complex-conversion.cpp
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaCXX/sugar-common-types.cpp
  clang/test/SemaCXX/sugared-auto.cpp
  clang/test/SemaObjC/format-strings-objc.m
  compiler-rt/test/ubsan/TestCases/Integer/add-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/no-recover.cpp
  compiler-rt/test/ubsan/TestCases/Integer/sub-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
  lldb/test/API/commands/expression/rdar42038760/main.c
  lldb/test/API/commands/expression/rdar44436068/main.c

Index: lldb/test/API/commands/expression/rdar44436068/main.c
===
--- lldb/test/API/commands/expression/rdar44436068/main.c
+++ lldb/test/API/commands/expression/rdar44436068/main.c
@@ -3,6 +3,6 @@
 __int128_t n = 1;
 n = n + n;
 return n; //%self.expect("p n", substrs=['(__int128_t) $0 = 2'])
-  //%self.expect("p n + 6", substrs=['(__int128) $1 = 8'])
-  //%self.expect("p n + n", substrs=['(__int128) $2 = 4'])
+  //%self.expect("p n + 6", substrs=['(__int128_t) $1 = 8'])
+  //%self.expect("p n + n", substrs=['(__int128_t) $2 = 4'])
 }
Index: lldb/test/API/commands/expression/rdar42038760/main.c
===
--- lldb/test/API/commands/expression/rdar42038760/main.c
+++ lldb/test/API/commands/expression/rdar42038760/main.c
@@ -10,7 +10,7 @@
   struct S0 l_19;
   l_19.f2 = 419;
   uint32_t l_4037 = 4294967295UL;
-  l_19.f2 = g_463; //%self.expect("expr ((l_4037 % (-(g_463))) | l_19.f2)", substrs=['(unsigned int) $0 = 358717883'])
+  l_19.f2 = g_463; //%self.expect("expr ((l_4037 % (-(g_463))) | l_19.f2)", substrs=['(uint32_t) $0 = 358717883'])
 }
 int main()
 {
Index: compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
@@ -12,12 +12,12 @@
 
 #ifdef SUB_I32
   (void)(uint32_t(1) - uint32_t(2));
-  // CHECK-SUB_I32: usub-overflow.cpp:[[@LINE-1]]:22: runtime error: unsigned integer overflow: 1 - 2 cannot be represented in type 'unsigned int'
+  // CHECK-SUB_I32: usub-overflow.cpp:[[@LINE-1]]:22: runtime error: unsigned integer overflow: 1 - 2 cannot be represented in type '{{uint32_t|unsigned int}}'
 #endif
 
 #ifdef SUB_I64
   (void)(uint64_t(800ll) - uint64_t(900ll));
-  // CHECK-SUB_I64: 800 - 900 cannot be represented in type 'unsigned {{long( long)?}}'
+  // CHECK-SUB_I64: 800 - 900 cannot be represented in type '{{uint64_t|unsigned long( long)?}}'
 #endif
 
 #ifdef SUB_I128
@@ -26,6 +26,6 @@
 # else
   puts("__int128 not supported\n");
 # endif
-  // CHECK-SUB_I128: {{0x4000 - 0x8000 cannot be represented in type 'unsigned __int128'|__int128 not supported}}
+  // CHECK-SUB_I128: {{0x4000 - 0x8000 cannot be represented in type '__uint128_t'|__int128 not supported}}
 #endif
 }
Index: compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
@@ -13,7 +13,7 @@
   (void)(uint16_t(0x) * uint16_t(0x8001));
 
   (void)(uint32_t(0x) * uint32_t(0x2));
-  // CHECK: umul-overflow.cpp:15:31: runtime error: unsigned integer overflow: 4294967295 * 2 cannot be represented in type 'unsigned int'
+  // CHECK: umul-overflow.cpp:15:31: runtime error: unsigned integer overflow: 4294967295 * 2 cannot be represented in type '{{uint32_t|unsigned int}}'
 
   return 0;
 }
Index: compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/In

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

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 459370.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130308

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/SemaCXX/sugar-common-types.cpp

Index: clang/test/SemaCXX/sugar-common-types.cpp
===
--- clang/test/SemaCXX/sugar-common-types.cpp
+++ clang/test/SemaCXX/sugar-common-types.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++20 -fenable-matrix
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++20 -fenable-matrix -triple i686-pc-win32
 
 enum class N {};
 
@@ -38,3 +38,77 @@
 N t7 = X4() + Y4(); // expected-error {{rvalue of type 'B4'}}
 N t8 = X4() * Y4(); // expected-error {{rvalue of type 'B4'}}
 N t9 = X5() * Y5(); // expected-error {{rvalue of type 'A4 __attribute__((matrix_type(3, 3)))'}}
+
+template  struct S1 {
+  template  struct S2 {};
+};
+
+N t10 = 0 ? S1() : S1(); // expected-error {{from 'S1' (aka 'S1')}}
+N t11 = 0 ? S1::S2() : S1::S2(); // expected-error {{from 'S1::S2' (aka 'S2')}}
+
+template  using Al = S1;
+
+N t12 = 0 ? Al() : Al(); // expected-error {{from 'Al' (aka 'S1')}}
+
+#define AS1 __attribute__((address_space(1)))
+#define AS2 __attribute__((address_space(1)))
+using AS1X1 = AS1 B1;
+using AS1Y1 = AS1 B1;
+using AS2Y1 = AS2 B1;
+N t13 = 0 ? (AS1X1){} : (AS1Y1){}; // expected-error {{rvalue of type 'AS1 B1' (aka '__attribute__((address_space(1))) int')}}
+N t14 = 0 ? (AS1X1){} : (AS2Y1){}; // expected-error {{rvalue of type '__attribute__((address_space(1))) B1' (aka '__attribute__((address_space(1))) int')}}
+
+using FX1 = X1 ();
+using FY1 = Y1 ();
+N t15 = 0 ? (FX1*){} : (FY1*){}; // expected-error {{rvalue of type 'B1 (*)()' (aka 'int (*)()')}}
+
+struct SS1 {};
+using SB1 = SS1;
+using SX1 = SB1;
+using SY1 = SB1;
+
+using MFX1 = X1 SX1::*();
+using MFY1 = Y1 SY1::*();
+
+N t16 = 0 ? (MFX1*){} : (MFY1*){}; // expected-error {{rvalue of type 'B1 SB1::*(*)()'}}
+
+N t17 = 0 ? (FX1 SX1::*){} : (FY1 SY1::*){}; // expected-error {{rvalue of type 'B1 (SB1::*)() __attribute__((thiscall))'}}
+
+N t18 = 0 ? (__typeof(X1*)){} : (__typeof(Y1*)){}; // expected-error {{rvalue of type 'typeof(B1 *)' (aka 'int *')}}
+
+struct Enums {
+  enum X : B1;
+  enum Y : ::B1;
+};
+using EnumsB = Enums;
+using EnumsX = EnumsB;
+using EnumsY = EnumsB;
+
+N t19 = 0 ? (__underlying_type(EnumsX::X)){} : (__underlying_type(EnumsY::Y)){};
+// expected-error@-1 {{rvalue of type 'B1' (aka 'int')}}
+
+N t20 = 0 ? (__underlying_type(EnumsX::X)){} : (__underlying_type(EnumsY::X)){};
+// expected-error@-1 {{rvalue of type '__underlying_type(Enums::X)' (aka 'int')}}
+
+using SBTF1 = SS1 [[clang::btf_type_tag("1")]];
+using SBTF2 = ::SS1 [[clang::btf_type_tag("1")]];
+using SBTF3 = ::SS1 [[clang::btf_type_tag("2")]];
+
+N t21 = 0 ? (SBTF1){} : (SBTF3){}; // expected-error {{from 'SS1'}}
+N t22 = 0 ? (SBTF1){} : (SBTF2){}; // expected-error {{from 'SS1 btf_type_tag(1)' (aka 'SS1')}}
+
+using QX = const SB1 *;
+using QY = const ::SB1 *;
+N t23 = 0 ? (QX){} : (QY){}; // expected-error {{rvalue of type 'const SB1 *' (aka 'const SS1 *')}}
+
+template  using Alias = short;
+N t24 = 0 ? (Alias){} : (Alias){}; // expected-error {{rvalue of type 'Alias' (aka 'short')}}
+N t25 = 0 ? (Alias){} : (Alias){}; // expected-error {{rvalue of type 'short'}}
+
+template  concept C1 = true;
+template  concept C2 = true;
+C1 auto t26_1 = (SB1){};
+C1 auto t26_2 = (::SB1){};
+C2 auto t26_3 = (::SB1){};
+N t26 = 0 ? t26_1 : t26_2; // expected-error {{from 'SB1' (aka 'SS1')}}
+N t27 = 0 ? t26_1 : t26_3; // expected-error {{from 'SB1' (aka 'SS1')}}
Index: clang/lib/Sema/SemaTemplateDeduction.cpp
===
--- clang/lib/Sema/SemaTemplateDeduction.cpp
+++ clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -3825,13 +3825,11 @@
 //   - If A is an array type, the pointer type produced by the
 // array-to-pointer standard conversion (4.2) is used in place of
 // A for type deduction; otherwise,
-if (ArgType->isArrayType())
-  ArgType = S.Context.getArrayDecayedType(ArgType);
 //   - If A is a function type, the pointer type produced by the
 // function-to-pointer standard conversion (4.3) is used in place
 // of A for type deduction; otherwise,
-else if (ArgType->isFunctionType())
-  ArgType = S.Context.getPointerType(ArgType);
+if (ArgType->canDecayToPointerType())
+  ArgType = S.Context.getDecayedType(ArgType);
 else {
   // - If A is a cv-qualified type, the top level cv-qualifiers of A's
   //   type are ignored for type deduction.
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -3332,6 +333

[PATCH] D133066: fix a typo in comment of AddConversionCandidate

[zhouyizhou via Phabricator via cfe-commits]

zhouyizhou added a comment.

my current progress - succesfully build  commit cba72b1f620fd on debian6:

1. git checkout cba72b1f620fd
2. download debian-6.0.10-amd64-DVD-1.iso and use it to create a debian6 
virtual machine
3. debian6/llvm-project>cp -fr clang llvm/tools
4. modifiy llvm/tools/CMakefileLists.txt:

diff --git a/llvm/tools/CMakeLists.txt b/llvm/tools/CMakeLists.txt
index 2f37911..71cdbcc 100644

- a/llvm/tools/CMakeLists.txt

+++ b/llvm/tools/CMakeLists.txt
@@ -46,8 +46,6 @@ add_subdirectory(llvm-stub)
 add_subdirectory(edis)
 add_subdirectory(llvmc)

-if( EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/clang/CMakeLists.txt )

- add_subdirectory( ${CMAKE_CURRENT_SOURCE_DIR}/clang )

-endif( EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/clang/CMakeLists.txt )
+add_subdirectory(clang)

5. debian6/llvm-project>mkdir build
6. debian6/llvm-project>cd build
7. cmake ../llvm -DLLVM_TARGETS_TO_BUILD="X86"  -DCMAKE_BUILD_TYPE="Debug" 
-DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++
8. make clang -j 8

I am now begin to debugging newly build clang-2.9

Thanks again for your guidance and encouragement ;-)
cheers
Zhouyi


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133066

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

[PATCH] D133634: [clang] Allow vector of BitInt

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

xbolva00 added a comment.

Missing IR tests. No issues in codegen?

Very poor description. Why it was disabled? Why we can enable it now?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133634

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

[PATCH] D133668: [HLSL] Use _BitInt(16) for int16_t to avoid promote to int.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Drive-by comment before I get into the review: does HLSL intend to follow the 
standard in terms of behavior of intN_t? If yes, then this doesn't follow the 
behavior allowed by the standard or the direction WG14 chose. We discussed 
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2960.pdf at our Jul 2022 
meeting, and this particular topic was part of that paper. The result of the 
preference poll was:

  Opinion poll: Which stdint.h types should be allowed to be bit-precise 
integer types?
  0) Leave it as is - [u]intN_t may not be bit-precise, but [u]intptr_t and 
[u]intmax_t are unclear.
   (no one asked for this direction)
  1) None of [u]intN_t, [u]intptr_t and [u]intmax_t.
   9 / 5 / 4 (this direction)
  2) None of [u]intN_t, [u]intptr_t and [u]intmax_t, unless they are wider than 
int.
   7 / 7 / 5 (not this direction)

So we decided explicitly to not allow intN_t to be defined in terms of a 
bit-precise integer type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133668

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

Re: [clang] b7a7aee - [clang] Qualify auto in range-based for loops (NFC)

[Aaron Ballman via cfe-commits]

On Sat, Sep 10, 2022 at 6:01 PM Kazu Hirata  wrote:
>
> Thank you Aaron and David for your inputs.
>
> First and foremost, I apologize if I made your job harder by increasing the 
> number of commits you have to peel to get to the real author.

No worries at all! It's all a tradeoff. :-)

> I hear that we are moving toward github pull requests.  A casual search tells 
> me that there are some add-ons to integrate clang-tidy into the code review 
> platform, so I am hoping we can use something like that to get each patch 
> right first time.

That would be lovely (though we could do the same with our current
precommit CI pipeline; there's no need for us to wait for a switch to
GitHub).

> Going forward, I'll take git churn and the difficulty of backsliding as big 
> factors in doing future clenaups.  For example, it's probably a good idea to 
> delete a function that hasn't been used for many years (excluding dump 
> functions and such).  Library standardization (like the recent removal of 
> llvm::array_lengthof in favor of std::size) is less good in terms of git 
> churn, but it's very unlikely for somebody to re-introduce 
> llvm::array_lengthof.

Thanks! If we're going to err on one side or the other, I think it's
better to err on the side that leaves us with the best code base
because that's what everyone interacts with the most. But I also like
David's idea of starting a community discussion to see where folks
want to draw the line these days. Perhaps the only kind of sweeping
changes we want to avoid are whitespace/line ending/formatting changes
and we're fine with other kinds of sweeping improvements.

~Aaron

>
> Thanks,
>
> Kazu Hirata
>
>
> On Fri, Sep 9, 2022 at 5:27 AM Aaron Ballman  wrote:
>>
>> On Thu, Sep 8, 2022 at 12:37 PM David Blaikie  wrote:
>> >
>> > Mixed feelings here - Kazu's made a lot of cleanup/stylistic changes
>> > across the LLVM project for a while now, most, at least I think, are
>> > quite welcome (things like switching to range-based-for, std
>> > algorithms over llvm ones, llvm algorithms over manually written
>> > loops, etc). But yeah, there's some threshold below which the churn
>> > might not be worth the benefit - especially if the change doesn't come
>> > along with tooling to enforce the invariant is maintained in the
>> > future (if it's easy to make mistakes like this one - we'll regress it
>> > and need to do cleanup again in the future)
>>
>> Thanks for speaking up, because I also waffled a bit on whether I
>> called this out or not. :-)
>>
>> > Also, for this particular one, I wonder if in some cases this sort of
>> > automatic transformation isn't ideal - if something is a pointer, but
>> > that's an implementation detail, rather than an intentional feature of
>> > an API (eg: the pointer-ness might be hidden behind a typedef and used
>> > as an opaque handle, without any dereferencing, etc)
>>
>> Agreed.
>>
>> > I think it'd be really good to have some discussion on discourse about
>> > if/how some of these cleanups could be formed into a way to
>> > enforce/encourage the invariant to be maintained going forward -
>> > clang-tidy (assuming that's the basis for the tooling Kazu's using to
>> > make these changes in the first place) integration into the LLVM build
>> > in some way, etc.
>>
>> I think that's a good idea! We want to encourage cleanups, but we
>> don't want to encourage churn, and I think it's somewhat subjective
>> where to draw that line. Having some more community awareness around
>> that would be beneficial. I'm especially interested in how we balance
>> between making incremental style improvements to the project and
>> keeping our git blame logs useful. I'm seeing a lot more git blames
>> that require several steps to get to an interesting commit because of
>> the number of NFCs and reverts/recommits. Unfortunately, the tooling
>> around viewing git blames of large files (like Clang tends to have)
>> makes these sorts of commits surprisingly painful when you do have to
>> dig to see where changes came from. (So I find myself having far less
>> concern when TransGCAttrs.cpp (~350LoC) gets a cleanup like this
>> compared to SemaExpr.cpp (~21kLoC), which suggests to me we should
>> maybe strongly consider splitting more of these massive files up so
>> that churn is less painful.)
>>
>> > & yeah, adding the `const` too if/when that's relevant would've
>> > improved the quality/value/justification for a cleanup change like
>> > this.
>>
>> It also would have matched our coding style. (We document it somewhat
>> poorly as an example showing "observe" and "change", but reviewers who
>> call for cleanups with auto are pretty consistent about asking to make
>> qualifiers explicit.)
>>
>> ~Aaron
>>
>> >
>> > On Sun, Sep 4, 2022 at 5:58 AM Aaron Ballman via cfe-commits
>> >  wrote:
>> > >
>> > > FWIW, sweeping NFC changes like this cause a fair amount of code churn
>> > > (which makes tools like git blame a bit harder to use) for a
>> > > relatively s

[PATCH] D133659: [Clang] P1169R4: static operator()

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added a comment.

Thanks a lot for working on that!

I think this is the right direction but i would like to see more tests.
Notably:

- converting a lambda with a static operator to a pointer
- tests in dependant contexts
- classes having both static and non-static `operator()` . especially the 
example in 
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1169r4.html#overload-resolution
 deserves a test.
- unevaluated lambda tests / constexpr tests

There is the question of whether we'd want the call operator to be implicitly 
static but I'm don't think it's currently allowed, it may have abi impact and 
it doesn't to be dealt with in this PR so that should not hold us.
The other question is whether we want to make static operator() an extension in 
older language modes. I don;t see a reason to prohibit that (with a warning)




Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1041
+def err_static_lambda_captures : Error<
+  "a static lambda cannot capture">;
+





Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:9075
+def ext_operator_overload_static : ExtWarn<
+  "making overloaded %0 static is a C++2b extension">, 
InGroup, DefaultIgnore;
+def err_call_operator_overload_static : Error<

For consistency and clarity, I'd say 'static overloaded %0'



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:9077
+def err_call_operator_overload_static : Error<
+  "overloaded %0 cannot be a static member function before C++2b">;
 def err_operator_overload_static : Error<





Comment at: clang/lib/Parse/ParseExprCXX.cpp:1265
+  if (Intro.hasLambdaCapture())
+P.Diag(StaticLoc, diag::err_static_lambda_captures);
+}

We might want to add a note showing where the capture list is.



Comment at: clang/lib/Sema/SemaChecking.cpp:5840
+  if (IsMemberOperatorCall && !FDecl->isStatic()) {
+// If this is a call to an instance member operator, hide the first 
argument
 // from checkCall.





Comment at: clang/lib/Sema/SemaLambda.cpp:954-955
 //   by mutable. It is neither virtual nor declared volatile. [...]
-if (!FTI.hasMutableQualifier()) {
+if (!FTI.hasMutableQualifier() &&
+ParamInfo.getDeclSpec().getStorageClassSpec() != DeclSpec::SCS_static) 
{
   FTI.getOrCreateMethodQualifiers().SetTypeQual(DeclSpec::TQ_const,

Do we actually need that check ? It should be diagnosed already.



Comment at: clang/lib/Sema/SemaLambda.cpp:983-985
+  ParamInfo.getDeclSpec().getStorageClassSpec() == DeclSpec::SCS_static
+  ? SC_Static
+  : SC_None,

Do we want an assert to make sure it's not something else than static or none?



Comment at: clang/test/CXX/over/over.oper/over.literal/p7.cpp:23-25
+struct Functor {
+  static int operator()(int a, int b);  // cxx11-error {{cannot be a static 
member function}}
+};

This doesn't really seem to be the right file for this test - I'd expect that 
to be in a test file where we do sema check on operators, not literal operators.
Do you need help looking for a better place?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133659

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

[clang-tools-extra] 4891ef2 - Revert "[test][clangd] Try to unbrake bots after 72142fbac4"

[Vitaly Buka via cfe-commits]

Author: Vitaly Buka
Date: 2022-09-11T10:07:26-07:00
New Revision: 4891ef23a0acfa0bad244ee89b8d9511a4187a84

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

LOG: Revert "[test][clangd] Try to unbrake bots after 72142fbac4"

It does not help.

This reverts commit 355dbd3b2aa28d479170c4e43265de186317dd86.

Added: 


Modified: 
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp 
b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
index 66260ab64fbe6..4e95fcfea91c1 100644
--- a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -169,7 +169,6 @@ class TUSchedulerTests : public ::testing::Test {
 
   MockFS FS;
   MockCompilationDatabase CDB;
-  Deadline BlockTimeout = timeoutSeconds(60);
 };
 
 Key)>>
@@ -242,7 +241,7 @@ TEST_F(TUSchedulerTests, WantDiagnostics) {
 [&](std::vector) { ++CallbackCount; });
 Ready.notify();
 
-ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
+ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
   }
   EXPECT_EQ(2, CallbackCount);
 }
@@ -265,7 +264,7 @@ TEST_F(TUSchedulerTests, Debounce) {
   Notification N;
   updateWithDiags(S, Path, "auto (timed out)", WantDiagnostics::Auto,
   [&](std::vector) { N.notify(); });
-  EXPECT_TRUE(N.wait(BlockTimeout));
+  EXPECT_TRUE(N.wait(timeoutSeconds(5)));
 
   // Once we start shutting down the TUScheduler, this one becomes a dead 
write.
   updateWithDiags(S, Path, "auto (discarded)", WantDiagnostics::Auto,
@@ -331,7 +330,7 @@ TEST_F(TUSchedulerTests, Cancellation) {
 Read("R3")();
 Proceed.notify();
 
-ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
+ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
   }
   EXPECT_THAT(DiagsSeen, ElementsAre("U2", "U3"))
   << "U1 and all dependent reads were cancelled. "
@@ -352,7 +351,7 @@ TEST_F(TUSchedulerTests, InvalidationNoCrash) {
   // We expect invalidation logic to not crash by trying to invalidate a 
running
   // request.
   S.update(Path, getInputs(Path, ""), WantDiagnostics::Auto);
-  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
+  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
   S.runWithAST(
   "invalidatable-but-running", Path,
   [&](llvm::Expected AST) {
@@ -364,7 +363,7 @@ TEST_F(TUSchedulerTests, InvalidationNoCrash) {
   StartedRunning.wait();
   S.update(Path, getInputs(Path, ""), WantDiagnostics::Auto);
   ScheduledChange.notify();
-  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
+  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
 }
 
 TEST_F(TUSchedulerTests, Invalidation) {
@@ -420,7 +419,7 @@ TEST_F(TUSchedulerTests, Invalidation) {
   },
   TUScheduler::InvalidateOnUpdate);
   Start.notify();
-  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
+  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
 
   EXPECT_EQ(2, Builds.load()) << "Middle build should be skipped";
   EXPECT_EQ(4, Actions.load()) << "All actions should run (some with error)";
@@ -453,7 +452,7 @@ TEST_F(TUSchedulerTests, InvalidationUnchanged) {
 ADD_FAILURE() << "Shouldn't build, identical to previous";
   });
   Start.notify();
-  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
+  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
 
   EXPECT_EQ(1, Actions.load()) << "All actions should run";
 }
@@ -560,7 +559,7 @@ TEST_F(TUSchedulerTests, ManyUpdates) {
 }
   }
 }
-ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
+ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
   } // TUScheduler destructor waits for all operations to finish.
 
   std::lock_guard Lock(Mut);
@@ -602,7 +601,7 @@ TEST_F(TUSchedulerTests, EvictedAST) {
   // one that the cache will evict.
   updateWithCallback(S, Foo, SourceContents, WantDiagnostics::Yes,
  [&BuiltASTCounter]() { ++BuiltASTCounter; });
-  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
+  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
   ASSERT_EQ(BuiltASTCounter.load(), 1);
   EXPECT_THAT(Tracer.takeMetric("ast_access_diag", "hit"), SizeIs(0));
   EXPECT_THAT(Tracer.takeMetric("ast_access_diag", "miss"), SizeIs(1));
@@ -613,7 +612,7 @@ TEST_F(TUSchedulerTests, EvictedAST) {
  [&BuiltASTCounter]() { ++BuiltASTCounter; });
   updateWithCallback(S, Baz, SourceContents, WantDiagnostics::Yes,
  [&BuiltASTCounter]() { ++BuiltASTCounter; });
-  ASSERT_TRUE(S.blockUntilIdle(BlockTimeout));
+  ASSERT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
   ASSERT_EQ(BuiltASTCounter.load(), 3);
   EXPECT_THAT(Tracer.takeMetric("ast_access_diag", "hit"), SizeIs(0));
   EXPECT_THAT(Tracer.takeMetric("ast_access_diag", "miss"), SizeIs(2));
@@ -624,

[clang-tools-extra] c3c930d - [test][clangd] Fix use-after-return after 72142fbac4

[Vitaly Buka via cfe-commits]

Author: Vitaly Buka
Date: 2022-09-11T10:15:13-07:00
New Revision: c3c930d573656a825523b7112891bd97eec7b64f

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

LOG: [test][clangd] Fix use-after-return after 72142fbac4

Added: 


Modified: 
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp 
b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
index 4e95fcfea91c1..b2ab97e4f2494 100644
--- a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -1227,14 +1227,14 @@ TEST_F(TUSchedulerTests, IncluderCache) {
   auto GetFlags = [&](PathRef Header) {
 S.update(Header, getInputs(Header, ";"), WantDiagnostics::Yes);
 EXPECT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
-tooling::CompileCommand Cmd;
+auto Cmd = std::make_shared();
 S.runWithPreamble("GetFlags", Header, TUScheduler::StaleOrAbsent,
-  [&](llvm::Expected Inputs) {
+  [Cmd](llvm::Expected Inputs) {
 ASSERT_FALSE(!Inputs) << Inputs.takeError();
-Cmd = std::move(Inputs->Command);
+*Cmd = std::move(Inputs->Command);
   });
 EXPECT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
-return Cmd.CommandLine;
+return Cmd->CommandLine;
   };
 
   for (const auto &Path : {NoCmd, Unreliable, OK, NotIncluded})



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

[PATCH] D133674: [Lex/DependencyDirectivesScanner] Handle the case where the source line starts with a `tok::hashhash`

[Argyrios Kyrtzidis via Phabricator via cfe-commits]

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133674

Files:
  clang/lib/Lex/DependencyDirectivesScanner.cpp
  clang/unittests/Lex/DependencyDirectivesScannerTest.cpp


Index: clang/unittests/Lex/DependencyDirectivesScannerTest.cpp
===
--- clang/unittests/Lex/DependencyDirectivesScannerTest.cpp
+++ clang/unittests/Lex/DependencyDirectivesScannerTest.cpp
@@ -124,6 +124,21 @@
   EXPECT_STREQ("#define MACRO a\n", Out.data());
 }
 
+TEST(MinimizeSourceToDependencyDirectivesTest, HashHash) {
+  SmallVector Out;
+
+  StringRef Source = R"(
+#define S
+#if 0
+  ##pragma cool
+  ##include "t.h"
+#endif
+#define E
+)";
+  ASSERT_FALSE(minimizeSourceToDependencyDirectives(Source, Out));
+  EXPECT_STREQ("#define S\n#if 0\n#endif\n#define E\n", Out.data());
+}
+
 TEST(MinimizeSourceToDependencyDirectivesTest, Define) {
   SmallVector Out;
   SmallVector Tokens;
Index: clang/lib/Lex/DependencyDirectivesScanner.cpp
===
--- clang/lib/Lex/DependencyDirectivesScanner.cpp
+++ clang/lib/Lex/DependencyDirectivesScanner.cpp
@@ -742,6 +742,11 @@
 
   // Lex '#'.
   const dependency_directives_scan::Token &HashTok = lexToken(First, End);
+  if (HashTok.is(tok::hashhash)) {
+skipLine(First, End);
+assert(First <= End);
+return false;
+  }
   assert(HashTok.is(tok::hash));
   (void)HashTok;
 


Index: clang/unittests/Lex/DependencyDirectivesScannerTest.cpp
===
--- clang/unittests/Lex/DependencyDirectivesScannerTest.cpp
+++ clang/unittests/Lex/DependencyDirectivesScannerTest.cpp
@@ -124,6 +124,21 @@
   EXPECT_STREQ("#define MACRO a\n", Out.data());
 }
 
+TEST(MinimizeSourceToDependencyDirectivesTest, HashHash) {
+  SmallVector Out;
+
+  StringRef Source = R"(
+#define S
+#if 0
+  ##pragma cool
+  ##include "t.h"
+#endif
+#define E
+)";
+  ASSERT_FALSE(minimizeSourceToDependencyDirectives(Source, Out));
+  EXPECT_STREQ("#define S\n#if 0\n#endif\n#define E\n", Out.data());
+}
+
 TEST(MinimizeSourceToDependencyDirectivesTest, Define) {
   SmallVector Out;
   SmallVector Tokens;
Index: clang/lib/Lex/DependencyDirectivesScanner.cpp
===
--- clang/lib/Lex/DependencyDirectivesScanner.cpp
+++ clang/lib/Lex/DependencyDirectivesScanner.cpp
@@ -742,6 +742,11 @@
 
   // Lex '#'.
   const dependency_directives_scan::Token &HashTok = lexToken(First, End);
+  if (HashTok.is(tok::hashhash)) {
+skipLine(First, End);
+assert(First <= End);
+return false;
+  }
   assert(HashTok.is(tok::hash));
   (void)HashTok;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] cbb3a39 - Revert "[test][clangd] Fix use-after-return after 72142fbac4"

[Vitaly Buka via cfe-commits]

Author: Vitaly Buka
Date: 2022-09-11T11:46:58-07:00
New Revision: cbb3a39e4dfcac5ea0ff353b6f81b0ea14eec8e2

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

LOG: Revert "[test][clangd] Fix use-after-return after 72142fbac4"

Will try another fix.

This reverts commit c3c930d573656a825523b7112891bd97eec7b64f.

Added: 


Modified: 
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp 
b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
index b2ab97e4f2494..4e95fcfea91c1 100644
--- a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -1227,14 +1227,14 @@ TEST_F(TUSchedulerTests, IncluderCache) {
   auto GetFlags = [&](PathRef Header) {
 S.update(Header, getInputs(Header, ";"), WantDiagnostics::Yes);
 EXPECT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
-auto Cmd = std::make_shared();
+tooling::CompileCommand Cmd;
 S.runWithPreamble("GetFlags", Header, TUScheduler::StaleOrAbsent,
-  [Cmd](llvm::Expected Inputs) {
+  [&](llvm::Expected Inputs) {
 ASSERT_FALSE(!Inputs) << Inputs.takeError();
-*Cmd = std::move(Inputs->Command);
+Cmd = std::move(Inputs->Command);
   });
 EXPECT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
-return Cmd->CommandLine;
+return Cmd.CommandLine;
   };
 
   for (const auto &Path : {NoCmd, Unreliable, OK, NotIncluded})



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

[clang-tools-extra] dde62a5 - [test][clangd] Fix use-after-return after 72142fbac4

[Vitaly Buka via cfe-commits]

Author: Vitaly Buka
Date: 2022-09-11T11:46:58-07:00
New Revision: dde62a575a3394c7c6734a5a1057bb8f91c729bb

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

LOG: [test][clangd] Fix use-after-return after 72142fbac4

Added: 


Modified: 
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp 
b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
index 4e95fcfea91c1..2719a4fe32ff4 100644
--- a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -1227,12 +1227,15 @@ TEST_F(TUSchedulerTests, IncluderCache) {
   auto GetFlags = [&](PathRef Header) {
 S.update(Header, getInputs(Header, ";"), WantDiagnostics::Yes);
 EXPECT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
+Notification CmdDone;
 tooling::CompileCommand Cmd;
 S.runWithPreamble("GetFlags", Header, TUScheduler::StaleOrAbsent,
   [&](llvm::Expected Inputs) {
 ASSERT_FALSE(!Inputs) << Inputs.takeError();
 Cmd = std::move(Inputs->Command);
+CmdDone.notify();
   });
+CmdDone.wait();
 EXPECT_TRUE(S.blockUntilIdle(timeoutSeconds(10)));
 return Cmd.CommandLine;
   };



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

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added inline comments.



Comment at: libcxx/docs/Contributing.rst:119
+
+Unless specified otherwise the ``main`` version of Clang is used.
+

Mordante wrote:
> aaron.ballman wrote:
> > 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. "Unless specified 
> > > otherwise" - where would I specify a different preference, when I upload 
> > > a patch and it gets run through CI?
> > > 
> > > There's three different concepts involved here:
> > > - The CI build matrix (buildkite-pipeline.yml) which specifies a bunch of 
> > > different versions of tools and standards to run the tests on. Here you 
> > > can't specify a different preference - all of them are run (unless you 
> > > edit the file in your patch).
> > > - The Docker images, where the default `clang` executable is a recent 
> > > nightly build, but older releases are available as `clang-`
> > > - The `run-buildbot` script, which just uses whatever compiler is set as 
> > > default (via e.g. the `CXX` env var).
> > > 
> > > So, what about these three concepts is this paragraph trying to say - the 
> > > second or the third point? This really needs to specify what it talks 
> > > about - build matrix, docker images or run-buildbot script.
> > > 
> > > The same thing goes for the following paragraph.
> > (mostly trying to get rid of the duplicate "Unless specified otherwise".)
> I've reworded it, please have a look whether the new wording is clear.
Right, that makes it clearer to me. Thanks!


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] D133659: [Clang] P1169R4: static operator()

[Roy Jacobson via Phabricator via cfe-commits]

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

Wow, thanks for the quick review!

In D133659#3783008 , @cor3ntin wrote:

> Thanks a lot for working on that!
>
> I think this is the right direction but i would like to see more tests.
> Notably:
>
> - converting a lambda with a static operator to a pointer

Turns out I had a bug in the conversion function generation, thanks for the 
suggestion! Fixed it and added tests.

> - tests in dependant contexts

Added some tests for that, but I'm not sure how to judge if I have good 
coverage of all the possible edge cases, so more suggestions are welcome :)

> - classes having both static and non-static `operator()` . especially the 
> example in 
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1169r4.html#overload-resolution
>  deserves a test.

I _think_ you can't do that - 
https://stackoverflow.com/questions/5365689/c-overload-static-function-with-non-static-function.

The example from the paper is about disambiguating the 
conversion-to-function-pointer call from the operator(), which is kind-of 
already tested because otherwise you wouldn't be able to call a static lambda 
at all. I added it as an explicit test, though.

> - unevaluated lambda tests / constexpr tests

I'm not sure I understand what you mean by unevaluated lambdas, could you 
elaborate? I added some constexpr/eval tests.

> There is the question of whether we'd want the call operator to be implicitly 
> static but I'm don't think it's currently allowed, it may have abi impact and 
> it doesn't to be dealt with in this PR so that should not hold us.
> The other question is whether we want to make static operator() an extension 
> in older language modes. I don;t see a reason to prohibit that (with a 
> warning)

I thought I made it an extension, but apparently it was only for the static 
lambdas, just because that's how most of the other lambda extensions were 
implemented :)
I don't have a strong opinion about this. But I realized that without 
backporting the overload resolution changes, this will not be useful for 
lambdas.
So just to be consistent right now I made it an error for both - we can always 
change that to a warning pretty easily.




Comment at: clang/lib/Sema/SemaLambda.cpp:954-955
 //   by mutable. It is neither virtual nor declared volatile. [...]
-if (!FTI.hasMutableQualifier()) {
+if (!FTI.hasMutableQualifier() &&
+ParamInfo.getDeclSpec().getStorageClassSpec() != DeclSpec::SCS_static) 
{
   FTI.getOrCreateMethodQualifiers().SetTypeQual(DeclSpec::TQ_const,

cor3ntin wrote:
> Do we actually need that check ? It should be diagnosed already.
It's not about diagnosing, it's preventing declaring the operator 'const' if 
it's static.




Comment at: clang/test/CXX/over/over.oper/over.literal/p7.cpp:23-25
+struct Functor {
+  static int operator()(int a, int b);  // cxx11-error {{cannot be a static 
member function}}
+};

cor3ntin wrote:
> This doesn't really seem to be the right file for this test - I'd expect that 
> to be in a test file where we do sema check on operators, not literal 
> operators.
> Do you need help looking for a better place?
Oops, this is the wrong p7 indeed :)

thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133659

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

[PATCH] D133659: [Clang] P1169R4: static operator()

[Roy Jacobson via Phabricator via cfe-commits]

royjacobson updated this revision to Diff 459387.
royjacobson marked an inline comment as done.
royjacobson added a comment.

Fix conversion to function pointer, add more tests and apply Corentin's wording.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133659

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/OperatorKinds.def
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/over/over.match/over.match.best/over.best.ics/p6.cpp
  clang/test/CXX/over/over.oper/p7.cpp
  clang/test/CodeGenCXX/cxx2b-static-call-operator.cpp
  clang/test/Parser/cxx2b-lambdas-ext-warns.cpp
  clang/test/Parser/cxx2b-lambdas.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1481,7 +1481,7 @@
 
   static operator()
   https://wg21.link/P1169R4";>P1169R4
-  No
+  Clang 16
 
 
   Extended floating-point types and standard names
Index: clang/test/Parser/cxx2b-lambdas.cpp
===
--- clang/test/Parser/cxx2b-lambdas.cpp
+++ clang/test/Parser/cxx2b-lambdas.cpp
@@ -38,3 +38,16 @@
 auto XL4 = [] requires true {}; // expected-error{{expected body}}
 auto XL5 = [] requires true requires true {}; // expected-error{{expected body}}
 auto XL6 = [] requires true noexcept requires true {}; // expected-error{{expected body}}
+
+auto XL7 = []() static static {}; // expected-error {{cannot appear multiple times}}
+auto XL8 = []() static mutable {}; // expected-error {{cannot be both mutable and static}}
+
+auto XL9 = [] static {};
+auto XL10 = []() static {};
+
+void static_captures() {
+  int x;
+  auto SC1 = [&]() static {}; // expected-error {{a static lambda cannot have any captures}}
+  auto SC2 = [&x]() static {}; // expected-error {{a static lambda cannot have any captures}}
+  auto SC3 = [=]() static {}; // expected-error {{a static lambda cannot have any captures}}
+}
Index: clang/test/Parser/cxx2b-lambdas-ext-warns.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx2b-lambdas-ext-warns.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -std=c++20 %s -verify=expected,cxx20
+// RUN: %clang_cc1 -std=c++2b %s -verify=expected,cxx2b
+
+//cxx2b-no-diagnostics
+
+auto L1 = [] constexpr {}; // cxx20-warning {{lambda without a parameter clause is a C++2b extension}}
+auto L2 = []() static {}; // cxx20-error {{static lambdas is a C++2b extension}}
+auto L3 = [] static {}; // cxx20-error {{static lambdas is a C++2b extension}} // cxx20-warning {{lambda without a parameter clause is a C++2b extension}}
Index: clang/test/CodeGenCXX/cxx2b-static-call-operator.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/cxx2b-static-call-operator.cpp
@@ -0,0 +1,129 @@
+// RUN: %clang_cc1 -std=c++2b %s -emit-llvm -triple x86_64-linux -o - | FileCheck %s
+// RUN: %clang_cc1 -std=c++2b %s -emit-llvm -triple x86_64-windows-msvc -o - | FileCheck %s
+
+struct Functor {
+  static int operator()(int x, int y) {
+return x + y;
+  }
+};
+
+auto GetALambda() {
+  return [](int x, int y) static {
+return x + y;
+  };
+}
+
+void CallsTheLambda() {
+  GetALambda()(1, 2);
+}
+
+// CHECK:  define {{.*}}CallsTheLambda{{.*}}
+// CHECK-NEXT: entry:
+// CHECK-NEXT:   %call = call noundef i32 {{.*}}(i32 noundef 1, i32 noundef 2)
+// CHECK-NEXT:   ret void
+// CHECK-NEXT: }
+
+void call_static_call_operator() {
+  Functor f;
+  f(101, 102);
+  f.operator()(201, 202);
+  Functor{}(301, 302);
+}
+
+// CHECK:  define {{.*}}call_static_call_operator{{.*}}
+// CHECK-NEXT: entry:
+// CHECK:{{.*}} = call noundef i32 {{.*}}Functor{{.*}}(i32 noundef 101, i32 noundef 102)
+// CHECK-NEXT:   {{.*}} = call noundef i32 {{.*}}Functor{{.*}}(i32 noundef 201, i32 noundef 202)
+// CHECK-NEXT:   {{.*}} = call noundef i32 {{.*}}Functor{{.*}}(i32 noundef 301, i32 noundef 302)
+// CHECK-NEXT:   ret void
+// CHECK-NEXT: }
+
+struct FunctorConsteval {
+  consteval static int operator()(int x, int y) {
+  return x + y;
+  }
+};
+
+struct FunctorConstexpr {
+  constexpr static int operator()(int x, int y) {
+  return x + y;
+  }
+};
+
+constexpr auto my_lambda = []() constexpr {
+  return 3;
+};
+
+void test_consteval_constexpr() {
+  int x = 0;
+  int y = FunctorConstexpr{}(x, 2);
+  constexpr int z1 = FunctorConsteval{}(2, 2);
+  constexpr int z2 = FunctorC

[PATCH] D133668: [HLSL] Use _BitInt(16) for int16_t to avoid promote to int.

[Chris Bieneman via Phabricator via cfe-commits]

beanz added a comment.

HLSL deviates from C here. HLSL doesn't actually have `short` (although I'm 
actually not sure we should disable it in Clang). We do have `int16_t`, but we 
don't promote `int16_t` to `int`. We discussed changing codegen to disable 
promotion for HLSL, but it seemed more straightforward to me to just define 
`int16_t` as `_BitInt(16)`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133668

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

[PATCH] D133634: [clang] Allow vector of BitInt

[Xiang Li via Phabricator via cfe-commits]

python3kgae added a comment.

In D133634#3782999 , @xbolva00 wrote:

> Missing IR tests. No issues in codegen?
>
> Very poor description. Why it was disabled? Why we can enable it now?

I'm not sure why it is disabled.
I guess it is never enabled and just assert in ASTContext::getExtVectorType 
before.
Then 
https://github.com/llvm/llvm-project/commit/c9edf843fcf954132271214445857498fb47bb72
 make it an error instead of assert.

I'm enabling it for HLSL to use _BitInt(16) as 16bit int at 
https://reviews.llvm.org/D133668
This PR only makes sure it does not fail at AST level.
https://reviews.llvm.org/D133668 will fix the fail in Mangling when codeGen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133634

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

[PATCH] D133088: [Clang] Fix wrong diagnostic for scope identifier with internal linkage

[Jun Zhang via Phabricator via cfe-commits]

junaire updated this revision to Diff 459394.
junaire added a comment.

Rebase, adjust commit message and release note.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133088

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Parser/cxx1z-decomposition.cpp
  clang/test/Sema/array-init.c
  clang/test/Sema/err-decl-block-extern-no-init.c
  clang/test/Sema/private-extern.c

Index: clang/test/Sema/private-extern.c
===
--- clang/test/Sema/private-extern.c
+++ clang/test/Sema/private-extern.c
@@ -69,9 +69,9 @@
 struct s0 { int x; };
 
 void f9(void) {
-  extern int g15 = 0; // expected-error{{'extern' variable cannot have an initializer}}
+  extern int g15 = 0; // expected-error{{declaration of block scope identifier with linkage cannot have an initializer}}
   // FIXME: linkage specifier in warning.
-  __private_extern__ int g16 = 0; // expected-error{{'extern' variable cannot have an initializer}}
+  __private_extern__ int g16 = 0; // expected-error{{declaration of block scope identifier with linkage cannot have an initializer}}
 }
 
 extern int g17;
Index: clang/test/Sema/err-decl-block-extern-no-init.c
===
--- /dev/null
+++ clang/test/Sema/err-decl-block-extern-no-init.c
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify %s
+static int x;
+
+void foo(void)
+{
+extern int x = 1; // expected-error {{declaration of block scope identifier with linkage cannot have an initializer}}
+}
+
+int y;
+
+void bar(void)
+{
+extern int y = 1; // expected-error {{declaration of block scope identifier with linkage cannot have an initializer}}
+
+}
Index: clang/test/Sema/array-init.c
===
--- clang/test/Sema/array-init.c
+++ clang/test/Sema/array-init.c
@@ -48,7 +48,7 @@
 
   struct threeElements *p = 7; // expected-error{{incompatible integer to pointer conversion initializing 'struct threeElements *' with an expression of type 'int'}}
 
-  extern int blockScopeExtern[3] = { 1, 3, 5 }; // expected-error{{'extern' variable cannot have an initializer}}
+  extern int blockScopeExtern[3] = { 1, 3, 5 }; // expected-error{{declaration of block scope identifier with linkage cannot have an initializer}}
 
   static long x2[3] = { 1.0,
 "abc", // expected-error{{incompatible pointer to integer conversion initializing 'long' with an expression of type 'char[4]'}}
Index: clang/test/Parser/cxx1z-decomposition.cpp
===
--- clang/test/Parser/cxx1z-decomposition.cpp
+++ clang/test/Parser/cxx1z-decomposition.cpp
@@ -69,7 +69,7 @@
 // storage-class-specifiers
 static auto &[a] = n; // expected-warning {{declared 'static' is a C++20 extension}}
 thread_local auto &[b] = n; // expected-warning {{declared 'thread_local' is a C++20 extension}}
-extern auto &[c] = n; // expected-error {{cannot be declared 'extern'}} expected-error {{cannot have an initializer}}
+extern auto &[c] = n; // expected-error {{cannot be declared 'extern'}} expected-error {{declaration of block scope identifier with linkage cannot have an initializer}}
 struct S {
   mutable auto &[d] = n; // expected-error {{not permitted in this context}}
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -12773,8 +12773,11 @@
 return;
   }
 
+  // C99 6.7.8p5. If the declaration of an identifier has block scope, and
+  // the identifier has external or internal linkage, the declaration shall
+  // have no initializer for the identifier.
+  // C++14 [dcl.init]p5 is the same restriction for C++.
   if (VDecl->isLocalVarDecl() && VDecl->hasExternalStorage()) {
-// C99 6.7.8p5. C++ has no such restriction, but that is a defect.
 Diag(VDecl->getLocation(), diag::err_block_extern_cant_init);
 VDecl->setInvalidDecl();
 return;
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -5901,7 +5901,7 @@
 : Error<"variable %0 cannot be declared both 'extern' and with the "
 "'loader_uninitialized' attribute">;
 def err_block_extern_cant_init : Error<
-  "'extern' variable cannot have an initializer">;
+  "declaration of block scope identifier with linkage cannot have an initializer">;
 def warn_extern_init : Warning<"'extern' variable has an initializer">,
   InGroup>;
 def err_variable_object_no_init : Error<
Index: clang/docs/ReleaseNotes.rst
=

[PATCH] D130867: [clang] adds builtin `std::invoke` and `std::invoke_r`

[Christopher Di Bella via Phabricator via cfe-commits]

cjdb added a comment.

In D130867#3781492 , @ldionne wrote:

> In D130867#3781429 , @cjdb wrote:
>
>> I had not realised that libc++ was listed as a reviewer.
>
> The change does have an impact on libc++, so I think it makes sense to look 
> at it not only from the compiler perspective, but from the whole clang/libc++ 
> ecosystem's perspective.
>
>> I am going to abandon this revision, since I only wish to interact with that 
>> community when it is both business-critical and unavoidable.
>
> While you're not saying so explicitly, you seem to be implying some sort of 
> fault on libc++ here, which I don't understand. I am trying to engage in a 
> genuine and productive discussion. I'm asking questions to clarify my 
> understanding of your benchmarks, raising IMO reasonable technical concerns 
> with the patch, and doing so politely unless I missed something. I'm not 
> saying we should not move forward with the patch -- there must be a reason 
> why you put in all this effort into it. I'm merely raising concerns because 
> no, this isn't a black-and-white situation -- there is a tradeoff with this 
> patch.
>
> I don't know whether your comment targets me personally or the libc++ 
> community as a whole, but either way, honestly this sort of "I won't talk to 
> you" behavior is kind of hurtful. If you feel there's something wrong with 
> the libc++ community or with me, the LLVM Foundation has channels to 
> remediate to that, and I encourage you (or anyone feeling bad about any part 
> of LLVM) to use them.

Please revise the emails I sent to you, titled 'libc++ involvement' on 
2022-01-18 and 'RE: RE: libc++ involvement' on 2022-01-20, for the reasons why 
I do not wish to engage with the libc++ community. Friday's commentary simply 
documents why work on this patch has abruptly stopped.

I do not intend to discuss the matter any further in D130867 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130867

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

[PATCH] D132379: [Support] Class for response file expansion

[Serge Pavlov via Phabricator via cfe-commits]

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

Rebased


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132379

Files:
  clang/lib/Driver/Driver.cpp
  clang/lib/Tooling/ExpandResponseFilesCompilationDatabase.cpp
  clang/tools/driver/driver.cpp
  llvm/include/llvm/Support/CommandLine.h
  llvm/lib/Support/CommandLine.cpp
  llvm/unittests/Support/CommandLineTest.cpp

Index: llvm/unittests/Support/CommandLineTest.cpp
===
--- llvm/unittests/Support/CommandLineTest.cpp
+++ llvm/unittests/Support/CommandLineTest.cpp
@@ -870,9 +870,9 @@
   // Expand response files.
   llvm::BumpPtrAllocator A;
   llvm::StringSaver Saver(A);
-  ASSERT_TRUE(llvm::cl::ExpandResponseFiles(
-  Saver, llvm::cl::TokenizeGNUCommandLine, Argv, false, true, false,
-  /*CurrentDir=*/StringRef(TestRoot), FS));
+  llvm::cl::ExpansionContext ECtx(Saver, llvm::cl::TokenizeGNUCommandLine, &FS);
+  ECtx.setCurrentDir(TestRoot).setRelativeNames(true);
+  ASSERT_TRUE(ECtx.expandResponseFiles(Argv));
   EXPECT_THAT(Argv, testing::Pointwise(
 StringEquality(),
 {"test/test", "-flag_1", "-option_1", "-option_2",
@@ -933,9 +933,9 @@
 #else
   cl::TokenizerCallback Tokenizer = cl::TokenizeGNUCommandLine;
 #endif
-  ASSERT_FALSE(
-  cl::ExpandResponseFiles(Saver, Tokenizer, Argv, false, false, false,
-  /*CurrentDir=*/llvm::StringRef(TestRoot), FS));
+  llvm::cl::ExpansionContext ECtx(Saver, Tokenizer, &FS);
+  ECtx.setCurrentDir(TestRoot);
+  ASSERT_FALSE(ECtx.expandResponseFiles(Argv));
 
   EXPECT_THAT(Argv,
   testing::Pointwise(StringEquality(),
@@ -972,9 +972,9 @@
 
   BumpPtrAllocator A;
   StringSaver Saver(A);
-  ASSERT_FALSE(cl::ExpandResponseFiles(Saver, cl::TokenizeGNUCommandLine, Argv,
-   false, false, false,
-   /*CurrentDir=*/StringRef(TestRoot), FS));
+  llvm::cl::ExpansionContext ECtx(Saver, cl::TokenizeGNUCommandLine, &FS);
+  ECtx.setCurrentDir(TestRoot);
+  ASSERT_FALSE(ECtx.expandResponseFiles(Argv));
 
   // ASSERT instead of EXPECT to prevent potential out-of-bounds access.
   ASSERT_EQ(Argv.size(), 1 + NON_RSP_AT_ARGS + 2);
@@ -1007,9 +1007,9 @@
 
   BumpPtrAllocator A;
   StringSaver Saver(A);
-  ASSERT_TRUE(cl::ExpandResponseFiles(Saver, cl::TokenizeGNUCommandLine, Argv,
-  false, true, false,
-  /*CurrentDir=*/StringRef(TestRoot), FS));
+  llvm::cl::ExpansionContext ECtx(Saver, cl::TokenizeGNUCommandLine, &FS);
+  ECtx.setCurrentDir(TestRoot).setRelativeNames(true);
+  ASSERT_TRUE(ECtx.expandResponseFiles(Argv));
   EXPECT_THAT(Argv,
   testing::Pointwise(StringEquality(), {"test/test", "-flag"}));
 }
@@ -1027,9 +1027,9 @@
   SmallVector Argv = {"clang", "@eols.rsp"};
   BumpPtrAllocator A;
   StringSaver Saver(A);
-  ASSERT_TRUE(cl::ExpandResponseFiles(Saver, cl::TokenizeWindowsCommandLine,
-  Argv, true, true, false,
-  /*CurrentDir=*/StringRef(TestRoot), FS));
+  llvm::cl::ExpansionContext ECtx(Saver, cl::TokenizeWindowsCommandLine, &FS);
+  ECtx.setCurrentDir(TestRoot).setMarkEOLs(true).setRelativeNames(true);
+  ASSERT_TRUE(ECtx.expandResponseFiles(Argv));
   const char *Expected[] = {"clang", "-Xclang", "-Wno-whatever", nullptr,
 "input.cpp"};
   ASSERT_EQ(std::size(Expected), Argv.size());
@@ -1126,8 +1126,8 @@
 
   llvm::BumpPtrAllocator A;
   llvm::StringSaver Saver(A);
-  bool Result = llvm::cl::readConfigFile(ConfigFile.path(), Saver, Argv,
-		 *llvm::vfs::getRealFileSystem());
+  llvm::cl::ExpansionContext ECtx(Saver, cl::tokenizeConfigFile);
+  bool Result = ECtx.readConfigFile(ConfigFile.path(), Argv);
 
   EXPECT_TRUE(Result);
   EXPECT_EQ(Argv.size(), 13U);
Index: llvm/lib/Support/CommandLine.cpp
===
--- llvm/lib/Support/CommandLine.cpp
+++ llvm/lib/Support/CommandLine.cpp
@@ -1153,15 +1153,12 @@
 }
 
 // FName must be an absolute path.
-static llvm::Error ExpandResponseFile(StringRef FName, StringSaver &Saver,
-  TokenizerCallback Tokenizer,
-  SmallVectorImpl &NewArgv,
-  bool MarkEOLs, bool RelativeNames,
-  bool ExpandBasePath,
-  llvm::vfs::FileSystem &FS) {
+llvm::Error
+ExpansionContext::expandResponseFile(StringRef FName,
+ SmallVectorImpl &NewArgv) {
   assert(sys::path::is_absolute(FName));
   llvm::ErrorOr> MemBufOrErr =
-  FS.getBufferForFile(FName);
+  FS->getBufferForF

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

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added a comment.

Hi @mizvekov , I noticed that deduction for partial ordering also inherits this 
new behavior. Do you think partial ordering could opt out of this, or is it 
better for partial ordering to deal with the new sugared types?


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