[PATCH] D143640: [Tooling/Inclusion] Support overload symbols in the stdlib.

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

All this complexity for handling only 4 symbols feels wrong. is this the whole 
set? are there any other symbols that fall under this class? can we 
disambiguate all of them solely based on number of parameters?
Downsides:

- We are relying heavily on number of parameters in certain cases now
- We only have that information available for symbols with variants
- We're creating a discrepancy in Symbol::all() vs Symbol::named() views of the 
world
- In addition to generator and hand curated list, now there's a 3rd place to 
augment symbol mapping

This complexity both in terms of mental load when introducing new symbols, and 
also possible discrepancies that can be encountered when using the public APIs 
makes me question if we're doing the sensible thing that'll generalize for the 
future variant symbols, or just trying to patch up a solution for couple cases 
we know to be not working.
I'd suggest:
1- doing a little bit more design work here and at least getting rid of the 
burden on the public APIs and a way to introduce these symbols through hand 
curated lists (e.g. we should be returning all alternatives in Symbol::named, 
with enough details for the caller to have a chance to disambiguate and have 
maybe new syntax in raw symbol map files to indicate this variant situation).
2- or handling this in include-cleaner only, similar to how we do it in clangd 
and other applications, until we encounter more problematic symbols. as 
handling this in the general case seems hard (especially in the absence of an 
AST), and we haven't seen enough signals for symbols other than `std::move` to 
cause trouble.

i feel like 2nd alternative gets us a long way with minimal effort. WDYT?




Comment at: clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp:131
[&QName](const SymbolHeaderMapping::SymbolName &S) {
  return S.qualifiedName() == QName;
}) &&

i think we'd now trigger this assert if a variant is provided by multiple 
headers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143640

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


[clang-tools-extra] 19659b5 - [clangd] Drop includes from disabled PP regions in preamble patch

2023-02-13 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2023-02-13T09:49:13+01:00
New Revision: 19659b5f0dd1a1dcf745cf058d042ada2d4ff061

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

LOG: [clangd] Drop includes from disabled PP regions in preamble patch

In rest of the clangd functionality we treat these includes as
non-existent. Do so under preamble patching.

Depends on D143197

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

Added: 


Modified: 
clang-tools-extra/clangd/Preamble.cpp
clang-tools-extra/clangd/unittests/PreambleTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Preamble.cpp 
b/clang-tools-extra/clangd/Preamble.cpp
index cdb8db14722d..f99c4142a464 100644
--- a/clang-tools-extra/clangd/Preamble.cpp
+++ b/clang-tools-extra/clangd/Preamble.cpp
@@ -685,13 +685,16 @@ PreamblePatch PreamblePatch::create(llvm::StringRef 
FileName,
   // Include already present in the baseline preamble. Set resolved path 
and
   // put into preamble includes.
   if (It != ExistingIncludes.end()) {
-auto &PatchedInc = PP.PreambleIncludes.emplace_back();
-// Copy everything from existing include, apart from the location, when
-// it's coming from baseline preamble.
-if (It->second)
+if (It->second) {
+  // If this header is included in an active region of the baseline
+  // preamble, preserve it.
+  auto &PatchedInc = PP.PreambleIncludes.emplace_back();
+  // Copy everything from existing include, apart from the location,
+  // when it's coming from baseline preamble.
   PatchedInc = *It->second;
-PatchedInc.HashLine = Inc.HashLine;
-PatchedInc.HashOffset = Inc.HashOffset;
+  PatchedInc.HashLine = Inc.HashLine;
+  PatchedInc.HashOffset = Inc.HashOffset;
+}
 continue;
   }
   // Include is new in the modified preamble. Inject it into the patch and

diff  --git a/clang-tools-extra/clangd/unittests/PreambleTests.cpp 
b/clang-tools-extra/clangd/unittests/PreambleTests.cpp
index ac46bfd06a13..ae353f94ce06 100644
--- a/clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ b/clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -170,6 +170,9 @@ TEST(PreamblePatchTest, PatchesPreambleIncludes) {
   auto TU = TestTU::withCode(R"cpp(
 #include "a.h" // IWYU pragma: keep
 #include "c.h"
+#ifdef FOO
+#include "d.h"
+#endif
   )cpp");
   TU.AdditionalFiles["a.h"] = "#include \"b.h\"";
   TU.AdditionalFiles["b.h"] = "";
@@ -178,10 +181,14 @@ TEST(PreamblePatchTest, PatchesPreambleIncludes) {
   auto BaselinePreamble = buildPreamble(
   TU.Filename, *buildCompilerInvocation(PI, Diags), PI, true, nullptr);
   // We drop c.h from modified and add a new header. Since the latter is 
patched
-  // we should only get a.h in preamble includes.
+  // we should only get a.h in preamble includes. d.h shouldn't be part of the
+  // preamble, as it's coming from a disabled region.
   TU.Code = R"cpp(
 #include "a.h"
 #include "b.h"
+#ifdef FOO
+#include "d.h"
+#endif
   )cpp";
   auto PP = PreamblePatch::createFullPatch(testPath(TU.Filename), 
TU.inputs(FS),
*BaselinePreamble);



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


[clang-tools-extra] fae01d1 - [clangd] Fix bugs in main-file include patching for stale preambles

2023-02-13 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2023-02-13T09:49:13+01:00
New Revision: fae01d175a29270ec01211d3988c7ae57ddabfd3

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

LOG: [clangd] Fix bugs in main-file include patching for stale preambles

- Make sure main file includes are present even when they're not patched
  (because they didn't change or we're explicitly not patching them).
- Populate extra fields for includes, which can be used by include-cleaner.

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

Added: 


Modified: 
clang-tools-extra/clangd/Preamble.cpp
clang-tools-extra/clangd/unittests/PreambleTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Preamble.cpp 
b/clang-tools-extra/clangd/Preamble.cpp
index 15eea9bb036bd..cdb8db14722d2 100644
--- a/clang-tools-extra/clangd/Preamble.cpp
+++ b/clang-tools-extra/clangd/Preamble.cpp
@@ -671,10 +671,10 @@ PreamblePatch PreamblePatch::create(llvm::StringRef 
FileName,
 // We are only interested in newly added includes, record the ones in
 // Baseline for exclusion.
 llvm::DenseMap,
-   /*Resolved=*/llvm::StringRef>
+   const Inclusion *>
 ExistingIncludes;
 for (const auto &Inc : Baseline.Includes.MainFileIncludes)
-  ExistingIncludes[{Inc.Directive, Inc.Written}] = Inc.Resolved;
+  ExistingIncludes[{Inc.Directive, Inc.Written}] = &Inc;
 // There might be includes coming from disabled regions, record these for
 // exclusion too. note that we don't have resolved paths for those.
 for (const auto &Inc : BaselineScan->Includes)
@@ -685,8 +685,13 @@ PreamblePatch PreamblePatch::create(llvm::StringRef 
FileName,
   // Include already present in the baseline preamble. Set resolved path 
and
   // put into preamble includes.
   if (It != ExistingIncludes.end()) {
-Inc.Resolved = It->second.str();
-PP.PreambleIncludes.push_back(Inc);
+auto &PatchedInc = PP.PreambleIncludes.emplace_back();
+// Copy everything from existing include, apart from the location, when
+// it's coming from baseline preamble.
+if (It->second)
+  PatchedInc = *It->second;
+PatchedInc.HashLine = Inc.HashLine;
+PatchedInc.HashOffset = Inc.HashOffset;
 continue;
   }
   // Include is new in the modified preamble. Inject it into the patch and
@@ -696,6 +701,11 @@ PreamblePatch PreamblePatch::create(llvm::StringRef 
FileName,
   Patch << llvm::formatv(
   "#{0} {1}\n", spellingForIncDirective(Inc.Directive), Inc.Written);
 }
+  } else {
+// Make sure we have the full set of includes available even when we're not
+// patching. As these are used by features we provide afterwards like 
hover,
+// go-to-def or include-cleaner when preamble is stale.
+PP.PreambleIncludes = Baseline.Includes.MainFileIncludes;
   }
 
   if (DirectivesChanged) {

diff  --git a/clang-tools-extra/clangd/unittests/PreambleTests.cpp 
b/clang-tools-extra/clangd/unittests/PreambleTests.cpp
index 1e95b62884f69..ac46bfd06a138 100644
--- a/clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ b/clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -15,6 +15,7 @@
 #include "TestFS.h"
 #include "TestTU.h"
 #include "XRefs.h"
+#include "clang/Basic/SourceManager.h"
 #include "clang/Format/Format.h"
 #include "clang/Frontend/FrontendActions.h"
 #include "clang/Frontend/PrecompiledPreamble.h"
@@ -23,6 +24,7 @@
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/VirtualFileSystem.h"
 #include "gmock/gmock.h"
+#include "gtest/gtest-matchers.h"
 #include "gtest/gtest.h"
 #include 
 #include 
@@ -166,7 +168,7 @@ TEST(PreamblePatchTest, PatchesPreambleIncludes) {
   MockFS FS;
   IgnoreDiagnostics Diags;
   auto TU = TestTU::withCode(R"cpp(
-#include "a.h"
+#include "a.h" // IWYU pragma: keep
 #include "c.h"
   )cpp");
   TU.AdditionalFiles["a.h"] = "#include \"b.h\"";
@@ -185,9 +187,14 @@ TEST(PreamblePatchTest, PatchesPreambleIncludes) {
*BaselinePreamble);
   // Only a.h should exists in the preamble, as c.h has been dropped and b.h 
was
   // newly introduced.
-  EXPECT_THAT(PP.preambleIncludes(),
-  ElementsAre(AllOf(Field(&Inclusion::Written, "\"a.h\""),
-Field(&Inclusion::Resolved, 
testPath("a.h");
+  EXPECT_THAT(
+  PP.preambleIncludes(),
+  ElementsAre(AllOf(
+  Field(&Inclusion::Written, "\"a.h\""),
+  Field(&Inclusion::Resolved, testPath("a.h")),
+  Field(&Inclusion::HeaderID, testing::Not(testing::Eq(std::nullopt))),
+  Field(&Inclusion::BehindPragmaKeep, true),
+  Field(&Inclusion::FileKind, SrcMgr::Character

[PATCH] D143197: [clangd] Fix bugs in main-file include patching for stale preambles

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfae01d175a29: [clangd] Fix bugs in main-file include 
patching for stale preambles (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143197

Files:
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/unittests/PreambleTests.cpp

Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -15,6 +15,7 @@
 #include "TestFS.h"
 #include "TestTU.h"
 #include "XRefs.h"
+#include "clang/Basic/SourceManager.h"
 #include "clang/Format/Format.h"
 #include "clang/Frontend/FrontendActions.h"
 #include "clang/Frontend/PrecompiledPreamble.h"
@@ -23,6 +24,7 @@
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/VirtualFileSystem.h"
 #include "gmock/gmock.h"
+#include "gtest/gtest-matchers.h"
 #include "gtest/gtest.h"
 #include 
 #include 
@@ -166,7 +168,7 @@
   MockFS FS;
   IgnoreDiagnostics Diags;
   auto TU = TestTU::withCode(R"cpp(
-#include "a.h"
+#include "a.h" // IWYU pragma: keep
 #include "c.h"
   )cpp");
   TU.AdditionalFiles["a.h"] = "#include \"b.h\"";
@@ -185,9 +187,14 @@
*BaselinePreamble);
   // Only a.h should exists in the preamble, as c.h has been dropped and b.h was
   // newly introduced.
-  EXPECT_THAT(PP.preambleIncludes(),
-  ElementsAre(AllOf(Field(&Inclusion::Written, "\"a.h\""),
-Field(&Inclusion::Resolved, testPath("a.h");
+  EXPECT_THAT(
+  PP.preambleIncludes(),
+  ElementsAre(AllOf(
+  Field(&Inclusion::Written, "\"a.h\""),
+  Field(&Inclusion::Resolved, testPath("a.h")),
+  Field(&Inclusion::HeaderID, testing::Not(testing::Eq(std::nullopt))),
+  Field(&Inclusion::BehindPragmaKeep, true),
+  Field(&Inclusion::FileKind, SrcMgr::CharacteristicKind::C_User;
 }
 
 std::optional createPatchedAST(llvm::StringRef Baseline,
@@ -225,6 +232,26 @@
   .str();
 }
 
+TEST(PreamblePatchTest, IncludesArePreserved) {
+  llvm::StringLiteral Baseline = R"(//error-ok
+#include 
+#include 
+)";
+  llvm::StringLiteral Modified = R"(//error-ok
+#include 
+#include 
+#define FOO)";
+
+  auto Includes = createPatchedAST(Baseline, Modified.str())
+  ->getIncludeStructure()
+  .MainFileIncludes;
+  EXPECT_TRUE(!Includes.empty());
+  EXPECT_EQ(Includes, TestTU::withCode(Baseline)
+  .build()
+  .getIncludeStructure()
+  .MainFileIncludes);
+}
+
 TEST(PreamblePatchTest, Define) {
   // BAR should be defined while parsing the AST.
   struct {
Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -671,10 +671,10 @@
 // We are only interested in newly added includes, record the ones in
 // Baseline for exclusion.
 llvm::DenseMap,
-   /*Resolved=*/llvm::StringRef>
+   const Inclusion *>
 ExistingIncludes;
 for (const auto &Inc : Baseline.Includes.MainFileIncludes)
-  ExistingIncludes[{Inc.Directive, Inc.Written}] = Inc.Resolved;
+  ExistingIncludes[{Inc.Directive, Inc.Written}] = &Inc;
 // There might be includes coming from disabled regions, record these for
 // exclusion too. note that we don't have resolved paths for those.
 for (const auto &Inc : BaselineScan->Includes)
@@ -685,8 +685,13 @@
   // Include already present in the baseline preamble. Set resolved path and
   // put into preamble includes.
   if (It != ExistingIncludes.end()) {
-Inc.Resolved = It->second.str();
-PP.PreambleIncludes.push_back(Inc);
+auto &PatchedInc = PP.PreambleIncludes.emplace_back();
+// Copy everything from existing include, apart from the location, when
+// it's coming from baseline preamble.
+if (It->second)
+  PatchedInc = *It->second;
+PatchedInc.HashLine = Inc.HashLine;
+PatchedInc.HashOffset = Inc.HashOffset;
 continue;
   }
   // Include is new in the modified preamble. Inject it into the patch and
@@ -696,6 +701,11 @@
   Patch << llvm::formatv(
   "#{0} {1}\n", spellingForIncDirective(Inc.Directive), Inc.Written);
 }
+  } else {
+// Make sure we have the full set of includes available even when we're not
+// patching. As these are used by features we provide afterwards like hover,
+// go-to-def or include-cleaner when preamble is stale.
+PP.PreambleIncludes = Baseline.Includes.MainFileIncludes;
   }
 
   if (Direc

[PATCH] D143597: [clangd] Drop includes from disabled PP regions in preamble patch

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG19659b5f0dd1: [clangd] Drop includes from disabled PP 
regions in preamble patch (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143597

Files:
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/unittests/PreambleTests.cpp


Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -170,6 +170,9 @@
   auto TU = TestTU::withCode(R"cpp(
 #include "a.h" // IWYU pragma: keep
 #include "c.h"
+#ifdef FOO
+#include "d.h"
+#endif
   )cpp");
   TU.AdditionalFiles["a.h"] = "#include \"b.h\"";
   TU.AdditionalFiles["b.h"] = "";
@@ -178,10 +181,14 @@
   auto BaselinePreamble = buildPreamble(
   TU.Filename, *buildCompilerInvocation(PI, Diags), PI, true, nullptr);
   // We drop c.h from modified and add a new header. Since the latter is 
patched
-  // we should only get a.h in preamble includes.
+  // we should only get a.h in preamble includes. d.h shouldn't be part of the
+  // preamble, as it's coming from a disabled region.
   TU.Code = R"cpp(
 #include "a.h"
 #include "b.h"
+#ifdef FOO
+#include "d.h"
+#endif
   )cpp";
   auto PP = PreamblePatch::createFullPatch(testPath(TU.Filename), 
TU.inputs(FS),
*BaselinePreamble);
Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -685,13 +685,16 @@
   // Include already present in the baseline preamble. Set resolved path 
and
   // put into preamble includes.
   if (It != ExistingIncludes.end()) {
-auto &PatchedInc = PP.PreambleIncludes.emplace_back();
-// Copy everything from existing include, apart from the location, when
-// it's coming from baseline preamble.
-if (It->second)
+if (It->second) {
+  // If this header is included in an active region of the baseline
+  // preamble, preserve it.
+  auto &PatchedInc = PP.PreambleIncludes.emplace_back();
+  // Copy everything from existing include, apart from the location,
+  // when it's coming from baseline preamble.
   PatchedInc = *It->second;
-PatchedInc.HashLine = Inc.HashLine;
-PatchedInc.HashOffset = Inc.HashOffset;
+  PatchedInc.HashLine = Inc.HashLine;
+  PatchedInc.HashOffset = Inc.HashOffset;
+}
 continue;
   }
   // Include is new in the modified preamble. Inject it into the patch and


Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -170,6 +170,9 @@
   auto TU = TestTU::withCode(R"cpp(
 #include "a.h" // IWYU pragma: keep
 #include "c.h"
+#ifdef FOO
+#include "d.h"
+#endif
   )cpp");
   TU.AdditionalFiles["a.h"] = "#include \"b.h\"";
   TU.AdditionalFiles["b.h"] = "";
@@ -178,10 +181,14 @@
   auto BaselinePreamble = buildPreamble(
   TU.Filename, *buildCompilerInvocation(PI, Diags), PI, true, nullptr);
   // We drop c.h from modified and add a new header. Since the latter is patched
-  // we should only get a.h in preamble includes.
+  // we should only get a.h in preamble includes. d.h shouldn't be part of the
+  // preamble, as it's coming from a disabled region.
   TU.Code = R"cpp(
 #include "a.h"
 #include "b.h"
+#ifdef FOO
+#include "d.h"
+#endif
   )cpp";
   auto PP = PreamblePatch::createFullPatch(testPath(TU.Filename), TU.inputs(FS),
*BaselinePreamble);
Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -685,13 +685,16 @@
   // Include already present in the baseline preamble. Set resolved path and
   // put into preamble includes.
   if (It != ExistingIncludes.end()) {
-auto &PatchedInc = PP.PreambleIncludes.emplace_back();
-// Copy everything from existing include, apart from the location, when
-// it's coming from baseline preamble.
-if (It->second)
+if (It->second) {
+  // If this header is included in an active region of the baseline
+  // preamble, preserve it.
+  auto &PatchedInc = PP.PreambleIncludes.emplace_back();
+  // Copy everything from existing include, apart from the location,
+  // when it'

[clang] 24ecd99 - [NFC] Set C++20 Named Modules for CodeGen in ASTContext in the early place

2023-02-13 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2023-02-13T17:14:58+08:00
New Revision: 24ecd99842352ed1e6d7877e76e93c2f83ebf3f3

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

LOG: [NFC] Set C++20 Named Modules for CodeGen in ASTContext in the early place

Previously we'll set the named modules for ASTContext in ParseAST. But
this is not intuitive and we need comments to tell the intuition. This
patch moves the code the right the place, where the corrresponding
module is first created/loaded. Now it is more intuitive and we can use
the value in the earlier places.

Added: 


Modified: 
clang/include/clang/AST/ASTContext.h
clang/lib/CodeGen/CGDeclCXX.cpp
clang/lib/CodeGen/CodeGenModule.cpp
clang/lib/Frontend/ASTUnit.cpp
clang/lib/Parse/ParseAST.cpp
clang/lib/Sema/SemaModule.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 0238371927e09..006063e21eb3d 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -447,8 +447,9 @@ class ASTContext : public RefCountedBase {
   };
   llvm::DenseMap ModuleInitializers;
 
-  /// For module code-gen cases, this is the top-level module we are building.
-  Module *TopLevelModule = nullptr;
+  /// For module code-gen cases, this is the top-level (C++20) Named module
+  /// we are building.
+  Module *TopLevelCXXNamedModule = nullptr;
 
   static constexpr unsigned ConstantArrayTypesLog2InitSize = 8;
   static constexpr unsigned GeneralTypesLog2InitSize = 9;
@@ -1051,10 +1052,10 @@ class ASTContext : public RefCountedBase {
   ArrayRef getModuleInitializers(Module *M);
 
   /// Set the (C++20) module we are building.
-  void setModuleForCodeGen(Module *M) { TopLevelModule = M; }
+  void setNamedModuleForCodeGen(Module *M) { TopLevelCXXNamedModule = M; }
 
   /// Get module under construction, nullptr if this is not a C++20 module.
-  Module *getModuleForCodeGen() const { return TopLevelModule; }
+  Module *getNamedModuleForCodeGen() const { return TopLevelCXXNamedModule; }
 
   TranslationUnitDecl *getTranslationUnitDecl() const {
 return TUDecl->getMostRecentDecl();

diff  --git a/clang/lib/CodeGen/CGDeclCXX.cpp b/clang/lib/CodeGen/CGDeclCXX.cpp
index dcd811ea257b3..416859668af98 100644
--- a/clang/lib/CodeGen/CGDeclCXX.cpp
+++ b/clang/lib/CodeGen/CGDeclCXX.cpp
@@ -880,11 +880,11 @@ CodeGenModule::EmitCXXGlobalInitFunc() {
   // and makes sure these symbols appear lexicographically behind the symbols
   // with priority emitted above.
   llvm::Function *Fn;
-  if (CXX20ModuleInits && getContext().getModuleForCodeGen()) {
+  if (CXX20ModuleInits && getContext().getNamedModuleForCodeGen()) {
 SmallString<256> InitFnName;
 llvm::raw_svector_ostream Out(InitFnName);
 cast(getCXXABI().getMangleContext())
-.mangleModuleInitializer(getContext().getModuleForCodeGen(), Out);
+.mangleModuleInitializer(getContext().getNamedModuleForCodeGen(), Out);
 Fn = CreateGlobalInitOrCleanUpFunction(
 FTy, llvm::Twine(InitFnName), FI, SourceLocation(), false,
 llvm::GlobalVariable::ExternalLinkage);

diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 71ec831435356..71a2f61ea955f 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -509,7 +509,7 @@ static void setVisibilityFromDLLStorageClass(const 
clang::LangOptions &LO,
 }
 
 void CodeGenModule::Release() {
-  Module *Primary = getContext().getModuleForCodeGen();
+  Module *Primary = getContext().getNamedModuleForCodeGen();
   if (CXX20ModuleInits && Primary && !Primary->isHeaderLikeModule())
 EmitModuleInitializers(Primary);
   EmitDeferred();

diff  --git a/clang/lib/Frontend/ASTUnit.cpp b/clang/lib/Frontend/ASTUnit.cpp
index 3b4f25182ac95..f2939a2e8f0ef 100644
--- a/clang/lib/Frontend/ASTUnit.cpp
+++ b/clang/lib/Frontend/ASTUnit.cpp
@@ -877,6 +877,10 @@ std::unique_ptr ASTUnit::LoadFromASTFile(
 
   PP.setCounterValue(Counter);
 
+  Module *M = HeaderInfo.lookupModule(AST->getLangOpts().CurrentModule);
+  if (M && AST->getLangOpts().isCompilingModule() && M->isModulePurview())
+AST->Ctx->setNamedModuleForCodeGen(M);
+
   // Create an AST consumer, even though it isn't used.
   if (ToLoad >= LoadASTOnly)
 AST->Consumer.reset(new ASTConsumer);

diff  --git a/clang/lib/Parse/ParseAST.cpp b/clang/lib/Parse/ParseAST.cpp
index f442b6213836d..04b3f0460bf3e 100644
--- a/clang/lib/Parse/ParseAST.cpp
+++ b/clang/lib/Parse/ParseAST.cpp
@@ -172,27 +172,6 @@ void clang::ParseAST(Sema &S, bool PrintStats, bool 
SkipFunctionBodies) {
   for (Decl *D : S.WeakTopLevelDecls())
 Consumer->HandleTopLevelDecl(DeclGroupRef(D));
 
-  // For C++20 modules, the codegen for module in

[PATCH] D143348: [Clang][Doc][OpenCL] Release 16 notes

2023-02-13 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh accepted this revision.
svenvh added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:840
+  * Fixed conditional definition of the depth image and read_write image3d 
builtins.
+  * Added ``nounwind`` attribute to all builtin functions.
+

Anastasia wrote:
> svenvh wrote:
> > It's slightly more than that: clang adds `nounwind` not only for builtin 
> > functions, but for any OpenCL function call.
> Thanks, this makes sense... stack unwind in OpenCL kernel is meaningless atm.
> 
> However has this change been made in a separate commit?
The change of https://reviews.llvm.org/D142033 is not specific to builtins.

Please remember to decrease the indent level of this bullet point, so that it 
is no longer under "Improved builtin functions support".  Otherwise LGTM.


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

https://reviews.llvm.org/D143348

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via Phabricator via cfe-commits
zyounan updated this revision to Diff 496875.
zyounan added a comment.

Revise symbols from N4100


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

Files:
  clang-tools-extra/clangd/unittests/CanonicalIncludesTests.cpp
  clang/include/clang/Tooling/Inclusions/StdSymbolMap.inc


Index: clang/include/clang/Tooling/Inclusions/StdSymbolMap.inc
===
--- clang/include/clang/Tooling/Inclusions/StdSymbolMap.inc
+++ clang/include/clang/Tooling/Inclusions/StdSymbolMap.inc
@@ -1465,6 +1465,63 @@
 SYMBOL(temp_directory_path, std::filesystem::, )
 SYMBOL(u8path, std::filesystem::, )
 SYMBOL(weakly_canonical, std::filesystem::, )
+// These symbols are exported from N4100[fs.filesystem.synopsis], the final
+// draft for experimental filesystem. Note that not all of these symbols were
+// merged into C++17 (See P0492 and related proposals for details). But the
+// cornerstone for mainstream Stdlib TS filesystem implementation is N4100,
+// whatever.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )
+SYMBOL(canonical, std::experimental::filesystem::, )
+SYMBOL(copy, std::experimental::filesystem::, )
+SYMBOL(copy_file, std::experimental::filesystem::, )
+SYMBOL(copy_options, std::experimental::filesystem::, 
)
+SYMBOL(copy_symlink, std::experimental::filesystem::, 
)
+SYMBOL(create_directories, std::experimental::filesystem::, 
)
+SYMBOL(create_directory, std::experimental::filesystem::, 
)
+SYMBOL(create_directory_symlink, std::experimental::filesystem::, 
)
+SYMBOL(create_hard_link, std::experimental::filesystem::, 
)
+SYMBOL(create_symlink, std::experimental::filesystem::, 
)
+SYMBOL(current_path, std::experimental::filesystem::, 
)
+SYMBOL(directory_entry, std::experimental::filesystem::, 
)
+SYMBOL(directory_iterator, std::experimental::filesystem::, 
)
+SYMBOL(directory_options, std::experimental::filesystem::, 
)
+SYMBOL(equivalent, std::experimental::filesystem::, )
+SYMBOL(exists, std::experimental::filesystem::, )
+SYMBOL(file_size, std::experimental::filesystem::, )
+SYMBOL(file_status, std::experimental::filesystem::, )
+SYMBOL(file_time_type, std::experimental::filesystem::, 
)
+SYMBOL(file_type, std::experimental::filesystem::, )
+SYMBOL(filesystem_error, std::experimental::filesystem::, 
)
+SYMBOL(hard_link_count, std::experimental::filesystem::, 
)
+SYMBOL(is_block_file, std::experimental::filesystem::, 
)
+SYMBOL(is_character_file, std::experimental::filesystem::, 
)
+SYMBOL(is_directory, std::experimental::filesystem::, 
)
+SYMBOL(is_empty, std::experimental::filesystem::, )
+SYMBOL(is_fifo, std::experimental::filesystem::, )
+SYMBOL(is_other, std::experimental::filesystem::, )
+SYMBOL(is_regular_file, std::experimental::filesystem::, 
)
+SYMBOL(is_socket, std::experimental::filesystem::, )
+SYMBOL(is_symlink, std::experimental::filesystem::, )
+SYMBOL(last_write_time, std::experimental::filesystem::, 
)
+SYMBOL(path, std::experimental::filesystem::, )
+SYMBOL(permissions, std::experimental::filesystem::, )
+SYMBOL(perms, std::experimental::filesystem::, )
+SYMBOL(read_symlink, std::experimental::filesystem::, 
)
+SYMBOL(recursive_directory_iterator, std::experimental::filesystem::, 
)
+SYMBOL(remove, std::experimental::filesystem::, )
+SYMBOL(remove_all, std::experimental::filesystem::, )
+SYMBOL(rename, std::experimental::filesystem::, )
+SYMBOL(resize_file, std::experimental::filesystem::, )
+SYMBOL(space, std::experimental::filesystem::, )
+SYMBOL(space_info, std::experimental::filesystem::, )
+SYMBOL(status, std::experimental::filesystem::, )
+SYMBOL(status_known, std::experimental::filesystem::, 
)
+SYMBOL(symlink_status, std::experimental::filesystem::, 
)
+SYMBOL(system_complete, std::experimental::filesystem::, 
)
+SYMBOL(temp_directory_path, std::experimental::filesystem::, 
)
+SYMBOL(u8path, std::experimental::filesystem::, )
+// clang-format on
 SYMBOL(basic_string, std::pmr::, )
 SYMBOL(deque, std::pmr::, )
 SYMBOL(forward_list, std::pmr::, )
Index: clang-tools-extra/clangd/unittests/CanonicalIncludesTests.cpp
===
--- clang-tools-extra/clangd/unittests/CanonicalIncludesTests.cpp
+++ clang-tools-extra/clangd/unittests/CanonicalIncludesTests.cpp
@@ -62,6 +62,27 @@
   EXPECT_EQ("", CI.mapHeader(File));
 }
 
+TEST(CanonicalIncludesTest, CXXStandardLibraryExperimentalFilesystem) {
+  CanonicalIncludes CI;
+  auto Language = LangOptions();
+  Language.CPlusPlus = true;
+  CI.addSystemHeadersMapping(Language);
+
+  EXPECT_EQ("",
+CI.mapSymbol("std::experimental::filesystem::path"));
+  EXPECT_EQ("",
+CI.mapSymbol("std::experimental::filesystem::directory_iterator"));
+  // system_complete is replaced by std::filesystem::absolute
+  EXPECT_EQ("",
+CI.mapSymbol("std::experimental::filesystem::system_complete"));
+  EXPECT_EQ(""

[PATCH] D143751: [clang][analyzer][NFC] Refactor code of StdLibraryFunctionsChecker.

2023-02-13 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 496882.
balazske added a comment.

small problem fix


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143751

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp

Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -68,6 +68,19 @@
   /// to us. If he doesn't, he performs additional invalidations.
   enum InvalidationKind { NoEvalCall, EvalCallAsPure };
 
+  /// Given a range, should the argument stay inside or outside this range?
+  enum RangeKind { OutOfRange, WithinRange };
+
+  static RangeKind negateKind(RangeKind K) {
+switch (K) {
+case OutOfRange:
+  return WithinRange;
+case WithinRange:
+  return OutOfRange;
+}
+llvm_unreachable("Unknown range kind");
+  }
+
   // The universal integral type to use in value range descriptions.
   // Unsigned to make sure overflows are well-defined.
   typedef uint64_t RangeInt;
@@ -82,9 +95,11 @@
   /// ArgNo in CallExpr and CallEvent is defined as Unsigned, but
   /// obviously uint32_t should be enough for all practical purposes.
   typedef uint32_t ArgNo;
+  /// Special argument number for specifying the return value.
   static const ArgNo Ret;
 
   using DescString = SmallString<96>;
+
   /// Returns the string representation of an argument index.
   /// E.g.: (1) -> '1st arg', (2) - > '2nd arg'
   static SmallString<8> getArgDesc(ArgNo);
@@ -102,10 +117,12 @@
   class ValueConstraint;
 
   // Pointer to the ValueConstraint. We need a copyable, polymorphic and
-  // default initialize able type (vector needs that). A raw pointer was good,
+  // default initializable type (vector needs that). A raw pointer was good,
   // however, we cannot default initialize that. unique_ptr makes the Summary
   // class non-copyable, therefore not an option. Releasing the copyability
   // requirement would render the initialization of the Summary map infeasible.
+  // A new value constraint is created furthermore by the negate functionality
+  // of the constraint and returned as pointer.
   using ValueConstraintPtr = std::shared_ptr;
 
   /// Polymorphic base class that represents a constraint on a given argument
@@ -122,35 +139,12 @@
   public:
 ValueConstraint(ArgNo ArgN) : ArgN(ArgN) {}
 virtual ~ValueConstraint() {}
+
 /// Apply the effects of the constraint on the given program state. If null
 /// is returned then the constraint is not feasible.
 virtual ProgramStateRef apply(ProgramStateRef State, const CallEvent &Call,
   const Summary &Summary,
   CheckerContext &C) const = 0;
-virtual ValueConstraintPtr negate() const {
-  llvm_unreachable("Not implemented");
-};
-
-/// Check whether the constraint is malformed or not. It is malformed if the
-/// specified argument has a mismatch with the given FunctionDecl (e.g. the
-/// arg number is out-of-range of the function's argument list).
-bool checkValidity(const FunctionDecl *FD) const {
-  const bool ValidArg = ArgN == Ret || ArgN < FD->getNumParams();
-  assert(ValidArg && "Arg out of range!");
-  if (!ValidArg)
-return false;
-  // Subclasses may further refine the validation.
-  return checkSpecificValidity(FD);
-}
-ArgNo getArgNo() const { return ArgN; }
-
-/// Return those arguments that should be tracked when we report a bug. By
-/// default it is the argument that is constrained, however, in some special
-/// cases we need to track other arguments as well. E.g. a buffer size might
-/// be encoded in another argument.
-virtual std::vector getArgsToTrack() const { return {ArgN}; }
-
-virtual StringRef getName() const = 0;
 
 /// Represents that in which context do we require a description of the
 /// constraint.
@@ -158,6 +152,8 @@
   /// The constraint is violated.
   Violation,
   /// We assume that the constraint is satisfied.
+  /// This can be used when a precondition is satisfied, or when a summary
+  /// case is applied.
   Assumption
 };
 
@@ -174,81 +170,96 @@
   "Description not implemented for summary case constraints");
 }
 
-  protected:
-ArgNo ArgN; // Argument to which we apply the constraint.
+/// Return those arguments that should be tracked when we report a bug about
+/// argument constraint violation. By default it is the argument that is
+/// constrained, however, in some special cases we need to track other
+/// arguments as well. E.g. a buffer size might be encoded in another
+/// argument.
+/// The "return value" argument number can not occur as returne

[PATCH] D143891: [Clang] Adjust triviality computation in QualType::isTrivialType to C++20 cases.

2023-02-13 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson created this revision.
royjacobson added reviewers: erichkeane, cor3ntin.
Herald added a project: All.
royjacobson requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Up to C++20, hasDefaultConstructor and !hasNonTrivialDefaultConstructor 
together implied
hasTrivialDefaultConstructor. In C++20, a constructor might be ineligible and 
can set
hasDefaultConstructor without setting hasNonTrivialDefaultConstructor.

Fix this by querying hasTrivialDefaultConstructor instead of 
hasDefaultConstructor.

I'd like to backport this to Clang 16.
I only change isTrivialType and in a way that should only affect code that uses
constrained constructors, so I think this is relatively safe to backport.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143891

Files:
  clang/lib/AST/Type.cpp
  clang/test/SemaCXX/constrained-special-member-functions.cpp


Index: clang/test/SemaCXX/constrained-special-member-functions.cpp
===
--- clang/test/SemaCXX/constrained-special-member-functions.cpp
+++ clang/test/SemaCXX/constrained-special-member-functions.cpp
@@ -265,3 +265,37 @@
 static_assert(__is_trivially_constructible(D), "");
 
 }
+
+namespace GH60697 {
+
+template 
+struct X {
+X() requires false = default;
+};
+static_assert(!__is_trivial(X));
+
+template 
+struct S {
+S() requires(__is_trivially_constructible(T)) = default;
+
+S() requires(!__is_trivially_constructible(T) &&
+  __is_constructible(T)) {}
+
+T t;
+};
+
+struct D {
+D(int i) : i(i) {}
+int i;
+};
+static_assert(!__is_trivially_constructible(D));
+static_assert(!__is_constructible(D));
+static_assert(!__is_trivial(D));
+
+static_assert(!__is_trivially_constructible(S));
+static_assert(!__is_constructible(S));
+
+static_assert(__is_trivial(S));
+static_assert(!__is_trivial(S));
+
+}
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -2487,11 +2487,13 @@
 return true;
   if (const auto *RT = CanonicalType->getAs()) {
 if (const auto *ClassDecl = dyn_cast(RT->getDecl())) {
-  // C++11 [class]p6:
-  //   A trivial class is a class that has a default constructor,
-  //   has no non-trivial default constructors, and is trivially
-  //   copyable.
-  return ClassDecl->hasDefaultConstructor() &&
+  // C++20 [class]p6:
+  //   A trivial class is a class that is trivially copyable, and
+  // has one or more eligible default constructors such that each is
+  // trivial.
+  // FIXME: We should merge this definition of triviality into
+  // CXXRecordDecl::isTrivial. Currently it computes the wrong thing.
+  return ClassDecl->hasTrivialDefaultConstructor() &&
  !ClassDecl->hasNonTrivialDefaultConstructor() &&
  ClassDecl->isTriviallyCopyable();
 }


Index: clang/test/SemaCXX/constrained-special-member-functions.cpp
===
--- clang/test/SemaCXX/constrained-special-member-functions.cpp
+++ clang/test/SemaCXX/constrained-special-member-functions.cpp
@@ -265,3 +265,37 @@
 static_assert(__is_trivially_constructible(D), "");
 
 }
+
+namespace GH60697 {
+
+template 
+struct X {
+X() requires false = default;
+};
+static_assert(!__is_trivial(X));
+
+template 
+struct S {
+S() requires(__is_trivially_constructible(T)) = default;
+
+S() requires(!__is_trivially_constructible(T) &&
+  __is_constructible(T)) {}
+
+T t;
+};
+
+struct D {
+D(int i) : i(i) {}
+int i;
+};
+static_assert(!__is_trivially_constructible(D));
+static_assert(!__is_constructible(D));
+static_assert(!__is_trivial(D));
+
+static_assert(!__is_trivially_constructible(S));
+static_assert(!__is_constructible(S));
+
+static_assert(__is_trivial(S));
+static_assert(!__is_trivial(S));
+
+}
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -2487,11 +2487,13 @@
 return true;
   if (const auto *RT = CanonicalType->getAs()) {
 if (const auto *ClassDecl = dyn_cast(RT->getDecl())) {
-  // C++11 [class]p6:
-  //   A trivial class is a class that has a default constructor,
-  //   has no non-trivial default constructors, and is trivially
-  //   copyable.
-  return ClassDecl->hasDefaultConstructor() &&
+  // C++20 [class]p6:
+  //   A trivial class is a class that is trivially copyable, and
+  // has one or more eligible default constructors such that each is
+  // trivial.
+  // FIXME: We should merge this definition of triviality into
+  // CXXRecordDecl::isTrivial. Currently it computes the wrong thing.
+  return ClassDecl->hasTriv

[PATCH] D143849: [Clang][OpenCL] Allow pointers in structs as kernel arguments from 2.0

2023-02-13 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:9494
+  // of SVM.
+  if (S.getLangOpts().getOpenCLCompatibleVersion() > 120 &&
+  (ParamType == PtrKernelParam || ParamType == PtrPtrKernelParam))

Ayal wrote:
> Anastasia wrote:
> > I think it should be possible to merge this with `if` below to avoid 
> > condition duplication.
> > 
> > 
> Sure, but that trades one duplication for another, rather than clearly 
> separating the early-continue case early?
> 
> ```
>   if (ParamType == PtrKernelParam || ParamType == PtrPtrKernelParam) {
> if (S.getLangOpts().getOpenCLCompatibleVersion() > 120)
>   continue;
> S.Diag(Param->getLocation(),
>diag::err_record_with_pointers_kernel_param)
>   << PT->isUnionType()
>   << PT;
>   } else if (ParamType == InvalidAddrSpacePtrKernelParam) {
> S.Diag(Param->getLocation(),
>diag::err_record_with_pointers_kernel_param)
>   << PT->isUnionType()
>   << PT;
>   } else {
> S.Diag(Param->getLocation(), diag::err_bad_kernel_param_type) << PT;
> 
> ```
I am mainly thinking in terms of maintenance if for example someone fixes one 
if and forgets another. Or if ifs will get separated by some other code and 
then it is not easy to see that the same thing is handled differently in OpenCL 
versions. 

Unfortunately we have a lot of those cases, I know this function has early 
exists but it is not a common style.


I was talking about something like:


```
if (((S.getLangOpts().getOpenCLCompatibleVersion() <= 120) &&
(ParamType == PtrKernelParam || ParamType == PtrPtrKernelParam)) ||
  ParamType == InvalidAddrSpacePtrKernelParam)
```

It would also be ok to separate `InvalidAddrSpacePtrKernelParam` since it's 
handling different feature.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143849

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


[PATCH] D143096: [clangd] Provide patched diagnostics with preamble patch

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 496900.
kadircet marked 12 inline comments as done.
kadircet added a comment.

- Change patching logic to iterate over diags instead of preamble lines
- Change translation logic to:
  - Preserve a diagnostic if its range can be translated.
  - Preserve all the notes whose range can be translated.
  - Preserve all the fixes whose edit ranges can be translated.
- Drop restrictions on ranges being a single line, make sure contents for all 
the lines are matched between modified and basline contents.
- Add couple new tests to demonstrate what's preserved.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143096

Files:
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Preamble.h
  clang-tools-extra/clangd/unittests/PreambleTests.cpp

Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -724,9 +724,8 @@
 #define BAR
 #include [[]])");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: We should point at the correct coordinates in NewCode.
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
   }
   {
 // Check with removals from preamble.
@@ -735,18 +734,15 @@
 #include [[]])");
 Annotations NewCode("#include [[]]");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: We should point at the correct coordinates in NewCode.
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
   }
   {
 // Drop line with diags.
 Annotations Code("#include [[]]");
 Annotations NewCode("#define BAR\n#define BAZ\n");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: No diagnostics.
-EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+EXPECT_THAT(*AST->getDiagnostics(), IsEmpty());
   }
   {
 // Picks closest line in case of multiple alternatives.
@@ -757,18 +753,79 @@
 #define BAR
 #include )");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: We should point at the correct coordinates in NewCode.
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
   }
   {
 // Drop diag if line spelling has changed.
 Annotations Code("#include [[]]");
 Annotations NewCode(" # include ");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: No diags.
+EXPECT_THAT(*AST->getDiagnostics(), IsEmpty());
+  }
+  {
+// Multiple lines.
+Annotations Code(R"(
+#define BAR
+#include [[]])");
+Annotations NewCode(R"(#include [[]])");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
+  }
+  {
+// Multiple lines with change.
+Annotations Code(R"(
+#define BAR
+#include 
+#include [[]])");
+Annotations NewCode(R"(#include )");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(*AST->getDiagnostics(), IsEmpty());
+  }
+  {
+// Preserves notes.
+Annotations Code(R"(
+#define $note[[BAR]] 1
+#define $main[[BAR]] 2)");
+Annotations NewCode(R"(
+#define BAZ 0
+#define $note[[BAR]] 1
+#define BAZ 0
+#define $main[[BAR]] 2)");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(
+*AST->getDiagnostics(),
+ElementsAre(AllOf(Diag(NewCode.range("main"), "-Wmacro-redefined"),
+  withNote(Diag(NewCode.range("note"));
+  }
+  {
+// Preserves diag without note.
+Annotations Code(R"(
+#define $note[[BAR]] 1
+#define $main[[BAR]] 2)");
+Annotations NewCode(R"(
+#define $main[[BAR]] 2)");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(
+*AST->getDiagnostics(),
+ElementsAre(AllOf(Diag(NewCode.range("main"), "-Wmacro-redefined"),
+  Field(&Diag::Notes, IsEmpty();
+  }
+  {
+// Note is also dropped if diag is gone.
+Annotations Code(R"(
+#define $note[[BAR]] 1
+#define $main[[BAR]] 2)");
+Annotations NewCode(R"(
+#define BAZ 0
+#define BAR 1)");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(*AST->getDiagnostics(), IsEmp

[PATCH] D143096: [clangd] Provide patched diagnostics with preamble patch

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 496905.
kadircet added a comment.

- Reflow comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143096

Files:
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Preamble.h
  clang-tools-extra/clangd/unittests/PreambleTests.cpp

Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -724,9 +724,8 @@
 #define BAR
 #include [[]])");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: We should point at the correct coordinates in NewCode.
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
   }
   {
 // Check with removals from preamble.
@@ -735,18 +734,15 @@
 #include [[]])");
 Annotations NewCode("#include [[]]");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: We should point at the correct coordinates in NewCode.
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
   }
   {
 // Drop line with diags.
 Annotations Code("#include [[]]");
 Annotations NewCode("#define BAR\n#define BAZ\n");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: No diagnostics.
-EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+EXPECT_THAT(*AST->getDiagnostics(), IsEmpty());
   }
   {
 // Picks closest line in case of multiple alternatives.
@@ -757,18 +753,79 @@
 #define BAR
 #include )");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: We should point at the correct coordinates in NewCode.
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
   }
   {
 // Drop diag if line spelling has changed.
 Annotations Code("#include [[]]");
 Annotations NewCode(" # include ");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: No diags.
+EXPECT_THAT(*AST->getDiagnostics(), IsEmpty());
+  }
+  {
+// Multiple lines.
+Annotations Code(R"(
+#define BAR
+#include [[]])");
+Annotations NewCode(R"(#include [[]])");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
+  }
+  {
+// Multiple lines with change.
+Annotations Code(R"(
+#define BAR
+#include 
+#include [[]])");
+Annotations NewCode(R"(#include )");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(*AST->getDiagnostics(), IsEmpty());
+  }
+  {
+// Preserves notes.
+Annotations Code(R"(
+#define $note[[BAR]] 1
+#define $main[[BAR]] 2)");
+Annotations NewCode(R"(
+#define BAZ 0
+#define $note[[BAR]] 1
+#define BAZ 0
+#define $main[[BAR]] 2)");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(
+*AST->getDiagnostics(),
+ElementsAre(AllOf(Diag(NewCode.range("main"), "-Wmacro-redefined"),
+  withNote(Diag(NewCode.range("note"));
+  }
+  {
+// Preserves diag without note.
+Annotations Code(R"(
+#define $note[[BAR]] 1
+#define $main[[BAR]] 2)");
+Annotations NewCode(R"(
+#define $main[[BAR]] 2)");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(
+*AST->getDiagnostics(),
+ElementsAre(AllOf(Diag(NewCode.range("main"), "-Wmacro-redefined"),
+  Field(&Diag::Notes, IsEmpty();
+  }
+  {
+// Note is also dropped if diag is gone.
+Annotations Code(R"(
+#define $note[[BAR]] 1
+#define $main[[BAR]] 2)");
+Annotations NewCode(R"(
+#define BAZ 0
+#define BAR 1)");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(*AST->getDiagnostics(), IsEmpty());
   }
 }
 } // namespace
Index: clang-tools-extra/clangd/Preamble.h
===
--- clang-tools-extra/clangd/Preamble.h
+++ clang-tools-extra/clangd/Preamble.h
@@ -34,6 +34,7 @@
 #include "clang/Frontend/PrecompiledPreamble.h"
 #include "clang/Lex/Lexer.h"
 #include "clang/Tooling/CompilationDatabase.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/StringRef.h"
 
 #include 
@@ -157,6 +158,8 @@
   /// Whether diagnostics generated usi

[PATCH] D143632: [clang] Handle __declspec() attributes in using

2023-02-13 Thread Tobias Hieta via Phabricator via cfe-commits
thieta updated this revision to Diff 496906.
thieta marked 2 inline comments as done.
thieta added a comment.

- Expand on tests
- Fix crash when Attrs was null
- Added release note


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143632

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Parse/ParseDecl.cpp
  clang/test/SemaCXX/using-declspec.cpp


Index: clang/test/SemaCXX/using-declspec.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/using-declspec.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fms-compatibility -fsyntax-only -verify %s
+
+// This should ignore the alignment and issue a warning about
+// align not being used
+auto func() -> __declspec(align(16)) int; // expected-warning{{attribute 
ignored when parsing type}}
+static_assert(alignof(decltype(func())) == alignof(int));
+
+// The following should NOT assert since alignment should
+// follow the type
+struct Test { int a; };
+using AlignedTest = __declspec(align(16)) const Test;
+static_assert(alignof(AlignedTest) == 16, "error");
+
+// Same here, no declaration to shift to
+int i = (__declspec(align(16))int)12; // expected-warning{{attribute ignored 
when parsing type}}
+
+// But there is a declaration here!
+typedef __declspec(align(16)) int Foo;
+static_assert(alignof(Foo) == 16);
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -56,6 +56,19 @@
   if (OwnedType)
 *OwnedType = DS.isTypeSpecOwned() ? DS.getRepAsDecl() : nullptr;
 
+  // Move declspec attributes to ParsedAttributes
+  if (Attrs)
+  {
+llvm::SmallVector ToBeMoved;
+for (ParsedAttr &AL : DS.getAttributes()) {
+  if (AL.isDeclspecAttribute())
+ToBeMoved.push_back(&AL);
+}
+
+for (ParsedAttr *AL : ToBeMoved)
+  Attrs->takeOneFrom(DS.getAttributes(), AL);
+  }
+
   // Parse the abstract-declarator, if present.
   Declarator DeclaratorInfo(DS, ParsedAttributesView::none(), Context);
   ParseDeclarator(DeclaratorInfo);
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -109,6 +109,10 @@
 bounds memory accesses. It emits warnings at call sites to such functions when
 the flag ``-Wunsafe-buffer-usage`` is enabled.
 
+__declspec attributes can now be used together with the using keyword. Before
+the attributes on __declspec was ignored, while now it will be forwarded to the
+point where the alias is used.
+
 Windows Support
 ---
 


Index: clang/test/SemaCXX/using-declspec.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/using-declspec.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fms-compatibility -fsyntax-only -verify %s
+
+// This should ignore the alignment and issue a warning about
+// align not being used
+auto func() -> __declspec(align(16)) int; // expected-warning{{attribute ignored when parsing type}}
+static_assert(alignof(decltype(func())) == alignof(int));
+
+// The following should NOT assert since alignment should
+// follow the type
+struct Test { int a; };
+using AlignedTest = __declspec(align(16)) const Test;
+static_assert(alignof(AlignedTest) == 16, "error");
+
+// Same here, no declaration to shift to
+int i = (__declspec(align(16))int)12; // expected-warning{{attribute ignored when parsing type}}
+
+// But there is a declaration here!
+typedef __declspec(align(16)) int Foo;
+static_assert(alignof(Foo) == 16);
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -56,6 +56,19 @@
   if (OwnedType)
 *OwnedType = DS.isTypeSpecOwned() ? DS.getRepAsDecl() : nullptr;
 
+  // Move declspec attributes to ParsedAttributes
+  if (Attrs)
+  {
+llvm::SmallVector ToBeMoved;
+for (ParsedAttr &AL : DS.getAttributes()) {
+  if (AL.isDeclspecAttribute())
+ToBeMoved.push_back(&AL);
+}
+
+for (ParsedAttr *AL : ToBeMoved)
+  Attrs->takeOneFrom(DS.getAttributes(), AL);
+  }
+
   // Parse the abstract-declarator, if present.
   Declarator DeclaratorInfo(DS, ParsedAttributesView::none(), Context);
   ParseDeclarator(DeclaratorInfo);
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -109,6 +109,10 @@
 bounds memory accesses. It emits warnings at call sites to such functions when
 the flag ``-Wunsafe-buffer-usage`` is enabled.
 
+__declspec attributes can now be used together with the using keyword. Before
+the attributes on __declspec was ignored, while now it will be forwarded to the
+point where the alias is used.
+
 Windows Support

[PATCH] D143096: [clangd] Provide patched diagnostics with preamble patch

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 496907.
kadircet edited the summary of this revision.
kadircet added a comment.

- Update commit message


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143096

Files:
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Preamble.h
  clang-tools-extra/clangd/unittests/PreambleTests.cpp

Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -724,9 +724,8 @@
 #define BAR
 #include [[]])");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: We should point at the correct coordinates in NewCode.
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
   }
   {
 // Check with removals from preamble.
@@ -735,18 +734,15 @@
 #include [[]])");
 Annotations NewCode("#include [[]]");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: We should point at the correct coordinates in NewCode.
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
   }
   {
 // Drop line with diags.
 Annotations Code("#include [[]]");
 Annotations NewCode("#define BAR\n#define BAZ\n");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: No diagnostics.
-EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+EXPECT_THAT(*AST->getDiagnostics(), IsEmpty());
   }
   {
 // Picks closest line in case of multiple alternatives.
@@ -757,18 +753,79 @@
 #define BAR
 #include )");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: We should point at the correct coordinates in NewCode.
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
   }
   {
 // Drop diag if line spelling has changed.
 Annotations Code("#include [[]]");
 Annotations NewCode(" # include ");
 auto AST = createPatchedAST(Code.code(), NewCode.code());
-// FIXME: No diags.
+EXPECT_THAT(*AST->getDiagnostics(), IsEmpty());
+  }
+  {
+// Multiple lines.
+Annotations Code(R"(
+#define BAR
+#include [[]])");
+Annotations NewCode(R"(#include [[]])");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
 EXPECT_THAT(*AST->getDiagnostics(),
-ElementsAre(Diag(Code.range(), "pp_file_not_found")));
+ElementsAre(Diag(NewCode.range(), "pp_file_not_found")));
+  }
+  {
+// Multiple lines with change.
+Annotations Code(R"(
+#define BAR
+#include 
+#include [[]])");
+Annotations NewCode(R"(#include )");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(*AST->getDiagnostics(), IsEmpty());
+  }
+  {
+// Preserves notes.
+Annotations Code(R"(
+#define $note[[BAR]] 1
+#define $main[[BAR]] 2)");
+Annotations NewCode(R"(
+#define BAZ 0
+#define $note[[BAR]] 1
+#define BAZ 0
+#define $main[[BAR]] 2)");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(
+*AST->getDiagnostics(),
+ElementsAre(AllOf(Diag(NewCode.range("main"), "-Wmacro-redefined"),
+  withNote(Diag(NewCode.range("note"));
+  }
+  {
+// Preserves diag without note.
+Annotations Code(R"(
+#define $note[[BAR]] 1
+#define $main[[BAR]] 2)");
+Annotations NewCode(R"(
+#define $main[[BAR]] 2)");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(
+*AST->getDiagnostics(),
+ElementsAre(AllOf(Diag(NewCode.range("main"), "-Wmacro-redefined"),
+  Field(&Diag::Notes, IsEmpty();
+  }
+  {
+// Note is also dropped if diag is gone.
+Annotations Code(R"(
+#define $note[[BAR]] 1
+#define $main[[BAR]] 2)");
+Annotations NewCode(R"(
+#define BAZ 0
+#define BAR 1)");
+auto AST = createPatchedAST(Code.code(), NewCode.code());
+EXPECT_THAT(*AST->getDiagnostics(), IsEmpty());
   }
 }
 } // namespace
Index: clang-tools-extra/clangd/Preamble.h
===
--- clang-tools-extra/clangd/Preamble.h
+++ clang-tools-extra/clangd/Preamble.h
@@ -34,6 +34,7 @@
 #include "clang/Frontend/PrecompiledPreamble.h"
 #include "clang/Lex/Lexer.h"
 #include "clang/Tooling/CompilationDatabase.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/StringRef.h"
 
 #include 
@@ -157,

[PATCH] D143632: [clang] Handle __declspec() attributes in using

2023-02-13 Thread Tobias Hieta via Phabricator via cfe-commits
thieta marked an inline comment as done.
thieta added a comment.

Thanks for your comments - feel free to comment on the release note, I was 
struggling with describing the fix well for a short release note paragraph.




Comment at: clang/lib/Parse/ParseDecl.cpp:61-63
+  for (ParsedAttr &AL : DS.getAttributes())
+if (AL.isDeclspecAttribute())
+  ToBeMoved.push_back(&AL);

aaron.ballman wrote:
> How about using an algorithm for this (would need to be reformatted for 80 
> col)?
I spent a while on trying to figure this out. I am not that great with the 
algorithms in the standard library since we don't really use that at work. But 
from my testing I couldn't get it to work:

- DS.getAttributes() returns a `ParsedAttr&`, but ToBeMoved needs a pointer to 
ParsedAttr. So your example code above fails because it can't convert 
ParsedAttr& to ParsedAttr* in the back_inserter()
- I tried to change ToBeMoved to be a list of references instead, but 
ParsedAttr disallows copying (I think, the error message was a bit confusing).
- I could do transform() to a list of pointers and then copy_if() but that 
seemed to really make it harder to understand.
- A transform_if() would solve the problem or I guess replace back_inserter() 
with some out iterator that could transform. But I couldn't find anything used 
like this browsing the LLVM source code.

So yeah - I might totally be missing something obvious here, feel free to point 
it out.



Comment at: clang/lib/Parse/ParseDecl.cpp:65-66
+
+  for (ParsedAttr *AL : ToBeMoved)
+Attrs->takeOneFrom(DS.getAttributes(), AL);
+

aaron.ballman wrote:
> Similar here, but this one might be less of a win in terms of readability.
yeah I can do this - I'll wait to see what we do with the block above first.



Comment at: clang/test/SemaCXX/using-declspec.cpp:4
+
+struct Test { int a; };
+using AlignedTest = __declspec(align(16)) const Test;

aaron.ballman wrote:
> Because we're touching `ParseTypeName()` and that is called in a lot of 
> contexts, I think we should have extra testing in non-alias declaration cases 
> and verify that MSVC behaves the same way. e.g., (search for 
> `ParseTypeName()`, see where we parse type names, devise some test cases)
> ```
> // I don't think the align attribute has a declaration to move onto in this 
> case...
> auto func() -> __declspec(align(16)) int;
> // So I *think* the alignment of the return type isn't changed?
> static_assert(alignof(decltype(func())) == alignof(int));
> 
> // Same here, no declaration to shift to
> int i = (__declspec(align(16))int)12;
> 
> // But there is a declaration here!
> typedef __declspec(align(16)) int Foo;
> static_assert(alignof(Foo) == 16);
> ```
> (There are possibly other interesting tests to consider.)
> 
> I suspect we should be issuing some "attribute ignored" diagnostics for the 
> cases where the attribute has no effect (even if MSVC does not warn).
Thanks for the expanded tests here! I tried all these tests on MSVC and they 
behave exactly as you described them above and they found bug in my 
implementation - Attrs in ParseTypeName() could be a nullptr.

We already emit warnings where the attribute is not used as you can see in the 
test case below.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143632

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

Thanks for updating this, as I mentioned in 
https://reviews.llvm.org/D143319#4115186, we should put these symbols into 
their own symbol map. ATM `StdSymbolMap.inc` is still generated by an automated 
tool and shouldn't be modified by hand.
So can you rather put these symbols into 
`llvm/llvm-project/clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc` ? 
you also need to rebase your branch, we've moved these mappings from `include` 
directory to `lib`. they're implementation details now, and not public 
interfaces.
After putting it into a new file, you'll also need to include it in 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp#L65.

As for tests, rather than using clangd, can you introduce tests into 
StandardLibrary instead in 
https://github.com/llvm/llvm-project/blob/main/clang/unittests/Tooling/StandardLibraryTest.cpp
 ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via Phabricator via cfe-commits
zyounan added a comment.

Sorry for the late update, I'm rebasing my branch now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

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


[PATCH] D143436: [clangd] Apply standard adaptors to CDBs pushed from LSP

2023-02-13 Thread Dmitry Polukhin via Phabricator via cfe-commits
DmitryPolukhin added a comment.

In D143436#4120899 , @nridge wrote:

> Note that D138546  is removing the call to 
> `inferTargetAndDriverMode()` from `GlobalCompilationDatabase.cpp`. It adds 
> equivalent logic too `CommandMangler` which is used for CDBs pushed from LSP 
> as well, so it accomplishes objective of this patch with respect to 
> `inferTargetAndDriverMode` (but not `inferMissingCompileCommands`).

@nridge I think D138546  solves the issue 
only partially and we need both patches applied. `inferMissingCompileCommands` 
and `expandResponseFiles` also needs to be applied to command pushed via LSP. I 
can rebase on top of D138546  if it will be 
landed first and update test. Please advise which patch should land first?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143436

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


[PATCH] D143751: [clang][analyzer][NFC] Refactor code of StdLibraryFunctionsChecker.

2023-02-13 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 496923.
balazske added a comment.

removed "IsLast"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143751

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp

Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -68,6 +68,19 @@
   /// to us. If he doesn't, he performs additional invalidations.
   enum InvalidationKind { NoEvalCall, EvalCallAsPure };
 
+  /// Given a range, should the argument stay inside or outside this range?
+  enum RangeKind { OutOfRange, WithinRange };
+
+  static RangeKind negateKind(RangeKind K) {
+switch (K) {
+case OutOfRange:
+  return WithinRange;
+case WithinRange:
+  return OutOfRange;
+}
+llvm_unreachable("Unknown range kind");
+  }
+
   // The universal integral type to use in value range descriptions.
   // Unsigned to make sure overflows are well-defined.
   typedef uint64_t RangeInt;
@@ -82,9 +95,11 @@
   /// ArgNo in CallExpr and CallEvent is defined as Unsigned, but
   /// obviously uint32_t should be enough for all practical purposes.
   typedef uint32_t ArgNo;
+  /// Special argument number for specifying the return value.
   static const ArgNo Ret;
 
   using DescString = SmallString<96>;
+
   /// Returns the string representation of an argument index.
   /// E.g.: (1) -> '1st arg', (2) - > '2nd arg'
   static SmallString<8> getArgDesc(ArgNo);
@@ -102,10 +117,12 @@
   class ValueConstraint;
 
   // Pointer to the ValueConstraint. We need a copyable, polymorphic and
-  // default initialize able type (vector needs that). A raw pointer was good,
+  // default initializable type (vector needs that). A raw pointer was good,
   // however, we cannot default initialize that. unique_ptr makes the Summary
   // class non-copyable, therefore not an option. Releasing the copyability
   // requirement would render the initialization of the Summary map infeasible.
+  // A new value constraint is created furthermore by the negate functionality
+  // of the constraint and returned as pointer.
   using ValueConstraintPtr = std::shared_ptr;
 
   /// Polymorphic base class that represents a constraint on a given argument
@@ -122,35 +139,12 @@
   public:
 ValueConstraint(ArgNo ArgN) : ArgN(ArgN) {}
 virtual ~ValueConstraint() {}
+
 /// Apply the effects of the constraint on the given program state. If null
 /// is returned then the constraint is not feasible.
 virtual ProgramStateRef apply(ProgramStateRef State, const CallEvent &Call,
   const Summary &Summary,
   CheckerContext &C) const = 0;
-virtual ValueConstraintPtr negate() const {
-  llvm_unreachable("Not implemented");
-};
-
-/// Check whether the constraint is malformed or not. It is malformed if the
-/// specified argument has a mismatch with the given FunctionDecl (e.g. the
-/// arg number is out-of-range of the function's argument list).
-bool checkValidity(const FunctionDecl *FD) const {
-  const bool ValidArg = ArgN == Ret || ArgN < FD->getNumParams();
-  assert(ValidArg && "Arg out of range!");
-  if (!ValidArg)
-return false;
-  // Subclasses may further refine the validation.
-  return checkSpecificValidity(FD);
-}
-ArgNo getArgNo() const { return ArgN; }
-
-/// Return those arguments that should be tracked when we report a bug. By
-/// default it is the argument that is constrained, however, in some special
-/// cases we need to track other arguments as well. E.g. a buffer size might
-/// be encoded in another argument.
-virtual std::vector getArgsToTrack() const { return {ArgN}; }
-
-virtual StringRef getName() const = 0;
 
 /// Represents that in which context do we require a description of the
 /// constraint.
@@ -158,6 +152,8 @@
   /// The constraint is violated.
   Violation,
   /// We assume that the constraint is satisfied.
+  /// This can be used when a precondition is satisfied, or when a summary
+  /// case is applied.
   Assumption
 };
 
@@ -174,81 +170,96 @@
   "Description not implemented for summary case constraints");
 }
 
-  protected:
-ArgNo ArgN; // Argument to which we apply the constraint.
+/// Return those arguments that should be tracked when we report a bug about
+/// argument constraint violation. By default it is the argument that is
+/// constrained, however, in some special cases we need to track other
+/// arguments as well. E.g. a buffer size might be encoded in another
+/// argument.
+/// The "return value" argument number can not occur as returned

[PATCH] D142655: [clang-tidy] Introduce HeaderFileExtensions and ImplementationFileExtensions options

2023-02-13 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp updated this revision to Diff 496924.
carlosgalvezp added a comment.

- Rebase.
- Fix code directly for the newly introduce check in llvmlibc. We do not need 
the deprecation process here since the check is brand new.
- Rebase the getter functions from ClangTidyCheck.h, they don't seem to belong. 
Solve it by having each check that needs it store a copy of the file 
extensions, fetching it from the Context in the constructor of the check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142655

Files:
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h
  clang-tools-extra/clang-tidy/ClangTidyOptions.cpp
  clang-tools-extra/clang-tidy/ClangTidyOptions.h
  clang-tools-extra/clang-tidy/FileExtensionsSet.h
  clang-tools-extra/clang-tidy/bugprone/DynamicStaticInitializersCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/DynamicStaticInitializersCheck.h
  clang-tools-extra/clang-tidy/bugprone/SuspiciousIncludeCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SuspiciousIncludeCheck.h
  clang-tools-extra/clang-tidy/google/GlobalNamesInHeadersCheck.cpp
  clang-tools-extra/clang-tidy/google/GlobalNamesInHeadersCheck.h
  clang-tools-extra/clang-tidy/google/UnnamedNamespaceInHeaderCheck.cpp
  clang-tools-extra/clang-tidy/google/UnnamedNamespaceInHeaderCheck.h
  clang-tools-extra/clang-tidy/llvmlibc/InlineFunctionDeclCheck.cpp
  clang-tools-extra/clang-tidy/llvmlibc/InlineFunctionDeclCheck.h
  clang-tools-extra/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
  clang-tools-extra/clang-tidy/misc/DefinitionsInHeadersCheck.h
  clang-tools-extra/clang-tidy/misc/UnusedUsingDeclsCheck.cpp
  clang-tools-extra/clang-tidy/misc/UnusedUsingDeclsCheck.h
  clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.cpp
  clang-tools-extra/clang-tidy/misc/UseAnonymousNamespaceCheck.h
  clang-tools-extra/clang-tidy/tool/ClangTidyMain.cpp
  clang-tools-extra/clang-tidy/utils/FileExtensionsUtils.h
  clang-tools-extra/clang-tidy/utils/HeaderGuard.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone/suspicious-include.rst
  clang-tools-extra/docs/clang-tidy/checks/google/build-namespaces.rst
  clang-tools-extra/docs/clang-tidy/checks/google/global-names-in-headers.rst
  clang-tools-extra/docs/clang-tidy/checks/llvm/header-guard.rst
  clang-tools-extra/docs/clang-tidy/checks/llvmlibc/inline-function-decl.rst
  clang-tools-extra/docs/clang-tidy/checks/misc/definitions-in-headers.rst
  clang-tools-extra/docs/clang-tidy/checks/misc/unused-using-decls.rst
  clang-tools-extra/docs/clang-tidy/checks/misc/use-anonymous-namespace.rst
  clang-tools-extra/docs/clang-tidy/index.rst
  clang-tools-extra/test/clang-tidy/infrastructure/verify-config.cpp
  clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp

Index: clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/ClangTidyOptionsTest.cpp
@@ -76,13 +76,20 @@
 
 TEST(ParseConfiguration, ValidConfiguration) {
   llvm::ErrorOr Options =
-  parseConfiguration(llvm::MemoryBufferRef("Checks: \"-*,misc-*\"\n"
-   "HeaderFilterRegex: \".*\"\n"
-   "AnalyzeTemporaryDtors: true\n"
-   "User: some.user",
-   "Options"));
+  parseConfiguration(llvm::MemoryBufferRef(
+  "Checks: \"-*,misc-*\"\n"
+  "HeaderFileExtensions: [\"\",\"h\",\"hh\",\"hpp\",\"hxx\"]\n"
+  "ImplementationFileExtensions: [\"c\",\"cc\",\"cpp\",\"cxx\"]\n"
+  "HeaderFilterRegex: \".*\"\n"
+  "AnalyzeTemporaryDtors: true\n"
+  "User: some.user",
+  "Options"));
   EXPECT_TRUE(!!Options);
   EXPECT_EQ("-*,misc-*", *Options->Checks);
+  EXPECT_EQ(std::vector({"", "h", "hh", "hpp", "hxx"}),
+*Options->HeaderFileExtensions);
+  EXPECT_EQ(std::vector({"c", "cc", "cpp", "cxx"}),
+*Options->ImplementationFileExtensions);
   EXPECT_EQ(".*", *Options->HeaderFilterRegex);
   EXPECT_EQ("some.user", *Options->User);
 }
@@ -105,6 +112,8 @@
   llvm::ErrorOr Options1 =
   parseConfiguration(llvm::MemoryBufferRef(R"(
   Checks: "check1,check2"
+  HeaderFileExtensions: ["h","hh"]
+  ImplementationFileExtensions: ["c","cc"]
   HeaderFilterRegex: "filter1"
   AnalyzeTemporaryDtors: true
   User: user1
@@ -117,6 +126,8 @@
   llvm::ErrorOr Options2 =
   parseConfiguration(llvm::MemoryBufferRef(R"(
   Checks: "check3,check4"
+  HeaderFileExtensions: ["hpp","hxx"]
+  ImplementationFileExtensions: ["cpp","cxx"]
   HeaderFilterRegex: "filter2"
   Analyze

[PATCH] D143260: [clangd] Add semantic token for labels

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

thanks for the patch, but could you elaborate a little bit on "why this is 
useful for clients".
in theory semantic highlighting tries to provide annotations for tokens that 
are hard to disambiguate by a syntax highlighter due to need for context.
at hindsight i can't see why `goto X;` and `X:` is not enough for clients to 
implement this without any need for semantic analysis. are there contexts where 
this kind of syntactical match is not enough?
moreover there are other label-like constructs that we're not handling, e.g. 
access specifiers and switch cases. any particular reason for not handling them 
as part of "label" highlights if we were to handle label-decls (the argument 
above applies to this case too though, I think these can be inferred without 
any semantic analysis)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143260

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


[PATCH] D143436: [clangd] Apply standard adaptors to CDBs pushed from LSP

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

> There is a discrepancy between how clangd processes CDB loaded from JSON file 
> on disk and pushed via LSP.

That's actually because we model compile commands pushed via LSP as a "fixed 
compilation database" rather than a json compilation database (you can check 
the code in `parseFixed`, near `parseJson`).
The reason behind the discrepancy between fixed and json compilation databases 
mostly arises from the fact that the former is written by people specifically 
to be used by clang-tooling, whereas the latter is usually provided by build 
system and doesn't necessarily have the same concerns as clang-tooling hence 
requires certain modifications.

That being said, the two particular transformations (response files & 
target/mode inference) seem like outliers when it comes to such 
transformations. These are handled by clang-driver binary, outside of the 
driver library, in 
https://github.com/llvm/llvm-project/blob/main/clang/tools/driver/driver.cpp#L426
 and 
https://github.com/llvm/llvm-project/blob/main/clang/tools/driver/driver.cpp#L534.
 Therefore all the other tools that wants to make use of clang infra tries to 
simulate this logic, at different layers with slight differences (at the bare 
minimum, as the logic isn't shared and people mostly care about the driver, 
logic in other places just gets out-of-date).
I believe the right thing to do here is putting all that arg preparation logic 
into driver library itself, so that all code paths that tries to create a 
compiler invocation can have the same behaviour. Unfortunately this is likely 
too hard to pull at this stage, due to people relying on almost every 
implementation detail of these interfaces.
So a middle ground would probably involve, moving that logic inside driver 
binary to a common library, so that future users can at least directly use it 
rather than trying to come up with their own interpretation (or trying to chose 
from existing N patterns) and we'll get rid of the issues that result from 
logic in this place and its duplicates getting out-of-sync. This way we don't 
need to migrate all the applications that want to create a compiler invocation 
to a new API and can only migrate clangd (CommandMangler is I believe the right 
layer for these purposes. as it handles all "string"-like modifications on the 
compile flags today).

Does that make sense? Is it something you'd like to propose a patch for? 
Because as things stand I think we're just making the matter worse here by 
introducing some new code paths that're trying to emulate the logic in driver 
today and will get out of sync at some point.




Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:1350
+->getCompileCommands(File)[0]);
 if (Old != New) {
   CDB->setCompileCommand(File, std::move(New));

it looks like this comparison is no longer valid.

`OverlayCDB::getCompileCommand` will apply more modifications to the stored 
flags than just expanding response files and inferring targets. I believe the 
intent of this interaction was to treat compile flags from the LSP client as-is 
without any modifications (as I explained more in my main comment).

No action needed right now, just thinking out-loud. I think the proper thing to 
do here is apply these "common driver transformations" here, and store/use the 
flags as is going forward inside clangd, without extra mangling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143436

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


[PATCH] D143640: [Tooling/Inclusion] Support overload symbols in the stdlib.

2023-02-13 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

Thanks for the comment, putting more thoughts.

In D143640#4121998 , @kadircet wrote:

> All this complexity for handling only 4 symbols feels wrong. is this the 
> whole set? are there any other symbols that fall under this class? can we 
> disambiguate all of them solely based on number of parameters?

No, these 4 symbols is not the whole set, there are other symbols (e.g. 
`isspace` from ``, or ``), but these are not important, IMO.

The number of parameters is the most critical information to disambiguate -- 
there are some exceptions, e.g. `std::get()` has a few 1-parameter overloads 
for array, vector, etc. We will add more information in the `SymbolName` 
structure for disambiguation in the future.

> Downsides:
>
> - We are relying heavily on number of parameters in certain cases now

Yeah, I think this is expected if we want to do disambiguations.

> - We only have that information available for symbols with variants

My intention of this information is internal, and merely used for 
disambiguation. And we're not exposing them to public APIs.

> - We're creating a discrepancy in Symbol::all() vs Symbol::named() views of 
> the world

Oh, this is not intended, we can remove this discrepancy, and make 
`Symbol::all()` and `Symbol::named()` aligned.

> - In addition to generator and hand curated list, now there's a 3rd place to 
> augment symbol mapping

Right, this bit is untweaked in this current patch (there is a FIXME), we can 
merge it with the hand-curated list.

> This complexity both in terms of mental load when introducing new symbols, 
> and also possible discrepancies that can be encountered when using the public 
> APIs makes me question if we're doing the sensible thing that'll generalize 
> for the future variant symbols, or just trying to patch up a solution for 
> couple cases we know to be not working.
> I'd suggest:
> 1- doing a little bit more design work here and at least getting rid of the 
> burden on the public APIs and a way to introduce these symbols through hand 
> curated lists (e.g. we should be returning all alternatives in Symbol::named, 
> with enough details for the caller to have a chance to disambiguate and have 
> maybe new syntax in raw symbol map files to indicate this variant situation).

OK, looks like we have some different ideas on the design here. I'm not sure 
returning all alternatives in `Symbol::named` and exposing all information for 
disambiguation is a good idea (I'm also not sure it is an important usecase). 
This seems complicating the public APIs too much.

My original design is

- full disambiguation is *only* performed in the `Recognizer` API where the 
input is the AST node
- other qualified-name-based APIs `Symbol::named` remains the same (or best 
effort returning the symbol with most common header)

I share your concern about the current approach, it is not perfect, but I think 
this is moving towards a right direction, the tradeoff seems OK to me (rather 
than putting the special-case handling to *every* application, we isolate it in 
one place).

> 2- or handling this in include-cleaner only, similar to how we do it in 
> clangd and other applications, until we encounter more problematic symbols. 
> as handling this in the general case seems hard (especially in the absence of 
> an AST), and we haven't seen enough signals for symbols other than 
> `std::move` to cause trouble.
>
> i feel like 2nd alternative gets us a long way with minimal effort. WDYT?

The 2nd alternative definitely sounds good to me. Before we settle down the 
design, I will prepare a patch to special-case these symbols in include-cleaner.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143640

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via Phabricator via cfe-commits
zyounan updated this revision to Diff 496934.
zyounan added a comment.

Rebase to main && Move tests to clang/Tooling


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
  clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
  clang/unittests/Tooling/StandardLibraryTest.cpp

Index: clang/unittests/Tooling/StandardLibraryTest.cpp
===
--- clang/unittests/Tooling/StandardLibraryTest.cpp
+++ clang/unittests/Tooling/StandardLibraryTest.cpp
@@ -79,6 +79,41 @@
   EXPECT_FALSE(stdlib::Header::named("", stdlib::Lang::CXX));
 }
 
+TEST(StdlibTest, Experimental) {
+  EXPECT_TRUE(
+  stdlib::Header::named("", stdlib::Lang::CXX));
+
+  auto Symbol =
+  stdlib::Symbol::named("std::experimental::filesystem::", "path");
+  EXPECT_TRUE(Symbol);
+  EXPECT_EQ(Symbol->scope(), "std::experimental::filesystem::");
+  EXPECT_EQ(Symbol->name(), "path");
+  EXPECT_EQ(Symbol->qualifiedName(), "std::experimental::filesystem::path");
+
+  // system_complete is replaced by std::filesystem::absolute
+  Symbol = stdlib::Symbol::named("std::filesystem::", "system_complete");
+  EXPECT_FALSE(Symbol);
+  Symbol = stdlib::Symbol::named("std::experimental::filesystem::",
+ "system_complete");
+  EXPECT_TRUE(Symbol);
+  EXPECT_EQ(Symbol->scope(), "std::experimental::filesystem::");
+  EXPECT_EQ(Symbol->name(), "system_complete");
+  EXPECT_EQ(Symbol->qualifiedName(),
+"std::experimental::filesystem::system_complete");
+
+  // relative-path-related operation is introduced by P0219
+  Symbol = stdlib::Symbol::named("std::filesystem::", "relative");
+  EXPECT_TRUE(Symbol);
+  Symbol = stdlib::Symbol::named("std::experimental::filesystem::", "relative");
+  EXPECT_FALSE(Symbol);
+  Symbol =
+  stdlib::Symbol::named("std::experimental::filesystem::", "proximate");
+  EXPECT_FALSE(Symbol);
+  Symbol = stdlib::Symbol::named("std::experimental::filesystem::",
+ "weakly_canonical");
+  EXPECT_FALSE(Symbol);
+}
+
 TEST(StdlibTest, CCompat) {
   EXPECT_THAT(
   stdlib::Symbol::named("", "int16_t", stdlib::Lang::CXX)->headers(),
Index: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
===
--- /dev/null
+++ clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
@@ -0,0 +1,57 @@
+// These symbols are exported from N4100[fs.filesystem.synopsis], the final
+// draft for experimental filesystem. Note that not all of these symbols were
+// merged into C++17 (See P0492 and related proposals for details). But the
+// cornerstone for mainstream Stdlib TS filesystem implementation is N4100,
+// whatever.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )
+SYMBOL(canonical, std::experimental::filesystem::, )
+SYMBOL(copy, std::experimental::filesystem::, )
+SYMBOL(copy_file, std::experimental::filesystem::, )
+SYMBOL(copy_options, std::experimental::filesystem::, )
+SYMBOL(copy_symlink, std::experimental::filesystem::, )
+SYMBOL(create_directories, std::experimental::filesystem::, )
+SYMBOL(create_directory, std::experimental::filesystem::, )
+SYMBOL(create_directory_symlink, std::experimental::filesystem::, )
+SYMBOL(create_hard_link, std::experimental::filesystem::, )
+SYMBOL(create_symlink, std::experimental::filesystem::, )
+SYMBOL(current_path, std::experimental::filesystem::, )
+SYMBOL(directory_entry, std::experimental::filesystem::, )
+SYMBOL(directory_iterator, std::experimental::filesystem::, )
+SYMBOL(directory_options, std::experimental::filesystem::, )
+SYMBOL(equivalent, std::experimental::filesystem::, )
+SYMBOL(exists, std::experimental::filesystem::, )
+SYMBOL(file_size, std::experimental::filesystem::, )
+SYMBOL(file_status, std::experimental::filesystem::, )
+SYMBOL(file_time_type, std::experimental::filesystem::, )
+SYMBOL(file_type, std::experimental::filesystem::, )
+SYMBOL(filesystem_error, std::experimental::filesystem::, )
+SYMBOL(hard_link_count, std::experimental::filesystem::, )
+SYMBOL(is_block_file, std::experimental::filesystem::, )
+SYMBOL(is_character_file, std::experimental::filesystem::, )
+SYMBOL(is_directory, std::experimental::filesystem::, )
+SYMBOL(is_empty, std::experimental::filesystem::, )
+SYMBOL(is_fifo, std::experimental::filesystem::, )
+SYMBOL(is_other, std::experimental::filesystem::, )
+SYMBOL(is_regular_file, std::experimental::filesystem::, )
+SYMBOL(is_socket, std::experimental::filesystem::, )
+SYMBOL(is_symlink, std::experimental::filesystem::, )
+SYMBOL(last_write_time, std::experimental::filesystem::, )
+SYMBOL(path, std::experimental::filesystem::, )
+SYMBOL(permissions, std::experimental::filesystem::, )
+SYMBOL(perms, std::experimental::filesystem::, )
+SYMBOL(read_symlink, std::experimental::filesystem::, )

[PATCH] D143640: [Tooling/Inclusion] Support overload symbols in the stdlib.

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

In D143640#4122603 , @hokein wrote:

> Thanks for the comment, putting more thoughts.
>
> In D143640#4121998 , @kadircet 
> wrote:
>
>> All this complexity for handling only 4 symbols feels wrong. is this the 
>> whole set? are there any other symbols that fall under this class? can we 
>> disambiguate all of them solely based on number of parameters?
>
> No, these 4 symbols is not the whole set, there are other symbols (e.g. 
> `isspace` from ``, or ``), but these are not important, IMO.

I agree them being not important. But I think having such a complex 
infrastructure for just 4 symbols and making it more complex in the future when 
we want to handle these just sounds like a big negative.

> The number of parameters is the most critical information to disambiguate -- 
> there are some exceptions, e.g. `std::get()` has a few 1-parameter overloads 
> for array, vector, etc. We will add more information in the `SymbolName` 
> structure for disambiguation in the future.

Makes sense. but maybe there's a way that involves not relying on parameter 
count at all and something completely different. that's another reason why I 
was asking for other symbols that are causing problems today.

>> Downsides:
>>
>> - We are relying heavily on number of parameters in certain cases now
>
> Yeah, I think this is expected if we want to do disambiguations.
>
>> - We only have that information available for symbols with variants
>
> My intention of this information is internal, and merely used for 
> disambiguation. And we're not exposing them to public APIs.

I can see that purpose, but having those symbols available internally without 
any way for users to poke at them sounds like a shortcoming of the design 
that'll never address. Hence I was trying to avoid that.

>> - We're creating a discrepancy in Symbol::all() vs Symbol::named() views of 
>> the world
>
> Oh, this is not intended, we can remove this discrepancy, and make 
> `Symbol::all()` and `Symbol::named()` aligned.

I don't think removing that discrepancy by also dropping these symbols from 
::all is the right trade-off though. As they're still available as a `Symbol` 
through Recognizer. I think the more appropriate thing would require us to 
change `::named` to return multiple symbols, with enough details for 
disambiguation if needed.

>> - In addition to generator and hand curated list, now there's a 3rd place to 
>> augment symbol mapping
>
> Right, this bit is untweaked in this current patch (there is a FIXME), we can 
> merge it with the hand-curated list.
>
>> This complexity both in terms of mental load when introducing new symbols, 
>> and also possible discrepancies that can be encountered when using the 
>> public APIs makes me question if we're doing the sensible thing that'll 
>> generalize for the future variant symbols, or just trying to patch up a 
>> solution for couple cases we know to be not working.
>> I'd suggest:
>> 1- doing a little bit more design work here and at least getting rid of the 
>> burden on the public APIs and a way to introduce these symbols through hand 
>> curated lists (e.g. we should be returning all alternatives in 
>> Symbol::named, with enough details for the caller to have a chance to 
>> disambiguate and have maybe new syntax in raw symbol map files to indicate 
>> this variant situation).
>
> OK, looks like we have some different ideas on the design here. I'm not sure 
> returning all alternatives in `Symbol::named` and exposing all information 
> for disambiguation is a good idea (I'm also not sure it is an important 
> usecase). This seems complicating the public APIs too much.

I think we agree on them being not important so far. But I don't see why having 
a discrepancy between `Symbol`s received through `Recognizer` and 
`Symbol::named` is preferred instead of having a unified view between the two 
(which we already have right now, by excluding variants from both).
I was suggesting preserving this invariant because it's easier to reason about 
the library when we only have a single view rather than 2. Could you elaborate 
a little on why you think "exposing all information for disambiguation" is not 
a good idea? The public interfaces stays ~the same. We'll be having these extra 
information in `Symbol`, if we can find a meaningful set.

> My original design is
>
> - full disambiguation is *only* performed in the `Recognizer` API where the 
> input is the AST node
> - other qualified-name-based APIs `Symbol::named` remains the same (or best 
> effort returning the symbol with most common header)
>
> I share your concern about the current approach, it is not perfect, but I 
> think this is moving towards a right direction, the tradeoff seems OK to me 
> (rather than putting the special-case handling to *every* application, we 
> isolate it in one place).

I agree that sharing this logic with applicat

[PATCH] D128440: [WebAssembly] Initial support for reference type funcref in clang

2023-02-13 Thread Paulo Matos via Phabricator via cfe-commits
pmatos marked 6 inline comments as done.
pmatos added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:6552-6555
+  // The call we get looks like
+  // CallExpr
+  // `- ImplicitCastExpr
+  //   `- DeclRefExpr

tlively wrote:
> How do these parts correspond to the original source code?
If I understand your question correctly, this is just the semantic checks for 
each of the builtins.



Comment at: clang/lib/Sema/SemaChecking.cpp:6564
+  // Prepare FDecl type
+  QualType Pointee = Context.getFunctionType(Context.VoidTy, {}, {});
+  QualType Type = Context.getPointerType(Pointee);

aaron.ballman wrote:
> Why are you guaranteed this function returns void?
I think this question is not relevant anymore given the current code, right? 
The wasm ref null builtin will always return the null funcref.



Comment at: clang/lib/Sema/SemaChecking.cpp:6704-6710
+  // Therefore we need to change the types of the DeclRefExpr (stored in FDecl)
+  // and regenerate a straight up CallExpr on the modified FDecl.
+  // returning
+  // CallExpr
+  // `- FunctionDecl
+
+  // Prepare FDecl type

aaron.ballman wrote:
> These comments no longer seem to match the code -- nothing creates a 
> `FunctionDecl` here.
Right - fixed.



Comment at: clang/lib/Sema/SemaChecking.cpp:6708
+  // CallExpr
+  // `- FunctionDecl
+

erichkeane wrote:
> All those comments don't really seem relevant here, and are not really 
> correct.  The only thing SemaChecking should do is either modify its 
> arguments (though you don't have any), or set its return type.  
Right, these comments can be removed. I fixed these.



Comment at: clang/lib/Sema/SemaType.cpp:7340
+  attr::Kind NewAttrKind = A->getKind();
+  QualType Desugared = Type;
+  const auto *AT = dyn_cast(Type);

erichkeane wrote:
> This name seems misleading... should you be desugaring 'Type' to store it in 
> 'Desugared'?
> 
> Also, I see that this value is never used, so why do the copy init?  ALSO, 
> why is it called Desugared, when it never seems to get a Desugared type?  
Bad naming due to earlier code. I have simplified this code now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128440

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


[PATCH] D128440: [WebAssembly] Initial support for reference type funcref in clang

2023-02-13 Thread Paulo Matos via Phabricator via cfe-commits
pmatos updated this revision to Diff 496937.
pmatos marked 5 inline comments as done.
pmatos added a comment.

Addressed a few comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128440

Files:
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/DirectX.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/WebAssembly.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/lib/Format/FormatToken.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseTentative.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/WebAssembly/wasm-funcref.c
  clang/test/Parser/wasm-funcref.c
  clang/test/SemaTemplate/address_space-dependent.cpp

Index: clang/test/SemaTemplate/address_space-dependent.cpp
===
--- clang/test/SemaTemplate/address_space-dependent.cpp
+++ clang/test/SemaTemplate/address_space-dependent.cpp
@@ -43,7 +43,7 @@
 
 template 
 void tooBig() {
-  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388587)}}
+  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388586)}}
 }
 
 template 
@@ -101,7 +101,7 @@
   car<1, 2, 3>(); // expected-note {{in instantiation of function template specialization 'car<1, 2, 3>' requested here}}
   HasASTemplateFields<1> HASTF;
   neg<-1>(); // expected-note {{in instantiation of function template specialization 'neg<-1>' requested here}}
-  correct<0x7FFFEA>();
+  correct<0x7FFFE9>();
   tooBig<8388650>(); // expected-note {{in instantiation of function template specialization 'tooBig<8388650L>' requested here}}
 
   __attribute__((address_space(1))) char *x;
Index: clang/test/Parser/wasm-funcref.c
===
--- /dev/null
+++ clang/test/Parser/wasm-funcref.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple powerpc-linux-gnu -fsyntax-only -verify %s
+
+// Test that we trigger an error at parse time if using keyword funcref
+// while not using a wasm triple.
+typedef void (*__funcref funcref_t)(); // expected-error {{invalid use of __funcref keyword outside the WebAssembly triple}}
+typedef int (*__funcref fn_funcref_t)(int);// expected-error {{invalid use of __funcref keyword outside the WebAssembly triple}}
+typedef int (*fn_t)(int);
+
+static fn_funcref_t nullFuncref = 0;
Index: clang/test/CodeGen/WebAssembly/wasm-funcref.c
===
--- /dev/null
+++ clang/test/CodeGen/WebAssembly/wasm-funcref.c
@@ -0,0 +1,84 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple wasm32 -target-feature +reference-types -o - -emit-llvm %s | FileCheck %s
+
+typedef void (*__funcref funcref_t)();
+typedef int (*__funcref fn_funcref_t)(int);
+typedef int (*fn_t)(int);
+
+// Null funcref builtin call
+// CHECK-LABEL: @get_null(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = call ptr addrspace(20) @llvm.wasm.ref.null.func()
+// CHECK-NEXT:ret ptr addrspace(20) [[TMP0]]
+//
+funcref_t get_null() {
+  return __builtin_wasm_ref_null_func();
+}
+
+// Call to null funcref builtin but requires cast since
+// default return value for builtin is a funcref with function type () -> ().
+// CHECK-LABEL: @get_null_ii(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = call ptr addrspace(20) @llvm.wasm.ref.null.func()
+// CHECK-NEXT:ret ptr addrspace(20) [[TMP0]]
+//
+fn_funcref_t get_null_ii() {
+  return (fn_funcref_t) __builtin_wasm_ref_null_func();
+}
+
+// Identity function for funcref.
+// CHECK-LABEL: @identity(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[FN_ADDR:%.*]] = alloca ptr addrspace(20), align 4
+// CHECK-NEXT:store ptr addrspace(20) [[FN:%.*]], ptr [[FN_ADDR]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load ptr addrspace(20), ptr [[FN_ADDR]], align 4
+// CHECK-NEXT:ret ptr addrspace(20) [[TMP0]]
+//
+funcref_t identity(funcref_t fn) {
+  return fn;
+}
+
+void helper(funcref_t);
+
+// Pass funcref ref as an argument to a helper function.
+// CHECK-LABEL: @handle(
+// CHECK-NEXT:  entry:
+

[PATCH] D141950: Use find_last_of when seraching for code in getRawCommentForDeclNoCacheImpl

2023-02-13 Thread Kugan Vivekanandarajah via Phabricator via cfe-commits
kuganv updated this revision to Diff 496936.
kuganv added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141950

Files:
  clang/lib/AST/ASTContext.cpp


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -349,7 +349,7 @@
 
   // There should be no other declarations or preprocessor directives between
   // comment and declaration.
-  if (Text.find_first_of(";{}#@") != StringRef::npos)
+  if (Text.find_last_of(";{}#@") != StringRef::npos)
 return nullptr;
 
   return CommentBeforeDecl;


Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -349,7 +349,7 @@
 
   // There should be no other declarations or preprocessor directives between
   // comment and declaration.
-  if (Text.find_first_of(";{}#@") != StringRef::npos)
+  if (Text.find_last_of(";{}#@") != StringRef::npos)
 return nullptr;
 
   return CommentBeforeDecl;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D142578: [Clang][Doc] Edit the Clang release notes

2023-02-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM, thank you for this, the new layout is a big improvement!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142578

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

thanks a lot! mostly LG couple more nits




Comment at: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc:1
+// These symbols are exported from N4100[fs.filesystem.synopsis], the final
+// draft for experimental filesystem. Note that not all of these symbols were

i think comment is a little too verbose. can you just say:
```
These are derived from N4100[fs.filesystem.synopsis], final draft for 
experimental filesystem.
```

There's no need for mentioning that these became the standard in C++17 or being 
a cornerstone for stdlib implementations. As they won't necessarily be true for 
other technical specs nor if we were adding this pre-c++17 standardisation. But 
we'd still like to have these widely adapted symbols included in the mapping to 
make sure we're not generating false negatives.



Comment at: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc:6
+// whatever.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )

can you strip clang-format pragmas to be similar to other mapping files.



Comment at: clang/unittests/Tooling/StandardLibraryTest.cpp:83
+TEST(StdlibTest, Experimental) {
+  EXPECT_TRUE(
+  stdlib::Header::named("", stdlib::Lang::CXX));

another EXPECT_FALSE with `Lang::C` would also be important to make sure we're 
not adding these for C mappings by mistake.



Comment at: clang/unittests/Tooling/StandardLibraryTest.cpp:91
+  EXPECT_EQ(Symbol->name(), "path");
+  EXPECT_EQ(Symbol->qualifiedName(), "std::experimental::filesystem::path");
+

can you also check for `Symbol->headers()`



Comment at: clang/unittests/Tooling/StandardLibraryTest.cpp:93
+
+  // system_complete is replaced by std::filesystem::absolute
+  Symbol = stdlib::Symbol::named("std::filesystem::", "system_complete");

i don't think there's much point in asserting these "meta" details about the 
mapping (same for the test below).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

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


[PATCH] D143891: [Clang] Adjust triviality computation in QualType::isTrivialType to C++20 cases.

2023-02-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

This is an ABI breaking change, isn't it? (The type trait now returns something 
different than it did before, which could change instantiations or object 
layout.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143891

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


[PATCH] D143781: [Clang][LLVM] Enable __arithmetic_fence and fprotect-parens on AArch64

2023-02-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM, though you should add a release note for the changes. The precommit CI 
failures appear to be unrelated to the changes in this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143781

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


[PATCH] D143891: [Clang] Adjust triviality computation in QualType::isTrivialType to C++20 cases.

2023-02-13 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson added a comment.

In D143891#4122660 , @aaron.ballman 
wrote:

> This is an ABI breaking change, isn't it? (The type trait now returns 
> something different than it did before, which could change instantiations or 
> object layout.)

Technically it is, but it only affects code that relies on constrained default 
constructors, which we're only going to support in Clang 16. So if we backport 
this to 16 it's not very problematic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143891

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


[PATCH] D143906: [include-cleaner] Better support ambiguous std symbols

2023-02-13 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added a reviewer: kadircet.
Herald added a project: All.
hokein requested review of this revision.
Herald added a project: clang-tools-extra.

By special-casing them at the moment. The tooling stdlib lib doesn't
support these symbols (most important one is std::move).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143906

Files:
  clang-tools-extra/include-cleaner/lib/FindHeaders.cpp
  clang-tools-extra/include-cleaner/unittests/FindHeadersTest.cpp

Index: clang-tools-extra/include-cleaner/unittests/FindHeadersTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/FindHeadersTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/FindHeadersTest.cpp
@@ -278,25 +278,31 @@
 
 class HeadersForSymbolTest : public FindHeadersTest {
 protected:
-  llvm::SmallVector headersForFoo() {
+  llvm::SmallVector headersFor(llvm::StringRef Name) {
 struct Visitor : public RecursiveASTVisitor {
   const NamedDecl *Out = nullptr;
+  llvm::StringRef Name;
+  Visitor(llvm::StringRef Name) : Name(Name) {}
   bool VisitNamedDecl(const NamedDecl *ND) {
-if (ND->getName() == "foo") {
+if (auto *TD = ND->getDescribedTemplate())
+  ND = TD;
+
+if (ND->getName() == Name) {
   EXPECT_TRUE(Out == nullptr || Out == ND->getCanonicalDecl())
-  << "Found multiple matches for foo.";
+  << "Found multiple matches for " << Name << ".";
   Out = cast(ND->getCanonicalDecl());
 }
 return true;
   }
 };
-Visitor V;
+Visitor V(Name);
 V.TraverseDecl(AST->context().getTranslationUnitDecl());
 if (!V.Out)
-  ADD_FAILURE() << "Couldn't find any decls named foo.";
+  ADD_FAILURE() << "Couldn't find any decls named " << Name << ".";
 assert(V.Out);
 return headersForSymbol(*V.Out, AST->sourceManager(), &PI);
   }
+  llvm::SmallVector headersForFoo() { return headersFor("foo"); }
 };
 
 TEST_F(HeadersForSymbolTest, Deduplicates) {
@@ -430,5 +436,54 @@
   EXPECT_THAT(headersForFoo(), ElementsAre(Header(StringRef("\"public.h\"")),
physicalHeader("foo.h")));
 }
+
+TEST_F(HeadersForSymbolTest, AmbiguousStdSymbols) {
+  struct {
+llvm::StringRef Code;
+llvm::StringRef Name;
+
+llvm::StringRef ExpectedHeader;
+  } TestCases[] = {
+  {
+  R"cpp(
+namespace std {
+ template 
+ constexpr OutputIt move(InputIt first, InputIt last, OutputIt dest);
+})cpp",
+  "move",
+  "",
+  },
+  {
+  R"cpp(
+namespace std {
+  template constexpr T move(T&& t) noexcept;
+})cpp",
+  "move",
+  "",
+  },
+  {
+  R"cpp(
+namespace std {
+  template
+  ForwardIt remove(ForwardIt first, ForwardIt last, const T& value);
+})cpp",
+  "remove",
+  "",
+  },
+  {
+  "namespace std { int remove(const char*); }",
+  "remove",
+  "",
+  },
+  };
+
+  for (const auto &T : TestCases) {
+Inputs.Code = T.Code;
+buildAST();
+EXPECT_THAT(headersFor(T.Name),
+UnorderedElementsAre(Header(T.ExpectedHeader)));
+  }
+}
+
 } // namespace
 } // namespace clang::include_cleaner
Index: clang-tools-extra/include-cleaner/lib/FindHeaders.cpp
===
--- clang-tools-extra/include-cleaner/lib/FindHeaders.cpp
+++ clang-tools-extra/include-cleaner/lib/FindHeaders.cpp
@@ -82,6 +82,36 @@
   llvm_unreachable("unhandled Symbol kind!");
 }
 
+// Special-case the ambiguous standard library symbols (e.g. std::move) which
+// are not supported by the tooling stdlib lib.
+llvm::SmallVector specialStandardSymbols(const Symbol &S) {
+  if (S.kind() != Symbol::Declaration || !S.declaration().isInStdNamespace())
+return {};
+
+  const auto *FD = S.declaration().getAsFunction();
+  if (!FD)
+return {};
+
+  llvm::StringRef FName = FD->getName();
+  if (FName == "move") {
+if (FD->getNumParams() == 1)
+  // move(T&& t)
+  return {Header("")};
+if (FD->getNumParams() == 3)
+  // move(InputIt first, InputIt last, OutputIt dest);
+  return {Header("")};
+  }
+  if (FName == "remove") {
+if (FD->getNumParams() == 1)
+  // remove(const char*);
+  return {Header("")};
+if (FD->getNumParams() == 3)
+  // remove(ForwardIt first, ForwardIt last, const T& value);
+  return {Header("")};
+  }
+  return {};
+}
+
 } // namespace
 
 llvm::SmallVector> findHeaders(const SymbolLocation &Loc,
@@ -141,6 +171,9 @@
 llvm::SmallVector headersForSymbol(const Symbol &S,
const SourceManager &SM,
const PragmaIncludes *PI) {
+  if (auto Header

[PATCH] D143891: [Clang] Adjust triviality computation in QualType::isTrivialType to C++20 cases.

2023-02-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D143891#4122668 , @royjacobson 
wrote:

> In D143891#4122660 , @aaron.ballman 
> wrote:
>
>> This is an ABI breaking change, isn't it? (The type trait now returns 
>> something different than it did before, which could change instantiations or 
>> object layout.)
>
> Technically it is, but it only affects code that relies on constrained 
> default constructors, which we're only going to support in Clang 16. So if we 
> backport this to 16 it's not very problematic.

Hmmm, if it's true that this only changes the behavior of a type with a 
constrained default constructor, then I think it's fine despite being an ABI 
break (we never claimed full support for concepts, so anyone relying on a 
particular behavior was mistaken to do that). I can't quite convince myself 
this doesn't impact other cases though -- the logic for computing triviality is 
nontrivial itself (pun intended), so I'm really only concerned that 
`__is_trivial` and friends return a different value for a non-constrained type. 
However, I also can't come up with a test case whose behavior changes either.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143891

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via Phabricator via cfe-commits
zyounan added inline comments.



Comment at: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc:6
+// whatever.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )

kadircet wrote:
> can you strip clang-format pragmas to be similar to other mapping files.
I'd love to if possible, but for some reason clang-format would add extra 
spaces before and after the slash, ``, which looks 
ugly and I don't expect it right.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

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


[PATCH] D143112: [clang] Support parsing comments without ASTContext

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

Thanks, this looks like a good start. I left some comments about the details of 
implementation, as for placing and APIs in general, i think it's useful to see 
how things will be built on top inside clangd to make the right call here.




Comment at: clang/include/clang/AST/RawCommentList.h:159
+  /// Parse the \p Comment, storing the result in \p Allocator
+  static comments::FullComment *parse(llvm::StringRef Comment,
+  llvm::BumpPtrAllocator &Allocator,

tom-anders wrote:
> Not sure if this is the right place for this? Could be moved to `FullComment` 
> or made a free function instead?
i think this would make more sense inside clangd as a free function when we're 
processing comments. it's nice to get to re-use some Lexer/Sema/Parser creation 
logic, but i don't think it's big enough to justify a new public interfaces 
that's solely used by clangd.
if we can figure out more patterns that we can migrate (the unittest in this 
patch is a good example, but still just a unittest and doesn't benefit much 
from code reuse) we can consider lifting this logic up to a common place. the 
other users should hopefully make it easier to decide where this code should 
live.



Comment at: clang/lib/AST/RawCommentList.cpp:227
+  
SourceMgr.getLocForStartOfFile(SourceMgr.getMainFileID()),
+  Allocator, SourceMgr.getDiagnostics(), Traits);
+}

tom-anders wrote:
> I wasn't sure if it's worth making the `Diagnostics` parameter optional here 
> - Our `SourceMgr` already has it anyway, does it impact performance 
> significantly to use it, even though we don't need it (yet)?
as things stand, Lexer, Sema and Parser expect a non-null diagnosticsengine so 
we have to pass something (i guess that's what you meant by making it optional).

the performance implications comes from two places:
1- extra analysis being performed in the face of malformed comments to produce 
"useful" diagnostics
2- creation cost of diagnostic itself, as all the data about ranges, decls etc. 
are copied around when constructing a diagnostic.

i don't know how costly the first action is today, it's unfortunately the case 
that would require a lot of code changes, if it's happening quite often in 
practice (especially when we're in codebases without proper doxygen comments)
the latter is somewhat easier to address by providing our own "mock" 
diagnostics engine, that'll just drop all of these extra diagnostic data on the 
floor instead of copying around.

i think taking a look at the codebase for the first (searching for `Diag(...) 
<<` patterns in Comment{Lexer,Sema,Parser}.cpp should give some ideas) and 
assessing whether we're performing any extra complicated analysis would be a 
good start. i would expect us not to, and if that's the case i think we can 
leave it at that and don't try to make code changes.
the latter we can address easily and we should.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143112

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc:6
+// whatever.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )

zyounan wrote:
> kadircet wrote:
> > can you strip clang-format pragmas to be similar to other mapping files.
> I'd love to if possible, but for some reason clang-format would add extra 
> spaces before and after the slash, ``, which looks 
> ugly and I don't expect it right.
i don't follow, why do you **need** to run clang-format on this file? symbols 
are already ordered


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

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


[PATCH] D143632: [clang] Handle __declspec() attributes in using

2023-02-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM aside from some minor nits that you can fix when landing, thank you for 
the fix!




Comment at: clang/docs/ReleaseNotes.rst:112-114
+__declspec attributes can now be used together with the using keyword. Before
+the attributes on __declspec was ignored, while now it will be forwarded to the
+point where the alias is used.





Comment at: clang/lib/Parse/ParseDecl.cpp:60-61
+  // Move declspec attributes to ParsedAttributes
+  if (Attrs)
+  {
+llvm::SmallVector ToBeMoved;

Formatting is off here.



Comment at: clang/lib/Parse/ParseDecl.cpp:61-63
+  for (ParsedAttr &AL : DS.getAttributes())
+if (AL.isDeclspecAttribute())
+  ToBeMoved.push_back(&AL);

thieta wrote:
> aaron.ballman wrote:
> > How about using an algorithm for this (would need to be reformatted for 80 
> > col)?
> I spent a while on trying to figure this out. I am not that great with the 
> algorithms in the standard library since we don't really use that at work. 
> But from my testing I couldn't get it to work:
> 
> - DS.getAttributes() returns a `ParsedAttr&`, but ToBeMoved needs a pointer 
> to ParsedAttr. So your example code above fails because it can't convert 
> ParsedAttr& to ParsedAttr* in the back_inserter()
> - I tried to change ToBeMoved to be a list of references instead, but 
> ParsedAttr disallows copying (I think, the error message was a bit confusing).
> - I could do transform() to a list of pointers and then copy_if() but that 
> seemed to really make it harder to understand.
> - A transform_if() would solve the problem or I guess replace back_inserter() 
> with some out iterator that could transform. But I couldn't find anything 
> used like this browsing the LLVM source code.
> 
> So yeah - I might totally be missing something obvious here, feel free to 
> point it out.
> So yeah - I might totally be missing something obvious here, feel free to 
> point it out.

Thank you for trying it out, I'd say let's leave it as-is (but fix the 
formatting issues).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143632

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


[PATCH] D143418: [libclang] Add API to set preferred temp dir path

2023-02-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D143418#4120058 , @vedgy wrote:

> In D143418#4118905 , @aaron.ballman 
> wrote:
>
>> I don't think "tries hard" is a good enough guarantee for where files are 
>> placed. I'm not comfortable with the security posture of that approach as it 
>> could potentially leak sensitive information (try to override the temp 
>> directory to something that's chroot jailed, get sensitive files showing up 
>> in the system temp directory anyway).
>
> That's why the function's documentation explicitly doesn't guarantee 
> anything. It should be safe to assume that security-sensitive users would at 
> least read the documentation. If this function and potential future function 
> like it are named specifically, a responsible security use case wouldn't be 
> better off. The only safety advantage would be to those who don't bother 
> reading the documentation. But why should we care much about such 
> hypothetical careless security needs?

Security isn't a one-shot thing, but something you want in-depth defense for. 
Telling users "well you were careless about security so this is your fault" is 
still user-hostile even if you can point to documentation they should have 
read. (A whole lot of people use APIs without reading the documentation, 
unfortunately.)

>>> Does the multithreading issue mean that `clang_parseTranslationUnit_Impl()` 
>>> can be called in a non-main thread and thus concurrently with 
>>> `clang_CXIndex_setPreferredTempDirPath()`?
>>
>> Yes. However, I don't think that situation is officially supported (it's 
>> more that we don't want to knowingly make it harder to support in the 
>> future).
>
> All right. Let's do it via a new constructor then. Unfortunately, supporting 
> different `CXIndexOptions` struct sizes/versions would complicate the 
> libclang implementation and the libclang user code. But the alternative of 
> adding a new constructor function each time can either grow to a large number 
> of function parameters unneeded by most users or to an exponential number of 
> overloads that support different usage requirements.
>
> How about including existing options, which //should// be set in constructor, 
> in the initial struct version and deprecating the corresponding setters?

I think that makes a lot of sense.

>   typedef struct CXIndexOptions {
> uint32_t size; // sizeof(struct CIndexOptions), used for option versioning
> unsigned globalOptions;
> const char *preferredTempDirPath;

In terms of documenting the structure, should we document this member as only 
impacting preamble files currently, should we rename this to be preamble-path 
specific, or should we try to use this preferred path in all the places we need 
the temp directory?

(I lean towards renaming to preamble-path specific -- then users don't have the 
problem of upgrading to a newer CIndex potentially changing the behavior of 
where non-preamble files are stored, and we don't have to do the work up-front 
to audit other temp file uses.)

>   const char *invocationEmissionPath;
>
> } CXIndexOptions;
>
>   The naming of struct data members is inconsistent in libclang's Index.h. 
> They start with a lower-case letter in about half of the structs. Which 
> naming scheme should the members of the new struct use?

Wow, it's almost an even split between styles from what I'm seeing, that's 
lovely. Let's go with the LLVM coding style recommendation because there's not 
a clear "winner" used in the same file. (So start with an uppercase letter 
instead of lower case.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143418

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


[clang] 877859a - [clang] Handle __declspec() attributes in using

2023-02-13 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2023-02-13T15:43:08+01:00
New Revision: 877859a09bda29fe9a7f1a9016b06cf80661a032

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

LOG: [clang] Handle __declspec() attributes in using

This patch fixes so that declspec attributes are forwarded
to the alias declaration.

Before this patch this would assert:

class Test { int a; };
using AlignedTest = __declspec(align(16)) const Test;
static_assert(alignof(AlignedTest) == 16, "error");

But afterwards it behaves the same as MSVC does and doesn't
assert.

Fixes: llvm/llvm-project#60513

Reviewed By: aaron.ballman

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

Added: 
clang/test/SemaCXX/using-declspec.cpp

Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Parse/ParseDecl.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 4fef5f883655..06f0bdcc796d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -109,6 +109,10 @@ to be worn by functions containing buffer operations that 
could cause out of
 bounds memory accesses. It emits warnings at call sites to such functions when
 the flag ``-Wunsafe-buffer-usage`` is enabled.
 
+``__declspec`` attributes can now be used together with the using keyword. 
Before
+the attributes on ``__declspec`` was ignored, while now it will be forwarded 
to the
+point where the alias is used.
+
 Windows Support
 ---
 

diff  --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index 96c25ba0c853..d32f26b9c32e 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -56,6 +56,18 @@ TypeResult Parser::ParseTypeName(SourceRange *Range, 
DeclaratorContext Context,
   if (OwnedType)
 *OwnedType = DS.isTypeSpecOwned() ? DS.getRepAsDecl() : nullptr;
 
+  // Move declspec attributes to ParsedAttributes
+  if (Attrs) {
+llvm::SmallVector ToBeMoved;
+for (ParsedAttr &AL : DS.getAttributes()) {
+  if (AL.isDeclspecAttribute())
+ToBeMoved.push_back(&AL);
+}
+
+for (ParsedAttr *AL : ToBeMoved)
+  Attrs->takeOneFrom(DS.getAttributes(), AL);
+  }
+
   // Parse the abstract-declarator, if present.
   Declarator DeclaratorInfo(DS, ParsedAttributesView::none(), Context);
   ParseDeclarator(DeclaratorInfo);

diff  --git a/clang/test/SemaCXX/using-declspec.cpp 
b/clang/test/SemaCXX/using-declspec.cpp
new file mode 100644
index ..a903bc93c9b4
--- /dev/null
+++ b/clang/test/SemaCXX/using-declspec.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fms-compatibility -fsyntax-only -verify %s
+
+// This should ignore the alignment and issue a warning about
+// align not being used
+auto func() -> __declspec(align(16)) int; // expected-warning{{attribute 
ignored when parsing type}}
+static_assert(alignof(decltype(func())) == alignof(int));
+
+// The following should NOT assert since alignment should
+// follow the type
+struct Test { int a; };
+using AlignedTest = __declspec(align(16)) const Test;
+static_assert(alignof(AlignedTest) == 16, "error");
+
+// Same here, no declaration to shift to
+int i = (__declspec(align(16))int)12; // expected-warning{{attribute ignored 
when parsing type}}
+
+// But there is a declaration here!
+typedef __declspec(align(16)) int Foo;
+static_assert(alignof(Foo) == 16);



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


[PATCH] D143632: [clang] Handle __declspec() attributes in using

2023-02-13 Thread Tobias Hieta via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG877859a09bda: [clang] Handle __declspec() attributes in 
using (authored by thieta).

Changed prior to commit:
  https://reviews.llvm.org/D143632?vs=496906&id=496961#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143632

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Parse/ParseDecl.cpp
  clang/test/SemaCXX/using-declspec.cpp


Index: clang/test/SemaCXX/using-declspec.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/using-declspec.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fms-compatibility -fsyntax-only -verify %s
+
+// This should ignore the alignment and issue a warning about
+// align not being used
+auto func() -> __declspec(align(16)) int; // expected-warning{{attribute 
ignored when parsing type}}
+static_assert(alignof(decltype(func())) == alignof(int));
+
+// The following should NOT assert since alignment should
+// follow the type
+struct Test { int a; };
+using AlignedTest = __declspec(align(16)) const Test;
+static_assert(alignof(AlignedTest) == 16, "error");
+
+// Same here, no declaration to shift to
+int i = (__declspec(align(16))int)12; // expected-warning{{attribute ignored 
when parsing type}}
+
+// But there is a declaration here!
+typedef __declspec(align(16)) int Foo;
+static_assert(alignof(Foo) == 16);
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -56,6 +56,18 @@
   if (OwnedType)
 *OwnedType = DS.isTypeSpecOwned() ? DS.getRepAsDecl() : nullptr;
 
+  // Move declspec attributes to ParsedAttributes
+  if (Attrs) {
+llvm::SmallVector ToBeMoved;
+for (ParsedAttr &AL : DS.getAttributes()) {
+  if (AL.isDeclspecAttribute())
+ToBeMoved.push_back(&AL);
+}
+
+for (ParsedAttr *AL : ToBeMoved)
+  Attrs->takeOneFrom(DS.getAttributes(), AL);
+  }
+
   // Parse the abstract-declarator, if present.
   Declarator DeclaratorInfo(DS, ParsedAttributesView::none(), Context);
   ParseDeclarator(DeclaratorInfo);
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -109,6 +109,10 @@
 bounds memory accesses. It emits warnings at call sites to such functions when
 the flag ``-Wunsafe-buffer-usage`` is enabled.
 
+``__declspec`` attributes can now be used together with the using keyword. 
Before
+the attributes on ``__declspec`` was ignored, while now it will be forwarded 
to the
+point where the alias is used.
+
 Windows Support
 ---
 


Index: clang/test/SemaCXX/using-declspec.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/using-declspec.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fms-compatibility -fsyntax-only -verify %s
+
+// This should ignore the alignment and issue a warning about
+// align not being used
+auto func() -> __declspec(align(16)) int; // expected-warning{{attribute ignored when parsing type}}
+static_assert(alignof(decltype(func())) == alignof(int));
+
+// The following should NOT assert since alignment should
+// follow the type
+struct Test { int a; };
+using AlignedTest = __declspec(align(16)) const Test;
+static_assert(alignof(AlignedTest) == 16, "error");
+
+// Same here, no declaration to shift to
+int i = (__declspec(align(16))int)12; // expected-warning{{attribute ignored when parsing type}}
+
+// But there is a declaration here!
+typedef __declspec(align(16)) int Foo;
+static_assert(alignof(Foo) == 16);
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -56,6 +56,18 @@
   if (OwnedType)
 *OwnedType = DS.isTypeSpecOwned() ? DS.getRepAsDecl() : nullptr;
 
+  // Move declspec attributes to ParsedAttributes
+  if (Attrs) {
+llvm::SmallVector ToBeMoved;
+for (ParsedAttr &AL : DS.getAttributes()) {
+  if (AL.isDeclspecAttribute())
+ToBeMoved.push_back(&AL);
+}
+
+for (ParsedAttr *AL : ToBeMoved)
+  Attrs->takeOneFrom(DS.getAttributes(), AL);
+  }
+
   // Parse the abstract-declarator, if present.
   Declarator DeclaratorInfo(DS, ParsedAttributesView::none(), Context);
   ParseDeclarator(DeclaratorInfo);
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -109,6 +109,10 @@
 bounds memory accesses. It emits warnings at call sites to such functions when
 the flag ``-Wunsafe-buffer-usage`` is enabled.
 
+``__declspec`` attributes can now be used together with the using key

[PATCH] D143632: [clang] Handle __declspec() attributes in using

2023-02-13 Thread Tobias Hieta via Phabricator via cfe-commits
thieta added a comment.

Thanks for the review and the explanations! I fixed your nits and landed this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143632

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via Phabricator via cfe-commits
zyounan updated this revision to Diff 496963.
zyounan marked 4 inline comments as done.
zyounan added a comment.

Revise


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
  clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
  clang/unittests/Tooling/StandardLibraryTest.cpp

Index: clang/unittests/Tooling/StandardLibraryTest.cpp
===
--- clang/unittests/Tooling/StandardLibraryTest.cpp
+++ clang/unittests/Tooling/StandardLibraryTest.cpp
@@ -79,6 +79,23 @@
   EXPECT_FALSE(stdlib::Header::named("", stdlib::Lang::CXX));
 }
 
+TEST(StdlibTest, Experimental) {
+  EXPECT_FALSE(
+  stdlib::Header::named("", stdlib::Lang::C));
+  EXPECT_TRUE(
+  stdlib::Header::named("", stdlib::Lang::CXX));
+
+  auto Symbol = stdlib::Symbol::named("std::experimental::filesystem::",
+  "system_complete");
+  EXPECT_TRUE(Symbol);
+  EXPECT_EQ(Symbol->scope(), "std::experimental::filesystem::");
+  EXPECT_EQ(Symbol->name(), "system_complete");
+  EXPECT_EQ(Symbol->header(),
+stdlib::Header::named(""));
+  EXPECT_EQ(Symbol->qualifiedName(),
+"std::experimental::filesystem::system_complete");
+}
+
 TEST(StdlibTest, CCompat) {
   EXPECT_THAT(
   stdlib::Symbol::named("", "int16_t", stdlib::Lang::CXX)->headers(),
Index: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
===
--- /dev/null
+++ clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
@@ -0,0 +1,54 @@
+// These are derived from N4100[fs.filesystem.synopsis], final
+// draft for experimental filesystem.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )
+SYMBOL(canonical, std::experimental::filesystem::, )
+SYMBOL(copy, std::experimental::filesystem::, )
+SYMBOL(copy_file, std::experimental::filesystem::, )
+SYMBOL(copy_options, std::experimental::filesystem::, )
+SYMBOL(copy_symlink, std::experimental::filesystem::, )
+SYMBOL(create_directories, std::experimental::filesystem::, )
+SYMBOL(create_directory, std::experimental::filesystem::, )
+SYMBOL(create_directory_symlink, std::experimental::filesystem::, )
+SYMBOL(create_hard_link, std::experimental::filesystem::, )
+SYMBOL(create_symlink, std::experimental::filesystem::, )
+SYMBOL(current_path, std::experimental::filesystem::, )
+SYMBOL(directory_entry, std::experimental::filesystem::, )
+SYMBOL(directory_iterator, std::experimental::filesystem::, )
+SYMBOL(directory_options, std::experimental::filesystem::, )
+SYMBOL(equivalent, std::experimental::filesystem::, )
+SYMBOL(exists, std::experimental::filesystem::, )
+SYMBOL(file_size, std::experimental::filesystem::, )
+SYMBOL(file_status, std::experimental::filesystem::, )
+SYMBOL(file_time_type, std::experimental::filesystem::, )
+SYMBOL(file_type, std::experimental::filesystem::, )
+SYMBOL(filesystem_error, std::experimental::filesystem::, )
+SYMBOL(hard_link_count, std::experimental::filesystem::, )
+SYMBOL(is_block_file, std::experimental::filesystem::, )
+SYMBOL(is_character_file, std::experimental::filesystem::, )
+SYMBOL(is_directory, std::experimental::filesystem::, )
+SYMBOL(is_empty, std::experimental::filesystem::, )
+SYMBOL(is_fifo, std::experimental::filesystem::, )
+SYMBOL(is_other, std::experimental::filesystem::, )
+SYMBOL(is_regular_file, std::experimental::filesystem::, )
+SYMBOL(is_socket, std::experimental::filesystem::, )
+SYMBOL(is_symlink, std::experimental::filesystem::, )
+SYMBOL(last_write_time, std::experimental::filesystem::, )
+SYMBOL(path, std::experimental::filesystem::, )
+SYMBOL(permissions, std::experimental::filesystem::, )
+SYMBOL(perms, std::experimental::filesystem::, )
+SYMBOL(read_symlink, std::experimental::filesystem::, )
+SYMBOL(recursive_directory_iterator, std::experimental::filesystem::, )
+SYMBOL(remove, std::experimental::filesystem::, )
+SYMBOL(remove_all, std::experimental::filesystem::, )
+SYMBOL(rename, std::experimental::filesystem::, )
+SYMBOL(resize_file, std::experimental::filesystem::, )
+SYMBOL(space, std::experimental::filesystem::, )
+SYMBOL(space_info, std::experimental::filesystem::, )
+SYMBOL(status, std::experimental::filesystem::, )
+SYMBOL(status_known, std::experimental::filesystem::, )
+SYMBOL(symlink_status, std::experimental::filesystem::, )
+SYMBOL(system_complete, std::experimental::filesystem::, )
+SYMBOL(temp_directory_path, std::experimental::filesystem::, )
+SYMBOL(u8path, std::experimental::filesystem::, )
+// clang-format on
Index: clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
===
--- clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
+++ clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
@@ -63,6 +63,7 @@
   case Lang::CXX:
 #include "St

[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via Phabricator via cfe-commits
zyounan added inline comments.



Comment at: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc:1
+// These symbols are exported from N4100[fs.filesystem.synopsis], the final
+// draft for experimental filesystem. Note that not all of these symbols were

kadircet wrote:
> i think comment is a little too verbose. can you just say:
> ```
> These are derived from N4100[fs.filesystem.synopsis], final draft for 
> experimental filesystem.
> ```
> 
> There's no need for mentioning that these became the standard in C++17 or 
> being a cornerstone for stdlib implementations. As they won't necessarily be 
> true for other technical specs nor if we were adding this pre-c++17 
> standardisation. But we'd still like to have these widely adapted symbols 
> included in the mapping to make sure we're not generating false negatives.
Well, I'm not quite sure if I should address these small differences between TS 
and C++17. But FWIW, the verbosity should go away.



Comment at: clang/unittests/Tooling/StandardLibraryTest.cpp:93
+
+  // system_complete is replaced by std::filesystem::absolute
+  Symbol = stdlib::Symbol::named("std::filesystem::", "system_complete");

kadircet wrote:
> i don't think there's much point in asserting these "meta" details about the 
> mapping (same for the test below).
They're used to emphasize the slight difference. They can be removed if you 
don't think it necessary :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

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


[PATCH] D143906: [include-cleaner] Better support ambiguous std symbols

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/include-cleaner/lib/FindHeaders.cpp:104
+  }
+  if (FName == "remove") {
+if (FD->getNumParams() == 1)

nit: `else if`



Comment at: clang-tools-extra/include-cleaner/lib/FindHeaders.cpp:110
+  // remove(ForwardIt first, ForwardIt last, const T& value);
+  return {Header("")};
+  }

we also need to account for exporters, similar to `findHeaders`. might be worth 
lifting that branch to a free-function.



Comment at: clang-tools-extra/include-cleaner/lib/FindHeaders.cpp:174
const PragmaIncludes *PI) {
+  if (auto Headers = specialStandardSymbols(S); !Headers.empty())
+return Headers;

rather than doing this here and bailing out early, i think we should just 
augment the `Headers` below, after `locateSymbol` and `findHeaders` is run.

that way we'll make sure rest of the logic applies in the future without 
special casing (e.g. we've some fixmes for treating implementation locations 
for stdlib symbols as providers, in such a scenario this early exits would 
create non-uniformity).
it also implies we'll need to think about hints to attach here, which seems 
consistent with rest of the logic again (as we still assign hints to headers 
derived from stdlib recognizer).

so what about an alternative with a signature like: 
`llvm::SmallVector> headersForSpecialSymbols(S, SM, PI);` then 
we can just initialize Headers with a call to it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143906

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via Phabricator via cfe-commits
zyounan added inline comments.



Comment at: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc:6
+// whatever.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )

kadircet wrote:
> zyounan wrote:
> > kadircet wrote:
> > > can you strip clang-format pragmas to be similar to other mapping files.
> > I'd love to if possible, but for some reason clang-format would add extra 
> > spaces before and after the slash, ``, which 
> > looks ugly and I don't expect it right.
> i don't follow, why do you **need** to run clang-format on this file? symbols 
> are already ordered
Specifically, it is `git clang-format`. The pipeline would fail if this command 
does modify some files IIRC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

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


[PATCH] D127910: [Clang][AArch64][SME] Add vector load/store (ld1/st1) intrinsics

2023-02-13 Thread Bryan Chan via Phabricator via cfe-commits
bryanpkc updated this revision to Diff 496964.
bryanpkc edited the summary of this revision.
bryanpkc added a comment.

Addressed review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127910

Files:
  clang/include/clang/Basic/BuiltinsSME.def
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sme.td
  clang/include/clang/Basic/arm_sve.td
  clang/include/clang/Basic/arm_sve_sme_incl.td
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_ld1.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_ld1_vnum.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_st1.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_st1_vnum.c
  clang/test/Sema/aarch64-sme-intrinsics/acle_sme_imm.cpp
  clang/utils/TableGen/SveEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -101,6 +101,11 @@
 void EmitSveTypeFlags(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitSveRangeChecks(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
+void EmitSmeHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSmeBuiltins(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSmeBuiltinCG(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSmeRangeChecks(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+
 void EmitMveHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitMveBuiltinDef(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitMveBuiltinSema(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -81,6 +81,10 @@
   GenArmSveBuiltinCG,
   GenArmSveTypeFlags,
   GenArmSveRangeChecks,
+  GenArmSmeHeader,
+  GenArmSmeBuiltins,
+  GenArmSmeBuiltinCG,
+  GenArmSmeRangeChecks,
   GenArmCdeHeader,
   GenArmCdeBuiltinDef,
   GenArmCdeBuiltinSema,
@@ -219,6 +223,14 @@
"Generate arm_sve_typeflags.inc for clang"),
 clEnumValN(GenArmSveRangeChecks, "gen-arm-sve-sema-rangechecks",
"Generate arm_sve_sema_rangechecks.inc for clang"),
+clEnumValN(GenArmSmeHeader, "gen-arm-sme-header",
+   "Generate arm_sme.h for clang"),
+clEnumValN(GenArmSmeBuiltins, "gen-arm-sme-builtins",
+   "Generate arm_sme_builtins.inc for clang"),
+clEnumValN(GenArmSmeBuiltinCG, "gen-arm-sme-builtin-codegen",
+   "Generate arm_sme_builtin_cg_map.inc for clang"),
+clEnumValN(GenArmSmeRangeChecks, "gen-arm-sme-sema-rangechecks",
+   "Generate arm_sme_sema_rangechecks.inc for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",
"Generate arm_mve.h for clang"),
 clEnumValN(GenArmMveBuiltinDef, "gen-arm-mve-builtin-def",
@@ -438,6 +450,18 @@
   case GenArmSveRangeChecks:
 EmitSveRangeChecks(Records, OS);
 break;
+  case GenArmSmeHeader:
+EmitSmeHeader(Records, OS);
+break;
+  case GenArmSmeBuiltins:
+EmitSmeBuiltins(Records, OS);
+break;
+  case GenArmSmeBuiltinCG:
+EmitSmeBuiltinCG(Records, OS);
+break;
+  case GenArmSmeRangeChecks:
+EmitSmeRangeChecks(Records, OS);
+break;
   case GenArmCdeHeader:
 EmitCdeHeader(Records, OS);
 break;
Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -228,7 +228,7 @@
   }
 
   /// Emits the intrinsic declaration to the ostream.
-  void emitIntrinsic(raw_ostream &OS) const;
+  void emitIntrinsic(raw_ostream &OS, SVEEmitter &Emitter) const;
 
 private:
   std::string getMergeSuffix() const { return MergeSuffix; }
@@ -346,8 +346,21 @@
   /// Create the SVETypeFlags used in CGBuiltins
   void createTypeFlags(raw_ostream &o);
 
+  /// Emit arm_sme.h.
+  void createSMEHeader(raw_ostream &o);
+
+  /// Emit all the SME __builtin prototypes and code needed by Sema.
+  void createSMEBuiltins(raw_ostream &o);
+
+  /// Emit all the information needed to map builtin -> LLVM IR intrinsic.
+  void createSMECodeGenMap(raw_ostream &o);
+
+  /// Emit all the range checks for the immediates.
+  void createSMERangeChecks(raw_ostream &o);
+
   /// Create intrinsic and add it to \p Out
-  void createIntrinsic(Record *

[PATCH] D127910: [Clang][AArch64][SME] Add vector load/store (ld1/st1) intrinsics

2023-02-13 Thread Bryan Chan via Phabricator via cfe-commits
bryanpkc marked 5 inline comments as done.
bryanpkc added inline comments.



Comment at: clang/include/clang/Basic/arm_sme.td:22
+let TargetGuard = "sme" in {
+  def SVLD1_HOR_ZA8 : MInst<"svld1_hor_za8", "vimiPQ", "c", [IsLoad, 
IsOverloadNone, IsStreaming, IsSharedZA], MemEltTyDefault, 
"aarch64_sme_ld1b_horiz", [ImmCheck<0, ImmCheck0_0>, ImmCheck<2, 
ImmCheck0_15>]>;
+  def SVLD1_HOR_ZA16 : MInst<"svld1_hor_za16", "vimiPQ", "s", [IsLoad, 
IsOverloadNone, IsStreaming, IsSharedZA], MemEltTyDefault, 
"aarch64_sme_ld1h_horiz", [ImmCheck<0, ImmCheck0_1>, ImmCheck<2, ImmCheck0_7>]>;

david-arm wrote:
> This is just a suggestion, but you could reduce the lines of code here if you 
> want by creating a multiclass that creates both the horizontal and vertical 
> variants for each size, i.e. something like
> 
>   multiclass MyMultiClass<..> {
> def NAME # _H : MInst<...>
> def NAME # _V : MInst<...>
>   }
> 
>   defm SVLD1_ZA8 : MyMultiClass<...>;
> 
> or whatever naming scheme you prefer, and same for the stores. Feel free to 
> ignore this suggestion though if it doesn't help you!
Thanks for the suggestion. Refactored.



Comment at: clang/lib/Headers/CMakeLists.txt:332
+  # Generate arm_sme.h
+  clang_generate_header(-gen-arm-sme-header arm_sme.td arm_sme.h)
   # Generate arm_bf16.h

bryanpkc wrote:
> sdesmalen wrote:
> > The ACLE specification is still in a draft (ALP) state, which means there 
> > may still be subject to significant changes. To avoid users from using this 
> > implementation with the expectation that their code is compliant going 
> > forward, it would be good to rename the header file to something that makes 
> > it very clear this feature is not yet ready to use. I'm thinking of 
> > something like `arm_sme_draft_spec_subject_to_change.h`. When the 
> > specification goes out of draft, we can rename it to `arm_sme.h`. Could you 
> > rename the file for now?
> Would something shorter like `arm_sme_draft.h` or `arm_sme_experimental.h` 
> suffice?
Renamed to `arm_sme_experimental.h`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127910

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet accepted this revision.
kadircet added a comment.
This revision is now accepted and ready to land.

thanks!




Comment at: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc:6
+// whatever.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )

zyounan wrote:
> kadircet wrote:
> > zyounan wrote:
> > > kadircet wrote:
> > > > can you strip clang-format pragmas to be similar to other mapping files.
> > > I'd love to if possible, but for some reason clang-format would add extra 
> > > spaces before and after the slash, ``, which 
> > > looks ugly and I don't expect it right.
> > i don't follow, why do you **need** to run clang-format on this file? 
> > symbols are already ordered
> Specifically, it is `git clang-format`. The pipeline would fail if this 
> command does modify some files IIRC.
not sure what workflow you're using but clang-format is not a mandatory part of 
the workflow.
recommended way is updating/uploading patches using arcanist, whose config only 
contains files with one of the `cc|h|cpp` extensions, see 
https://github.com/llvm/llvm-project/blob/main/.arclint.

anyways, happy to land this for you if it's not easy to disable clang-format 
linting on your workflow for whatever reason.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

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


[PATCH] D143736: [PowerPC] Specify the dynamic loader prefix in ppc-float-abi-warning

2023-02-13 Thread Tulio Magno Quites Machado Filho via Phabricator via cfe-commits
tuliom added a comment.

@qiucf Thanks! I still don't have commit access yet. Could you land this patch 
for me, please?
Please use “Tulio Magno Quites Machado Filho tul...@redhat.com” to commit the 
change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143736

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via Phabricator via cfe-commits
zyounan added a comment.

Thank you for your detailed explanation and sorry again for my dumb mistake 
before. :)




Comment at: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc:6
+// whatever.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )

kadircet wrote:
> zyounan wrote:
> > kadircet wrote:
> > > zyounan wrote:
> > > > kadircet wrote:
> > > > > can you strip clang-format pragmas to be similar to other mapping 
> > > > > files.
> > > > I'd love to if possible, but for some reason clang-format would add 
> > > > extra spaces before and after the slash, ``, 
> > > > which looks ugly and I don't expect it right.
> > > i don't follow, why do you **need** to run clang-format on this file? 
> > > symbols are already ordered
> > Specifically, it is `git clang-format`. The pipeline would fail if this 
> > command does modify some files IIRC.
> not sure what workflow you're using but clang-format is not a mandatory part 
> of the workflow.
> recommended way is updating/uploading patches using arcanist, whose config 
> only contains files with one of the `cc|h|cpp` extensions, see 
> https://github.com/llvm/llvm-project/blob/main/.arclint.
> 
> anyways, happy to land this for you if it's not easy to disable clang-format 
> linting on your workflow for whatever reason.
I've looked into the script of the running pipeline, it shows that it is 
running `${SRC}/scripts/premerge_checks.py --check-clang-format`, which would 
[run `git 
clang-format`](https://github.com/google/llvm-premerge-checks/blob/abe5c8991b5e81f0182528ff8ce515ba89a66c0a/scripts/premerge_checks.py#L163).
 I'm using arcanist with default config, and I don't know if I'm missing 
something to skip this. (Perhaps it is because the rule you mentioned doesn't 
exclude `.inc` files, and we didn't write any slashes in such files either.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via Phabricator via cfe-commits
zyounan added inline comments.



Comment at: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc:6
+// whatever.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )

zyounan wrote:
> kadircet wrote:
> > zyounan wrote:
> > > kadircet wrote:
> > > > zyounan wrote:
> > > > > kadircet wrote:
> > > > > > can you strip clang-format pragmas to be similar to other mapping 
> > > > > > files.
> > > > > I'd love to if possible, but for some reason clang-format would add 
> > > > > extra spaces before and after the slash, ` > > > > filesystem>`, which looks ugly and I don't expect it right.
> > > > i don't follow, why do you **need** to run clang-format on this file? 
> > > > symbols are already ordered
> > > Specifically, it is `git clang-format`. The pipeline would fail if this 
> > > command does modify some files IIRC.
> > not sure what workflow you're using but clang-format is not a mandatory 
> > part of the workflow.
> > recommended way is updating/uploading patches using arcanist, whose config 
> > only contains files with one of the `cc|h|cpp` extensions, see 
> > https://github.com/llvm/llvm-project/blob/main/.arclint.
> > 
> > anyways, happy to land this for you if it's not easy to disable 
> > clang-format linting on your workflow for whatever reason.
> I've looked into the script of the running pipeline, it shows that it is 
> running `${SRC}/scripts/premerge_checks.py --check-clang-format`, which would 
> [run `git 
> clang-format`](https://github.com/google/llvm-premerge-checks/blob/abe5c8991b5e81f0182528ff8ce515ba89a66c0a/scripts/premerge_checks.py#L163).
>  I'm using arcanist with default config, and I don't know if I'm missing 
> something to skip this. (Perhaps it is because the rule you mentioned doesn't 
> exclude `.inc` files, and we didn't write any slashes in such files either.)
...Or it is the rule defined in pipeline doesn't exclude them... 
https://github.com/google/llvm-premerge-checks/blob/abe5c8991b5e81f0182528ff8ce515ba89a66c0a/scripts/clang-format.ignore



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

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


[PATCH] D142836: [clangd] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via Phabricator via cfe-commits
zyounan updated this revision to Diff 496971.
zyounan added a comment.

Apply clang-format to StandardLibrary.cpp to fix pipeline failure


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
  clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
  clang/unittests/Tooling/StandardLibraryTest.cpp

Index: clang/unittests/Tooling/StandardLibraryTest.cpp
===
--- clang/unittests/Tooling/StandardLibraryTest.cpp
+++ clang/unittests/Tooling/StandardLibraryTest.cpp
@@ -79,6 +79,23 @@
   EXPECT_FALSE(stdlib::Header::named("", stdlib::Lang::CXX));
 }
 
+TEST(StdlibTest, Experimental) {
+  EXPECT_FALSE(
+  stdlib::Header::named("", stdlib::Lang::C));
+  EXPECT_TRUE(
+  stdlib::Header::named("", stdlib::Lang::CXX));
+
+  auto Symbol = stdlib::Symbol::named("std::experimental::filesystem::",
+  "system_complete");
+  EXPECT_TRUE(Symbol);
+  EXPECT_EQ(Symbol->scope(), "std::experimental::filesystem::");
+  EXPECT_EQ(Symbol->name(), "system_complete");
+  EXPECT_EQ(Symbol->header(),
+stdlib::Header::named(""));
+  EXPECT_EQ(Symbol->qualifiedName(),
+"std::experimental::filesystem::system_complete");
+}
+
 TEST(StdlibTest, CCompat) {
   EXPECT_THAT(
   stdlib::Symbol::named("", "int16_t", stdlib::Lang::CXX)->headers(),
Index: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
===
--- /dev/null
+++ clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
@@ -0,0 +1,54 @@
+// These are derived from N4100[fs.filesystem.synopsis], final
+// draft for experimental filesystem.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )
+SYMBOL(canonical, std::experimental::filesystem::, )
+SYMBOL(copy, std::experimental::filesystem::, )
+SYMBOL(copy_file, std::experimental::filesystem::, )
+SYMBOL(copy_options, std::experimental::filesystem::, )
+SYMBOL(copy_symlink, std::experimental::filesystem::, )
+SYMBOL(create_directories, std::experimental::filesystem::, )
+SYMBOL(create_directory, std::experimental::filesystem::, )
+SYMBOL(create_directory_symlink, std::experimental::filesystem::, )
+SYMBOL(create_hard_link, std::experimental::filesystem::, )
+SYMBOL(create_symlink, std::experimental::filesystem::, )
+SYMBOL(current_path, std::experimental::filesystem::, )
+SYMBOL(directory_entry, std::experimental::filesystem::, )
+SYMBOL(directory_iterator, std::experimental::filesystem::, )
+SYMBOL(directory_options, std::experimental::filesystem::, )
+SYMBOL(equivalent, std::experimental::filesystem::, )
+SYMBOL(exists, std::experimental::filesystem::, )
+SYMBOL(file_size, std::experimental::filesystem::, )
+SYMBOL(file_status, std::experimental::filesystem::, )
+SYMBOL(file_time_type, std::experimental::filesystem::, )
+SYMBOL(file_type, std::experimental::filesystem::, )
+SYMBOL(filesystem_error, std::experimental::filesystem::, )
+SYMBOL(hard_link_count, std::experimental::filesystem::, )
+SYMBOL(is_block_file, std::experimental::filesystem::, )
+SYMBOL(is_character_file, std::experimental::filesystem::, )
+SYMBOL(is_directory, std::experimental::filesystem::, )
+SYMBOL(is_empty, std::experimental::filesystem::, )
+SYMBOL(is_fifo, std::experimental::filesystem::, )
+SYMBOL(is_other, std::experimental::filesystem::, )
+SYMBOL(is_regular_file, std::experimental::filesystem::, )
+SYMBOL(is_socket, std::experimental::filesystem::, )
+SYMBOL(is_symlink, std::experimental::filesystem::, )
+SYMBOL(last_write_time, std::experimental::filesystem::, )
+SYMBOL(path, std::experimental::filesystem::, )
+SYMBOL(permissions, std::experimental::filesystem::, )
+SYMBOL(perms, std::experimental::filesystem::, )
+SYMBOL(read_symlink, std::experimental::filesystem::, )
+SYMBOL(recursive_directory_iterator, std::experimental::filesystem::, )
+SYMBOL(remove, std::experimental::filesystem::, )
+SYMBOL(remove_all, std::experimental::filesystem::, )
+SYMBOL(rename, std::experimental::filesystem::, )
+SYMBOL(resize_file, std::experimental::filesystem::, )
+SYMBOL(space, std::experimental::filesystem::, )
+SYMBOL(space_info, std::experimental::filesystem::, )
+SYMBOL(status, std::experimental::filesystem::, )
+SYMBOL(status_known, std::experimental::filesystem::, )
+SYMBOL(symlink_status, std::experimental::filesystem::, )
+SYMBOL(system_complete, std::experimental::filesystem::, )
+SYMBOL(temp_directory_path, std::experimental::filesystem::, )
+SYMBOL(u8path, std::experimental::filesystem::, )
+// clang-format on
Index: clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
===
--- clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
+++ clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
@@ -61,8 +61,9 @@
 #include "CSym

[PATCH] D127910: [Clang][AArch64][SME] Add vector load/store (ld1/st1) intrinsics

2023-02-13 Thread Bryan Chan via Phabricator via cfe-commits
bryanpkc updated this revision to Diff 496976.
bryanpkc marked an inline comment as done.
bryanpkc added a comment.

Fixed minor bugs in the previous upload.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127910

Files:
  clang/include/clang/Basic/BuiltinsSME.def
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sme.td
  clang/include/clang/Basic/arm_sve.td
  clang/include/clang/Basic/arm_sve_sme_incl.td
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_ld1.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_ld1_vnum.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_st1.c
  clang/test/CodeGen/aarch64-sme-intrinsics/acle_sme_st1_vnum.c
  clang/test/Sema/aarch64-sme-intrinsics/acle_sme_imm.cpp
  clang/utils/TableGen/SveEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -101,6 +101,11 @@
 void EmitSveTypeFlags(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitSveRangeChecks(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 
+void EmitSmeHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSmeBuiltins(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSmeBuiltinCG(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitSmeRangeChecks(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+
 void EmitMveHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitMveBuiltinDef(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitMveBuiltinSema(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -81,6 +81,10 @@
   GenArmSveBuiltinCG,
   GenArmSveTypeFlags,
   GenArmSveRangeChecks,
+  GenArmSmeHeader,
+  GenArmSmeBuiltins,
+  GenArmSmeBuiltinCG,
+  GenArmSmeRangeChecks,
   GenArmCdeHeader,
   GenArmCdeBuiltinDef,
   GenArmCdeBuiltinSema,
@@ -219,6 +223,14 @@
"Generate arm_sve_typeflags.inc for clang"),
 clEnumValN(GenArmSveRangeChecks, "gen-arm-sve-sema-rangechecks",
"Generate arm_sve_sema_rangechecks.inc for clang"),
+clEnumValN(GenArmSmeHeader, "gen-arm-sme-header",
+   "Generate arm_sme.h for clang"),
+clEnumValN(GenArmSmeBuiltins, "gen-arm-sme-builtins",
+   "Generate arm_sme_builtins.inc for clang"),
+clEnumValN(GenArmSmeBuiltinCG, "gen-arm-sme-builtin-codegen",
+   "Generate arm_sme_builtin_cg_map.inc for clang"),
+clEnumValN(GenArmSmeRangeChecks, "gen-arm-sme-sema-rangechecks",
+   "Generate arm_sme_sema_rangechecks.inc for clang"),
 clEnumValN(GenArmMveHeader, "gen-arm-mve-header",
"Generate arm_mve.h for clang"),
 clEnumValN(GenArmMveBuiltinDef, "gen-arm-mve-builtin-def",
@@ -438,6 +450,18 @@
   case GenArmSveRangeChecks:
 EmitSveRangeChecks(Records, OS);
 break;
+  case GenArmSmeHeader:
+EmitSmeHeader(Records, OS);
+break;
+  case GenArmSmeBuiltins:
+EmitSmeBuiltins(Records, OS);
+break;
+  case GenArmSmeBuiltinCG:
+EmitSmeBuiltinCG(Records, OS);
+break;
+  case GenArmSmeRangeChecks:
+EmitSmeRangeChecks(Records, OS);
+break;
   case GenArmCdeHeader:
 EmitCdeHeader(Records, OS);
 break;
Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -228,7 +228,7 @@
   }
 
   /// Emits the intrinsic declaration to the ostream.
-  void emitIntrinsic(raw_ostream &OS) const;
+  void emitIntrinsic(raw_ostream &OS, SVEEmitter &Emitter) const;
 
 private:
   std::string getMergeSuffix() const { return MergeSuffix; }
@@ -346,8 +346,21 @@
   /// Create the SVETypeFlags used in CGBuiltins
   void createTypeFlags(raw_ostream &o);
 
+  /// Emit arm_sme.h.
+  void createSMEHeader(raw_ostream &o);
+
+  /// Emit all the SME __builtin prototypes and code needed by Sema.
+  void createSMEBuiltins(raw_ostream &o);
+
+  /// Emit all the information needed to map builtin -> LLVM IR intrinsic.
+  void createSMECodeGenMap(raw_ostream &o);
+
+  /// Emit all the range checks for the immediates.
+  void createSMERangeChecks(raw_ostream &o);
+
   /// Create intrinsic and add it to \p Out
-  void createIntrins

[PATCH] D132819: [RISCV] Add MC support of RISCV zcmp Extension

2023-02-13 Thread Xinlong Wu via Phabricator via cfe-commits
VincentWu updated this revision to Diff 496985.
VincentWu added a comment.
Herald added a subscriber: luke.

add doc & update to v1.0


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132819

Files:
  clang/test/Preprocessor/riscv-target-features.c
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVInstPrinter.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVInstPrinter.h
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVMCCodeEmitter.cpp
  llvm/lib/Target/RISCV/RISCVFeatures.td
  llvm/lib/Target/RISCV/RISCVInstrInfoZc.td
  llvm/lib/Target/RISCV/RISCVRegisterInfo.td
  llvm/lib/Target/RISCV/RISCVSchedRocket.td
  llvm/lib/Target/RISCV/RISCVSchedSiFive7.td
  llvm/lib/Target/RISCV/RISCVTargetMachine.cpp
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/rv32zcmp-invalid.s
  llvm/test/MC/RISCV/rv32zcmp-valid.s
  llvm/test/MC/RISCV/rv64zcb-invalid.s
  llvm/test/MC/RISCV/rv64zcmp-invalid.s
  llvm/test/MC/RISCV/rv64zcmp-valid.s

Index: llvm/test/MC/RISCV/rv64zcmp-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv64zcmp-valid.s
@@ -0,0 +1,149 @@
+# RUN: llvm-mc %s -triple=riscv64 -mattr=experimental-zcmp -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=experimental-zcmp < %s \
+# RUN: | llvm-objdump --mattr=-c,experimental-zcmp -M no-aliases -d -r - \
+# RUN: | FileCheck --check-prefixes=CHECK-ASM-AND-OBJ %s
+
+# CHECK-ASM-AND-OBJ: cm.mvsa01 s1, s0
+# CHECK-ASM: encoding: [0xa2,0xac]
+cm.mvsa01 s1, s0
+
+# CHECK-ASM-AND-OBJ: cm.mva01s s1, s0
+# CHECK-ASM: encoding: [0xe2,0xac]
+cm.mva01s s1, s0
+
+# CHECK-ASM-AND-OBJ: cm.popret   {ra}, 16
+# CHECK-ASM: encoding: [0x42,0xbe]
+cm.popret {ra}, 16
+
+# CHECK-ASM-AND-OBJ: cm.popret   {ra}, 32
+# CHECK-ASM: encoding: [0x46,0xbe]
+cm.popret {ra}, 32
+
+# CHECK-ASM-AND-OBJ: cm.popret   {ra, s0}, 64
+# CHECK-ASM: encoding: [0x5e,0xbe]
+cm.popret {ra, s0}, 64
+
+# CHECK-ASM-AND-OBJ: cm.popret   {ra, s0-s1}, 32
+# CHECK-ASM: encoding: [0x62,0xbe]
+cm.popret {ra,s0-s1}, 32
+
+# CHECK-ASM-AND-OBJ: cm.popret   {ra, s0-s2}, 32
+# CHECK-ASM: encoding: [0x72,0xbe]
+cm.popret {ra, s0-s2}, 32
+
+# CHECK-ASM-AND-OBJ: cm.popret   {ra, s0-s3}, 64
+# CHECK-ASM: encoding: [0x86,0xbe]
+cm.popret {ra, s0-s3}, 64
+
+# CHECK-ASM-AND-OBJ: cm.popret   {ra, s0-s5}, 64
+# CHECK-ASM: encoding: [0xa2,0xbe]
+cm.popret {ra, s0-s5}, 64
+
+# CHECK-ASM-AND-OBJ: cm.popret   {ra, s0-s7}, 80
+# CHECK-ASM: encoding: [0xc2,0xbe]
+cm.popret {ra, s0-s7}, 80
+
+# CHECK-ASM-AND-OBJ: cm.popret   {ra, s0-s11}, 112
+# CHECK-ASM: encoding: [0xf2,0xbe]
+cm.popret {ra, s0-s11}, 112
+
+# CHECK-ASM-AND-OBJ: cm.popretz   {ra}, 16
+# CHECK-ASM: encoding: [0x42,0xbc]
+cm.popretz {ra}, 16
+
+# CHECK-ASM-AND-OBJ: cm.popretz   {ra}, 32
+# CHECK-ASM: encoding: [0x46,0xbc]
+cm.popretz {ra}, 32
+
+# CHECK-ASM-AND-OBJ: cm.popretz   {ra, s0}, 64
+# CHECK-ASM: encoding: [0x5e,0xbc]
+cm.popretz {ra, s0}, 64
+
+# CHECK-ASM-AND-OBJ: cm.popretz   {ra, s0-s1}, 32
+# CHECK-ASM: encoding: [0x62,0xbc]
+cm.popretz {ra, s0-s1}, 32
+
+# CHECK-ASM-AND-OBJ: cm.popretz   {ra, s0-s2}, 32
+# CHECK-ASM: encoding: [0x72,0xbc]
+cm.popretz {ra, s0-s2}, 32
+
+# CHECK-ASM-AND-OBJ: cm.popretz   {ra, s0-s3}, 64
+# CHECK-ASM: encoding: [0x86,0xbc]
+cm.popretz {ra, s0-s3}, 64
+
+# CHECK-ASM-AND-OBJ: cm.popretz   {ra, s0-s5}, 64
+# CHECK-ASM: encoding: [0xa2,0xbc]
+cm.popretz {ra, s0-s5}, 64
+
+# CHECK-ASM-AND-OBJ: cm.popretz   {ra, s0-s7}, 80
+# CHECK-ASM: encoding: [0xc2,0xbc]
+cm.popretz {ra, s0-s7}, 80
+
+# CHECK-ASM-AND-OBJ: cm.popretz   {ra, s0-s11}, 112
+# CHECK-ASM: encoding: [0xf2,0xbc]
+cm.popretz {ra, s0-s11}, 112
+
+# CHECK-ASM-AND-OBJ: cm.pop  {ra}, 16
+# CHECK-ASM: encoding: [0x42,0xba]
+cm.pop {ra}, 16
+
+# CHECK-ASM-AND-OBJ: cm.pop  {ra}, 32
+# CHECK-ASM: encoding: [0x46,0xba]
+cm.pop {ra}, 32
+
+# CHECK-ASM-AND-OBJ: cm.pop  {ra, s0}, 16
+# CHECK-ASM: encoding: [0x52,0xba]
+cm.pop {ra, s0}, 16
+
+# CHECK-ASM-AND-OBJ: cm.pop  {ra, s0-s1}, 32
+# CHECK-ASM: encoding: [0x62,0xba]
+cm.pop {ra, s0-s1}, 32
+
+# CHECK-ASM-AND-OBJ: cm.pop  {ra, s0-s2}, 32
+# CHECK-ASM: encoding: [0x72,0xba]
+cm.pop {ra, s0-s2}, 32
+
+# CHECK-ASM-AND-OBJ: cm.pop  {ra, s0-s5}, 64
+# CHECK-ASM: encoding: [0xa2,0xba]
+cm.pop {ra, s0-s5}, 64
+
+# CHECK-ASM-AND-OBJ: cm.pop  {ra, s0-s7}, 80
+# CHECK-ASM: encoding: [0xc2,0xba]
+cm.pop {ra, s0-s7}, 80
+
+# CHECK-ASM-AND-OBJ: cm.pop  {ra, s0-s11}, 112
+# CHECK-ASM: encoding: [0xf2,0xba]
+cm.pop {ra, s0-s11}, 112
+
+# CHECK-ASM-AND-OBJ: cm.push {ra}, -16
+# CHECK-ASM: encoding: [0x42,0xb8]
+cm.push {ra}, -16
+
+# CHECK-ASM-AND-

[PATCH] D143917: [clang-tidy] Clarify branch-clone diagnostic message

2023-02-13 Thread Donát Nagy via Phabricator via cfe-commits
donat.nagy created this revision.
donat.nagy added reviewers: aaron.ballman, njames93, carlosgalvezp.
donat.nagy added a project: clang-tools-extra.
Herald added subscribers: gamesh411, Szelethus, dkrupp, xazax.hun.
Herald added a project: All.
donat.nagy requested review of this revision.

This simple commit inserts "body" into the message "repeated branch //body// in 
conditional chain". This is motivated by feedback from a confused user who (at 
first glance) thought that clang-tidy complained about a repeated branch 
//condition//.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143917

Files:
  clang-tools-extra/clang-tidy/bugprone/BranchCloneCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone/branch-clone-if-constexpr-template.cpp
  clang-tools-extra/test/clang-tidy/checkers/bugprone/branch-clone-macro-crash.c
  clang-tools-extra/test/clang-tidy/checkers/bugprone/branch-clone.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone/branch-clone.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone/branch-clone.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone/branch-clone.cpp
@@ -388,7 +388,7 @@
 
 void test_chain1(int in, int &out) {
   if (in > 77)
-// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: repeated branch in conditional chain [bugprone-branch-clone]
+// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: repeated branch body in conditional chain [bugprone-branch-clone]
 out++;
 // CHECK-MESSAGES: :[[@LINE-1]]:10: note: end of the original
   else if (in > 55)
@@ -400,7 +400,7 @@
 
 void test_chain2(int in, int &out) {
   if (in > 77)
-// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: repeated branch in conditional chain [bugprone-branch-clone]
+// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: repeated branch body in conditional chain [bugprone-branch-clone]
 out++;
 // CHECK-MESSAGES: :[[@LINE-1]]:10: note: end of the original
   else if (in > 55)
@@ -422,7 +422,7 @@
 
 void test_chain3(int in, int &out) {
   if (in > 77) {
-// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: repeated branch in conditional chain [bugprone-branch-clone]
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: repeated branch body in conditional chain [bugprone-branch-clone]
 out++;
 out++;
 // CHECK-MESSAGES: :[[@LINE+1]]:4: note: end of the original
@@ -452,7 +452,7 @@
 // describes all branches of the first one before mentioning the second one.
 void test_chain4(int in, int &out) {
   if (in > 77) {
-// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: repeated branch in conditional chain [bugprone-branch-clone]
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: repeated branch body in conditional chain [bugprone-branch-clone]
 out++;
 out++;
 // CHECK-MESSAGES: :[[@LINE+1]]:4: note: end of the original
@@ -463,7 +463,7 @@
 out++;
 out++;
   } else if (in > 42)
-// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: repeated branch in conditional chain [bugprone-branch-clone]
+// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: repeated branch body in conditional chain [bugprone-branch-clone]
 out--;
 // CHECK-MESSAGES: :[[@LINE-1]]:10: note: end of the original
   else if (in > 28) {
@@ -485,7 +485,7 @@
 
 void test_chain5(int in, int &out) {
   if (in > 77)
-// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: repeated branch in conditional chain [bugprone-branch-clone]
+// CHECK-MESSAGES: :[[@LINE+1]]:5: warning: repeated branch body in conditional chain [bugprone-branch-clone]
 out++;
 // CHECK-MESSAGES: :[[@LINE-1]]:10: note: end of the original
   else if (in > 55)
@@ -507,7 +507,7 @@
 
 void test_chain6(int in, int &out) {
   if (in > 77) {
-// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: repeated branch in conditional chain [bugprone-branch-clone]
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: repeated branch body in conditional chain [bugprone-branch-clone]
 out++;
 out++;
 // CHECK-MESSAGES: :[[@LINE+1]]:4: note: end of the original
@@ -538,7 +538,7 @@
 // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: if with identical then and else branches [bugprone-branch-clone]
 // CHECK-MESSAGES: :[[@LINE+27]]:5: note: else branch starts here
 if (b > 5) {
-// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: repeated branch in conditional chain [bugprone-branch-clone]
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: repeated branch body in conditional chain [bugprone-branch-clone]
 // CHECK-MESSAGES: :[[@LINE+9]]:6: note: end of the original
 // CHECK-MESSAGES: :[[@LINE+8]]:24: note: clone 1 starts here
 // CHECK-MESSAGES: :[[@LINE+14]]:12: note: clone 2 starts here
@@ -565,7 +565,7 @@
 }
   } else {
 if (b > 5) {
-// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: repeated branch in conditional chain [bugprone-branch-clone]
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: repeated branch body in conditional chain [bugprone-branch-clone]
 // CHECK-MESSAGES: :[[@LINE+9]]:6: note: end of the original
 // CHECK-MESSAGES: :[[@LINE+8]]:24: note:

[PATCH] D143849: [Clang][OpenCL] Allow pointers in structs as kernel arguments from 2.0

2023-02-13 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: clang/test/SemaOpenCL/invalid-kernel-parameters.cl:90
 
+#if __OPENCL_C_VERSION__ <= CL_VERSION_1_2
 typedef struct FooImage2D // expected-note{{within field of type 'FooImage2D' 
declared here}}

we should not limit the tests to CL1.2. We should test them with 2.0 to make 
sure there is no diagnostics.

To differentiate between 1.2 and 2.0 you can use -verify=ocl12 and 
-verify=ocl20.

same as below


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143849

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


[clang] b8c2ba1 - [NFC] Fix using-declspec.cpp test with non-C++17 compilers

2023-02-13 Thread Tobias Hieta via cfe-commits

Author: Tobias Hieta
Date: 2023-02-13T16:58:13+01:00
New Revision: b8c2ba138ef689710efaa6331a618620058057fb

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

LOG: [NFC] Fix using-declspec.cpp test with non-C++17 compilers

Added: 


Modified: 
clang/test/SemaCXX/using-declspec.cpp

Removed: 




diff  --git a/clang/test/SemaCXX/using-declspec.cpp 
b/clang/test/SemaCXX/using-declspec.cpp
index a903bc93c9b44..f4cc8d3736ca4 100644
--- a/clang/test/SemaCXX/using-declspec.cpp
+++ b/clang/test/SemaCXX/using-declspec.cpp
@@ -3,7 +3,7 @@
 // This should ignore the alignment and issue a warning about
 // align not being used
 auto func() -> __declspec(align(16)) int; // expected-warning{{attribute 
ignored when parsing type}}
-static_assert(alignof(decltype(func())) == alignof(int));
+static_assert(alignof(decltype(func())) == alignof(int), "error");
 
 // The following should NOT assert since alignment should
 // follow the type
@@ -16,4 +16,5 @@ int i = (__declspec(align(16))int)12; // 
expected-warning{{attribute ignored whe
 
 // But there is a declaration here!
 typedef __declspec(align(16)) int Foo;
-static_assert(alignof(Foo) == 16);
+static_assert(alignof(Foo) == 16, "error");
+



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


[PATCH] D143919: [Clang] Copy strictfp attribute from pattern to instantiation

2023-02-13 Thread Serge Pavlov via Phabricator via cfe-commits
sepavloff created this revision.
sepavloff added reviewers: rsmith, rjmccall, aaron.ballman, efriedma.
Herald added a project: All.
sepavloff requested review of this revision.
Herald added a project: clang.

If a template function contained a pragma that made it strictfp, code
generation for such function crashed, because the instantiation did not
have strictfp attribute. As a solution this attribute is copied from the
template to instantiation.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143919

Files:
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CodeGen/fp-template.cpp


Index: clang/test/CodeGen/fp-template.cpp
===
--- /dev/null
+++ clang/test/CodeGen/fp-template.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm 
-fdelayed-template-parsing -o - %s | FileCheck %s
+
+template 
+T templ_01(T x, T y) {
+#pragma STDC FENV_ACCESS ON
+  return x + y;
+}
+
+float func_01(float x, float y) {
+  return templ_01(x, y);
+}
+
+// CHECK-LABEL: define {{.*}} @_Z8templ_01IfET_S0_S0_
+// CHECK-SAME:  (float noundef %{{.*}}, float noundef %{{.*}}) 
#[[ATTR01:[0-9]+]]{{.*}} {
+// CHECK:   call float @llvm.experimental.constrained.fadd.f32
+
+// CHECK: attributes #[[ATTR01]] = { {{.*}}strictfp
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -4923,6 +4923,11 @@
   PatternDecl->hasSkippedBody()) &&
  "unexpected kind of function template definition");
 
+  // If a function template is marked as strictfp, its instantiations should
+  // also have this attribute.
+  if (PatternDecl->hasAttr())
+Function->addAttr(StrictFPAttr::CreateImplicit(Context));
+
   // C++1y [temp.explicit]p10:
   //   Except for inline functions, declarations with types deduced from their
   //   initializer or return value, and class template specializations, other


Index: clang/test/CodeGen/fp-template.cpp
===
--- /dev/null
+++ clang/test/CodeGen/fp-template.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -fdelayed-template-parsing -o - %s | FileCheck %s
+
+template 
+T templ_01(T x, T y) {
+#pragma STDC FENV_ACCESS ON
+  return x + y;
+}
+
+float func_01(float x, float y) {
+  return templ_01(x, y);
+}
+
+// CHECK-LABEL: define {{.*}} @_Z8templ_01IfET_S0_S0_
+// CHECK-SAME:  (float noundef %{{.*}}, float noundef %{{.*}}) #[[ATTR01:[0-9]+]]{{.*}} {
+// CHECK:   call float @llvm.experimental.constrained.fadd.f32
+
+// CHECK: attributes #[[ATTR01]] = { {{.*}}strictfp
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -4923,6 +4923,11 @@
   PatternDecl->hasSkippedBody()) &&
  "unexpected kind of function template definition");
 
+  // If a function template is marked as strictfp, its instantiations should
+  // also have this attribute.
+  if (PatternDecl->hasAttr())
+Function->addAttr(StrictFPAttr::CreateImplicit(Context));
+
   // C++1y [temp.explicit]p10:
   //   Except for inline functions, declarations with types deduced from their
   //   initializer or return value, and class template specializations, other
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143495: [AMDGPU ASAN] Remove reference to asan bitcode library

2023-02-13 Thread praveen velliengiri via Phabricator via cfe-commits
pvellien added a comment.

@yaxunl Could you please commit this change on my behalf? I don't have a write 
access to the trunk


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143495

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


[PATCH] D127910: [Clang][AArch64][SME] Add vector load/store (ld1/st1) intrinsics

2023-02-13 Thread Dave Green via Phabricator via cfe-commits
dmgreen added inline comments.



Comment at: clang/utils/TableGen/SveEmitter.cpp:1477
+
+  OS << "#if !defined(__ARM_FEATURE_SME)\n";
+  OS << "#error \"SME support not enabled\"\n";

bryanpkc wrote:
> dmgreen wrote:
> > We have been changing how the existing SVE and NEON instrinsics work a 
> > little. There are some details in https://reviews.llvm.org/D131064. The 
> > short version is it is best to not rely upon preprocessor macros, and 
> > instead define the intrinsics so that they can be used if the right target 
> > features are available. This allows us to do things like this below, even 
> > without a -march that supports sme, and have them callable at runtime under 
> > the right situations. We should be doing the same for SME.
> > ```
> > __attribute__((target("+sme")))
> > void sme_func() {
> >   somesmeintrinsics();
> > }
> > ```
> I have refactored the SME intrinsics in a similar fashion. Could you confirm 
> if I did it correctly?
It looks OK - as far as I can see. It might be worth adding a test for it? But 
otherwise it looks good. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127910

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


[PATCH] D143260: [clangd] Add semantic token for labels

2023-02-13 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler added a comment.

In D143260#4122523 , @kadircet wrote:

> at hindsight i can't see why `goto X;` and `X:` is not enough for clients to 
> implement this without any need for semantic analysis. are there contexts 
> where this kind of syntactical match is not enough?

I suppose the label *use* could be identified by looking at the previous token, 
but not the label *declaration* (see below).

> moreover there are other label-like constructs that we're not handling, e.g. 
> access specifiers and switch cases.

But access specifiers are a completely different thing semantically, that's the 
point: The user does not tell the client: "I want everything  that is followed 
by a single colon in this color"; that would be silly. They say "I want goto 
labels in this color", exactly because then they immediately stand out compared 
to access specifiers.
switch cases are indeed similar semantically, but the difference is that they 
already have a category assigned: They are either enum values (a semantic token 
type in clangd), macros (ditto) or number literals (likely to be its own 
category in the client's syntax highlighter).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143260

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


[PATCH] D143763: [Clang] Add clangMinimumVersion to multilib.yaml

2023-02-13 Thread Peter Smith via Phabricator via cfe-commits
peter.smith added a comment.

No objections to MaskRay's suggestion to merge with an earlier patch. I've made 
some suggestions to make the error messages be a bit more specific about what 
is wrong.




Comment at: clang/lib/Driver/Multilib.cpp:185
+if (M.ClangMinimumVersion.empty())
+  return "missing required key 'clangMinimumVersion'";
+

Perhaps
"missing required key 'clangMinimumVersion' expect MAJOR.MINOR.PATCHLEVEL" to 
give an idea what the key is expecting?



Comment at: clang/lib/Driver/Multilib.cpp:195
+if (MinVerStrings.size() != 3)
+  return "not a valid version string \"" + M.ClangMinimumVersion + "\"";
+

Can we add why the version string isn't valid? For example "expected format 
MAJOR.MINOR.PATCHLEVEL got " + M.CLangMinimumVersion ...





Comment at: clang/lib/Driver/Multilib.cpp:200
+  if (S.getAsInteger(10, V))
+return "not a valid version string \"" + M.ClangMinimumVersion + "\"";
+  ClangMinimumVersion.push_back(V);

Similarly, can we say what we were expecting. For example all components must 
be decimal integers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143763

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


[PATCH] D143851: [clang-tidy] Tweak 'rule of 3/5' checks to allow defaulting a destructor outside the class.

2023-02-13 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson updated this revision to Diff 496998.
royjacobson added a comment.

Address CR comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143851

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/special-member-functions.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions-cxx-03.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions-relaxed.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions.cpp
@@ -3,7 +3,7 @@
 class DefinesDestructor {
   ~DefinesDestructor();
 };
-// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesDestructor' defines a non-default destructor but does not define a copy constructor, a copy assignment operator, a move constructor or a move assignment operator [cppcoreguidelines-special-member-functions]
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesDestructor' defines a destructor but does not define a copy constructor, a copy assignment operator, a move constructor or a move assignment operator [cppcoreguidelines-special-member-functions]
 
 class DefinesDefaultedDestructor {
   ~DefinesDefaultedDestructor() = default;
Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions-relaxed.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions-relaxed.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions-relaxed.cpp
@@ -1,14 +1,26 @@
 // RUN: %check_clang_tidy %s cppcoreguidelines-special-member-functions %t -- -config="{CheckOptions: [{key: cppcoreguidelines-special-member-functions.AllowMissingMoveFunctions, value: true}, {key: cppcoreguidelines-special-member-functions.AllowSoleDefaultDtor, value: true}]}" --
 
+// Don't warn on destructors without definitions, they might be defaulted in another TU.
+class DeclaresDestructor {
+  ~DeclaresDestructor();
+};
+
 class DefinesDestructor {
   ~DefinesDestructor();
 };
-// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesDestructor' defines a non-default destructor but does not define a copy constructor or a copy assignment operator [cppcoreguidelines-special-member-functions]
+DefinesDestructor::~DefinesDestructor() {}
+// CHECK-MESSAGES: [[@LINE-4]]:7: warning: class 'DefinesDestructor' defines a non-default destructor but does not define a copy constructor or a copy assignment operator [cppcoreguidelines-special-member-functions]
 
 class DefinesDefaultedDestructor {
   ~DefinesDefaultedDestructor() = default;
 };
 
+class DefinesDefaultedDestructorOutside {
+  ~DefinesDefaultedDestructorOutside();
+};
+
+DefinesDefaultedDestructorOutside::~DefinesDefaultedDestructorOutside() = default;
+
 class DefinesCopyConstructor {
   DefinesCopyConstructor(const DefinesCopyConstructor &);
 };
Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions-cxx-03.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions-cxx-03.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/special-member-functions-cxx-03.cpp
@@ -3,7 +3,7 @@
 class DefinesDestructor {
   ~DefinesDestructor();
 };
-// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesDestructor' defines a non-default destructor but does not define a copy constructor or a copy assignment operator [cppcoreguidelines-special-member-functions]
+// CHECK-MESSAGES: [[@LINE-3]]:7: warning: class 'DefinesDestructor' defines a destructor but does not define a copy constructor or a copy assignment operator [cppcoreguidelines-special-member-functions]
 
 class DefinesCopyConstructor {
   DefinesCopyConstructor(const DefinesCopyConstructor &);
Index: clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/special-member-functions.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/special-member-functions.rst
+++ clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/special-member-functions.rst
@@ -25,15 +25,25 @@
 
 .. option:: AllowSoleDefaultDtor
 
-   When set to `true` (default is `false`), this check doesn't flag classes with a sole, explicitly
-   defaulted destructor. An example for such a class is:
+   When

[PATCH] D143920: [clang][dataflow] Change `transfer` API to take a reference.

2023-02-13 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel created this revision.
ymandel added reviewers: xazax.hun, gribozavr2.
Herald added subscribers: martong, rnkovacs.
Herald added a reviewer: NoQ.
Herald added a project: All.
ymandel requested review of this revision.
Herald added a project: clang.

The provided `CFGElement` is never null, so a reference is a more precise type.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143920

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
  
clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h
  clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
  clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
  clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
  clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
  clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/SignAnalysisTest.cpp
  clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/TransferBranchTest.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -112,7 +112,7 @@
 
   static NonConvergingLattice initialElement() { return {0}; }
 
-  void transfer(const CFGElement *, NonConvergingLattice &E, Environment &) {
+  void transfer(const CFGElement &, NonConvergingLattice &E, Environment &) {
 ++E.State;
   }
 };
@@ -194,8 +194,8 @@
 
   static FunctionCallLattice initialElement() { return {}; }
 
-  void transfer(const CFGElement *Elt, FunctionCallLattice &E, Environment &) {
-auto CS = Elt->getAs();
+  void transfer(const CFGElement &Elt, FunctionCallLattice &E, Environment &) {
+auto CS = Elt.getAs();
 if (!CS)
   return;
 const auto *S = CS->getStmt();
@@ -350,8 +350,8 @@
 
   static NoopLattice initialElement() { return {}; }
 
-  void transfer(const CFGElement *Elt, NoopLattice &, Environment &Env) {
-auto CS = Elt->getAs();
+  void transfer(const CFGElement &Elt, NoopLattice &, Environment &Env) {
+auto CS = Elt.getAs();
 if (!CS)
   return;
 const auto *S = CS->getStmt();
@@ -508,8 +508,8 @@
 
   static NoopLattice initialElement() { return {}; }
 
-  void transfer(const CFGElement *Elt, NoopLattice &, Environment &Env) {
-auto CS = Elt->getAs();
+  void transfer(const CFGElement &Elt, NoopLattice &, Environment &Env) {
+auto CS = Elt.getAs();
 if (!CS)
   return;
 const Stmt *S = CS->getStmt();
@@ -1202,8 +1202,8 @@
 
   static NoopLattice initialElement() { return {}; }
 
-  void transfer(const CFGElement *Elt, NoopLattice &, Environment &Env) {
-auto CS = Elt->getAs();
+  void transfer(const CFGElement &Elt, NoopLattice &, Environment &Env) {
+auto CS = Elt.getAs();
 if (!CS)
   return;
 const Stmt *S = CS->getStmt();
Index: clang/unittests/Analysis/FlowSensitive/TransferBranchTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferBranchTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferBranchTest.cpp
@@ -44,7 +44,7 @@
   explicit TestPropagationAnalysis(ASTContext &Context)
   : DataflowAnalysis(Context) {}
   static TestLattice initialElement() { return TestLattice::bottom(); }
-  void transfer(const CFGElement *, TestLattice &, Environment &) {}
+  void transfer(const CFGElement &, TestLattice &, Environment &) {}
   void transferBranch(bool Branch, const Stmt *S, TestLattice &L,
   Environment &Env) {
 L.Branch = Branch;
Index: clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
@@ -124,9 +124,9 @@
 return ConstantPropagationLattice::bottom();
   }
 
-  void transfer(const CFGElement *E, ConstantPropagationLattice &Element,
+  void transfer(const CFGElement &E, ConstantPropagationLattice &Element,
 Environment &Env) {
-auto CS = E->getAs();
+auto CS = E.getAs();
 if (!CS)
   return;
 auto S = CS->getStmt();
Index: clang/unittests/Analysis/FlowSensitive/SignAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/SignAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/Sig

[PATCH] D143921: [debug-info][codegen] Prevent creation of self-referential SP node

2023-02-13 Thread Felipe de Azevedo Piovezan via Phabricator via cfe-commits
fdeazeve created this revision.
Herald added subscribers: jdoerfert, hiraditya.
Herald added a project: All.
fdeazeve requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: llvm-commits, cfe-commits, sstefan1.
Herald added projects: clang, LLVM.

The function `CGDebugInfo::EmitFunctionDecl` is supposed to create a
declaration -- never a _definition_ -- of a subprogram. This is made
evident by the fact that the SPFlags never have the "Declaration" bit
set by that function.

However, when `EmitFunctionDecl` calls `DIBuilder::createFunction`, it
still tries to fill the "Declaration" argument by passing it the result
of `getFunctionDeclaration(D)`. This will query an internal cache of
previously created declarations and, for most code paths, we return
nullptr; all is good.

However, as reported in [0], there are pathological cases in which we
attempt to recreate a declaration, so the cache query succeeds,
resulting in a subprogram declaration whose declaration field points to
another declaration. Through a series of RAUWs, the declaration field
ends up pointing to the SP itself. Self-referential MDNodes can't be
`unique`, which causes the verifier to fail (declarations must be
`unique`).

We can argue that the caller should check the cache first, but this is
not a correctness issue (declarations are `unique` anyway). The bug is
that `CGDebugInfo::EmitFunctionDecl` should always pass `nullptr` to the
declaration argument of `DIBuilder::createFunction`, expressing the fact
that declarations don't point to other declarations. AFAICT this is not
something for which any reasonable meaning exists.

This seems a lot like a copy-paste mistake that has survived for ~10
years, since other places in this file have the exact same call almost
token-by-token.

I've tested this by compiling LLVMSupport with and without the patch, O2 

and O0, and comparing the dwarfdump of the lib. The dumps are identical
modulo the attributes decl_file/producer/comp_dir.

[0]: https://github.com/llvm/llvm-project/issues/59241


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143921

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  llvm/docs/LangRef.rst
  llvm/lib/IR/Verifier.cpp


Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1400,6 +1400,8 @@
   } else {
 // Subprogram declarations (part of the type hierarchy).
 CheckDI(!Unit, "subprogram declarations must not have a compile unit", &N);
+CheckDI(!N.getRawDeclaration(),
+"subprogram declaration must not have a declaration field");
   }
 
   if (auto *RawThrownTypes = N.getRawThrownTypes()) {
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -5772,11 +5772,12 @@
 
 .. _DISubprogramDeclaration:
 
-When ``isDefinition: false``, subprograms describe a declaration in the type
-tree as opposed to a definition of a function.  If the scope is a composite
-type with an ODR ``identifier:`` and that does not set ``flags: DIFwdDecl``,
-then the subprogram declaration is uniqued based only on its ``linkageName:``
-and ``scope:``.
+When ``spFlags: DISPFlagDefinition`` is not present, subprograms describe a
+declaration in the type tree as opposed to a definition of a function. In this
+case, the ``declaration`` field must be empty. If the scope is a composite type
+with an ODR ``identifier:`` and that does not set ``flags: DIFwdDecl``, then
+the subprogram declaration is uniqued based only on its ``linkageName:`` and
+``scope:``.
 
 .. code-block:: text
 
@@ -5785,9 +5786,9 @@
 }
 
 !0 = distinct !DISubprogram(name: "foo", linkageName: "_Zfoov", scope: !1,
-file: !2, line: 7, type: !3, isLocal: true,
-isDefinition: true, scopeLine: 8,
-containingType: !4,
+file: !2, line: 7, type: !3,
+spFlags: DISPFlagDefinition | 
DISPFlagLocalToUnit,
+scopeLine: 8, containingType: !4,
 virtuality: DW_VIRTUALITY_pure_virtual,
 virtualIndex: 10, flags: DIFlagPrototyped,
 isOptimized: true, unit: !5, templateParams: 
!6,
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -4217,7 +4217,7 @@
   llvm::DISubprogram *SP =
   DBuilder.createFunction(FDContext, Name, LinkageName, Unit, LineNo, STy,
   ScopeLine, Flags, SPFlags, TParamsArray.get(),
-  getFunctionDeclaration(D), nullptr, Annotations);
+ 

[PATCH] D128440: [WebAssembly] Initial support for reference type funcref in clang

2023-02-13 Thread Paulo Matos via Phabricator via cfe-commits
pmatos marked 4 inline comments as done.
pmatos added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:6696
+bool Sema::BuiltinWasmRefNullFunc(CallExpr *TheCall) {
+  if (TheCall->getNumArgs() != 0)
+return true;

erichkeane wrote:
> Does this diagnose?  Should we be emitting an error here?
I think it makes sense. Will add a test as well for the diagnostic.



Comment at: clang/lib/Sema/SemaChecking.cpp:6557-6561
+  // Therefore we need to change the types of the DeclRefExpr (stored in FDecl)
+  // and regenerate a straight up CallExpr on the modified FDecl.
+  // returning
+  // CallExpr
+  // `- FunctionDecl

aaron.ballman wrote:
> Why would we need to do this?? And what do we do when there is no 
> `FunctionDecl` to get back to (because it's a call expression through a 
> function pointer, for example)?
I have added a test to check this situation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128440

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


[PATCH] D128440: [WebAssembly] Initial support for reference type funcref in clang

2023-02-13 Thread Paulo Matos via Phabricator via cfe-commits
pmatos updated this revision to Diff 497002.
pmatos marked 2 inline comments as done.
pmatos added a comment.

Further refinement of the patch with more diagnostics tested.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128440

Files:
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/DirectX.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/WebAssembly.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/lib/Format/FormatToken.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseTentative.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/WebAssembly/wasm-funcref.c
  clang/test/Parser/wasm-funcref.c
  clang/test/Sema/wasm-refs.c
  clang/test/SemaTemplate/address_space-dependent.cpp

Index: clang/test/SemaTemplate/address_space-dependent.cpp
===
--- clang/test/SemaTemplate/address_space-dependent.cpp
+++ clang/test/SemaTemplate/address_space-dependent.cpp
@@ -43,7 +43,7 @@
 
 template 
 void tooBig() {
-  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388587)}}
+  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388586)}}
 }
 
 template 
@@ -101,7 +101,7 @@
   car<1, 2, 3>(); // expected-note {{in instantiation of function template specialization 'car<1, 2, 3>' requested here}}
   HasASTemplateFields<1> HASTF;
   neg<-1>(); // expected-note {{in instantiation of function template specialization 'neg<-1>' requested here}}
-  correct<0x7FFFEA>();
+  correct<0x7FFFE9>();
   tooBig<8388650>(); // expected-note {{in instantiation of function template specialization 'tooBig<8388650L>' requested here}}
 
   __attribute__((address_space(1))) char *x;
Index: clang/test/Sema/wasm-refs.c
===
--- clang/test/Sema/wasm-refs.c
+++ clang/test/Sema/wasm-refs.c
@@ -46,6 +46,8 @@
 __externref_t ***illegal_return_2(); // expected-error {{pointer to WebAssembly reference type is not allowed}}
 
 void varargs(int, ...);
+typedef void (*__funcref funcref_t)();
+typedef void (*__funcref __funcref funcref_fail_t)(); // expected-warning {{attribute '__funcref' is already applied}}
 
 __externref_t func(__externref_t ref) {
   &ref; // expected-error {{cannot take address of WebAssembly reference}}
@@ -67,5 +69,7 @@
   _Alignof(__externref_t ***);   // expected-error {{pointer to WebAssembly reference type is not allowed}};
   varargs(1, ref);   // expected-error {{cannot pass expression of type '__externref_t' to variadic function}}
 
+  funcref_t func = __builtin_wasm_ref_null_func(0); // expected-error {{too many arguments to function call, expected 0, have 1}}
+
   return ref;
 }
Index: clang/test/Parser/wasm-funcref.c
===
--- /dev/null
+++ clang/test/Parser/wasm-funcref.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple powerpc-linux-gnu -fsyntax-only -verify %s
+
+// Test that we trigger an error at parse time if using keyword funcref
+// while not using a wasm triple.
+typedef void (*__funcref funcref_t)(); // expected-error {{invalid use of '__funcref' keyword outside the WebAssembly triple}}
+typedef int (*__funcref fn_funcref_t)(int);// expected-error {{invalid use of '__funcref' keyword outside the WebAssembly triple}}
+typedef int (*fn_t)(int);
+
+static fn_funcref_t nullFuncref = 0;
Index: clang/test/CodeGen/WebAssembly/wasm-funcref.c
===
--- /dev/null
+++ clang/test/CodeGen/WebAssembly/wasm-funcref.c
@@ -0,0 +1,99 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple wasm32 -target-feature +reference-types -o - -emit-llvm %s | FileCheck %s
+
+typedef void (*__funcref funcref_t)();
+typedef int (*__funcref fn_funcref_t)(int);
+typedef int (*fn_t)(int);
+
+// Null funcref builtin call
+// CHECK-LABEL: @get_null(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = call ptr addrspace(20) @llvm.wasm.ref.null.func()
+// CHECK-NEXT:ret ptr addrsp

[PATCH] D128440: [WebAssembly] Initial support for reference type funcref in clang

2023-02-13 Thread Paulo Matos via Phabricator via cfe-commits
pmatos updated this revision to Diff 497004.
pmatos added a comment.

Remove unnecessary code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128440

Files:
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/DirectX.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/WebAssembly.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/lib/Format/FormatToken.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseTentative.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/WebAssembly/wasm-funcref.c
  clang/test/Parser/wasm-funcref.c
  clang/test/Sema/wasm-refs.c
  clang/test/SemaTemplate/address_space-dependent.cpp

Index: clang/test/SemaTemplate/address_space-dependent.cpp
===
--- clang/test/SemaTemplate/address_space-dependent.cpp
+++ clang/test/SemaTemplate/address_space-dependent.cpp
@@ -43,7 +43,7 @@
 
 template 
 void tooBig() {
-  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388587)}}
+  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388586)}}
 }
 
 template 
@@ -101,7 +101,7 @@
   car<1, 2, 3>(); // expected-note {{in instantiation of function template specialization 'car<1, 2, 3>' requested here}}
   HasASTemplateFields<1> HASTF;
   neg<-1>(); // expected-note {{in instantiation of function template specialization 'neg<-1>' requested here}}
-  correct<0x7FFFEA>();
+  correct<0x7FFFE9>();
   tooBig<8388650>(); // expected-note {{in instantiation of function template specialization 'tooBig<8388650L>' requested here}}
 
   __attribute__((address_space(1))) char *x;
Index: clang/test/Sema/wasm-refs.c
===
--- clang/test/Sema/wasm-refs.c
+++ clang/test/Sema/wasm-refs.c
@@ -46,6 +46,8 @@
 __externref_t ***illegal_return_2(); // expected-error {{pointer to WebAssembly reference type is not allowed}}
 
 void varargs(int, ...);
+typedef void (*__funcref funcref_t)();
+typedef void (*__funcref __funcref funcref_fail_t)(); // expected-warning {{attribute '__funcref' is already applied}}
 
 __externref_t func(__externref_t ref) {
   &ref; // expected-error {{cannot take address of WebAssembly reference}}
@@ -67,5 +69,7 @@
   _Alignof(__externref_t ***);   // expected-error {{pointer to WebAssembly reference type is not allowed}};
   varargs(1, ref);   // expected-error {{cannot pass expression of type '__externref_t' to variadic function}}
 
+  funcref_t func = __builtin_wasm_ref_null_func(0); // expected-error {{too many arguments to function call, expected 0, have 1}}
+
   return ref;
 }
Index: clang/test/Parser/wasm-funcref.c
===
--- /dev/null
+++ clang/test/Parser/wasm-funcref.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple powerpc-linux-gnu -fsyntax-only -verify %s
+
+// Test that we trigger an error at parse time if using keyword funcref
+// while not using a wasm triple.
+typedef void (*__funcref funcref_t)(); // expected-error {{invalid use of '__funcref' keyword outside the WebAssembly triple}}
+typedef int (*__funcref fn_funcref_t)(int);// expected-error {{invalid use of '__funcref' keyword outside the WebAssembly triple}}
+typedef int (*fn_t)(int);
+
+static fn_funcref_t nullFuncref = 0;
Index: clang/test/CodeGen/WebAssembly/wasm-funcref.c
===
--- /dev/null
+++ clang/test/CodeGen/WebAssembly/wasm-funcref.c
@@ -0,0 +1,99 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple wasm32 -target-feature +reference-types -o - -emit-llvm %s | FileCheck %s
+
+typedef void (*__funcref funcref_t)();
+typedef int (*__funcref fn_funcref_t)(int);
+typedef int (*fn_t)(int);
+
+// Null funcref builtin call
+// CHECK-LABEL: @get_null(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[TMP0:%.*]] = call ptr addrspace(20) @llvm.wasm.ref.null.func()
+// CHECK-NEXT:ret ptr addrspace(20) [[TMP0]]
+//
+funcref_t get_null() {
+  return __builtin_wasm_ref_null

[PATCH] D128440: [WebAssembly] Initial support for reference type funcref in clang

2023-02-13 Thread Paulo Matos via Phabricator via cfe-commits
pmatos marked 2 inline comments as done.
pmatos added inline comments.



Comment at: clang/lib/Sema/SemaType.cpp:7269
+  }
+  Attrs[NewAttrKind] = true;
+

aaron.ballman wrote:
> aaron.ballman wrote:
> > This seems like it's not used.
> Still wondering about this
That's correct - removed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128440

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


[PATCH] D143921: [debug-info][codegen] Prevent creation of self-referential SP node

2023-02-13 Thread Felipe de Azevedo Piovezan via Phabricator via cfe-commits
fdeazeve added a comment.

Any testing suggestions here? I can use what we have on GH (cpp -> codegen 
test), but I'm not sure if there's a finer grained test we could use.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143921

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


[PATCH] D143439: [RISCV] Add vendor-defined XTheadBb (basic bit-manipulation) extension

2023-02-13 Thread Yingchi Long via Phabricator via cfe-commits
inclyc added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:315
+  if (Subtarget.hasVendorXTHeadBb()) {
+setOperationAction({ISD::CTLZ}, XLenVT, Legal);
+

It looks like this line of code will cause compilation warning.

```
[1677/1717] Building CXX object 
lib/Target/RISCV/CMakeFiles/LLVMRISCVCodeGen.dir/RISCVISelLowering.cpp.o
/tmp/llvm-project/llvm/lib/Target/RISCV/RISCVISelLowering.cpp:315:24: warning: 
braces around scalar initializer [-Wbraced-scalar-init]
setOperationAction({ISD::CTLZ}, XLenVT, Legal);
   ^~~
1 warning generated.
[1717/1717] Creating library symlink lib/libclang-cpp.so
[1542/1716] Building CXX object 
lib/Target/RISCV/CMakeFiles/LLVMRISCVCodeGen.dir/RISCVISelLowering.cpp.o
/tmp/llvm-project/llvm/lib/Target/RISCV/RISCVISelLowering.cpp:315:24: warning: 
braces around scalar initializer [-Wbraced-scalar-init]
setOperationAction({ISD::CTLZ}, XLenVT, Legal);
   ^~~
1 warning generated.
[1716/1716] Linking C executable bin/mlir-capi-execution-engine-test
```



Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:320
+if (Subtarget.is64Bit())
+  setOperationAction({ISD::CTLZ, ISD::CTLZ_ZERO_UNDEF}, MVT::i32, Custom);
+  }

And this one


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143439

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


[PATCH] D143439: [RISCV] Add vendor-defined XTheadBb (basic bit-manipulation) extension

2023-02-13 Thread Yingchi Long via Phabricator via cfe-commits
inclyc added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:320
+if (Subtarget.is64Bit())
+  setOperationAction({ISD::CTLZ, ISD::CTLZ_ZERO_UNDEF}, MVT::i32, Custom);
+  }

inclyc wrote:
> And this one
Ah, this is my fault :(. There should be only 1 warning on line 315


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143439

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


[PATCH] D143439: [RISCV] Add vendor-defined XTheadBb (basic bit-manipulation) extension

2023-02-13 Thread Philipp Tomsich via Phabricator via cfe-commits
philipp.tomsich marked 4 inline comments as done.
philipp.tomsich added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:315
+  if (Subtarget.hasVendorXTHeadBb()) {
+setOperationAction({ISD::CTLZ}, XLenVT, Legal);
+

inclyc wrote:
> It looks like this line of code will cause compilation warning.
> 
> ```
> [1677/1717] Building CXX object 
> lib/Target/RISCV/CMakeFiles/LLVMRISCVCodeGen.dir/RISCVISelLowering.cpp.o
> /tmp/llvm-project/llvm/lib/Target/RISCV/RISCVISelLowering.cpp:315:24: 
> warning: braces around scalar initializer [-Wbraced-scalar-init]
> setOperationAction({ISD::CTLZ}, XLenVT, Legal);
>^~~
> 1 warning generated.
> [1717/1717] Creating library symlink lib/libclang-cpp.so
> [1542/1716] Building CXX object 
> lib/Target/RISCV/CMakeFiles/LLVMRISCVCodeGen.dir/RISCVISelLowering.cpp.o
> /tmp/llvm-project/llvm/lib/Target/RISCV/RISCVISelLowering.cpp:315:24: 
> warning: braces around scalar initializer [-Wbraced-scalar-init]
> setOperationAction({ISD::CTLZ}, XLenVT, Legal);
>^~~
> 1 warning generated.
> [1716/1716] Linking C executable bin/mlir-capi-execution-engine-test
> ```
Thanks. I'll push a NFC commit to fix this, as soon as my testrun completes.
Interesting that I don't see this warning on my build ... will dig to make sure 
that we are not missing anything in the future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143439

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


[PATCH] D141666: [RISCV] Proper support of extensions Zicsr and Zifencei

2023-02-13 Thread Philip Reames via Phabricator via cfe-commits
reames added a comment.

JFYI, I have a change out which just documents current status while we wait for 
a resolution.  https://reviews.llvm.org/D143924


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141666

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


[PATCH] D141215: [clang-repl][WIP] Implement pretty printing

2023-02-13 Thread Jun Zhang via Phabricator via cfe-commits
junaire updated this revision to Diff 497011.
junaire added a comment.

Update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141215

Files:
  clang/include/clang/Interpreter/Interpreter.h
  clang/include/clang/Interpreter/Value.h
  clang/include/clang/Parse/Parser.h
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/lib/Interpreter/Value.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Parse/Parser.cpp
  clang/test/Interpreter/pretty-print.cpp
  clang/tools/clang-repl/CMakeLists.txt
  clang/tools/clang-repl/ClangRepl.cpp

Index: clang/tools/clang-repl/ClangRepl.cpp
===
--- clang/tools/clang-repl/ClangRepl.cpp
+++ clang/tools/clang-repl/ClangRepl.cpp
@@ -10,6 +10,7 @@
 //
 //===--===//
 
+#include "clang/AST/Decl.h"
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/FrontendDiagnostic.h"
@@ -18,6 +19,8 @@
 #include "llvm/ExecutionEngine/Orc/LLJIT.h"
 #include "llvm/LineEditor/LineEditor.h"
 #include "llvm/Support/CommandLine.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/ManagedStatic.h" // llvm_shutdown
 #include "llvm/Support/Signals.h"
 #include "llvm/Support/TargetSelect.h" // llvm::Initialize*
@@ -66,6 +69,29 @@
   return (Errs || HasError) ? EXIT_FAILURE : EXIT_SUCCESS;
 }
 
+static void DeclareMagicFunctions(clang::Interpreter &Interp) {
+  llvm::ArrayRef MagicFunctions = {
+  "void __InterpreterCreateValue(void*, void*, bool);",
+  "void __InterpreterCreateValue(void*, void*, char);",
+  "void __InterpreterCreateValue(void*, void*, signed char);",
+  "void __InterpreterCreateValue(void*, void*, short);",
+  "void __InterpreterCreateValue(void*, void*, int);",
+  "void __InterpreterCreateValue(void*, void*, long);",
+  "void __InterpreterCreateValue(void*, void*, long long);",
+  "void __InterpreterCreateValue(void*, void*, unsigned char);",
+  "void __InterpreterCreateValue(void*, void*, unsigned short);",
+  "void __InterpreterCreateValue(void*, void*, unsigned int);",
+  "void __InterpreterCreateValue(void*, void*, unsigned long);",
+  "void __InterpreterCreateValue(void*, void*, unsigned long long);",
+  "void __InterpreterCreateValue(void*, void*, float);",
+  "void __InterpreterCreateValue(void*, void*, double);",
+  "void __InterpreterCreateValue(void*, void*, void*);"};
+
+  for (llvm::StringRef Function : MagicFunctions) {
+llvm::cantFail(Interp.ParseAndExecute(Function));
+  }
+}
+
 llvm::ExitOnError ExitOnErr;
 int main(int argc, const char **argv) {
   ExitOnErr.setBanner("clang-repl: ");
@@ -110,6 +136,7 @@
 
   bool HasError = false;
 
+  DeclareMagicFunctions(*Interp);
   if (OptInputs.empty()) {
 llvm::LineEditor LE("clang-repl");
 // FIXME: Add LE.setListCompleter
Index: clang/tools/clang-repl/CMakeLists.txt
===
--- clang/tools/clang-repl/CMakeLists.txt
+++ clang/tools/clang-repl/CMakeLists.txt
@@ -12,6 +12,7 @@
   )
 
 clang_target_link_libraries(clang-repl PRIVATE
+  clangAST
   clangBasic
   clangFrontend
   clangInterpreter
Index: clang/test/Interpreter/pretty-print.cpp
===
--- /dev/null
+++ clang/test/Interpreter/pretty-print.cpp
@@ -0,0 +1,12 @@
+// RUN: clang-repl "int i = 10;" 'extern "C" int printf(const char*,...);' \
+// RUN:'auto r1 = printf("i = %d\n", i);' | FileCheck --check-prefix=CHECK-DRIVER %s
+// UNSUPPORTED: system-aix
+// CHECK-DRIVER: i = 10
+// RUN: cat %s | clang-repl | FileCheck %s
+int x = 42;
+x
+// CHECK: (int) 42
+x - 2
+// CHECK-NEXT: (int) 40
+%quit
+
Index: clang/lib/Parse/Parser.cpp
===
--- clang/lib/Parse/Parser.cpp
+++ clang/lib/Parse/Parser.cpp
@@ -154,10 +154,20 @@
   return true;
 }
 
-bool Parser::ExpectAndConsumeSemi(unsigned DiagID, StringRef TokenUsed) {
+bool Parser::ExpectAndConsumeSemi(unsigned DiagID, StringRef TokenUsed,
+  bool IsTopExpr) {
   if (TryConsumeToken(tok::semi))
 return false;
 
+  // If this is in the incremental C++ mode, then it means we need to pretty
+  // print this expression. Thus, let's pretend we have this semi and continue
+  // parsing.
+  if (PP.isIncrementalProcessingEnabled() && IsTopExpr &&
+  DiagID == diag::err_expected_semi_after_expr) {
+setPrettyPrintMode();
+return false;
+  }
+
   if (Tok.is(tok::code_completion)) {
 handleUnexpectedCodeCompletionToken();
 return false;
Index: clang/lib/Parse/ParseStmt.cpp

[PATCH] D143768: [Clang] Add options to disable direct linking of arch tools

2023-02-13 Thread Aaron Siddhartha Mondal via Phabricator via cfe-commits
aaronmondal added a subscriber: aaron.ballman.
aaronmondal added a comment.

Ok so I went over 
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#testing-for-the-presence-of-a-header-__has_include
 (thanks, @aaron.ballman 😊) and through the commit history for the amdgpu-arch 
tool.

As I understand, in cases such as standard library headers, these 
`__has_include`s are useful (and are encouraged), (I assume especially for 
header-only libraries). But I'm not convinced that it's the right way to do 
things in the HSA case.

1. If we don't detect this during configuration, we will fail during the build, 
not during configuration. this means that if the hsa CMake package is found but 
the headers are not actually present, we will fail late, potentially *very* 
late in the build.
2. It also seems like the `__has_include`s have continuously been a source of 
confusion, and maybe I'm confused as well, but I think even the current 
implementation after 
https://reviews.llvm.org/rGbfe4514add5b7ab7e1f06248983a7162d734cffb has a bug 
(if DYNAMIC_HSA is not set and hsa is not found, we don't raise a "missing 
hsa.h" error).

@jhuber6 I didn't understand what you mean with linking it into libc. But if 
the performance regression is "ignorable" I'd be in favor of just always using 
`dlopen`.

I also agree with @tianshilei1992 that if this should remain we should 
definitely have configuration for this.

IMO it would be very desirable for every out-of-llvm-tree dependency to be 
checked during configuration. If someone without access to a compile server 
runs an LLVM build that seemingly passes configuration and then fails after 90 
minutes because they had leftover cmake configs their package manager failed to 
clean up it unnecessarily inconveniences the user and we can prevent it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143768

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


[clang] d4021ed - [Tooling/Inclusion] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via cfe-commits

Author: Younan Zhang
Date: 2023-02-14T01:07:39+08:00
New Revision: d4021ed3d79d8823317d894b55f4e6a30cfc3614

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

LOG: [Tooling/Inclusion] Add symbol mappings for `std::experimental::filesystem`

Clangd maintains a symbol map from standard library, in order to prevent
unexpected header/symbol leaks from internal files. (e.g. files under
`bits/` for libstdc++) This symbol map was generated by a python script
that parses pages of offline cppreference archive. The script didn't
handle the case for `std::experimental::`, where most symbols are from
TS. It works well as symbols are directly laid out in the corresponding
header under `experimental` directory for most of time.

However, libstdc++'s implementation split symbols of TS FS into a few
header files located in `experimental/bits`. This would make the code
completion provide internal headers when we simply select the symbols.

There are slightly differences between TS FS and C++17 FS. Some
functions like `system_complete` was replaced by `absolute` and
relative-related operations were introduced later by another proposal.
Even so, all mainstream implementation are based on N4100, the final
filesystem TS draft that was published in 2014 and from which symbols
we've added are exported.

This fixes https://github.com/clangd/clangd/issues/1481

Reviewed By: kadircet

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

Added: 
clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc

Modified: 
clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
clang/unittests/Tooling/StandardLibraryTest.cpp

Removed: 




diff  --git a/clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp 
b/clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
index 2f8537951a0f3..416b53117d16b 100644
--- a/clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
+++ b/clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
@@ -61,8 +61,9 @@ static int countSymbols(Lang Language) {
 #include "CSymbolMap.inc"
 break;
   case Lang::CXX:
-#include "StdSymbolMap.inc"
 #include "StdSpecialSymbolMap.inc"
+#include "StdSymbolMap.inc"
+#include "StdTsSymbolMap.inc"
 break;
   }
 #undef SYMBOL
@@ -130,8 +131,9 @@ static int initialize(Lang Language) {
 #include "CSymbolMap.inc"
 break;
   case Lang::CXX:
-#include "StdSymbolMap.inc"
 #include "StdSpecialSymbolMap.inc"
+#include "StdSymbolMap.inc"
+#include "StdTsSymbolMap.inc"
 break;
   }
 #undef SYMBOL

diff  --git a/clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc 
b/clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
new file mode 100644
index 0..7fd17ed49c72c
--- /dev/null
+++ b/clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
@@ -0,0 +1,54 @@
+// These are derived from N4100[fs.filesystem.synopsis], final
+// draft for experimental filesystem.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )
+SYMBOL(canonical, std::experimental::filesystem::, )
+SYMBOL(copy, std::experimental::filesystem::, )
+SYMBOL(copy_file, std::experimental::filesystem::, )
+SYMBOL(copy_options, std::experimental::filesystem::, 
)
+SYMBOL(copy_symlink, std::experimental::filesystem::, 
)
+SYMBOL(create_directories, std::experimental::filesystem::, 
)
+SYMBOL(create_directory, std::experimental::filesystem::, 
)
+SYMBOL(create_directory_symlink, std::experimental::filesystem::, 
)
+SYMBOL(create_hard_link, std::experimental::filesystem::, 
)
+SYMBOL(create_symlink, std::experimental::filesystem::, 
)
+SYMBOL(current_path, std::experimental::filesystem::, 
)
+SYMBOL(directory_entry, std::experimental::filesystem::, 
)
+SYMBOL(directory_iterator, std::experimental::filesystem::, 
)
+SYMBOL(directory_options, std::experimental::filesystem::, 
)
+SYMBOL(equivalent, std::experimental::filesystem::, )
+SYMBOL(exists, std::experimental::filesystem::, )
+SYMBOL(file_size, std::experimental::filesystem::, )
+SYMBOL(file_status, std::experimental::filesystem::, )
+SYMBOL(file_time_type, std::experimental::filesystem::, 
)
+SYMBOL(file_type, std::experimental::filesystem::, )
+SYMBOL(filesystem_error, std::experimental::filesystem::, 
)
+SYMBOL(hard_link_count, std::experimental::filesystem::, 
)
+SYMBOL(is_block_file, std::experimental::filesystem::, 
)
+SYMBOL(is_character_file, std::experimental::filesystem::, 
)
+SYMBOL(is_directory, std::experimental::filesystem::, 
)
+SYMBOL(is_empty, std::experimental::filesystem::, )
+SYMBOL(is_fifo, std::experimental::filesystem::, )
+SYMBOL(is_other, std::experimental::filesystem::, )
+SYMBOL(is_regular_file, std::experimental::filesystem::, 
)
+SYMBOL(is_socket, std::experimental::filesystem::, )
+SYMBOL(is_symlink, std::experimental::filesystem::, )
+SYMBOL(last_write_time, std::experi

[PATCH] D142836: [Tooling/Inclusion] Add symbol mappings for `std::experimental::filesystem`

2023-02-13 Thread Younan Zhang via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd4021ed3d79d: [Tooling/Inclusion] Add symbol mappings for 
`std::experimental::filesystem` (authored by zyounan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142836

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
  clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
  clang/unittests/Tooling/StandardLibraryTest.cpp

Index: clang/unittests/Tooling/StandardLibraryTest.cpp
===
--- clang/unittests/Tooling/StandardLibraryTest.cpp
+++ clang/unittests/Tooling/StandardLibraryTest.cpp
@@ -79,6 +79,23 @@
   EXPECT_FALSE(stdlib::Header::named("", stdlib::Lang::CXX));
 }
 
+TEST(StdlibTest, Experimental) {
+  EXPECT_FALSE(
+  stdlib::Header::named("", stdlib::Lang::C));
+  EXPECT_TRUE(
+  stdlib::Header::named("", stdlib::Lang::CXX));
+
+  auto Symbol = stdlib::Symbol::named("std::experimental::filesystem::",
+  "system_complete");
+  EXPECT_TRUE(Symbol);
+  EXPECT_EQ(Symbol->scope(), "std::experimental::filesystem::");
+  EXPECT_EQ(Symbol->name(), "system_complete");
+  EXPECT_EQ(Symbol->header(),
+stdlib::Header::named(""));
+  EXPECT_EQ(Symbol->qualifiedName(),
+"std::experimental::filesystem::system_complete");
+}
+
 TEST(StdlibTest, CCompat) {
   EXPECT_THAT(
   stdlib::Symbol::named("", "int16_t", stdlib::Lang::CXX)->headers(),
Index: clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
===
--- /dev/null
+++ clang/lib/Tooling/Inclusions/Stdlib/StdTsSymbolMap.inc
@@ -0,0 +1,54 @@
+// These are derived from N4100[fs.filesystem.synopsis], final
+// draft for experimental filesystem.
+// clang-format off
+SYMBOL(absolute, std::experimental::filesystem::, )
+SYMBOL(canonical, std::experimental::filesystem::, )
+SYMBOL(copy, std::experimental::filesystem::, )
+SYMBOL(copy_file, std::experimental::filesystem::, )
+SYMBOL(copy_options, std::experimental::filesystem::, )
+SYMBOL(copy_symlink, std::experimental::filesystem::, )
+SYMBOL(create_directories, std::experimental::filesystem::, )
+SYMBOL(create_directory, std::experimental::filesystem::, )
+SYMBOL(create_directory_symlink, std::experimental::filesystem::, )
+SYMBOL(create_hard_link, std::experimental::filesystem::, )
+SYMBOL(create_symlink, std::experimental::filesystem::, )
+SYMBOL(current_path, std::experimental::filesystem::, )
+SYMBOL(directory_entry, std::experimental::filesystem::, )
+SYMBOL(directory_iterator, std::experimental::filesystem::, )
+SYMBOL(directory_options, std::experimental::filesystem::, )
+SYMBOL(equivalent, std::experimental::filesystem::, )
+SYMBOL(exists, std::experimental::filesystem::, )
+SYMBOL(file_size, std::experimental::filesystem::, )
+SYMBOL(file_status, std::experimental::filesystem::, )
+SYMBOL(file_time_type, std::experimental::filesystem::, )
+SYMBOL(file_type, std::experimental::filesystem::, )
+SYMBOL(filesystem_error, std::experimental::filesystem::, )
+SYMBOL(hard_link_count, std::experimental::filesystem::, )
+SYMBOL(is_block_file, std::experimental::filesystem::, )
+SYMBOL(is_character_file, std::experimental::filesystem::, )
+SYMBOL(is_directory, std::experimental::filesystem::, )
+SYMBOL(is_empty, std::experimental::filesystem::, )
+SYMBOL(is_fifo, std::experimental::filesystem::, )
+SYMBOL(is_other, std::experimental::filesystem::, )
+SYMBOL(is_regular_file, std::experimental::filesystem::, )
+SYMBOL(is_socket, std::experimental::filesystem::, )
+SYMBOL(is_symlink, std::experimental::filesystem::, )
+SYMBOL(last_write_time, std::experimental::filesystem::, )
+SYMBOL(path, std::experimental::filesystem::, )
+SYMBOL(permissions, std::experimental::filesystem::, )
+SYMBOL(perms, std::experimental::filesystem::, )
+SYMBOL(read_symlink, std::experimental::filesystem::, )
+SYMBOL(recursive_directory_iterator, std::experimental::filesystem::, )
+SYMBOL(remove, std::experimental::filesystem::, )
+SYMBOL(remove_all, std::experimental::filesystem::, )
+SYMBOL(rename, std::experimental::filesystem::, )
+SYMBOL(resize_file, std::experimental::filesystem::, )
+SYMBOL(space, std::experimental::filesystem::, )
+SYMBOL(space_info, std::experimental::filesystem::, )
+SYMBOL(status, std::experimental::filesystem::, )
+SYMBOL(status_known, std::experimental::filesystem::, )
+SYMBOL(symlink_status, std::experimental::filesystem::, )
+SYMBOL(system_complete, std::experimental::filesystem::, )
+SYMBOL(temp_directory_path, std::experimental::filesystem::, )
+SYMBOL(u8path, std::experimental::filesystem::, )
+// clang-format on
Index: clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
===
--- clang/lib/Tooling/Inclusions/Stdlib/StandardLibrary.cpp
+++ clang/lib/Tooling/Inc

[PATCH] D143891: [Clang] Adjust triviality computation in QualType::isTrivialType to C++20 cases.

2023-02-13 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added a comment.

In D143891#4122731 , @aaron.ballman 
wrote:

> In D143891#4122668 , @royjacobson 
> wrote:
>
>> In D143891#4122660 , 
>> @aaron.ballman wrote:
>>
>>> This is an ABI breaking change, isn't it? (The type trait now returns 
>>> something different than it did before, which could change instantiations 
>>> or object layout.)
>>
>> Technically it is, but it only affects code that relies on constrained 
>> default constructors, which we're only going to support in Clang 16. So if 
>> we backport this to 16 it's not very problematic.
>
> Hmmm, if it's true that this only changes the behavior of a type with a 
> constrained default constructor, then I think it's fine despite being an ABI 
> break (we never claimed full support for concepts, so anyone relying on a 
> particular behavior was mistaken to do that). I can't quite convince myself 
> this doesn't impact other cases though -- the logic for computing triviality 
> is nontrivial itself (pun intended), so I'm really only concerned that 
> `__is_trivial` and friends return a different value for a non-constrained 
> type. However, I also can't come up with a test case whose behavior changes 
> either.

I think this makes sense.




Comment at: clang/lib/AST/Type.cpp:2495
+  // FIXME: We should merge this definition of triviality into
+  // CXXRecordDecl::isTrivial. Currently it computes the wrong thing.
+  return ClassDecl->hasTrivialDefaultConstructor() &&

Will you follow-up this change by updating `CXXRecordDecl::isTrivial` as well 
or is that a more difficult issue?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143891

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


[clang] b6259ec - [Clang] Export CanPassInRegisters as a type trait

2023-02-13 Thread Roy Jacobson via cfe-commits

Author: Roy Jacobson
Date: 2023-02-13T19:16:23+02:00
New Revision: b6259eca16f6c923d87a1ca1d424931e37d6871a

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

LOG: [Clang] Export CanPassInRegisters as a type trait

While working on D140664, I thought it would be nice to be able to write tests
for parameter passing ABI. Currently we test this by dumping the AST and
matching the results which makes it hard to write new tests.
Adding this builtin will allow writing better ABI tests which
can help improve our coverage in this area.

While less useful, maybe some users would also find it useful for asserting
against pessimisations for their classes.

Reviewed By: erichkeane

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

Added: 


Modified: 
clang/docs/LanguageExtensions.rst
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Basic/TokenKinds.def
clang/lib/Sema/SemaExprCXX.cpp
clang/test/SemaCXX/type-traits.cpp

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 84d5b0ed98108..20c8bb5de0443 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -1401,6 +1401,10 @@ The following type trait primitives are supported by 
Clang. Those traits marked
 * ``__array_extent(type, dim)`` (Embarcadero):
   The ``dim``'th array bound in the type ``type``, or ``0`` if
   ``dim >= __array_rank(type)``.
+* ``__can_pass_in_regs`` (C++)
+  Returns whether a class can be passed in registers under the current
+  ABI. This type can only be applied to unqualified class types.
+  This is not a portable type trait.
 * ``__has_nothrow_assign`` (GNU, Microsoft, Embarcadero):
   Deprecated, use ``__is_nothrow_assignable`` instead.
 * ``__has_nothrow_move_assign`` (GNU, Microsoft):

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 9b9ec23a2f21f..b658ad71e63a1 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11794,4 +11794,8 @@ def note_unsafe_buffer_variable_fixit : Note<
   "change type of '%0' to '%select{std::span|std::array|std::span::iterator}1' 
to preserve bounds information">;
 def err_loongarch_builtin_requires_la32 : Error<
   "this builtin requires target: loongarch32">;
+
+def err_builtin_pass_in_regs_non_class : Error<
+  "argument %0 is not an unqualified class type">;
+
 } // end of sema component.

diff  --git a/clang/include/clang/Basic/TokenKinds.def 
b/clang/include/clang/Basic/TokenKinds.def
index 96feae991ccbc..6d35f1bb31fcd 100644
--- a/clang/include/clang/Basic/TokenKinds.def
+++ b/clang/include/clang/Basic/TokenKinds.def
@@ -523,6 +523,7 @@ TYPE_TRAIT_1(__is_unbounded_array, IsUnboundedArray, KEYCXX)
 TYPE_TRAIT_1(__is_nullptr, IsNullPointer, KEYCXX)
 TYPE_TRAIT_1(__is_scoped_enum, IsScopedEnum, KEYCXX)
 TYPE_TRAIT_1(__is_referenceable, IsReferenceable, KEYCXX)
+TYPE_TRAIT_1(__can_pass_in_regs, CanPassInRegs, KEYCXX)
 TYPE_TRAIT_2(__reference_binds_to_temporary, ReferenceBindsToTemporary, KEYCXX)
 
 // Embarcadero Expression Traits

diff  --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index ef012770747ca..eb9a3e65763f2 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -4885,6 +4885,7 @@ static bool CheckUnaryTypeTraitTypeCompleteness(Sema &S, 
TypeTrait UTT,
   case UTT_IsLiteral:
   // By analogy, is_trivially_relocatable imposes the same constraints.
   case UTT_IsTriviallyRelocatable:
+  case UTT_CanPassInRegs:
   // Per the GCC type traits documentation, T shall be a complete type, cv 
void,
   // or an array of unknown bound. But GCC actually imposes the same 
constraints
   // as above.
@@ -5373,6 +5374,11 @@ static bool EvaluateUnaryTypeTrait(Sema &Self, TypeTrait 
UTT,
 return T.isTriviallyRelocatableType(C);
   case UTT_IsReferenceable:
 return T.isReferenceable();
+  case UTT_CanPassInRegs:
+if (CXXRecordDecl *RD = T->getAsCXXRecordDecl(); RD && !T.hasQualifiers())
+  return RD->canPassInRegisters();
+Self.Diag(KeyLoc, diag::err_builtin_pass_in_regs_non_class) << T;
+return false;
   }
 }
 

diff  --git a/clang/test/SemaCXX/type-traits.cpp 
b/clang/test/SemaCXX/type-traits.cpp
index 76a67252c9410..7d425acb56813 100644
--- a/clang/test/SemaCXX/type-traits.cpp
+++ b/clang/test/SemaCXX/type-traits.cpp
@@ -3055,6 +3055,36 @@ 
static_assert(__is_trivially_relocatable(TrivialAbiNontrivialMoveCtor[]), "");
 
 } // namespace is_trivially_relocatable
 
+namespace can_pass_in_regs {
+
+struct A { };
+
+struct B {
+  ~B();
+};
+
+struct C; // expected-note {{forward declaration}}
+
+union D {
+  int x;
+};
+
+static_assert(__can_pass_in_

[PATCH] D141775: [Clang] Export CanPassInRegisters as a type trait

2023-02-13 Thread Roy Jacobson via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGb6259eca16f6: [Clang] Export CanPassInRegisters as a type 
trait (authored by royjacobson).

Changed prior to commit:
  https://reviews.llvm.org/D141775?vs=491102&id=497016#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141775

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/SemaCXX/type-traits.cpp

Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -3055,6 +3055,36 @@
 
 } // namespace is_trivially_relocatable
 
+namespace can_pass_in_regs {
+
+struct A { };
+
+struct B {
+  ~B();
+};
+
+struct C; // expected-note {{forward declaration}}
+
+union D {
+  int x;
+};
+
+static_assert(__can_pass_in_regs(A), "");
+static_assert(__can_pass_in_regs(A), "");
+static_assert(!__can_pass_in_regs(B), "");
+static_assert(__can_pass_in_regs(D), "");
+
+void test_errors() {
+  (void)__can_pass_in_regs(const A); // expected-error {{not an unqualified class type}}
+  (void)__can_pass_in_regs(A&); // expected-error {{not an unqualified class type}}
+  (void)__can_pass_in_regs(A&&); // expected-error {{not an unqualified class type}}
+  (void)__can_pass_in_regs(const A&); // expected-error {{not an unqualified class type}}
+  (void)__can_pass_in_regs(C); // expected-error {{incomplete type}}
+  (void)__can_pass_in_regs(int); // expected-error {{not an unqualified class type}}
+  (void)__can_pass_in_regs(int&); // expected-error {{not an unqualified class type}}
+}
+}
+
 struct S {};
 template  using remove_const_t = __remove_const(T);
 
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -4885,6 +4885,7 @@
   case UTT_IsLiteral:
   // By analogy, is_trivially_relocatable imposes the same constraints.
   case UTT_IsTriviallyRelocatable:
+  case UTT_CanPassInRegs:
   // Per the GCC type traits documentation, T shall be a complete type, cv void,
   // or an array of unknown bound. But GCC actually imposes the same constraints
   // as above.
@@ -5373,6 +5374,11 @@
 return T.isTriviallyRelocatableType(C);
   case UTT_IsReferenceable:
 return T.isReferenceable();
+  case UTT_CanPassInRegs:
+if (CXXRecordDecl *RD = T->getAsCXXRecordDecl(); RD && !T.hasQualifiers())
+  return RD->canPassInRegisters();
+Self.Diag(KeyLoc, diag::err_builtin_pass_in_regs_non_class) << T;
+return false;
   }
 }
 
Index: clang/include/clang/Basic/TokenKinds.def
===
--- clang/include/clang/Basic/TokenKinds.def
+++ clang/include/clang/Basic/TokenKinds.def
@@ -523,6 +523,7 @@
 TYPE_TRAIT_1(__is_nullptr, IsNullPointer, KEYCXX)
 TYPE_TRAIT_1(__is_scoped_enum, IsScopedEnum, KEYCXX)
 TYPE_TRAIT_1(__is_referenceable, IsReferenceable, KEYCXX)
+TYPE_TRAIT_1(__can_pass_in_regs, CanPassInRegs, KEYCXX)
 TYPE_TRAIT_2(__reference_binds_to_temporary, ReferenceBindsToTemporary, KEYCXX)
 
 // Embarcadero Expression Traits
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -11794,4 +11794,8 @@
   "change type of '%0' to '%select{std::span|std::array|std::span::iterator}1' to preserve bounds information">;
 def err_loongarch_builtin_requires_la32 : Error<
   "this builtin requires target: loongarch32">;
+
+def err_builtin_pass_in_regs_non_class : Error<
+  "argument %0 is not an unqualified class type">;
+
 } // end of sema component.
Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -1401,6 +1401,10 @@
 * ``__array_extent(type, dim)`` (Embarcadero):
   The ``dim``'th array bound in the type ``type``, or ``0`` if
   ``dim >= __array_rank(type)``.
+* ``__can_pass_in_regs`` (C++)
+  Returns whether a class can be passed in registers under the current
+  ABI. This type can only be applied to unqualified class types.
+  This is not a portable type trait.
 * ``__has_nothrow_assign`` (GNU, Microsoft, Embarcadero):
   Deprecated, use ``__is_nothrow_assignable`` instead.
 * ``__has_nothrow_move_assign`` (GNU, Microsoft):
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141808: [Driver] Add --vfsoverlay flag

2023-02-13 Thread Alex Brachet via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGdf5beebc98bb: [Driver] Add --vfsoverlay flag (authored by 
abrachet).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D141808?vs=489839&id=497022#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141808

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/msvc-link.c
  clang/test/Driver/vfsoverlay.c


Index: clang/test/Driver/vfsoverlay.c
===
--- clang/test/Driver/vfsoverlay.c
+++ clang/test/Driver/vfsoverlay.c
@@ -1,5 +1,8 @@
 // RUN: %clang -ivfsoverlay foo.h -### %s 2>&1 | FileCheck %s
 // CHECK: "-ivfsoverlay" "foo.h"
 
+// RUN: %clang --vfsoverlay foo.h -### %s 2>&1 | FileCheck %s 
--check-prefix=CHECK2
+// CHECK2: "--vfsoverlay" "foo.h"
+
 // RUN: not %clang -ivfsoverlay foo.h %s 2>&1 | FileCheck 
-check-prefix=CHECK-MISSING %s
 // CHECK-MISSING: virtual filesystem overlay file 'foo.h' not found
Index: clang/test/Driver/msvc-link.c
===
--- clang/test/Driver/msvc-link.c
+++ clang/test/Driver/msvc-link.c
@@ -30,3 +30,9 @@
 // NOREPRO: "-out:msvc-link.exe"
 // NOREPRO: "-nologo"
 // NOREPRO-NOT: "-Brepro"
+
+// RUN: %clang_cl -fuse-ld=lld --vfsoverlay %s -### -- %s 2>&1 | FileCheck 
--check-prefix=VFSOVERLAY %s
+// VFSOVERLAY: -cc1"
+// VFSOVERLAY: "--vfsoverlay"
+// VFSOVERLAY: lld-link"
+// VFSOVERLAY: "/vfsoverlay:
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3167,7 +3167,7 @@
 Opts.AddSystemHeaderPrefix(
 A->getValue(), A->getOption().matches(OPT_system_header_prefix));
 
-  for (const auto *A : Args.filtered(OPT_ivfsoverlay))
+  for (const auto *A : Args.filtered(OPT_ivfsoverlay, OPT_vfsoverlay))
 Opts.AddVFSOverlayFile(A->getValue());
 
   return Diags.getNumErrors() == NumErrorsBefore;
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -312,6 +312,11 @@
   if (Linker.equals_insensitive("lld"))
 Linker = "lld-link";
 
+  if (Linker == "lld-link")
+for (Arg *A : Args.filtered(options::OPT_vfsoverlay))
+  CmdArgs.push_back(
+  Args.MakeArgString(std::string("/vfsoverlay:") + A->getValue()));
+
   if (Linker.equals_insensitive("link")) {
 // If we're using the MSVC linker, it's not sufficient to just use link
 // from the program PATH, because other environments like GnuWin32 install
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -7038,6 +7038,13 @@
 A->claim();
   }
 
+  // Forward --vfsoverlay to -cc1.
+  for (const Arg *A : Args.filtered(options::OPT_vfsoverlay)) {
+CmdArgs.push_back("--vfsoverlay");
+CmdArgs.push_back(A->getValue());
+A->claim();
+  }
+
   // Setup statistics file output.
   SmallString<128> StatsFile = getStatsFileName(Args, Output, Input, D);
   if (!StatsFile.empty())
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3400,6 +3400,9 @@
   Flags<[CC1Option]>;
 def ivfsoverlay : JoinedOrSeparate<["-"], "ivfsoverlay">, 
Group, Flags<[CC1Option]>,
   HelpText<"Overlay the virtual filesystem described by file over the real 
file system">;
+def vfsoverlay : JoinedOrSeparate<["-", "--"], "vfsoverlay">, 
Flags<[CC1Option, CoreOption]>,
+  HelpText<"Overlay the virtual filesystem described by file over the real 
file system. "
+   "Additionally, pass this overlay file to the linker if it supports 
it">;
 def imultilib : Separate<["-"], "imultilib">, Group;
 def keep__private__externs : Flag<["-"], "keep_private_externs">;
 def l : JoinedOrSeparate<["-"], "l">, Flags<[LinkerInput, RenderJoined]>,


Index: clang/test/Driver/vfsoverlay.c
===
--- clang/test/Driver/vfsoverlay.c
+++ clang/test/Driver/vfsoverlay.c
@@ -1,5 +1,8 @@
 // RUN: %clang -ivfsoverlay foo.h -### %s 2>&1 | FileCheck %s
 // CHECK: "-ivfsoverlay" "foo.h"
 
+// RUN: %clang --vfsoverlay foo.h -### %s 2>&1 | FileCheck %s --check-prefix=CHECK2
+// CHECK2: "--vfsoverlay" "foo.h"
+
 // RUN: not %clang -ivfsoverlay foo.h %s 2>&

[clang] df5beeb - [Driver] Add --vfsoverlay flag

2023-02-13 Thread Alex Brachet via cfe-commits

Author: Alex Brachet
Date: 2023-02-13T17:25:45Z
New Revision: df5beebc98bbe76312e3a416d5fbc563c037923c

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

LOG: [Driver] Add --vfsoverlay flag

This flag implies `-ivfsoverlay`, and additionally passes the same
argument to the linker if it supports it. At present the only linker
which does is lld-link, so this functionality has only been added to
the MSVC toolchain. Additionally this option has been made a
CoreOption so that clang-cl can use it without `-Xclang`

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/MSVC.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/Driver/msvc-link.c
clang/test/Driver/vfsoverlay.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 96904518a51d7..9b7f30454534b 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3400,6 +3400,9 @@ def iwithsysroot : JoinedOrSeparate<["-"], 
"iwithsysroot">, Group
   Flags<[CC1Option]>;
 def ivfsoverlay : JoinedOrSeparate<["-"], "ivfsoverlay">, 
Group, Flags<[CC1Option]>,
   HelpText<"Overlay the virtual filesystem described by file over the real 
file system">;
+def vfsoverlay : JoinedOrSeparate<["-", "--"], "vfsoverlay">, 
Flags<[CC1Option, CoreOption]>,
+  HelpText<"Overlay the virtual filesystem described by file over the real 
file system. "
+   "Additionally, pass this overlay file to the linker if it supports 
it">;
 def imultilib : Separate<["-"], "imultilib">, Group;
 def keep__private__externs : Flag<["-"], "keep_private_externs">;
 def l : JoinedOrSeparate<["-"], "l">, Flags<[LinkerInput, RenderJoined]>,

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index c97856a47686a..7b91fdf933286 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -7038,6 +7038,13 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
 A->claim();
   }
 
+  // Forward --vfsoverlay to -cc1.
+  for (const Arg *A : Args.filtered(options::OPT_vfsoverlay)) {
+CmdArgs.push_back("--vfsoverlay");
+CmdArgs.push_back(A->getValue());
+A->claim();
+  }
+
   // Setup statistics file output.
   SmallString<128> StatsFile = getStatsFileName(Args, Output, Input, D);
   if (!StatsFile.empty())

diff  --git a/clang/lib/Driver/ToolChains/MSVC.cpp 
b/clang/lib/Driver/ToolChains/MSVC.cpp
index 223a4e8a1560f..13a7a2f47cf49 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -312,6 +312,11 @@ void visualstudio::Linker::ConstructJob(Compilation &C, 
const JobAction &JA,
   if (Linker.equals_insensitive("lld"))
 Linker = "lld-link";
 
+  if (Linker == "lld-link")
+for (Arg *A : Args.filtered(options::OPT_vfsoverlay))
+  CmdArgs.push_back(
+  Args.MakeArgString(std::string("/vfsoverlay:") + A->getValue()));
+
   if (Linker.equals_insensitive("link")) {
 // If we're using the MSVC linker, it's not sufficient to just use link
 // from the program PATH, because other environments like GnuWin32 install

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 86717cc6ebfbf..84b2345266036 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -3167,7 +3167,7 @@ static bool ParseHeaderSearchArgs(HeaderSearchOptions 
&Opts, ArgList &Args,
 Opts.AddSystemHeaderPrefix(
 A->getValue(), A->getOption().matches(OPT_system_header_prefix));
 
-  for (const auto *A : Args.filtered(OPT_ivfsoverlay))
+  for (const auto *A : Args.filtered(OPT_ivfsoverlay, OPT_vfsoverlay))
 Opts.AddVFSOverlayFile(A->getValue());
 
   return Diags.getNumErrors() == NumErrorsBefore;

diff  --git a/clang/test/Driver/msvc-link.c b/clang/test/Driver/msvc-link.c
index 1ee17fc63c321..52efaf5ece266 100644
--- a/clang/test/Driver/msvc-link.c
+++ b/clang/test/Driver/msvc-link.c
@@ -30,3 +30,9 @@
 // NOREPRO: "-out:msvc-link.exe"
 // NOREPRO: "-nologo"
 // NOREPRO-NOT: "-Brepro"
+
+// RUN: %clang_cl -fuse-ld=lld --vfsoverlay %s -### -- %s 2>&1 | FileCheck 
--check-prefix=VFSOVERLAY %s
+// VFSOVERLAY: -cc1"
+// VFSOVERLAY: "--vfsoverlay"
+// VFSOVERLAY: lld-link"
+// VFSOVERLAY: "/vfsoverlay:

diff  --git a/clang/test/Driver/vfsoverlay.c b/clang/test/Driver/vfsoverlay.c
index 6ae494544f9fd..694cf623c4476 100644
--- a/clang/test/Driver/vfsoverlay.c
+++ b/clang/test/Driver/vfsoverlay.c
@@ -1,5 +1,8 @@
 // RUN: %clang -ivfsoverlay foo.h -### %s 2>&1 | FileCheck %s
 // CHECK: "-ivfsoverlay

[PATCH] D141698: doc: Rewrite opening paragraph of CFI Design Doc

2023-02-13 Thread Shao-Ce SUN via Phabricator via cfe-commits
sunshaoce added a comment.

I tend to keep it as it is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141698

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


[clang] 756395f - [clang] fix DR status in cxx_status.html

2023-02-13 Thread Corentin Jabot via cfe-commits

Author: Corentin Jabot
Date: 2023-02-13T09:30:57-08:00
New Revision: 756395f61b90e30c9087b5efa8b4809ab03aff6e

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

LOG: [clang] fix DR status in cxx_status.html

Added: 


Modified: 
clang/www/cxx_status.html

Removed: 




diff  --git a/clang/www/cxx_status.html b/clang/www/cxx_status.html
index 729135deced82..f93a788aa0d7a 100755
--- a/clang/www/cxx_status.html
+++ b/clang/www/cxx_status.html
@@ -1203,12 +1203,11 @@ C++20 implementation status
 Partial
   

-https://wg21.link/P2615R1";>P2615R1
+https://wg21.link/P2615R1";>P2615R1 (DR)
 No
   

-https://wg21.link/P2788R0";>P2788R0
-
+https://wg21.link/P2788R0";>P2788R0 (DR)
 No
   
 
@@ -1530,13 +1529,13 @@ C++2b implementation status
   Clang 16
 
 
-  Permitting static constexpr variables in constexpr functions 
(DR)
+  Permitting static constexpr variables in constexpr functions
   https://wg21.link/P2647R1";>P2647R1
   Clang 16
 
 
-  consteval needs to propagate up (DR)
-  https://wg21.link/P2564R3";>P2564R3
+  consteval needs to propagate up
+  https://wg21.link/P2564R3";>P2564R3 (DR)
   No
 
 
@@ -1546,9 +1545,9 @@ C++2b implementation status
 
 
 
-  Static and explicit object member functions with the same 
parameter-type-lists
-  https://wg21.link/P2797R0";>P2797R0
-  No
+  Referencing The Unicode Standard
+  https://wg21.link/P2736R2";>P2736R2
+  Yes
 
 
 



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


[PATCH] D143418: [libclang] Add API to set preferred temp dir path

2023-02-13 Thread Igor Kushnir via Phabricator via cfe-commits
vedgy added a comment.

In D143418#4122821 , @aaron.ballman 
wrote:

>> How about including existing options, which //should// be set in 
>> constructor, in the initial struct version and deprecating the corresponding 
>> setters?
>
> I think that makes a lot of sense.

How to deprecate the setters? Add `DEPRECATED` in the documentations as is 
already done in two places in //Index.h//?

>>   `const char *preferredTempDirPath;`
>
> In terms of documenting the structure, should we document this member as only 
> impacting preamble files currently, should we rename this to be preamble-path 
> specific, or should we try to use this preferred path in all the places we 
> need the temp directory?
>
> (I lean towards renaming to preamble-path specific -- then users don't have 
> the problem of upgrading to a newer CIndex potentially changing the behavior 
> of where non-preamble files are stored, and we don't have to do the work 
> up-front to audit other temp file uses.)

Looks like an imperfect general implementation is unacceptable. So I'll rename 
this data member to `PreambleStoragePath`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143418

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


[PATCH] D140795: [Flang] Add user option -funderscoring/-fnounderscoring to control trailing underscore added to external names

2023-02-13 Thread Mark Danial via Phabricator via cfe-commits
madanial updated this revision to Diff 497024.
madanial added a comment.

Addressing the review comments relating to the test case. Thanks for the catch!


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

https://reviews.llvm.org/D140795

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/CodeGenOptions.def
  flang/include/flang/Optimizer/Transforms/Passes.h
  flang/include/flang/Optimizer/Transforms/Passes.td
  flang/include/flang/Tools/CLOptions.inc
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/Optimizer/Transforms/ExternalNameConversion.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/underscoring.f90
  flang/test/Fir/external-mangling.fir

Index: flang/test/Fir/external-mangling.fir
===
--- flang/test/Fir/external-mangling.fir
+++ flang/test/Fir/external-mangling.fir
@@ -1,6 +1,9 @@
-// RUN: fir-opt --external-name-interop %s | FileCheck %s
-// RUN: tco --external-name-interop %s | FileCheck %s
-// RUN: tco --external-name-interop %s | tco --fir-to-llvm-ir | FileCheck %s --check-prefix=LLVMIR
+// RUN: fir-opt --external-name-interop="append-underscore=true" %s | FileCheck %s --check-prefix=CHECK-UNDER
+// RUN: fir-opt --external-name-interop="append-underscore=false" %s | FileCheck %s --check-prefix=CHECK-NOUNDER
+// RUN: tco --external-name-interop="append-underscore=true" %s | FileCheck %s --check-prefix=CHECK-UNDER
+// RUN: tco --external-name-interop="append-underscore=false" %s | FileCheck %s --check-prefix=CHECK-NOUNDER
+// RUN: tco --external-name-interop="append-underscore=true" %s | tco --fir-to-llvm-ir | FileCheck %s --check-prefix=LLVMIR-UNDER
+// RUN: tco --external-name-interop="append-underscore=false" %s | tco --fir-to-llvm-ir | FileCheck %s --check-prefix=LLVMIR-NOUNDER
 
 func.func @_QPfoo() {
   %c0 = arith.constant 0 : index
@@ -21,24 +24,43 @@
 func.func private @_QPbar(!fir.ref)
 func.func private @_QPbar2(!fir.ref)
 
-// CHECK: func @foo_
-// CHECK: %{{.*}} = fir.address_of(@a_) : !fir.ref>
-// CHECK: %{{.*}} = fir.address_of(@__BLNK__) : !fir.ref>
-// CHECK: fir.call @bar_
-// CHECK: fir.call @bar2_
-// CHECK: fir.global common @a_(dense<0> : vector<4xi8>) : !fir.array<4xi8>
-// CHECK: fir.global common @__BLNK__(dense<0> : vector<4xi8>) : !fir.array<4xi8>
-// CHECK: func private @bar_(!fir.ref)
-
-// LLVMIR: %{{.*}} = llvm.mlir.addressof @a_ : !llvm.ptr>
-// LLVMIR: %{{.*}} = llvm.mlir.addressof @__BLNK__ : !llvm.ptr>
-// LLVMIR: llvm.call @bar_(%{{.*}}) : (!llvm.ptr) -> ()
-// LLVMIR: llvm.call @bar2_(%{{.*}}) : (!llvm.ptr) -> ()
-
-// LLVMIR: llvm.mlir.global common @a_(dense<0> : vector<4xi8>) {{.*}} : !llvm.array<4 x i8>
-// LLVMIR: llvm.mlir.global common @__BLNK__(dense<0> : vector<4xi8>) {{.*}}  : !llvm.array<4 x i8>
-// LLVMIR: llvm.func @bar_(!llvm.ptr) attributes {sym_visibility = "private"}
-// LLVMIR: llvm.func @bar2_(!llvm.ptr) attributes {sym_visibility = "private"}
+// CHECK-UNDER: func @foo_
+// CHECK-UNDER: %{{.*}} = fir.address_of(@a_) : !fir.ref>
+// CHECK-UNDER: %{{.*}} = fir.address_of(@__BLNK__) : !fir.ref>
+// CHECK-UNDER: fir.call @bar_
+// CHECK-UNDER: fir.call @bar2_
+// CHECK-UNDER: fir.global common @a_(dense<0> : vector<4xi8>) : !fir.array<4xi8>
+// CHECK-UNDER: fir.global common @__BLNK__(dense<0> : vector<4xi8>) : !fir.array<4xi8>
+// CHECK-UNDER: func private @bar_(!fir.ref)
+
+// CHECK-NOUNDER: func @foo(
+// CHECK-NOUNDER: %{{.*}} = fir.address_of(@a) : !fir.ref>
+// CHECK-NOUNDER: %{{.*}} = fir.address_of(@__BLNK__) : !fir.ref>
+// CHECK-NOUNDER: fir.call @bar(
+// CHECK-NOUNDER: fir.call @bar2(
+// CHECK-NOUNDER: fir.global common @a(dense<0> : vector<4xi8>) : !fir.array<4xi8>
+// CHECK-NOUNDER: fir.global common @__BLNK__(dense<0> : vector<4xi8>) : !fir.array<4xi8>
+// CHECK-NOUNDER: func private @bar(!fir.ref)
+
+// LLVMIR-UNDER: %{{.*}} = llvm.mlir.addressof @a_ : !llvm.ptr>
+// LLVMIR-UNDER: %{{.*}} = llvm.mlir.addressof @__BLNK__ : !llvm.ptr>
+// LLVMIR-UNDER: llvm.call @bar_(%{{.*}}) : (!llvm.ptr) -> ()
+// LLVMIR-UNDER: llvm.call @bar2_(%{{.*}}) : (!llvm.ptr) -> ()
+
+// LLVMIR-UNDER: llvm.mlir.global common @a_(dense<0> : vector<4xi8>) {{.*}} : !llvm.array<4 x i8>
+// LLVMIR-UNDER: llvm.mlir.global common @__BLNK__(dense<0> : vector<4xi8>) {{.*}}  : !llvm.array<4 x i8>
+// LLVMIR-UNDER: llvm.func @bar_(!llvm.ptr) attributes {sym_visibility = "private"}
+// LLVMIR-UNDER: llvm.func @bar2_(!llvm.ptr) attributes {sym_visibility = "private"}
+
+// LLVMIR-NOUNDER: %{{.*}} = llvm.mlir.addressof @a : !llvm.ptr>
+// LLVMIR-NOUNDER: %{{.*}} = llvm.mlir.addressof @__BLNK__ : !llvm.ptr>
+// LLVMIR-NOUNDER: llvm.call @bar(%{{.*}}) : (!llvm.ptr) -> ()
+// LLVMIR-NOUNDER: llvm.call @bar2(%{{.*}}) : (!llvm.ptr) -> ()
+
+// LLVMIR-NOUNDER: llvm.mlir.global common @a(dense<0> : vector<4xi8>) {{.*}} : !ll

[PATCH] D143260: [clangd] Add semantic token for labels

2023-02-13 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a comment.

FWIW, I agree that switch labels and goto labels are conceptually quite 
different: the thing before a switch label is an expression, and if it's an 
identifier it references an already-declared entity with its own kind (e.g. 
enumerator), whereas a goto label basically declares a new entity of a special 
kind (which can then be referenced from `goto` statements); having a distint 
color for that kind would make sense to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143260

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


[PATCH] D143891: [Clang] Adjust triviality computation in QualType::isTrivialType to C++20 cases.

2023-02-13 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson added inline comments.



Comment at: clang/lib/AST/Type.cpp:2495
+  // FIXME: We should merge this definition of triviality into
+  // CXXRecordDecl::isTrivial. Currently it computes the wrong thing.
+  return ClassDecl->hasTrivialDefaultConstructor() &&

shafik wrote:
> Will you follow-up this change by updating `CXXRecordDecl::isTrivial` as well 
> or is that a more difficult issue?
I want to, but I need to check the call sites to make sure it won't change ABI 
or something. And I wanted a fix that I can safely backport :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143891

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


[PATCH] D143260: [clangd] Add semantic token for labels

2023-02-13 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a comment.

Another potential consideration here is the GNU "labels as values 
" language extension, 
which clang seems to support, and which allows referencing a `LabelDecl` from a 
context other than a goto-statement (and thus less obvious from the lexical 
context only).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143260

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


[PATCH] D143725: [llvm-objdump][ARM] support --symbolize-operands for ARM/ELF

2023-02-13 Thread Hongtao Yu via Phabricator via cfe-commits
hoy added inline comments.



Comment at: llvm/tools/llvm-objdump/llvm-objdump.cpp:1169-1171
+  // On PowerPC and ARM/Thumb, if the address of a branch is the same as
+  // the target, it means that it's a function call. Do not mark the label
+  // for this case.

Is this always true for linked binary?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143725

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


[PATCH] D143418: [libclang] Add API to set preferred temp dir path

2023-02-13 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D143418#4123468 , @vedgy wrote:

> In D143418#4122821 , @aaron.ballman 
> wrote:
>
>>> How about including existing options, which //should// be set in 
>>> constructor, in the initial struct version and deprecating the 
>>> corresponding setters?
>>
>> I think that makes a lot of sense.
>
> How to deprecate the setters? Add `DEPRECATED` in the documentations as is 
> already done in two places in //Index.h//?

I think that is reasonable. (Maybe someday in the future we should use 
attributes to give users better diagnostics, but not as part of this patch.)

>>>   `const char *preferredTempDirPath;`
>>
>> In terms of documenting the structure, should we document this member as 
>> only impacting preamble files currently, should we rename this to be 
>> preamble-path specific, or should we try to use this preferred path in all 
>> the places we need the temp directory?
>>
>> (I lean towards renaming to preamble-path specific -- then users don't have 
>> the problem of upgrading to a newer CIndex potentially changing the behavior 
>> of where non-preamble files are stored, and we don't have to do the work 
>> up-front to audit other temp file uses.)
>
> Looks like an imperfect general implementation is unacceptable. So I'll 
> rename this data member to `PreambleStoragePath`.

I like that direction, thank you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143418

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


[PATCH] D143781: [Clang][LLVM] Enable __arithmetic_fence and fprotect-parens on AArch64

2023-02-13 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
alexander-shaposhnikov added a comment.

sure, will do! thanks for the review


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143781

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


[PATCH] D142316: [clang] Add test for CWG2396

2023-02-13 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik accepted this revision.
shafik added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142316

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


[PATCH] D143919: [Clang] Copy strictfp attribute from pattern to instantiation

2023-02-13 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

We have code somewhere to generically copy attributes from function templates 
to instantiations, right?  Why do we need to explicitly copy StrictFPAttr in 
particular, separate from that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143919

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


[PATCH] D140123: [TLS] Clamp the alignment of TLS global variables if required by the target

2023-02-13 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

In D140123#4113536 , @efriedma wrote:

> Missing LangRef change?

Ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140123

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


[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

2023-02-13 Thread Akash Banerjee via Phabricator via cfe-commits
TIFitis updated this revision to Diff 497045.
TIFitis added a comment.

Fixing build errors. Added mlir/lib/Target/LLVMIR/Dialect/Utils.cpp, made it 
part of the MLIRTargetLLVMIRExport lib.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPConstants.h
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
  mlir/include/mlir/Target/LLVMIR/Dialect/Utils.h
  mlir/lib/Target/LLVMIR/CMakeLists.txt
  mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp
  mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
  mlir/lib/Target/LLVMIR/Dialect/Utils.cpp

Index: mlir/lib/Target/LLVMIR/Dialect/Utils.cpp
===
--- /dev/null
+++ mlir/lib/Target/LLVMIR/Dialect/Utils.cpp
@@ -0,0 +1,41 @@
+//===- Utils.cpp - General Utils for translating MLIR dialect to LLVM IR---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file defines general utilities for MLIR Dialect translations to LLVM IR.
+//
+//===--===//
+
+#include "mlir/Target/LLVMIR/Dialect/Utils.h"
+
+llvm::Constant *
+mlir::LLVM::createSourceLocStrFromLocation(Location loc,
+   llvm::OpenMPIRBuilder &builder,
+   StringRef name, uint32_t &strLen) {
+  if (auto fileLoc = loc.dyn_cast()) {
+StringRef fileName = fileLoc.getFilename();
+unsigned lineNo = fileLoc.getLine();
+unsigned colNo = fileLoc.getColumn();
+return builder.getOrCreateSrcLocStr(name, fileName, lineNo, colNo, strLen);
+  }
+  std::string locStr;
+  llvm::raw_string_ostream locOS(locStr);
+  locOS << loc;
+  return builder.getOrCreateSrcLocStr(locOS.str(), strLen);
+}
+
+llvm::Constant *
+mlir::LLVM::createMappingInformation(Location loc,
+ llvm::OpenMPIRBuilder &builder) {
+  uint32_t strLen;
+  if (auto nameLoc = loc.dyn_cast()) {
+StringRef name = nameLoc.getName();
+return createSourceLocStrFromLocation(nameLoc.getChildLoc(), builder, name,
+  strLen);
+  }
+  return createSourceLocStrFromLocation(loc, builder, "unknown", strLen);
+}
Index: mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
===
--- mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
+++ mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
@@ -15,10 +15,12 @@
 #include "mlir/IR/IRMapping.h"
 #include "mlir/IR/Operation.h"
 #include "mlir/Support/LLVM.h"
+#include "mlir/Target/LLVMIR/Dialect/Utils.h"
 #include "mlir/Target/LLVMIR/ModuleTranslation.h"
 
 #include "llvm/ADT/SetVector.h"
 #include "llvm/ADT/TypeSwitch.h"
+#include "llvm/Frontend/OpenMP/OMPConstants.h"
 #include "llvm/Frontend/OpenMP/OMPIRBuilder.h"
 #include "llvm/IR/DebugInfoMetadata.h"
 #include "llvm/IR/IRBuilder.h"
@@ -1325,6 +1327,191 @@
   return success();
 }
 
+/// Process MapOperands for Target Data directives.
+static LogicalResult processMapOperand(
+llvm::IRBuilderBase &builder, LLVM::ModuleTranslation &moduleTranslation,
+const SmallVector &mapOperands, const ArrayAttr &mapTypes,
+SmallVector &mapTypeFlags,
+SmallVectorImpl &mapNames,
+struct llvm::OpenMPIRBuilder::MapperAllocas &mapperAllocas) {
+  auto numMapOperands = mapOperands.size();
+  llvm::OpenMPIRBuilder *ompBuilder = moduleTranslation.getOpenMPBuilder();
+  llvm::PointerType *i8PtrTy = builder.getInt8PtrTy();
+  llvm::ArrayType *arrI8PtrTy = llvm::ArrayType::get(i8PtrTy, numMapOperands);
+  llvm::IntegerType *i64Ty = builder.getInt64Ty();
+  llvm::ArrayType *arrI64Ty = llvm::ArrayType::get(i64Ty, numMapOperands);
+
+  unsigned index = 0;
+  for (const auto &mapOp : mapOperands) {
+const auto &mapTypeOp = mapTypes[index];
+
+llvm::Value *mapOpValue = moduleTranslation.lookupValue(mapOp);
+llvm::Value *mapOpPtrBase;
+llvm::Value *mapOpPtr;
+llvm::Value *mapOpSize;
+
+if (mapOp.getType().isa()) {
+  mapOpPtrBase = mapOpValue;
+  mapOpPtr = mapOpValue;
+  mapOpSize = ompBuilder->getSizeInBytes(mapOpValue);
+} else {
+  return failure();
+}
+
+// Store base pointer extracted from operand into the i-th position of
+// argBase.
+llvm::Value *ptrBaseGEP = builder.CreateInBoundsGEP(
+arrI8PtrTy, mapperAllocas.ArgsBase,
+{builder.getInt32(0), builder

  1   2   >