[PATCH] D146655: [clang-tidy] Ignore DISABLED_ in test suite name in google-avoid-underscore-in-googletest-name

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:237
 
+- Fixed an issue in :doc:`google-avoid-underscore-in-googletest-name
+  ` when using

Eugene.Zelenko wrote:
> Please keep alphabetical order (by check name) in this section.
I was planning to do that but noticed that the alphabetical order is already 
broken. It seems to be a source of friction and there's no official 
documentation that states it should be done like that, so I can understand if 
it gets broken often. Do you know if this is documented somewhere? If not, do 
we see value in keeping this convention? I suppose now we would need an NFC 
patch to fix the order again, causing churn.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp:90
 // Underscores are allowed to disable a test with the DISABLED_ prefix.
-// 
https://github.com/google/googletest/blob/master/googletest/docs/faq.md#why-should-test-suite-names-and-test-names-not-contain-underscore
+// 
https://google.github.io/googletest/faq.html#why-should-test-suite-names-and-test-names-not-contain-underscore
 TEST(TestCaseName, TestName) {}

LegalizeAdulthood wrote:
> PiotrZSL wrote:
> > Would be good if this link would exist also in documentation for this check.
> My experience has been that these external links move around with gtest and 
> are a source of churn.
Good point, I can add on a separate NFC patch :) I believe if we use the 
github.io (instead of github.com) the links can be a bit more stable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146655

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

[PATCH] D146686: [Driver] Fix rpath for compiler-rt

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

This change is correct for Linux. `llvm/CMakeLists.txt` says:

  if(CMAKE_SYSTEM_NAME MATCHES "BSD|Linux|OS390")
set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default ON)

Some rpath using OSes (notably macOS) use 
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default=OFF. Is the rpath setting ever 
usable on macOS?
If not, the change is correct.


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

https://reviews.llvm.org/D146686

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

[clang] c5d22f4 - [clang][Sema][NFC] Make local variable const

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2023-03-23T08:23:00+01:00
New Revision: c5d22f4e1866549f0d8c3aad598c0153c31679e7

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

LOG: [clang][Sema][NFC] Make local variable const

Added: 


Modified: 
clang/lib/Sema/SemaDeclAttr.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index 229e73618c53c..efa275c0aa12b 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -3759,7 +3759,7 @@ static void handleEnumExtensibilityAttr(Sema &S, Decl *D,
 /// Handle __attribute__((format_arg((idx attribute based on
 /// http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
 static void handleFormatArgAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
-  Expr *IdxExpr = AL.getArgAsExpr(0);
+  const Expr *IdxExpr = AL.getArgAsExpr(0);
   ParamIdx Idx;
   if (!checkFunctionOrMethodParameterIndex(S, D, AL, 1, IdxExpr, Idx))
 return;



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

[PATCH] D144164: [clang][Interp] Handle PtrMemOps

[Timm Bäder via Phabricator via cfe-commits]

tbaeder added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144164

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

[PATCH] D145545: [clang][Interp] Fix local variable (destructor) management in loop bodies

[Timm Bäder via Phabricator via cfe-commits]

tbaeder added a comment.

Ping


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

https://reviews.llvm.org/D145545

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

[PATCH] D146030: [clang][Interp] Handle LambdaExprs

[Timm Bäder via Phabricator via cfe-commits]

tbaeder added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146030

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

[PATCH] D130181: [clang-tidy] Add readability-use-early-exits check

[Piotr Zegar via Phabricator via cfe-commits]

PiotrZSL added inline comments.



Comment at: clang-tools-extra/clang-tidy/readability/UseEarlyExitsCheck.cpp:359
+void UseEarlyExitsCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(translationUnitDecl(), this);
+}

This will trigger on all system code, and then users will complain again that 
they see poor clang-tidy performance...

when it could be just something like

```
ifStmt(unless(isExpansionInSystemHeader()),
   unless(isConsteval()),
   unless(isConstexpr()),
   unless(hasElse(stmt())),
   unless(hasInitStatement(stmt()),
   hasThen(compoundStmt(hasSizeAboeLineTreshold())),
   ...
```

Simply everything that could be put into matcher should be put into matcher 
(easier to maintain), also what's a point of checking functions that doesn't 
have if's. On that point also some implicit functions or if statement should be 
ignored, to avoid checking templates twice.




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability/use-early-exits.cpp:144
+  //  CHECK-FIXES-NEXT: }
+}

- Missing test with if in template function & implicit specialization, just to 
make sure that fixes won't get to mess up.
- Missing test with if under macro.
- Missing test with if under switch under loop (to check if brak/continue will 
be used correctly, instead of return).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130181

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

[PATCH] D146514: [clang][dataflow] Fix crash when RHS of `&&` or `||` calls `noreturn` func.

[Martin Böhme via Phabricator via cfe-commits]

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

In D146514#4213302 , @xazax.hun wrote:

> In D146514#4212528 , @mboehme wrote:
>
>> No, I think this is a different case.
>
> Sorry, I might have been unclear. I 100% agree that these are different 
> cases. I was wondering whether we can/should have a single code path 
> supporting both. But I do not insist since we do not seem to have precedent 
> for the scenario I mentioned and do not want to block anything based on 
> hypotheticals.

Got it, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146514

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

[PATCH] D146655: [clang-tidy] Ignore DISABLED_ in test suite name in google-avoid-underscore-in-googletest-name

[Piotr Zegar via Phabricator via cfe-commits]

PiotrZSL added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:237
 
+- Fixed an issue in :doc:`google-avoid-underscore-in-googletest-name
+  ` when using

carlosgalvezp wrote:
> Eugene.Zelenko wrote:
> > Please keep alphabetical order (by check name) in this section.
> I was planning to do that but noticed that the alphabetical order is already 
> broken. It seems to be a source of friction and there's no official 
> documentation that states it should be done like that, so I can understand if 
> it gets broken often. Do you know if this is documented somewhere? If not, do 
> we see value in keeping this convention? I suppose now we would need an NFC 
> patch to fix the order again, causing churn.
I run into same issue also. I would say, let leave it as it is, and fix it with 
one commit at the end of release.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146655

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

[PATCH] D145581: [clang-tidy] In C++17, callee is guaranteed to be sequenced before arguments.

[Piotr Zegar via Phabricator via cfe-commits]

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

Switching status of review, once you will be ready with changes (or your 
decision), just mark it ready for review again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145581

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

[clang] 5acd29e - [clang][dataflow] Fix crash when RHS of `&&` or `||` calls `noreturn` func.

[Martin Braenne via cfe-commits]

Author: Martin Braenne
Date: 2023-03-23T08:02:43Z
New Revision: 5acd29eb4d9e411b3631c26babcd1d2655623f4a

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

LOG: [clang][dataflow] Fix crash when RHS of `&&` or `||` calls `noreturn` func.

The crash happened because the transfer fucntion for `&&` and `||`
unconditionally tried to retrieve the value of the RHS. However, if the RHS
is unreachable, there is no environment for it, and trying to retrieve the
operand's value causes an assertion failure.

See also the comments in the code for further details.

Reviewed By: xazax.hun, ymandel, sgatev, gribozavr2

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

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
clang/include/clang/Analysis/FlowSensitive/Transfer.h
clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
clang/lib/Analysis/FlowSensitive/Transfer.cpp
clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
clang/unittests/Analysis/FlowSensitive/TestingSupport.h
clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h 
b/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
index e641468f77d00..3495bdfc538cb 100644
--- a/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
+++ b/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
@@ -18,6 +18,7 @@
 #include "clang/AST/Decl.h"
 #include "clang/AST/Stmt.h"
 #include "clang/Analysis/CFG.h"
+#include "llvm/ADT/BitVector.h"
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -47,18 +48,26 @@ class ControlFlowContext {
 return StmtToBlock;
   }
 
+  /// Returns whether `B` is reachable from the entry block.
+  bool isBlockReachable(const CFGBlock &B) const {
+return BlockReachable[B.getBlockID()];
+  }
+
 private:
   // FIXME: Once the deprecated `build` method is removed, mark `D` as "must 
not
   // be null" and add an assertion.
   ControlFlowContext(const Decl *D, std::unique_ptr Cfg,
- llvm::DenseMap 
StmtToBlock)
+ llvm::DenseMap 
StmtToBlock,
+ llvm::BitVector BlockReachable)
   : ContainingDecl(D), Cfg(std::move(Cfg)),
-StmtToBlock(std::move(StmtToBlock)) {}
+StmtToBlock(std::move(StmtToBlock)),
+BlockReachable(std::move(BlockReachable)) {}
 
   /// The `Decl` containing the statement used to construct the CFG.
   const Decl *ContainingDecl;
   std::unique_ptr Cfg;
   llvm::DenseMap StmtToBlock;
+  llvm::BitVector BlockReachable;
 };
 
 } // namespace dataflow

diff  --git a/clang/include/clang/Analysis/FlowSensitive/Transfer.h 
b/clang/include/clang/Analysis/FlowSensitive/Transfer.h
index 78a426ed94dd5..db3d780bf35e5 100644
--- a/clang/include/clang/Analysis/FlowSensitive/Transfer.h
+++ b/clang/include/clang/Analysis/FlowSensitive/Transfer.h
@@ -26,9 +26,9 @@ class StmtToEnvMap {
 public:
   virtual ~StmtToEnvMap() = default;
 
-  /// Returns the environment of the basic block that contains `S` or nullptr 
if
-  /// there isn't one.
-  /// FIXME: Ensure that the result can't be null and return a const reference.
+  /// Retrieves the environment of the basic block that contains `S`.
+  /// If `S` is reachable, returns a non-null pointer to the environment.
+  /// If `S` is not reachable, returns nullptr.
   virtual const Environment *getEnvironment(const Stmt &S) const = 0;
 };
 

diff  --git a/clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp 
b/clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
index 2492b5203724c..6699a0fc9d79e 100644
--- a/clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
+++ b/clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
@@ -16,6 +16,7 @@
 #include "clang/AST/Decl.h"
 #include "clang/AST/Stmt.h"
 #include "clang/Analysis/CFG.h"
+#include "llvm/ADT/BitVector.h"
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/Support/Error.h"
 #include 
@@ -44,6 +45,28 @@ buildStmtToBasicBlockMap(const CFG &Cfg) {
   return StmtToBlock;
 }
 
+static llvm::BitVector findReachableBlocks(const CFG &Cfg) {
+  llvm::BitVector BlockReachable(Cfg.getNumBlockIDs(), false);
+
+  llvm::SmallVector BlocksToVisit;
+  BlocksToVisit.push_back(&Cfg.getEntry());
+  while (!BlocksToVisit.empty()) {
+const CFGBlock *Block = BlocksToVisit.back();
+BlocksToVisit.pop_back();
+
+if (BlockReachable[Block->getBlockID()])
+  continue;
+
+BlockReachable[Block->getBlockID()] = true;
+
+for (const CFGBlock *Succ : Block->succs())
+  if (Succ)
+BlocksToVisit.push_back(Succ);
+  }
+
+  return BlockReachable;
+}
+
 llvm::Expected
 ControlFlowContext::build(const Decl *D, St

[PATCH] D146514: [clang][dataflow] Fix crash when RHS of `&&` or `||` calls `noreturn` func.

[Martin Böhme via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5acd29eb4d9e: [clang][dataflow] Fix crash when RHS of 
`&&` or `||` calls `noreturn` func. (authored by mboehme).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146514

Files:
  clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
  clang/include/clang/Analysis/FlowSensitive/Transfer.h
  clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
  clang/lib/Analysis/FlowSensitive/Transfer.cpp
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/TestingSupport.h
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -5104,4 +5104,70 @@
   });
 }
 
+// Repro for a crash that used to occur when we call a `noreturn` function
+// within one of the operands of a `&&` or `||` operator.
+TEST(TransferTest, NoReturnFunctionInsideShortCircuitedBooleanOp) {
+  std::string Code = R"(
+__attribute__((noreturn)) int doesnt_return();
+bool some_condition();
+void target(bool b1, bool b2) {
+  // Neither of these should crash. In addition, if we don't terminate the
+  // program, we know that the operators need to trigger the short-circuit
+  // logic, so `NoreturnOnRhsOfAnd` will be false and `NoreturnOnRhsOfOr`
+  // will be true.
+  bool NoreturnOnRhsOfAnd = b1 && doesnt_return() > 0;
+  bool NoreturnOnRhsOfOr = b2 || doesnt_return() > 0;
+
+  // Calling a `noreturn` function on the LHS of an `&&` or `||` makes the
+  // entire expression unreachable. So we know that in both of the following
+  // cases, if `target()` terminates, the `else` branch was taken.
+  bool NoreturnOnLhsMakesAndUnreachable = false;
+  if (some_condition())
+ doesnt_return() > 0 && some_condition();
+  else
+ NoreturnOnLhsMakesAndUnreachable = true;
+
+  bool NoreturnOnLhsMakesOrUnreachable = false;
+  if (some_condition())
+ doesnt_return() > 0 || some_condition();
+  else
+ NoreturnOnLhsMakesOrUnreachable = true;
+
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results.keys(), UnorderedElementsAre("p"));
+const Environment &Env = getEnvironmentAtAnnotation(Results, "p");
+
+// Check that [[p]] is reachable with a non-false flow condition.
+EXPECT_FALSE(Env.flowConditionImplies(Env.getBoolLiteralValue(false)));
+
+auto &B1 = getValueForDecl(ASTCtx, Env, "b1");
+EXPECT_TRUE(Env.flowConditionImplies(Env.makeNot(B1)));
+
+auto &NoreturnOnRhsOfAnd =
+getValueForDecl(ASTCtx, Env, "NoreturnOnRhsOfAnd");
+EXPECT_TRUE(Env.flowConditionImplies(Env.makeNot(NoreturnOnRhsOfAnd)));
+
+auto &B2 = getValueForDecl(ASTCtx, Env, "b2");
+EXPECT_TRUE(Env.flowConditionImplies(B2));
+
+auto &NoreturnOnRhsOfOr =
+getValueForDecl(ASTCtx, Env, "NoreturnOnRhsOfOr");
+EXPECT_TRUE(Env.flowConditionImplies(NoreturnOnRhsOfOr));
+
+auto &NoreturnOnLhsMakesAndUnreachable = getValueForDecl(
+ASTCtx, Env, "NoreturnOnLhsMakesAndUnreachable");
+EXPECT_TRUE(Env.flowConditionImplies(NoreturnOnLhsMakesAndUnreachable));
+
+auto &NoreturnOnLhsMakesOrUnreachable = getValueForDecl(
+ASTCtx, Env, "NoreturnOnLhsMakesOrUnreachable");
+EXPECT_TRUE(Env.flowConditionImplies(NoreturnOnLhsMakesOrUnreachable));
+  });
+}
+
 } // namespace
Index: clang/unittests/Analysis/FlowSensitive/TestingSupport.h
===
--- clang/unittests/Analysis/FlowSensitive/TestingSupport.h
+++ clang/unittests/Analysis/FlowSensitive/TestingSupport.h
@@ -389,6 +389,20 @@
 ///   `Name` must be unique in `ASTCtx`.
 const ValueDecl *findValueDecl(ASTContext &ASTCtx, llvm::StringRef Name);
 
+/// Returns the value (of type `ValueT`) for the given identifier.
+/// `ValueT` must be a subclass of `Value` and must be of the appropriate type.
+///
+/// Requirements:
+///
+///   `Name` must be unique in `ASTCtx`.
+template 
+ValueT &getValueForDecl(ASTContext &ASTCtx, const Environment &Env,
+llvm::StringRef Name) {
+  const ValueDecl *VD = findValueDecl(ASTCtx, Name);
+  assert(VD != nullptr);
+  return *cast(Env.getValue(*VD, SkipPast::None));
+}
+
 /// Creates and owns constraints which are boolean values.
 class ConstraintContext {
 public:
Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===

[PATCH] D146655: [clang-tidy] Ignore DISABLED_ in test suite name in google-avoid-underscore-in-googletest-name

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:237
 
+- Fixed an issue in :doc:`google-avoid-underscore-in-googletest-name
+  ` when using

PiotrZSL wrote:
> carlosgalvezp wrote:
> > Eugene.Zelenko wrote:
> > > Please keep alphabetical order (by check name) in this section.
> > I was planning to do that but noticed that the alphabetical order is 
> > already broken. It seems to be a source of friction and there's no official 
> > documentation that states it should be done like that, so I can understand 
> > if it gets broken often. Do you know if this is documented somewhere? If 
> > not, do we see value in keeping this convention? I suppose now we would 
> > need an NFC patch to fix the order again, causing churn.
> I run into same issue also. I would say, let leave it as it is, and fix it 
> with one commit at the end of release.
Good idea, let's do that!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146655

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

[PATCH] D146497: libclang: Pass Clang install directory to driver via argv[0].

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld added a comment.

FYI this commit breaks `clang/test/Index/index-file.cu` for me:

  warning: CUDA version 11.8 is only partially supported 
[-Wunknown-cuda-version]
  warning: CUDA version 11.8 is only partially supported 
[-Wunknown-cuda-version]
  /home/jhahnfel/LLVM/src/clang/test/Index/index-file.cu:8:20: error: 
CHECK-HOST-NOT: excluded string found in input
  // CHECK-HOST-NOT: macro definition=__CUDA_ARCH__
 ^
  :6218:48: note: found here
  // CHECK: __clang_cuda_runtime_wrapper.h:70:9: macro definition=__CUDA_ARCH__ 
Extent=[70:9 - 70:27]
 ^~

It //could// be related to the warning about my locally installed CUDA version, 
but `__CUDA_ARCH__` should really not be defined when compiling for the host. 
If you have any idea what's going on here, please let me know - I'm a bit 
puzzled right now...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146497

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

[PATCH] D139705: [clang] fix zero-initialization fix-it for variable template

[Tomasz Kamiński via Phabricator via cfe-commits]

tomasz-kaminski-sonarsource added a comment.

As a downstream, we have concerns with this change. From what I saw it breaks 
the behavior of the fix-it that wants to remove the whole variable definition 
(including the initializer). For example, I have unused, that I want to remove 
variable x and unnecessary explicit specialization temp
  T temp = 1;
  
  int x  = 10;
  template<> double temp = 1;

Previously, this could be handled (in case of single variable declaration) by 
simply removing the `var->getSourceRange()` with succeeding coma. However, such 
code does not work for variable templates (and only for them).

As an alternative, I would suggest introducing an additional function to 
VarDecl (which could be moved up in the hierarchy), that would report a source 
range that corresponds to `declarator-id`, i.e. for template variable it would 
include template arguments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139705

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

[clang-tools-extra] b08d35f - [clang-tidy] Ignore DISABLED_ in test suite name in google-avoid-underscore-in-googletest-name

[Carlos Galvez via cfe-commits]

Author: Carlos Galvez
Date: 2023-03-23T08:31:12Z
New Revision: b08d35f826a6b7696a02f1d811da7a2f951e74a1

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

LOG: [clang-tidy] Ignore DISABLED_ in test suite name in 
google-avoid-underscore-in-googletest-name

Test suite name can also be disabled with DISABLED_, not just
the test case name.

Fix also broken link in the test that refers to the explanation
as to why underscores may not be used.

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
clang-tools-extra/docs/ReleaseNotes.rst

clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp 
b/clang-tools-extra/clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
index c5bd6055072aa..b903f2552b7e6 100644
--- 
a/clang-tools-extra/clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
+++ 
b/clang-tools-extra/clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
@@ -51,8 +51,10 @@ class AvoidUnderscoreInGoogletestNameCallback : public 
PPCallbacks {
 const Token *TestNameToken = Args->getUnexpArgument(1);
 if (!TestCaseNameToken || !TestNameToken)
   return;
-std::string TestCaseName = PP->getSpelling(*TestCaseNameToken);
-if (TestCaseName.find('_') != std::string::npos)
+std::string TestCaseNameMaybeDisabled = 
PP->getSpelling(*TestCaseNameToken);
+StringRef TestCaseName = TestCaseNameMaybeDisabled;
+TestCaseName.consume_front(KDisabledTestPrefix);
+if (TestCaseName.contains('_'))
   Check->diag(TestCaseNameToken->getLocation(),
   "avoid using \"_\" in test case name \"%0\" according to "
   "Googletest FAQ")

diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 3f79e8e2a187a..80f5b46681713 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -234,6 +234,10 @@ Changes in existing checks
   string for ``Prefix`` or ``Suffix`` options could result in the style not
   being used.
 
+- Fixed an issue in :doc:`google-avoid-underscore-in-googletest-name
+  ` when using
+  ``DISABLED_`` in the test suite name.
+
 Removed checks
 ^^
 

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
 
b/clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
index 6e8a5c2d50af9..3ab5a6ffe383b 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
@@ -87,21 +87,31 @@ TYPED_TEST_P(Illegal_Type_ParameterizedTestCaseName, 
TestName) {}
 // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: avoid using "_" in test case name 
"Illegal_Type_ParameterizedTestCaseName" according to Googletest FAQ 
[google-readability-avoid-underscore-in-googletest-name]
 
 // Underscores are allowed to disable a test with the DISABLED_ prefix.
-// 
https://github.com/google/googletest/blob/master/googletest/docs/faq.md#why-should-test-suite-names-and-test-names-not-contain-underscore
+// 
https://google.github.io/googletest/faq.html#why-should-test-suite-names-and-test-names-not-contain-underscore
 TEST(TestCaseName, TestName) {}
 TEST(TestCaseName, DISABLED_TestName) {}
+TEST(DISABLED_TestCaseName, TestName) {}
+TEST(DISABLED_TestCaseName, DISABLED_TestName) {}
 
 TEST_F(TestCaseFixtureName, TestName) {}
 TEST_F(TestCaseFixtureName, DISABLED_TestName) {}
+TEST_F(DISABLED_TestCaseFixtureName, TestName) {}
+TEST_F(DISABLED_TestCaseFixtureName, DISABLED_TestName) {}
 
 TEST_P(ParameterizedTestCaseFixtureName, TestName) {}
 TEST_P(ParameterizedTestCaseFixtureName, DISABLED_TestName) {}
+TEST_P(DISABLED_ParameterizedTestCaseFixtureName, TestName) {}
+TEST_P(DISABLED_ParameterizedTestCaseFixtureName, DISABLED_TestName) {}
 
 TYPED_TEST(TypedTestName, TestName) {}
 TYPED_TEST(TypedTestName, DISABLED_TestName) {}
+TYPED_TEST(DISABLED_TypedTestName, TestName) {}
+TYPED_TEST(DISABLED_TypedTestName, DISABLED_TestName) {}
 
 TYPED_TEST_P(TypeParameterizedTestName, TestName) {}
 TYPED_TEST_P(TypeParameterizedTestName, DISABLED_TestName) {}
+TYPED_TEST_P(DISABLED_TypeParameterizedTestName, TestName) {}
+TYPED_TEST_P(DISABLED_TypeParameterizedTestName, DISABLED_TestName) {}
 
 FRIEND_TEST(FriendTest, Is_NotChecked) {}
 FRIEND_TEST(Friend_Test, IsNotChecked) {}



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists

[PATCH] D146655: [clang-tidy] Ignore DISABLED_ in test suite name in google-avoid-underscore-in-googletest-name

[Carlos Galvez via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb08d35f826a6: [clang-tidy] Ignore DISABLED_ in test suite 
name in google-avoid-underscore-in… (authored by carlosgalvezp).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146655

Files:
  clang-tools-extra/clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp


Index: 
clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
===
--- 
clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
+++ 
clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
@@ -87,21 +87,31 @@
 // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: avoid using "_" in test case name 
"Illegal_Type_ParameterizedTestCaseName" according to Googletest FAQ 
[google-readability-avoid-underscore-in-googletest-name]
 
 // Underscores are allowed to disable a test with the DISABLED_ prefix.
-// 
https://github.com/google/googletest/blob/master/googletest/docs/faq.md#why-should-test-suite-names-and-test-names-not-contain-underscore
+// 
https://google.github.io/googletest/faq.html#why-should-test-suite-names-and-test-names-not-contain-underscore
 TEST(TestCaseName, TestName) {}
 TEST(TestCaseName, DISABLED_TestName) {}
+TEST(DISABLED_TestCaseName, TestName) {}
+TEST(DISABLED_TestCaseName, DISABLED_TestName) {}
 
 TEST_F(TestCaseFixtureName, TestName) {}
 TEST_F(TestCaseFixtureName, DISABLED_TestName) {}
+TEST_F(DISABLED_TestCaseFixtureName, TestName) {}
+TEST_F(DISABLED_TestCaseFixtureName, DISABLED_TestName) {}
 
 TEST_P(ParameterizedTestCaseFixtureName, TestName) {}
 TEST_P(ParameterizedTestCaseFixtureName, DISABLED_TestName) {}
+TEST_P(DISABLED_ParameterizedTestCaseFixtureName, TestName) {}
+TEST_P(DISABLED_ParameterizedTestCaseFixtureName, DISABLED_TestName) {}
 
 TYPED_TEST(TypedTestName, TestName) {}
 TYPED_TEST(TypedTestName, DISABLED_TestName) {}
+TYPED_TEST(DISABLED_TypedTestName, TestName) {}
+TYPED_TEST(DISABLED_TypedTestName, DISABLED_TestName) {}
 
 TYPED_TEST_P(TypeParameterizedTestName, TestName) {}
 TYPED_TEST_P(TypeParameterizedTestName, DISABLED_TestName) {}
+TYPED_TEST_P(DISABLED_TypeParameterizedTestName, TestName) {}
+TYPED_TEST_P(DISABLED_TypeParameterizedTestName, DISABLED_TestName) {}
 
 FRIEND_TEST(FriendTest, Is_NotChecked) {}
 FRIEND_TEST(Friend_Test, IsNotChecked) {}
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -234,6 +234,10 @@
   string for ``Prefix`` or ``Suffix`` options could result in the style not
   being used.
 
+- Fixed an issue in :doc:`google-avoid-underscore-in-googletest-name
+  ` when using
+  ``DISABLED_`` in the test suite name.
+
 Removed checks
 ^^
 
Index: 
clang-tools-extra/clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
===
--- clang-tools-extra/clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
+++ clang-tools-extra/clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
@@ -51,8 +51,10 @@
 const Token *TestNameToken = Args->getUnexpArgument(1);
 if (!TestCaseNameToken || !TestNameToken)
   return;
-std::string TestCaseName = PP->getSpelling(*TestCaseNameToken);
-if (TestCaseName.find('_') != std::string::npos)
+std::string TestCaseNameMaybeDisabled = 
PP->getSpelling(*TestCaseNameToken);
+StringRef TestCaseName = TestCaseNameMaybeDisabled;
+TestCaseName.consume_front(KDisabledTestPrefix);
+if (TestCaseName.contains('_'))
   Check->diag(TestCaseNameToken->getLocation(),
   "avoid using \"_\" in test case name \"%0\" according to "
   "Googletest FAQ")


Index: clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
@@ -87,21 +87,31 @@
 // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: avoid using "_" in test case name "Illegal_Type_ParameterizedTestCaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
 
 // Underscores are allowed to disable a test with the DISABLED_ prefix.
-// https://github.com/google/googletest/blob/master/googletest/docs/faq.md#why-should-test-suite-names-and-test-names-not-contain-underscore
+// https://google.github.io/googletest/faq.html#why-should-test-suite

[PATCH] D146408: [clang][Interp] Start supporting complex types

[Timm Bäder via Phabricator via cfe-commits]

tbaeder updated this revision to Diff 507646.
tbaeder added a comment.

Completely forgot to add the tests to the patch, oops.


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

https://reviews.llvm.org/D146408

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/ByteCodeExprGen.h
  clang/lib/AST/Interp/Context.cpp
  clang/lib/AST/Interp/EvalEmitter.cpp
  clang/test/AST/Interp/complex.cpp

Index: clang/test/AST/Interp/complex.cpp
===
--- /dev/null
+++ clang/test/AST/Interp/complex.cpp
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -fexperimental-new-constant-interpreter -verify %s
+// RUN: %clang_cc1 -verify=ref %s
+
+// expected-no-diagnostics
+// ref-no-diagnostics
+
+constexpr _Complex double z1 = {1.0, 2.0};
+static_assert(__real(z1) == 1.0);
+static_assert(__imag(z1) == 2.0);
+
+constexpr double setter() {
+  _Complex float d = {1.0, 2.0};
+
+  __imag(d) = 4.0;
+  return __imag(d);
+}
+static_assert(setter() == 4);
+
+constexpr _Complex double getter() {
+  return {1.0, 3.0};
+}
+constexpr _Complex double D = getter();
+static_assert(__real(D) == 1.0);
+static_assert(__imag(D) == 3.0);
Index: clang/lib/AST/Interp/EvalEmitter.cpp
===
--- clang/lib/AST/Interp/EvalEmitter.cpp
+++ clang/lib/AST/Interp/EvalEmitter.cpp
@@ -196,6 +196,22 @@
   }
   return Ok;
 }
+
+// Complex types.
+if (const auto *CT = Ty->getAs()) {
+  QualType ElemTy = CT->getElementType();
+  std::optional ElemT = Ctx.classify(ElemTy);
+  assert(ElemT);
+
+  if (ElemTy->isIntegerType()) {
+return false; // FIXME
+  } else if (ElemTy->isFloatingType()) {
+Result = APValue(Ptr.atIndex(0).deref().getAPFloat(),
+ Ptr.atIndex(1).deref().getAPFloat());
+return true;
+  }
+  return false;
+}
 llvm_unreachable("invalid value to return");
   };
 
Index: clang/lib/AST/Interp/Context.cpp
===
--- clang/lib/AST/Interp/Context.cpp
+++ clang/lib/AST/Interp/Context.cpp
@@ -81,6 +81,9 @@
   if (T->isBooleanType())
 return PT_Bool;
 
+  if (T->isAnyComplexType())
+return std::nullopt;
+
   if (T->isSignedIntegerOrEnumerationType()) {
 switch (Ctx.getIntWidth(T)) {
 case 64:
Index: clang/lib/AST/Interp/ByteCodeExprGen.h
===
--- clang/lib/AST/Interp/ByteCodeExprGen.h
+++ clang/lib/AST/Interp/ByteCodeExprGen.h
@@ -139,6 +139,7 @@
   bool visitArrayInitializer(const Expr *Initializer);
   /// Compiles a record initializer.
   bool visitRecordInitializer(const Expr *Initializer);
+  bool visitComplexInitializer(const Expr *Initializer);
   /// Creates and initializes a variable from the given decl.
   bool visitVarDecl(const VarDecl *VD);
 
Index: clang/lib/AST/Interp/ByteCodeExprGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -1573,6 +1573,33 @@
   return false;
 }
 
+/// Visit an initializer for a _Complex type.
+/// They are represented as two-element arrays.
+template 
+bool ByteCodeExprGen::visitComplexInitializer(
+const Expr *Initializer) {
+  if (const auto *InitList = dyn_cast(Initializer)) {
+unsigned InitIndex = 0;
+for (const Expr *Init : InitList->inits()) {
+  PrimType InitT = classifyPrim(Init->getType());
+
+  if (!this->visit(Init))
+return false;
+
+  if (!this->emitInitElem(InitT, InitIndex, InitList))
+return false;
+  ++InitIndex;
+}
+assert(InitIndex == 2);
+return true;
+  } else if (const auto *CE = dyn_cast(Initializer)) {
+if (!this->emitDupPtr(Initializer))
+  return false;
+return this->visit(CE);
+  }
+  return false;
+}
+
 template 
 bool ByteCodeExprGen::visitInitializer(const Expr *Initializer) {
   QualType InitializerType = Initializer->getType();
@@ -1583,6 +1610,9 @@
   if (InitializerType->isRecordType())
 return visitRecordInitializer(Initializer);
 
+  if (InitializerType->isAnyComplexType())
+return visitComplexInitializer(Initializer);
+
   // Otherwise, visit the expression like normal.
   return this->visit(Initializer);
 }
@@ -1983,8 +2013,22 @@
 if (!this->visit(SubExpr))
   return false;
 return DiscardResult ? this->emitPop(*T, E) : this->emitComp(*T, E);
-  case UO_Real:   // __real x
-  case UO_Imag:   // __imag x
+  case UO_Real: { // __real x
+assert(!T);
+if (!this->visit(SubExpr))
+  return false;
+if (!this->emitConstUint8(0, E))
+  return false;
+return this->emitArrayElemPtrPopUint8(E);
+  }
+  case UO_Imag: { // __imag x
+assert(!T);
+if (!this->visit(SubExpr))
+  return false;
+if (!this->emitConstUint8(1, E))
+  return false;
+return this->emitArrayEle

[PATCH] D142630: [clang][Interp] Implement virtual function calls

[Timm Bäder via Phabricator via cfe-commits]

tbaeder updated this revision to Diff 507648.
tbaeder added a comment.

Add some more tests for virtual destructors.


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

https://reviews.llvm.org/D142630

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/Context.cpp
  clang/lib/AST/Interp/Context.h
  clang/lib/AST/Interp/Descriptor.cpp
  clang/lib/AST/Interp/Function.h
  clang/lib/AST/Interp/Interp.h
  clang/lib/AST/Interp/InterpState.h
  clang/lib/AST/Interp/Opcodes.td
  clang/lib/AST/Interp/Pointer.h
  clang/test/AST/Interp/records.cpp

Index: clang/test/AST/Interp/records.cpp
===
--- clang/test/AST/Interp/records.cpp
+++ clang/test/AST/Interp/records.cpp
@@ -1,8 +1,10 @@
 // RUN: %clang_cc1 -fexperimental-new-constant-interpreter -verify %s
 // RUN: %clang_cc1 -fexperimental-new-constant-interpreter -std=c++14 -verify %s
+// RUN: %clang_cc1 -fexperimental-new-constant-interpreter -std=c++20 -verify %s
 // RUN: %clang_cc1 -fexperimental-new-constant-interpreter -triple i686 -verify %s
 // RUN: %clang_cc1 -verify=ref %s
 // RUN: %clang_cc1 -verify=ref -std=c++14 %s
+// RUN: %clang_cc1 -verify=ref -std=c++20 %s
 // RUN: %clang_cc1 -verify=ref -triple i686 %s
 
 struct BoolPair {
@@ -308,6 +310,7 @@
 };
 
 namespace DeriveFailures {
+#if __cplusplus < 202002L
   struct Base { // ref-note 2{{declared here}} expected-note {{declared here}}
 int Val;
   };
@@ -325,10 +328,12 @@
// ref-note {{declared here}} \
// expected-error {{must be initialized by a constant expression}} \
// expected-note {{in call to 'Derived(12)'}}
+
   static_assert(D.Val == 0, ""); // ref-error {{not an integral constant expression}} \
  // ref-note {{initializer of 'D' is not a constant expression}} \
  // expected-error {{not an integral constant expression}} \
  // expected-note {{read of object outside its lifetime}}
+#endif
 
   struct AnotherBase {
 int Val;
@@ -378,3 +383,158 @@
   static_assert(getS(true).a == 12, "");
   static_assert(getS(false).a == 13, "");
 };
+
+#if __cplusplus >= 202002L
+namespace VirtualCalls {
+namespace Obvious {
+
+  class A {
+  public:
+constexpr A(){}
+constexpr virtual int foo() {
+  return 3;
+}
+  };
+  class B : public A {
+  public:
+constexpr int foo() override {
+  return 6;
+}
+  };
+
+  constexpr int getFooB(bool b) {
+A *a;
+A myA;
+B myB;
+
+if (b)
+  a = &myA;
+else
+  a = &myB;
+
+return a->foo();
+  }
+  static_assert(getFooB(true) == 3, "");
+  static_assert(getFooB(false) == 6, "");
+}
+
+namespace MultipleBases {
+  class A {
+  public:
+constexpr virtual int getInt() const { return 10; }
+  };
+  class B {
+  public:
+  };
+  class C : public A, public B {
+  public:
+constexpr int getInt() const override { return 20; }
+  };
+
+  constexpr int callGetInt(const A& a) { return a.getInt(); }
+  static_assert(callGetInt(C()) == 20, "");
+  static_assert(callGetInt(A()) == 10, "");
+}
+
+namespace Destructors {
+  class Base {
+  public:
+int i;
+constexpr Base(int &i) : i(i) {i++;}
+constexpr virtual ~Base() {i--;}
+  };
+
+  class Derived : public Base {
+  public:
+constexpr Derived(int &i) : Base(i) {}
+constexpr virtual ~Derived() {i--;}
+  };
+
+  constexpr int test() {
+int i = 0;
+Derived d(i);
+return i;
+  }
+  static_assert(test() == 1);
+}
+
+
+namespace VirtualDtors {
+  class A {
+  public:
+unsigned &v;
+constexpr A(unsigned &v) : v(v) {}
+constexpr virtual ~A() {
+  v |= (1 << 0);
+}
+  };
+  class B : public A {
+  public:
+constexpr B(unsigned &v) : A(v) {}
+constexpr virtual ~B() {
+  v |= (1 << 1);
+}
+  };
+  class C : public B {
+  public:
+constexpr C(unsigned &v) : B(v) {}
+constexpr virtual ~C() {
+  v |= (1 << 2);
+}
+  };
+
+  constexpr bool foo() {
+unsigned a = 0;
+{
+  C c(a);
+}
+return ((a & (1 << 0)) && (a & (1 << 1)) && (a & (1 << 2)));
+  }
+
+  static_assert(foo());
+
+
+};
+
+namespace QualifiedCalls {
+  class A {
+  public:
+  constexpr virtual int foo() const {
+  return 5;
+  }
+  };
+  class B : public A {};
+  class C : public B {
+  public:
+  constexpr int foo() const override {
+  return B::foo(); // B doesn't have a foo(), so this should call A::foo().
+  }
+  constexpr int foo2() const {
+return this->A::foo();
+  }
+  };
+  constexpr C c;
+  static_assert(c.foo() == 5);
+  static_assert(c.foo2() == 5);
+
+
+  struct S {
+int _c = 0;
+virtual constexpr int foo() const { return 1; }
+  };
+
+  struct SS : S {
+int a;
+constexpr SS() {
+  a = S::foo();
+}
+constexpr int foo() const override {
+  r

[PATCH] D144976: [clangd] Add provider info on symbol hover.

[Haojian Wu via Phabricator via cfe-commits]

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

Thanks, this looks great! Please fix the code style of the unit-test (see my 
other comment) before landing it.




Comment at: clang-tools-extra/clangd/Hover.cpp:
+  // Main file ranked higher than any #include'd file
+  break;
+

VitaNuo wrote:
> hokein wrote:
> > if we perform an early `return` inside the loop, the code can be simpler.
> > 
> > ```
> > // Pickup the highest provider that satisfied the symbol usage, if 
> > available.
> > // If the main-file is the chosen provider, we deliberately do not display 
> > it (as it may cause too much noise, e.g. for local variables).
> > for (const auto & H : Headers) {
> >if (isMainFile(H)) {
> >   return;
> >}
> >if (!Matches.empty()) {
> >   HI.Provider = Matches[0]->quote();
> >   return;
> >} 
> > }
> > 
> > HI.Provider = spellHeader(AST...);
> > ```
> Not really, this is not what we'd agreed upon.
> 
> Consider the provider list `[foo.h, main-file]`, `foo.h` _not_ being 
> #include'd. 
> The above code will return without a provider, but we would actually like to 
> return `foo.h`.
Yeah, you're right. I don't remember what I thought on writing the comment.



Comment at: clang-tools-extra/clangd/unittests/HoverTests.cpp:2894
+const std::function ExpectedBuilder;
+  } Cases[] = {{Annotations(R"cpp(
+struct Foo {}; 

Can you follow the the indentation-style of  `R"cpp()cpp"` from the above 
`TEST(Hover, NoHover)` example? It would be nice to be consistent.

We can save the explicit `Annotations` word here by changing the type of `Code` 
from `Annotations` to `const char* const`, and constructing the `Annotations` 
object inside the for-loop. 



Comment at: clang-tools-extra/clangd/unittests/HoverTests.cpp:2938
+  )cpp"),
+[](HoverInfo &HI) { HI.Provider = "\"foo.h\""; }}};
+

VitaNuo wrote:
> hokein wrote:
> > I think this should be `""`, the using declaration is defined in main-file, 
> > main-file should be the only one provider, and we don't display main-file 
> > provider.
> This is the same situation as `absl::string_view` vs. `std::string_view`, I 
> believe.
> The decl that is used in hover is `class Foo {};` from `foo.h`, so `foo.h` is 
> correct AFAIU.
oh, right. I missed that fact that the target on Hover here is the underlying 
decl of the using decl, can you add a comment clarifying the hover here is 
showing the underlying decl?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144976

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

[PATCH] D146418: Support for OpenMP 5.0 sec 2.12.7 - Declare Target initializer expressions

[Ritanya via Phabricator via cfe-commits]

RitanyaB added inline comments.



Comment at: clang/lib/Parse/ParseDecl.cpp:2093-2115
+void ParseImplicitDeclareTargetAttr(Decl *TargetDecl) {
+  if (TargetDecl && TargetDecl->hasAttr() &&
+  isa(TargetDecl)) {
+VarDecl *TargetVarDecl = cast(TargetDecl);
+Expr *Ex = TargetVarDecl->getInit()->IgnoreCasts();
+const DeclRefExpr *DeclRef = nullptr;
+if (Ex && isa(Ex) && TargetVarDecl->hasGlobalStorage()) {

ABataev wrote:
> It has nothing to do with parsing, sema analysis. Make it part of 
> Sema::checkDeclIsAllowedInOpenMPTarget
The Declaration in Sema::checkDeclIsAllowedInOpenMPTarget is incomplete. 

```
VarDecl 0x1582b278  col:7 ptr1 'int **'
`-OMPDeclareTargetDeclAttr 0x1582b2e0  Implicit MT_To DT_Any 1
  `-<<>>

```  
At this point, I do not have access to the initializer expression. Any 
suggestions? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146418

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

[PATCH] D146701: [AMDGPU] Create Subtarget Features for some of 16 bits atomic fadd instructions

[Mariusz Sikora via Phabricator via cfe-commits]

mariusz-sikora-at-amd created this revision.
Herald added subscribers: kosarev, foad, kerbowa, hiraditya, tpr, dstuttard, 
yaxunl, jvesely, kzhuravl, arsenm.
Herald added a project: All.
mariusz-sikora-at-amd requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, wdng.
Herald added projects: clang, LLVM.

Introducing Subtarget Features for instructions:

- ds_pk_add_bf16
- ds_pk_add_f16
- ds_pk_add_rtn_bf16
- ds_pk_add_rtn_f16
- flat_atomic_pk_add_f16
- flat_atomic_pk_add_bf16
- global_atomic_pk_add_f16
- global_atomic_pk_add_bf16
- buffer_atomic_pk_add_f16


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146701

Files:
  clang/include/clang/Basic/BuiltinsAMDGPU.def
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  clang/test/CodeGenOpenCL/builtins-amdgcn-fp-atomics-gfx11-err.cl
  clang/test/CodeGenOpenCL/builtins-amdgcn-fp-atomics-gfx908-err.cl
  clang/test/CodeGenOpenCL/builtins-amdgcn-fp-atomics-gfx90a-err.cl
  llvm/lib/Target/AMDGPU/AMDGPU.td
  llvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp
  llvm/lib/Target/AMDGPU/BUFInstructions.td
  llvm/lib/Target/AMDGPU/DSInstructions.td
  llvm/lib/Target/AMDGPU/FLATInstructions.td
  llvm/lib/Target/AMDGPU/GCNSubtarget.h

Index: llvm/lib/Target/AMDGPU/GCNSubtarget.h
===
--- llvm/lib/Target/AMDGPU/GCNSubtarget.h
+++ llvm/lib/Target/AMDGPU/GCNSubtarget.h
@@ -152,9 +152,13 @@
   bool HasMAIInsts = false;
   bool HasFP8Insts = false;
   bool HasPkFmacF16Inst = false;
+  bool HasAtomicDsPkAdd16Insts = false;
+  bool HasAtomicFlatPkAdd16Insts = false;
   bool HasAtomicFaddRtnInsts = false;
   bool HasAtomicFaddNoRtnInsts = false;
-  bool HasAtomicPkFaddNoRtnInsts = false;
+  bool HasAtomicBufferGlobalPkAddF16NoRtnInsts = false;
+  bool HasAtomicBufferGlobalPkAddF16Insts = false;
+  bool HasAtomicGlobalPkAddBF16Inst = false;
   bool HasFlatAtomicFaddF32Inst = false;
   bool SupportsSRAMECC = false;
 
@@ -758,6 +762,10 @@
 return HasPkFmacF16Inst;
   }
 
+  bool hasAtomicDsPkAdd16Insts() const { return HasAtomicDsPkAdd16Insts; }
+
+  bool hasAtomicFlatPkAdd16Insts() const { return HasAtomicFlatPkAdd16Insts; }
+
   bool hasAtomicFaddInsts() const {
 return HasAtomicFaddRtnInsts || HasAtomicFaddNoRtnInsts;
   }
@@ -766,7 +774,17 @@
 
   bool hasAtomicFaddNoRtnInsts() const { return HasAtomicFaddNoRtnInsts; }
 
-  bool hasAtomicPkFaddNoRtnInsts() const { return HasAtomicPkFaddNoRtnInsts; }
+  bool hasAtomicBufferGlobalPkAddF16NoRtnInsts() const {
+return HasAtomicBufferGlobalPkAddF16NoRtnInsts;
+  }
+
+  bool hasAtomicBufferGlobalPkAddF16Insts() const {
+return HasAtomicBufferGlobalPkAddF16Insts;
+  }
+
+  bool hasAtomicGlobalPkAddBF16Inst() const {
+return HasAtomicGlobalPkAddBF16Inst;
+  }
 
   bool hasFlatAtomicFaddF32Inst() const { return HasFlatAtomicFaddF32Inst; }
 
Index: llvm/lib/Target/AMDGPU/FLATInstructions.td
===
--- llvm/lib/Target/AMDGPU/FLATInstructions.td
+++ llvm/lib/Target/AMDGPU/FLATInstructions.td
@@ -730,11 +730,14 @@
   defm GLOBAL_ATOMIC_MAX_F64 : FLAT_Global_Atomic_Pseudo<"global_atomic_max_f64", VReg_64, f64>;
 } // End SubtargetPredicate = isGFX90APlus
 
-let SubtargetPredicate = isGFX940Plus in {
+let SubtargetPredicate = HasAtomicFlatPkAdd16Insts in {
   defm FLAT_ATOMIC_PK_ADD_F16: FLAT_Atomic_Pseudo<"flat_atomic_pk_add_f16",  VGPR_32, v2f16>;
   defm FLAT_ATOMIC_PK_ADD_BF16   : FLAT_Atomic_Pseudo<"flat_atomic_pk_add_bf16", VGPR_32, v2f16>;
+} // End SubtargetPredicate = HasAtomicFlatPkAdd16Insts
+
+let SubtargetPredicate = HasAtomicGlobalPkAddBF16Inst in {
   defm GLOBAL_ATOMIC_PK_ADD_BF16 : FLAT_Global_Atomic_Pseudo<"global_atomic_pk_add_bf16", VGPR_32, v2f16>;
-} // End SubtargetPredicate = isGFX940Plus
+} // End SubtargetPredicate = HasAtomicGlobalPkAddBF16Inst
 
 // GFX7-, GFX10-, GFX11-only flat instructions.
 let SubtargetPredicate = isGFX7GFX10GFX11 in {
@@ -938,7 +941,7 @@
   defm GLOBAL_ATOMIC_ADD_F32 : FLAT_Global_Atomic_Pseudo_NO_RTN <
 "global_atomic_add_f32", VGPR_32, f32
   >;
-let OtherPredicates = [HasAtomicPkFaddNoRtnInsts] in
+let OtherPredicates = [HasAtomicBufferGlobalPkAddF16NoRtnInsts] in
   defm GLOBAL_ATOMIC_PK_ADD_F16 : FLAT_Global_Atomic_Pseudo_NO_RTN <
 "global_atomic_pk_add_f16", VGPR_32, v2f16
   >;
@@ -946,7 +949,7 @@
   defm GLOBAL_ATOMIC_ADD_F32 : FLAT_Global_Atomic_Pseudo_RTN <
 "global_atomic_add_f32", VGPR_32, f32
   >;
-let OtherPredicates = [isGFX90APlus] in
+let OtherPredicates = [HasAtomicBufferGlobalPkAddF16Insts] in
   defm GLOBAL_ATOMIC_PK_ADD_F16 : FLAT_Global_Atomic_Pseudo_RTN <
 "global_atomic_pk_add_f16", VGPR_32, v2f16
   >;
@@ -1505,7 +1508,7 @@
 defm : GlobalFLATAtomicPatsNoRtnWithAddrSpace <"GLOBAL_ATOMIC_ADD_F32", "int_amdgcn_global_atomic_fadd", "global_addrspace", f32>;
 }
 
-let OtherPredicates = [HasAtomicPkFaddNoRtnInsts] in {
+let OtherPred

[PATCH] D146634: [clang][USR] Prevent crashes when parameter lists have nulls

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

I am aware that this null checking at leaves are not considered a sustainable 
solution and I agree with the sentiment there. But we're seeing an increasing 
number of crashes in production on invalid code recently. Happy to take a 
different course if there are alternatives, but as also explained in D146426 
, the situation around parameter lists having 
nullptrs seem to be the state for a long time now, e.g:

  template  auto x = [](__fp16) {};
  decltype(x);

is a reproducer that crashes even clang-12 due to a nullptr in the paremeter 
list. Surely it'd be better to fix this invariant, but I am afraid we don't 
know how to do that immediately and considering people have been dealing with 
this situation by adding null checks into the places that triggered crashes 
ever since, I'd like to move forward with this fix until someone can figure out 
the situation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146634

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

[PATCH] D144170: [clang-format] Add simple macro replacements in formatting.

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

I know this is like "telling my grandmother to suck eggs" but  @klimek the 
change here to Format.h means you need to regenerate 
ClangFormatStyleOptions.rst via docs/tools/dump_format_style.py

Impacting the next change to generate - D125171: Add a new clang-format option 
AlwaysBreakBeforeFunctionParameters 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144170

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

[clang] 0691bcb - [clang][Interp][NFC] Add tests for __fp16

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2023-03-23T10:08:34+01:00
New Revision: 0691bcb18024a28e82e8dd9a08ab0820b40c9a37

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

LOG: [clang][Interp][NFC] Add tests for __fp16

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

Added: 


Modified: 
clang/test/AST/Interp/floats.cpp

Removed: 




diff  --git a/clang/test/AST/Interp/floats.cpp 
b/clang/test/AST/Interp/floats.cpp
index 7b9328c4d1182..b3c4dd4c19a84 100644
--- a/clang/test/AST/Interp/floats.cpp
+++ b/clang/test/AST/Interp/floats.cpp
@@ -78,3 +78,94 @@ namespace compound {
   }
   static_assert(f2() == __FLT_MAX__, "");
 }
+
+
+namespace FP16 {
+  constexpr int i = 2;
+  constexpr __fp16 f = 1.0f;
+  static_assert(f == 1.0f, "");
+
+  constexpr __fp16 f2 = 1u * f;
+  static_assert(f2 == 1.0f, "");
+
+  constexpr __fp16 f3 = 1.5;
+  constexpr int i3 = f3;
+  static_assert(i3 == 1, "");
+
+  constexpr bool b3 = f3;
+  static_assert(b3, "");
+
+
+  static_assert(1.0f16 + 3u == 4, "");
+  static_assert(4.0f16 / 1.0f16 == 4, "");
+  static_assert(10.0f16 * false == 0, "");
+
+  constexpr __fp16 __fp16s[] = {1.0f16, 2.0f16, 3.0f16, 4.0f16};
+
+  constexpr __fp16 m = 5.0f16 / 0.0f16; // ref-error {{must be initialized by 
a constant expression}} \
+   // ref-note {{division by zero}} \
+   // expected-error {{must be initialized by 
a constant expression}} \
+   // expected-note {{division by zero}}
+
+  static_assert(~2.0f16 == 3, ""); // ref-error {{invalid argument type 
'_Float16' to unary expression}} \
+ // expected-error {{invalid argument type 
'_Float16' to unary expression}}
+
+  /// Initialized by a double.
+  constexpr __fp16 df = 0.0;
+  /// The other way around.
+  constexpr double fd = 0.0f16;
+
+  static_assert(0.0f == -0.0f, "");
+
+  const int k = 3 * (1.0f16 / 3.0f16);
+  static_assert(k == 1, "");
+
+  constexpr bool b = 1.0f16;
+  static_assert(b, "");
+
+  constexpr double db = true;
+  static_assert(db == 1.0f16, "");
+
+  constexpr __fp16 fa[] = {1.0f, 2.0, 1, false};
+  constexpr double da[] = {1.0f, 2.0, 1, false};
+
+  constexpr __fp16 fm = __FLT16_MAX__;
+  constexpr int someInt = fm;
+
+  constexpr float SomeFloat = __FLT_MAX__;
+  constexpr __fp16 halfFloat = SomeFloat;
+
+  constexpr float fp16ptr() {
+__fp16 f1 = 1.0f16;
+__fp16 *f2 = &f1;
+
+*f2 = 3.0;
+return f1;
+  }
+  static_assert(fp16ptr() == 3.0, "");
+
+  namespace compound {
+constexpr float f1() {
+  __fp16 f = 0;
+  f += 3.0;
+  f -= 3.0f;
+
+  f += 1;
+  f /= 1;
+  f /= 1.0;
+  f *= f;
+
+  f *= 2.0;
+  return f;
+}
+static_assert(f1() == 2, "");
+
+constexpr float f2() {
+  __fp16 f = __FLT16_MAX__;
+  f += 1.0;
+  return f;
+}
+static_assert(f2() == __FLT16_MAX__, "");
+  }
+
+}



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

[PATCH] D146436: [clang][Interp][NFC] Add tests for __fp16

[Timm Bäder via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG0691bcb18024: [clang][Interp][NFC] Add tests for __fp16 
(authored by tbaeder).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146436

Files:
  clang/test/AST/Interp/floats.cpp


Index: clang/test/AST/Interp/floats.cpp
===
--- clang/test/AST/Interp/floats.cpp
+++ clang/test/AST/Interp/floats.cpp
@@ -78,3 +78,94 @@
   }
   static_assert(f2() == __FLT_MAX__, "");
 }
+
+
+namespace FP16 {
+  constexpr int i = 2;
+  constexpr __fp16 f = 1.0f;
+  static_assert(f == 1.0f, "");
+
+  constexpr __fp16 f2 = 1u * f;
+  static_assert(f2 == 1.0f, "");
+
+  constexpr __fp16 f3 = 1.5;
+  constexpr int i3 = f3;
+  static_assert(i3 == 1, "");
+
+  constexpr bool b3 = f3;
+  static_assert(b3, "");
+
+
+  static_assert(1.0f16 + 3u == 4, "");
+  static_assert(4.0f16 / 1.0f16 == 4, "");
+  static_assert(10.0f16 * false == 0, "");
+
+  constexpr __fp16 __fp16s[] = {1.0f16, 2.0f16, 3.0f16, 4.0f16};
+
+  constexpr __fp16 m = 5.0f16 / 0.0f16; // ref-error {{must be initialized by 
a constant expression}} \
+   // ref-note {{division by zero}} \
+   // expected-error {{must be initialized by 
a constant expression}} \
+   // expected-note {{division by zero}}
+
+  static_assert(~2.0f16 == 3, ""); // ref-error {{invalid argument type 
'_Float16' to unary expression}} \
+ // expected-error {{invalid argument type 
'_Float16' to unary expression}}
+
+  /// Initialized by a double.
+  constexpr __fp16 df = 0.0;
+  /// The other way around.
+  constexpr double fd = 0.0f16;
+
+  static_assert(0.0f == -0.0f, "");
+
+  const int k = 3 * (1.0f16 / 3.0f16);
+  static_assert(k == 1, "");
+
+  constexpr bool b = 1.0f16;
+  static_assert(b, "");
+
+  constexpr double db = true;
+  static_assert(db == 1.0f16, "");
+
+  constexpr __fp16 fa[] = {1.0f, 2.0, 1, false};
+  constexpr double da[] = {1.0f, 2.0, 1, false};
+
+  constexpr __fp16 fm = __FLT16_MAX__;
+  constexpr int someInt = fm;
+
+  constexpr float SomeFloat = __FLT_MAX__;
+  constexpr __fp16 halfFloat = SomeFloat;
+
+  constexpr float fp16ptr() {
+__fp16 f1 = 1.0f16;
+__fp16 *f2 = &f1;
+
+*f2 = 3.0;
+return f1;
+  }
+  static_assert(fp16ptr() == 3.0, "");
+
+  namespace compound {
+constexpr float f1() {
+  __fp16 f = 0;
+  f += 3.0;
+  f -= 3.0f;
+
+  f += 1;
+  f /= 1;
+  f /= 1.0;
+  f *= f;
+
+  f *= 2.0;
+  return f;
+}
+static_assert(f1() == 2, "");
+
+constexpr float f2() {
+  __fp16 f = __FLT16_MAX__;
+  f += 1.0;
+  return f;
+}
+static_assert(f2() == __FLT16_MAX__, "");
+  }
+
+}


Index: clang/test/AST/Interp/floats.cpp
===
--- clang/test/AST/Interp/floats.cpp
+++ clang/test/AST/Interp/floats.cpp
@@ -78,3 +78,94 @@
   }
   static_assert(f2() == __FLT_MAX__, "");
 }
+
+
+namespace FP16 {
+  constexpr int i = 2;
+  constexpr __fp16 f = 1.0f;
+  static_assert(f == 1.0f, "");
+
+  constexpr __fp16 f2 = 1u * f;
+  static_assert(f2 == 1.0f, "");
+
+  constexpr __fp16 f3 = 1.5;
+  constexpr int i3 = f3;
+  static_assert(i3 == 1, "");
+
+  constexpr bool b3 = f3;
+  static_assert(b3, "");
+
+
+  static_assert(1.0f16 + 3u == 4, "");
+  static_assert(4.0f16 / 1.0f16 == 4, "");
+  static_assert(10.0f16 * false == 0, "");
+
+  constexpr __fp16 __fp16s[] = {1.0f16, 2.0f16, 3.0f16, 4.0f16};
+
+  constexpr __fp16 m = 5.0f16 / 0.0f16; // ref-error {{must be initialized by a constant expression}} \
+   // ref-note {{division by zero}} \
+   // expected-error {{must be initialized by a constant expression}} \
+   // expected-note {{division by zero}}
+
+  static_assert(~2.0f16 == 3, ""); // ref-error {{invalid argument type '_Float16' to unary expression}} \
+ // expected-error {{invalid argument type '_Float16' to unary expression}}
+
+  /// Initialized by a double.
+  constexpr __fp16 df = 0.0;
+  /// The other way around.
+  constexpr double fd = 0.0f16;
+
+  static_assert(0.0f == -0.0f, "");
+
+  const int k = 3 * (1.0f16 / 3.0f16);
+  static_assert(k == 1, "");
+
+  constexpr bool b = 1.0f16;
+  static_assert(b, "");
+
+  constexpr double db = true;
+  static_assert(db == 1.0f16, "");
+
+  constexpr __fp16 fa[] = {1.0f, 2.0, 1, false};
+  constexpr double da[] = {1.0f, 2.0, 1, false};
+
+  constexpr __fp16 fm = __FLT16_MAX__;
+  constexpr int someInt = fm;
+
+  constexpr float SomeFloat = __FLT_MAX__;
+  constexpr __fp16 halfFloat = SomeFloat;
+
+  constexpr float fp16ptr() {
+__fp16 f1 = 1.0f16;
+__fp16 *f2 = &f1;
+
+*f2 = 3.0;
+retu

[PATCH] D125171: Add a new clang-format option AlwaysBreakBeforeFunctionParameters

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/docs/ClangFormatStyleOptions.rst:3663
 
+.. _Macros:
+

jrmolin wrote:
> I didn't modify this section in the header at all. I assume someone modified 
> the Format.h file and didn't update the docs.
that needs to be looked at, as to what changed that meant it changed and done 
separately.



Comment at: clang/docs/ClangFormatStyleOptions.rst:3699
+ 'A(a, b) will not be expanded.
+
 .. _MaxEmptyLinesToKeep:

This won't generate without a /version, we need to get this fixed outside of 
this commit



Comment at: clang/include/clang/Format/Format.h:823
+  /// \endcode
+  /// \version 16
+  bool AlwaysBreakBeforeFunctionParameters;

16.0


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125171

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

[PATCH] D146244: [clangd] Show used symbols on #include line hover.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/Hover.cpp:1158
+  const SourceManager &SM = AST.getSourceManager();
+  std::set UsedSymbolNames;
+  include_cleaner::walkUsed(

VitaNuo wrote:
> hokein wrote:
> > just want to check the intention, we're using the `set` here because we 
> > want an alphabet order of `UsedSymbolNames`. If yes, then looks good 
> > (probably add a comment in the field `UsedSymbolNames` of HoverInfo).
> Actually no, we're using set primarily to deduplicate symbol names. 
> Otherwise, many symbols have multiple references each, and the resulting list 
> of used symbols ends up having a lot of duplicates.
> 
> I didn't know a set would order used symbols names alphabetically, but if so, 
> that's a nice side effect :)
> 
> 
yeah, if duplication is the only purpose, then `llvm::DenseSet` (which is based 
on a hash-table, thus elements are not sorted) is preferred. The bonus point of 
using `std::set` (which is based on the red-black tree) is that the elements 
are sorted.

I think it would be nice to keep the result sorted (either by the ref range, or 
the symbol name), using symbol name seems fine to me, can you add a comment for 
UsedSymbolNames field to clarify that it is sorted by the symbol name?



Comment at: clang-tools-extra/clangd/Hover.cpp:1172
+include_cleaner::Includes ConvertedIncludes =
+convertIncludes(SM, llvm::ArrayRef{Inc});
+for (const include_cleaner::Header &H : Providers) {

can you move it out of the callback? otherwise we will construct an 
`include_cleaner::Includes` every time when the callback is invoked, which is 
an unnecessary cost.



Comment at: clang-tools-extra/clangd/Hover.cpp:1176
+  ConvertedIncludes.match(H);
+  if (!Matches.empty()) {
+UsedSymbolNames.insert(getRefName(Ref));

nit: inline the Matches in the `if` body, `if 
(!ConvertedIncludes.match(H).empty())`



Comment at: clang-tools-extra/clangd/Hover.cpp:1444
+
+if (UsedSymbolNames.size() >= SymbolNamesLimit) {
+  P.appendCode(UsedSymbolNames[SymbolNamesLimit - 1]);

I think it'd be better to move this into the above for loop (adding a special 
logic) rather than having a non-trivial handling for the last element.

What do you think about the something like below (it has less usages of 
`.size()` and `SymbolNamesLimit-1`)

```
auto Fronts = 
llvm::ArrayRef(UsedSymbolNames).take_front(std::min(UnusedSymbolNames.size(), 
SymbolNamesLimit));

for (const auto& Sym : Fronts) {
   P.appendCode(Sym);
   if (Sym != Fronts.back())
 P.appendText(", ");
}

if (UsedSymbolNames.size() > Fronts.size()) {
P.appendText(" and ");
P.appendText(std::to_string(UsedSymbolNames.size() - Fronts.size()));
P.appendText(" more");
}
```



Comment at: clang-tools-extra/clangd/unittests/HoverTests.cpp:24
 #include 
+#include 
 #include 

the newly-introduced code doesn't seem to use the `std::optional` symbol



Comment at: clang-tools-extra/clangd/unittests/HoverTests.cpp:2987
+const std::function ExpectedBuilder;
+  } Cases[] = {{Annotations(R"cpp(
+#inclu^de "foo.h"

nit: fix the indentation (align with the one using in this file), see my 
comment in your other patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146244

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

[clang-tools-extra] 8c10256 - clang-tidy: Detect use-after-move in CXXCtorInitializer

[via cfe-commits]

Author: MarcoFalke
Date: 2023-03-23T10:19:54+01:00
New Revision: 8c10256734cd47274671fcabe94f24f15ecd6209

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

LOG: clang-tidy: Detect use-after-move in CXXCtorInitializer

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

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
index b7eadb87b4fcd..c10c3652a153a 100644
--- a/clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
@@ -58,11 +58,11 @@ class UseAfterMoveFinder {
 public:
   UseAfterMoveFinder(ASTContext *TheContext);
 
-  // Within the given function body, finds the first use of 'MovedVariable' 
that
+  // Within the given code block, finds the first use of 'MovedVariable' that
   // occurs after 'MovingCall' (the expression that performs the move). If a
   // use-after-move is found, writes information about it to 'TheUseAfterMove'.
   // Returns whether a use-after-move was found.
-  bool find(Stmt *FunctionBody, const Expr *MovingCall,
+  bool find(Stmt *CodeBlock, const Expr *MovingCall,
 const ValueDecl *MovedVariable, UseAfterMove *TheUseAfterMove);
 
 private:
@@ -104,7 +104,7 @@ static StatementMatcher inDecltypeOrTemplateArg() {
 UseAfterMoveFinder::UseAfterMoveFinder(ASTContext *TheContext)
 : Context(TheContext) {}
 
-bool UseAfterMoveFinder::find(Stmt *FunctionBody, const Expr *MovingCall,
+bool UseAfterMoveFinder::find(Stmt *CodeBlock, const Expr *MovingCall,
   const ValueDecl *MovedVariable,
   UseAfterMove *TheUseAfterMove) {
   // Generate the CFG manually instead of through an AnalysisDeclContext 
because
@@ -118,12 +118,11 @@ bool UseAfterMoveFinder::find(Stmt *FunctionBody, const 
Expr *MovingCall,
   Options.AddImplicitDtors = true;
   Options.AddTemporaryDtors = true;
   std::unique_ptr TheCFG =
-  CFG::buildCFG(nullptr, FunctionBody, Context, Options);
+  CFG::buildCFG(nullptr, CodeBlock, Context, Options);
   if (!TheCFG)
 return false;
 
-  Sequence =
-  std::make_unique(TheCFG.get(), FunctionBody, Context);
+  Sequence = std::make_unique(TheCFG.get(), CodeBlock, Context);
   BlockMap = std::make_unique(TheCFG.get(), Context);
   Visited.clear();
 
@@ -398,20 +397,28 @@ static void emitDiagnostic(const Expr *MovingCall, const 
DeclRefExpr *MoveArg,
 }
 
 void UseAfterMoveCheck::registerMatchers(MatchFinder *Finder) {
+  // try_emplace is a common maybe-moving function that returns a
+  // bool to tell callers whether it moved. Ignore std::move inside
+  // try_emplace to avoid false positives as we don't track uses of
+  // the bool.
+  auto TryEmplaceMatcher =
+  cxxMemberCallExpr(callee(cxxMethodDecl(hasName("try_emplace";
   auto CallMoveMatcher =
-  callExpr(callee(functionDecl(hasName("::std::move"))), 
argumentCountIs(1),
+  callExpr(argumentCountIs(1), 
callee(functionDecl(hasName("::std::move"))),
hasArgument(0, declRefExpr().bind("arg")),
+   unless(inDecltypeOrTemplateArg()),
+   unless(hasParent(TryEmplaceMatcher)), expr().bind("call-move"),
anyOf(hasAncestor(compoundStmt(
  hasParent(lambdaExpr().bind("containing-lambda",
- hasAncestor(functionDecl().bind("containing-func"))),
-   unless(inDecltypeOrTemplateArg()),
-   // try_emplace is a common maybe-moving function that returns a
-   // bool to tell callers whether it moved. Ignore std::move 
inside
-   // try_emplace to avoid false positives as we don't track uses 
of
-   // the bool.
-   unless(hasParent(cxxMemberCallExpr(
-   callee(cxxMethodDecl(hasName("try_emplace")))
-  .bind("call-move");
+ hasAncestor(functionDecl(anyOf(
+ cxxConstructorDecl(
+ hasAnyConstructorInitializer(withInitializer(
+ expr(anyOf(equalsBoundNode("call-move"),
+hasDescendant(expr(
+
equalsBoundNode("call-move")
+ .bind("containing-ctor-init"
+ .bind("containing-ctor"),
+ functionDecl().bind(

[PATCH] D146288: clang-tidy: Detect use-after-move in CXXCtorInitializer

[Marco Falke via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8c10256734cd: clang-tidy: Detect use-after-move in 
CXXCtorInitializer (authored by MarcoFalke).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146288

Files:
  clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp
@@ -369,6 +369,18 @@
 };
 a.foo();
   }
+  // Don't warn if 'a' is a copy inside a synchronous lambda
+  {
+A a;
+A copied{[a] mutable { return std::move(a); }()};
+a.foo();
+  }
+  // False negative (should warn if 'a' is a ref inside a synchronous lambda)
+  {
+A a;
+A moved{[&a] mutable { return std::move(a); }()};
+a.foo();
+  }
   // Warn if the use consists of a capture that happens after a move.
   {
 A a;
@@ -1367,6 +1379,120 @@
 }
 } // namespace UnevalContext
 
+class CtorInit {
+public:
+  CtorInit(std::string val)
+  : a{val.empty()},// fine
+s{std::move(val)},
+b{val.empty()}
+  // CHECK-NOTES: [[@LINE-1]]:11: warning: 'val' used after it was moved
+  // CHECK-NOTES: [[@LINE-3]]:9: note: move occurred here
+  {}
+
+private:
+  bool a;
+  std::string s;
+  bool b;
+};
+
+class CtorInitLambda {
+public:
+  CtorInitLambda(std::string val)
+  : a{val.empty()},// fine
+s{std::move(val)},
+b{[&] { return val.empty(); }()},
+// CHECK-NOTES: [[@LINE-1]]:12: warning: 'val' used after it was moved
+// CHECK-NOTES: [[@LINE-3]]:9: note: move occurred here
+c{[] {
+  std::string str{};
+  std::move(str);
+  return str.empty();
+  // CHECK-NOTES: [[@LINE-1]]:18: warning: 'str' used after it was moved
+  // CHECK-NOTES: [[@LINE-3]]:11: note: move occurred here
+}()} {
+std::move(val);
+// CHECK-NOTES: [[@LINE-1]]:15: warning: 'val' used after it was moved
+// CHECK-NOTES: [[@LINE-13]]:9: note: move occurred here
+std::string val2{};
+std::move(val2);
+val2.empty();
+// CHECK-NOTES: [[@LINE-1]]:5: warning: 'val2' used after it was moved
+// CHECK-NOTES: [[@LINE-3]]:5: note: move occurred here
+  }
+
+private:
+  bool a;
+  std::string s;
+  bool b;
+  bool c;
+  bool d{};
+};
+
+class CtorInitOrder {
+public:
+  CtorInitOrder(std::string val)
+  : a{val.empty()}, // fine
+b{val.empty()},
+// CHECK-NOTES: [[@LINE-1]]:11: warning: 'val' used after it was moved
+s{std::move(val)} {} // wrong order
+  // CHECK-NOTES: [[@LINE-1]]:9: note: move occurred here
+  // CHECK-NOTES: [[@LINE-4]]:11: note: the use happens in a later loop iteration than the move
+
+private:
+  bool a;
+  std::string s;
+  bool b;
+};
+
+struct Obj {};
+struct CtorD {
+  CtorD(Obj b);
+};
+
+struct CtorC {
+  CtorC(Obj b);
+};
+
+struct CtorB {
+  CtorB(Obj &b);
+};
+
+struct CtorA : CtorB, CtorC, CtorD {
+  CtorA(Obj b) : CtorB{b}, CtorC{std::move(b)}, CtorD{b} {}
+  // CHECK-NOTES: [[@LINE-1]]:55: warning: 'b' used after it was moved
+  // CHECK-NOTES: [[@LINE-2]]:34: note: move occurred here
+};
+
+struct Base {
+  Base(Obj b) : bb{std::move(b)} {}
+  template  Base(Call &&c) : bb{c()} {};
+
+  Obj bb;
+};
+
+struct Derived : Base, CtorC {
+  Derived(Obj b)
+  : Base{[&] mutable { return std::move(b); }()},
+// False negative: The lambda/std::move was executed, so it should warn
+// below
+CtorC{b} {}
+};
+
+struct Derived2 : Base, CtorC {
+  Derived2(Obj b)
+  : Base{[&] mutable { return std::move(b); }},
+// This was a move, but it doesn't warn below, because it can't know if
+// the lambda/std::move was actually called
+CtorC{b} {}
+};
+
+struct Derived3 : Base, CtorC {
+  Derived3(Obj b)
+  : Base{[c = std::move(b)] mutable { return std::move(c); }}, CtorC{b} {}
+  // CHECK-NOTES: [[@LINE-1]]:74: warning: 'b' used after it was moved
+  // CHECK-NOTES: [[@LINE-2]]:19: note: move occurred here
+};
+
 class PR38187 {
 public:
   PR38187(std::string val) : val_(std::move(val)) {
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -162,6 +162,10 @@
   ` check.
   Global options of the same name should be used instead.
 
+- Improved :doc:`bugprone-use-after-move
+  ` check to also cover constructor
+  initializers.
+
 - Deprecated check-local options `HeaderFileExtensions`
   in :doc:`google-build-namespaces
   ` check.
In

[clang] 814177e - Revert "[clang][Interp][NFC] Add tests for __fp16"

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2023-03-23T10:33:51+01:00
New Revision: 814177e434d8daf70a3d67345c166d40457f68f1

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

LOG: Revert "[clang][Interp][NFC] Add tests for __fp16"

This reverts commit 0691bcb18024a28e82e8dd9a08ab0820b40c9a37.

Looks like this breaks builders, e.g.
https://lab.llvm.org/buildbot#builders/231/builds/9790

Added: 


Modified: 
clang/test/AST/Interp/floats.cpp

Removed: 




diff  --git a/clang/test/AST/Interp/floats.cpp 
b/clang/test/AST/Interp/floats.cpp
index b3c4dd4c19a84..7b9328c4d1182 100644
--- a/clang/test/AST/Interp/floats.cpp
+++ b/clang/test/AST/Interp/floats.cpp
@@ -78,94 +78,3 @@ namespace compound {
   }
   static_assert(f2() == __FLT_MAX__, "");
 }
-
-
-namespace FP16 {
-  constexpr int i = 2;
-  constexpr __fp16 f = 1.0f;
-  static_assert(f == 1.0f, "");
-
-  constexpr __fp16 f2 = 1u * f;
-  static_assert(f2 == 1.0f, "");
-
-  constexpr __fp16 f3 = 1.5;
-  constexpr int i3 = f3;
-  static_assert(i3 == 1, "");
-
-  constexpr bool b3 = f3;
-  static_assert(b3, "");
-
-
-  static_assert(1.0f16 + 3u == 4, "");
-  static_assert(4.0f16 / 1.0f16 == 4, "");
-  static_assert(10.0f16 * false == 0, "");
-
-  constexpr __fp16 __fp16s[] = {1.0f16, 2.0f16, 3.0f16, 4.0f16};
-
-  constexpr __fp16 m = 5.0f16 / 0.0f16; // ref-error {{must be initialized by 
a constant expression}} \
-   // ref-note {{division by zero}} \
-   // expected-error {{must be initialized by 
a constant expression}} \
-   // expected-note {{division by zero}}
-
-  static_assert(~2.0f16 == 3, ""); // ref-error {{invalid argument type 
'_Float16' to unary expression}} \
- // expected-error {{invalid argument type 
'_Float16' to unary expression}}
-
-  /// Initialized by a double.
-  constexpr __fp16 df = 0.0;
-  /// The other way around.
-  constexpr double fd = 0.0f16;
-
-  static_assert(0.0f == -0.0f, "");
-
-  const int k = 3 * (1.0f16 / 3.0f16);
-  static_assert(k == 1, "");
-
-  constexpr bool b = 1.0f16;
-  static_assert(b, "");
-
-  constexpr double db = true;
-  static_assert(db == 1.0f16, "");
-
-  constexpr __fp16 fa[] = {1.0f, 2.0, 1, false};
-  constexpr double da[] = {1.0f, 2.0, 1, false};
-
-  constexpr __fp16 fm = __FLT16_MAX__;
-  constexpr int someInt = fm;
-
-  constexpr float SomeFloat = __FLT_MAX__;
-  constexpr __fp16 halfFloat = SomeFloat;
-
-  constexpr float fp16ptr() {
-__fp16 f1 = 1.0f16;
-__fp16 *f2 = &f1;
-
-*f2 = 3.0;
-return f1;
-  }
-  static_assert(fp16ptr() == 3.0, "");
-
-  namespace compound {
-constexpr float f1() {
-  __fp16 f = 0;
-  f += 3.0;
-  f -= 3.0f;
-
-  f += 1;
-  f /= 1;
-  f /= 1.0;
-  f *= f;
-
-  f *= 2.0;
-  return f;
-}
-static_assert(f1() == 2, "");
-
-constexpr float f2() {
-  __fp16 f = __FLT16_MAX__;
-  f += 1.0;
-  return f;
-}
-static_assert(f2() == __FLT16_MAX__, "");
-  }
-
-}



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

[PATCH] D146436: [clang][Interp][NFC] Add tests for __fp16

[Timm Bäder via Phabricator via cfe-commits]

tbaeder added a comment.

Meh, is `__fp16` something I need to check support for?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146436

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

[PATCH] D146704: [clang-format] NFC Format.h and ClangFormatStyleOptions.rst are out of date

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: klimek, owenpan, HazardyKnusperkeks, rymiel.
MyDeveloperDay added a project: clang-format.
Herald added a project: All.
MyDeveloperDay requested review of this revision.
Herald added a project: clang.

Regenerate the style documentation, requires some minor sphinx changes to avoid 
warnings

F26871026: image.png 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146704

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

Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -2754,28 +2754,35 @@
   /// \code
   ///   A(a*b);
   /// \endcode
+  ///
   /// will usually be interpreted as a call to a function A, and the
   /// multiplication expression will be formatted as `a * b`.
   ///
   /// If we specify the macro definition:
-  /// \code
+  /// \code{.yaml}
   ///   Macros:
   ///   - A(x)=x
   /// \endcode
+  ///
   /// the code will now be parsed as a declaration of the variable b of type a*,
   /// and formatted as `a* b` (depending on pointer-binding rules).
   ///
   /// Features and restrictions:
-  /// *  Both function-like macros and object-like macros are supported.
-  /// *  Macro arguments must be used exactly once in the expansion.
-  /// *  No recursive expansion; macros referencing other macros will be
+  ///  * Both function-like macros and object-like macros are supported.
+  ///  * Macro arguments must be used exactly once in the expansion.
+  ///  * No recursive expansion; macros referencing other macros will be
   ///ignored.
-  /// *  Overloading by arity is supported: for example, given the macro
-  ///definitions A=x, A()=y, A(a)=a,
-  ///'A;' -> 'x;'
-  ///'A();' -> 'y;'
-  ///'A(z);' -> 'z;'
-  ///'A(a, b) will not be expanded.
+  ///  * Overloading by arity is supported: for example, given the macro
+  ///definitions A=x, A()=y, A(a)=a:
+  ///
+  /// \code
+  ///A; -> x;
+  ///A(); -> y;
+  ///A(z); -> z;
+  ///A(a, b); // will not be expanded.
+  /// \endcode
+  ///
+  /// \version 17.0
   std::vector Macros;
 
   /// The maximum number of consecutive empty lines to keep.
Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -3642,6 +3642,49 @@
 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ `
   A regular expression matching macros that end a block.
 
+.. _Macros:
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ `
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  will usually be interpreted as a call to a function A, and the
+  multiplication expression will be formatted as `a * b`.
+
+  If we specify the macro definition:
+
+  .. code-block:: yaml
+
+Macros:
+- A(x)=x
+
+  the code will now be parsed as a declaration of the variable b of type a*,
+  and formatted as `a* b` (depending on pointer-binding rules).
+
+  Features and restrictions:
+   * Both function-like macros and object-like macros are supported.
+   * Macro arguments must be used exactly once in the expansion.
+   * No recursive expansion; macros referencing other macros will be
+ ignored.
+   * Overloading by arity is supported: for example, given the macro
+ definitions A=x, A()=y, A(a)=a:
+
+
+  .. code-block:: c++
+
+ A; -> x;
+ A(); -> y;
+ A(z); -> z;
+ A(a, b); // will not be expanded.
+
 .. _MaxEmptyLinesToKeep:
 
 **MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ `
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D146704: [clang-format] NFC Format.h and ClangFormatStyleOptions.rst are out of date

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

This is a missed change as part of D144170: [clang-format] Add simple macro 
replacements in formatting.  and as this is 
NFC and its blocking other reviews I'm going to go ahead and commit, but I'm 
passing this by your eyes and I'm happy to make adjustments  D125171: Add a new 
clang-format option AlwaysBreakBeforeFunctionParameters 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146704

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

[clang] 7a5b957 - [clang-format] NFC Format.h and ClangFormatStyleOptions.rst are out of date

[via cfe-commits]

Author: mydeveloperday
Date: 2023-03-23T09:48:24Z
New Revision: 7a5b95732ade6c2de69b26f1038aa0a5afc39393

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

LOG: [clang-format] NFC Format.h and ClangFormatStyleOptions.rst are out of date

Regenerate the style documentation, requires some minor sphinx changes to avoid 
warnings

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

Added: 


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

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index fd8f2bbb54322..37500d7bff52d 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -3642,6 +3642,95 @@ the configuration (without a prefix: ``Auto``).
 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ 
`
   A regular expression matching macros that end a block.
 
+.. _Macros:
+<<<
+===
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ 
`
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  will usually be interpreted as a call to a function A, and the
+  multiplication expression will be formatted as `a * b`.
+
+  If we specify the macro definition:
+
+  .. code-block:: yaml
+
+Macros:
+- A(x)=x
+
+  the code will now be parsed as a declaration of the variable b of type a*,
+  and formatted as `a* b` (depending on pointer-binding rules).
+
+  Features and restrictions:
+   * Both function-like macros and object-like macros are supported.
+   * Macro arguments must be used exactly once in the expansion.
+   * No recursive expansion; macros referencing other macros will be
+ ignored.
+   * Overloading by arity is supported: for example, given the macro
+ definitions A=x, A()=y, A(a)=a:
+
+
+  .. code-block:: c++
+
+ A; -> x;
+ A(); -> y;
+ A(z); -> z;
+ A(a, b); // will not be expanded.
+
+.. _MaxEmptyLinesToKeep:
+>>>
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ 
`
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  will usually be interpreted as a call to a function A, and the
+  multiplication expression will be formatted as `a * b`.
+
+  If we specify the macro definition:
+
+  .. code-block:: yaml
+
+Macros:
+- A(x)=x
+
+  the code will now be parsed as a declaration of the variable b of type a*,
+  and formatted as `a* b` (depending on pointer-binding rules).
+
+  Features and restrictions:
+   * Both function-like macros and object-like macros are supported.
+   * Macro arguments must be used exactly once in the expansion.
+   * No recursive expansion; macros referencing other macros will be
+ ignored.
+   * Overloading by arity is supported: for example, given the macro
+ definitions A=x, A()=y, A(a)=a:
+
+
+  .. code-block:: c++
+
+ A; -> x;
+ A(); -> y;
+ A(z); -> z;
+ A(a, b); // will not be expanded.
+
 .. _MaxEmptyLinesToKeep:
 
 **MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7` 
:ref:`¶ `

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 66904a6a11232..e2709cca3967f 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -2754,28 +2754,56 @@ struct FormatStyle {
   /// \code
   ///   A(a*b);
   /// \endcode
+  ///
   /// will usually be interpreted as a call to a function A, and the
   /// multiplication expression will be formatted as `a * b`.
   ///
   /// If we specify the macro definition:
-  /// \code
+  /// \code{.yaml}
   ///   Macros:
   ///   - A(x)=x
   /// \endcode
+  ///
   /// the code will now be parsed as a declaration of the variable b of type 
a*,
   /// and formatted as `a* b` (depending on pointer-binding rules).
   ///
   /// Features and restrictions:
-  /// *  Both function-like macros and object-like macros are supported.
-  /// *  Macro arguments must be used exactly once in the expansion.
-  /// *  No recursive expansion; macros referencing other macros will be
+<<<
+===
+  ///  * Both function-like macros and object-like macros are supported.
+  ///  * Macro arguments must be used exactly once in the expansion.
+  ///  * No recursive expansion; macros referencing other macros will be
+  ///ignored.
+  ///  * Overloading by arity is supported: for example, given the macro
+  ///

[PATCH] D146704: [clang-format] NFC Format.h and ClangFormatStyleOptions.rst are out of date

[MyDeveloperDay via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7a5b95732ade: [clang-format] NFC Format.h and 
ClangFormatStyleOptions.rst are out of date (authored by MyDeveloperDay).

Changed prior to commit:
  https://reviews.llvm.org/D146704?vs=507661&id=507664#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146704

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

Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -2754,28 +2754,56 @@
   /// \code
   ///   A(a*b);
   /// \endcode
+  ///
   /// will usually be interpreted as a call to a function A, and the
   /// multiplication expression will be formatted as `a * b`.
   ///
   /// If we specify the macro definition:
-  /// \code
+  /// \code{.yaml}
   ///   Macros:
   ///   - A(x)=x
   /// \endcode
+  ///
   /// the code will now be parsed as a declaration of the variable b of type a*,
   /// and formatted as `a* b` (depending on pointer-binding rules).
   ///
   /// Features and restrictions:
-  /// *  Both function-like macros and object-like macros are supported.
-  /// *  Macro arguments must be used exactly once in the expansion.
-  /// *  No recursive expansion; macros referencing other macros will be
+<<<
+===
+  ///  * Both function-like macros and object-like macros are supported.
+  ///  * Macro arguments must be used exactly once in the expansion.
+  ///  * No recursive expansion; macros referencing other macros will be
+  ///ignored.
+  ///  * Overloading by arity is supported: for example, given the macro
+  ///definitions A=x, A()=y, A(a)=a:
+  ///
+  /// \code
+  ///A; -> x;
+  ///A(); -> y;
+  ///A(z); -> z;
+  ///A(a, b); // will not be expanded.
+  /// \endcode
+  ///
+  /// \version 17.0
+  std::vector Macros;
+
+  /// The maximum number of consecutive empty lines to keep.
+>>>
+  ///  * Both function-like macros and object-like macros are supported.
+  ///  * Macro arguments must be used exactly once in the expansion.
+  ///  * No recursive expansion; macros referencing other macros will be
   ///ignored.
-  /// *  Overloading by arity is supported: for example, given the macro
-  ///definitions A=x, A()=y, A(a)=a,
-  ///'A;' -> 'x;'
-  ///'A();' -> 'y;'
-  ///'A(z);' -> 'z;'
-  ///'A(a, b) will not be expanded.
+  ///  * Overloading by arity is supported: for example, given the macro
+  ///definitions A=x, A()=y, A(a)=a:
+  ///
+  /// \code
+  ///A; -> x;
+  ///A(); -> y;
+  ///A(z); -> z;
+  ///A(a, b); // will not be expanded.
+  /// \endcode
+  ///
+  /// \version 17.0
   std::vector Macros;
 
   /// The maximum number of consecutive empty lines to keep.
Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -3642,6 +3642,95 @@
 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ `
   A regular expression matching macros that end a block.
 
+.. _Macros:
+<<<
+===
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ `
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  will usually be interpreted as a call to a function A, and the
+  multiplication expression will be formatted as `a * b`.
+
+  If we specify the macro definition:
+
+  .. code-block:: yaml
+
+Macros:
+- A(x)=x
+
+  the code will now be parsed as a declaration of the variable b of type a*,
+  and formatted as `a* b` (depending on pointer-binding rules).
+
+  Features and restrictions:
+   * Both function-like macros and object-like macros are supported.
+   * Macro arguments must be used exactly once in the expansion.
+   * No recursive expansion; macros referencing other macros will be
+ ignored.
+   * Overloading by arity is supported: for example, given the macro
+ definitions A=x, A()=y, A(a)=a:
+
+
+  .. code-block:: c++
+
+ A; -> x;
+ A(); -> y;
+ A(z); -> z;
+ A(a, b); // will not be expanded.
+
+.. _MaxEmptyLinesToKeep:
+>>>
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ `
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  wil

[PATCH] D125171: Add a new clang-format option AlwaysBreakBeforeFunctionParameters

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

if you go ahead an rebase your should get rG7a5b95732ade: [clang-format] NFC 
Format.h and ClangFormatStyleOptions.rst are out of date 
 that will 
remove the need for the Macro section in the rst


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125171

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

[clang] 7c92820 - Revert "[clang-format] NFC Format.h and ClangFormatStyleOptions.rst are out of date"

[via cfe-commits]

Author: mydeveloperday
Date: 2023-03-23T09:52:59Z
New Revision: 7c928205c1f5a972f1f4dbeae83bd979c9a617d7

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

LOG: Revert "[clang-format] NFC Format.h and ClangFormatStyleOptions.rst are 
out of date"

This reverts commit 7a5b95732ade6c2de69b26f1038aa0a5afc39393.

Added: 


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

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index 37500d7bff52d..fd8f2bbb54322 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -3642,95 +3642,6 @@ the configuration (without a prefix: ``Auto``).
 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ 
`
   A regular expression matching macros that end a block.
 
-.. _Macros:
-<<<
-===
-
-**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ 
`
-  A list of macros of the form ``=`` .
-
-  Code will be parsed with macros expanded, in order to determine how to
-  interpret and format the macro arguments.
-
-  For example, the code:
-
-  .. code-block:: c++
-
-A(a*b);
-
-  will usually be interpreted as a call to a function A, and the
-  multiplication expression will be formatted as `a * b`.
-
-  If we specify the macro definition:
-
-  .. code-block:: yaml
-
-Macros:
-- A(x)=x
-
-  the code will now be parsed as a declaration of the variable b of type a*,
-  and formatted as `a* b` (depending on pointer-binding rules).
-
-  Features and restrictions:
-   * Both function-like macros and object-like macros are supported.
-   * Macro arguments must be used exactly once in the expansion.
-   * No recursive expansion; macros referencing other macros will be
- ignored.
-   * Overloading by arity is supported: for example, given the macro
- definitions A=x, A()=y, A(a)=a:
-
-
-  .. code-block:: c++
-
- A; -> x;
- A(); -> y;
- A(z); -> z;
- A(a, b); // will not be expanded.
-
-.. _MaxEmptyLinesToKeep:
->>>
-
-**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ 
`
-  A list of macros of the form ``=`` .
-
-  Code will be parsed with macros expanded, in order to determine how to
-  interpret and format the macro arguments.
-
-  For example, the code:
-
-  .. code-block:: c++
-
-A(a*b);
-
-  will usually be interpreted as a call to a function A, and the
-  multiplication expression will be formatted as `a * b`.
-
-  If we specify the macro definition:
-
-  .. code-block:: yaml
-
-Macros:
-- A(x)=x
-
-  the code will now be parsed as a declaration of the variable b of type a*,
-  and formatted as `a* b` (depending on pointer-binding rules).
-
-  Features and restrictions:
-   * Both function-like macros and object-like macros are supported.
-   * Macro arguments must be used exactly once in the expansion.
-   * No recursive expansion; macros referencing other macros will be
- ignored.
-   * Overloading by arity is supported: for example, given the macro
- definitions A=x, A()=y, A(a)=a:
-
-
-  .. code-block:: c++
-
- A; -> x;
- A(); -> y;
- A(z); -> z;
- A(a, b); // will not be expanded.
-
 .. _MaxEmptyLinesToKeep:
 
 **MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7` 
:ref:`¶ `

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index e2709cca3967f..66904a6a11232 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -2754,56 +2754,28 @@ struct FormatStyle {
   /// \code
   ///   A(a*b);
   /// \endcode
-  ///
   /// will usually be interpreted as a call to a function A, and the
   /// multiplication expression will be formatted as `a * b`.
   ///
   /// If we specify the macro definition:
-  /// \code{.yaml}
+  /// \code
   ///   Macros:
   ///   - A(x)=x
   /// \endcode
-  ///
   /// the code will now be parsed as a declaration of the variable b of type 
a*,
   /// and formatted as `a* b` (depending on pointer-binding rules).
   ///
   /// Features and restrictions:
-<<<
-===
-  ///  * Both function-like macros and object-like macros are supported.
-  ///  * Macro arguments must be used exactly once in the expansion.
-  ///  * No recursive expansion; macros referencing other macros will be
-  ///ignored.
-  ///  * Overloading by arity is supported: for example, given the macro
-  ///definitions A=x, A()=y, A(a)=a:
-  ///
-  /// \code
-  ///A; -> x;
-  ///A(); -> y;
-  ///A(z); -> z;
-  ///A(a, b); // will not be expanded.
-  /// \endcode
-  ///
-  /// \version 17.0
-  std::vector Macros;
-
-  /// The maximum number of consecutive empty lines to keep.

[PATCH] D146704: [clang-format] NFC Format.h and ClangFormatStyleOptions.rst are out of date

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay updated this revision to Diff 507666.
MyDeveloperDay added a comment.

Ok it seems a fix has already been landed but its not correct (missing version)


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

https://reviews.llvm.org/D146704

Files:
  clang/docs/ClangFormatStyleOptions.rst


Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -3642,6 +3642,95 @@
 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ 
`
   A regular expression matching macros that end a block.
 
+.. _Macros:
+<<<
+===
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ 
`
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  will usually be interpreted as a call to a function A, and the
+  multiplication expression will be formatted as `a * b`.
+
+  If we specify the macro definition:
+
+  .. code-block:: yaml
+
+Macros:
+- A(x)=x
+
+  the code will now be parsed as a declaration of the variable b of type a*,
+  and formatted as `a* b` (depending on pointer-binding rules).
+
+  Features and restrictions:
+   * Both function-like macros and object-like macros are supported.
+   * Macro arguments must be used exactly once in the expansion.
+   * No recursive expansion; macros referencing other macros will be
+ ignored.
+   * Overloading by arity is supported: for example, given the macro
+ definitions A=x, A()=y, A(a)=a:
+
+
+  .. code-block:: c++
+
+ A; -> x;
+ A(); -> y;
+ A(z); -> z;
+ A(a, b); // will not be expanded.
+
+.. _MaxEmptyLinesToKeep:
+>>>
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ 
`
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  will usually be interpreted as a call to a function A, and the
+  multiplication expression will be formatted as `a * b`.
+
+  If we specify the macro definition:
+
+  .. code-block:: yaml
+
+Macros:
+- A(x)=x
+
+  the code will now be parsed as a declaration of the variable b of type a*,
+  and formatted as `a* b` (depending on pointer-binding rules).
+
+  Features and restrictions:
+   * Both function-like macros and object-like macros are supported.
+   * Macro arguments must be used exactly once in the expansion.
+   * No recursive expansion; macros referencing other macros will be
+ ignored.
+   * Overloading by arity is supported: for example, given the macro
+ definitions A=x, A()=y, A(a)=a:
+
+
+  .. code-block:: c++
+
+ A; -> x;
+ A(); -> y;
+ A(z); -> z;
+ A(a, b); // will not be expanded.
+
 .. _MaxEmptyLinesToKeep:
 
 **MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7` 
:ref:`¶ `


Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -3642,6 +3642,95 @@
 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ `
   A regular expression matching macros that end a block.
 
+.. _Macros:
+<<<
+===
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ `
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  will usually be interpreted as a call to a function A, and the
+  multiplication expression will be formatted as `a * b`.
+
+  If we specify the macro definition:
+
+  .. code-block:: yaml
+
+Macros:
+- A(x)=x
+
+  the code will now be parsed as a declaration of the variable b of type a*,
+  and formatted as `a* b` (depending on pointer-binding rules).
+
+  Features and restrictions:
+   * Both function-like macros and object-like macros are supported.
+   * Macro arguments must be used exactly once in the expansion.
+   * No recursive expansion; macros referencing other macros will be
+ ignored.
+   * Overloading by arity is supported: for example, given the macro
+ definitions A=x, A()=y, A(a)=a:
+
+
+  .. code-block:: c++
+
+ A; -> x;
+ A(); -> y;
+ A(z); -> z;
+ A(a, b); // will not be expanded.
+
+.. _MaxEmptyLinesToKeep:
+>>>
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ `
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro argum

[PATCH] D146704: [clang-format] NFC Format.h and ClangFormatStyleOptions.rst are out of date

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay updated this revision to Diff 507668.
MyDeveloperDay added a comment.

incorrect yaml code block


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

https://reviews.llvm.org/D146704

Files:
  clang/docs/ClangFormatStyleOptions.rst


Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -3642,6 +3642,95 @@
 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ 
`
   A regular expression matching macros that end a block.
 
+.. _Macros:
+<<<
+===
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ 
`
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  will usually be interpreted as a call to a function A, and the
+  multiplication expression will be formatted as `a * b`.
+
+  If we specify the macro definition:
+
+  .. code-block:: yaml
+
+Macros:
+- A(x)=x
+
+  the code will now be parsed as a declaration of the variable b of type a*,
+  and formatted as `a* b` (depending on pointer-binding rules).
+
+  Features and restrictions:
+   * Both function-like macros and object-like macros are supported.
+   * Macro arguments must be used exactly once in the expansion.
+   * No recursive expansion; macros referencing other macros will be
+ ignored.
+   * Overloading by arity is supported: for example, given the macro
+ definitions A=x, A()=y, A(a)=a:
+
+
+  .. code-block:: c++
+
+ A; -> x;
+ A(); -> y;
+ A(z); -> z;
+ A(a, b); // will not be expanded.
+
+.. _MaxEmptyLinesToKeep:
+>>>
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ 
`
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  will usually be interpreted as a call to a function A, and the
+  multiplication expression will be formatted as `a * b`.
+
+  If we specify the macro definition:
+
+  .. code-block:: yaml
+
+Macros:
+- A(x)=x
+
+  the code will now be parsed as a declaration of the variable b of type a*,
+  and formatted as `a* b` (depending on pointer-binding rules).
+
+  Features and restrictions:
+   * Both function-like macros and object-like macros are supported.
+   * Macro arguments must be used exactly once in the expansion.
+   * No recursive expansion; macros referencing other macros will be
+ ignored.
+   * Overloading by arity is supported: for example, given the macro
+ definitions A=x, A()=y, A(a)=a:
+
+
+  .. code-block:: c++
+
+ A; -> x;
+ A(); -> y;
+ A(z); -> z;
+ A(a, b); // will not be expanded.
+
 .. _MaxEmptyLinesToKeep:
 
 **MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7` 
:ref:`¶ `


Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -3642,6 +3642,95 @@
 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ `
   A regular expression matching macros that end a block.
 
+.. _Macros:
+<<<
+===
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ `
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  will usually be interpreted as a call to a function A, and the
+  multiplication expression will be formatted as `a * b`.
+
+  If we specify the macro definition:
+
+  .. code-block:: yaml
+
+Macros:
+- A(x)=x
+
+  the code will now be parsed as a declaration of the variable b of type a*,
+  and formatted as `a* b` (depending on pointer-binding rules).
+
+  Features and restrictions:
+   * Both function-like macros and object-like macros are supported.
+   * Macro arguments must be used exactly once in the expansion.
+   * No recursive expansion; macros referencing other macros will be
+ ignored.
+   * Overloading by arity is supported: for example, given the macro
+ definitions A=x, A()=y, A(a)=a:
+
+
+  .. code-block:: c++
+
+ A; -> x;
+ A(); -> y;
+ A(z); -> z;
+ A(a, b); // will not be expanded.
+
+.. _MaxEmptyLinesToKeep:
+>>>
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ `
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block::

[PATCH] D146704: [clang-format] NFC Format.h and ClangFormatStyleOptions.rst are out of date

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay updated this revision to Diff 507670.
MyDeveloperDay added a comment.

I've got out of practice... correct the diff properly


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

https://reviews.llvm.org/D146704

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

Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -2754,28 +2754,35 @@
   /// \code
   ///   A(a*b);
   /// \endcode
+  ///
   /// will usually be interpreted as a call to a function A, and the
   /// multiplication expression will be formatted as `a * b`.
   ///
   /// If we specify the macro definition:
-  /// \code
+  /// \code{.yaml}
   ///   Macros:
   ///   - A(x)=x
   /// \endcode
+  ///
   /// the code will now be parsed as a declaration of the variable b of type a*,
   /// and formatted as `a* b` (depending on pointer-binding rules).
   ///
   /// Features and restrictions:
-  /// *  Both function-like macros and object-like macros are supported.
-  /// *  Macro arguments must be used exactly once in the expansion.
-  /// *  No recursive expansion; macros referencing other macros will be
+  ///  * Both function-like macros and object-like macros are supported.
+  ///  * Macro arguments must be used exactly once in the expansion.
+  ///  * No recursive expansion; macros referencing other macros will be
   ///ignored.
-  /// *  Overloading by arity is supported: for example, given the macro
-  ///definitions A=x, A()=y, A(a)=a,
-  ///'A;' -> 'x;'
-  ///'A();' -> 'y;'
-  ///'A(z);' -> 'z;'
-  ///'A(a, b) will not be expanded.
+  ///  * Overloading by arity is supported: for example, given the macro
+  ///definitions A=x, A()=y, A(a)=a
+  ///
+  /// \code
+  ///A; -> x;
+  ///A(); -> y;
+  ///A(z); -> z;
+  ///A(a, b); // will not be expanded.
+  /// \endcode
+  ///
+  /// \version 17.0
   std::vector Macros;
 
   /// The maximum number of consecutive empty lines to keep.
Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -3642,6 +3642,49 @@
 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ `
   A regular expression matching macros that end a block.
 
+.. _Macros:
+
+**Macros** (``List of Strings``) :versionbadge:`clang-format 17.0` :ref:`¶ `
+  A list of macros of the form ``=`` .
+
+  Code will be parsed with macros expanded, in order to determine how to
+  interpret and format the macro arguments.
+
+  For example, the code:
+
+  .. code-block:: c++
+
+A(a*b);
+
+  will usually be interpreted as a call to a function A, and the
+  multiplication expression will be formatted as `a * b`.
+
+  If we specify the macro definition:
+
+  .. code-block:: yaml
+
+Macros:
+- A(x)=x
+
+  the code will now be parsed as a declaration of the variable b of type a*,
+  and formatted as `a* b` (depending on pointer-binding rules).
+
+  Features and restrictions:
+   * Both function-like macros and object-like macros are supported.
+   * Macro arguments must be used exactly once in the expansion.
+   * No recursive expansion; macros referencing other macros will be
+ ignored.
+   * Overloading by arity is supported: for example, given the macro
+ definitions A=x, A()=y, A(a)=a
+
+
+  .. code-block:: c++
+
+ A; -> x;
+ A(); -> y;
+ A(z); -> z;
+ A(a, b); // will not be expanded.
+
 .. _MaxEmptyLinesToKeep:
 
 **MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ `
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D146701: [AMDGPU] Create Subtarget Features for some of 16 bits atomic fadd instructions

[Jay Foad via Phabricator via cfe-commits]

foad added inline comments.



Comment at: clang/include/clang/Basic/BuiltinsAMDGPU.def:233
+TARGET_BUILTIN(__builtin_amdgcn_global_atomic_fadd_v2bf16, "V2sV2s*1V2s", "t", 
"atomic-global-pk-add-bf16-inst")
+TARGET_BUILTIN(__builtin_amdgcn_ds_atomic_fadd_v2bf16, "V2sV2s*3V2s", "t", 
"atomic-ds-pk-add-16-insts")
 

So __builtin_amdgcn_ds_atomic_fadd_v2f16 is missing here? (Just curious- I am 
not asking you to add it in this patch.)



Comment at: llvm/lib/Target/AMDGPU/BUFInstructions.td:2889
 
-defm BUFFER_ATOMIC_ADD_F32: MUBUF_Real_Atomic_vi <0x4d>;
+let SubtargetPredicate = HasAtomicBufferGlobalPkAddF16NoRtnInsts in {
 defm BUFFER_ATOMIC_PK_ADD_F16 : MUBUF_Real_Atomic_vi <0x4e>;

Could remove the braces if you prefer - then you don't need the "End" comment 
either.



Comment at: llvm/lib/Target/AMDGPU/FLATInstructions.td:1916
+let SubtargetPredicate = HasAtomicBufferGlobalPkAddF16NoRtnInsts in
+defm GLOBAL_ATOMIC_PK_ADD_F16 : FLAT_Global_Real_Atomics_vi <0x04e, 0>;
+

Generally Real instructions copy their predicates from the corresponding 
Pseudo, so this should not be required here. Please check the other places 
where you have added predicates to Real instructions too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146701

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

[PATCH] D125171: Add a new clang-format option AlwaysBreakBeforeFunctionParameters

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

Please rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125171

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

[clang-tools-extra] b767784 - [clang-tidy][NFC] Fix broken link in Release Notes

[Carlos Galvez via cfe-commits]

Author: Carlos Galvez
Date: 2023-03-23T10:30:15Z
New Revision: b7677846da66fd003a538f87fd8de948cfcc3d6a

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

LOG: [clang-tidy][NFC] Fix broken link in Release Notes

Added: 


Modified: 
clang-tools-extra/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 89419141cebb..a5f090045615 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -238,8 +238,8 @@ Changes in existing checks
   string for ``Prefix`` or ``Suffix`` options could result in the style not
   being used.
 
-- Fixed an issue in :doc:`google-avoid-underscore-in-googletest-name
-  ` when using
+- Fixed an issue in 
:doc:`google-readability-avoid-underscore-in-googletest-name
+  ` 
when using
   ``DISABLED_`` in the test suite name.
 
 Removed checks



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

[clang] 48f97e5 - [FlowSensitive] Log analysis progress for debugging purposes

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2023-03-23T11:36:21+01:00
New Revision: 48f97e5751372b4a64144605c5e9f7e5e13e382a

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

LOG: [FlowSensitive] Log analysis progress for debugging purposes

The goal is to be able to understand how the analysis executes, and what its
incremental and final findings are, by enabling logging and reading the logs.
This should include both framework and analysis-specific information.

Ad-hoc printf-debugging doesn't seem sufficient for my understanding, at least.
Being able to check in logging, turn it on in a production binary, and quickly
find particular analysis steps within complex functions seem important.

This can be enabled programmatically through DataflowAnalysisOptions, or
via the flag -dataflow-log. (Works in unittests, clang-tidy, standalone
tools...)

Important missing pieces here:
 - a logger implementation that produces an interactive report (HTML file)
   which can be navigated via timeline/code/CFG.
   (I think the Logger interface is sufficient for this, but need to prototype).
 - display of the application-specific lattice
 - more useful display for the built-in environment
   (e.g. meaningful & consistent names for values, hiding redundant variables in
   the flow condition, hiding unreachable expressions)

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

Added: 
clang/include/clang/Analysis/FlowSensitive/Logger.h
clang/lib/Analysis/FlowSensitive/Logger.cpp
clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp

Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
clang/lib/Analysis/FlowSensitive/CMakeLists.txt
clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
clang/unittests/Analysis/FlowSensitive/CMakeLists.txt

Removed: 




diff  --git 
a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
index 702aaff9c7e7..a044f477ce1b 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
@@ -34,6 +34,7 @@
 
 namespace clang {
 namespace dataflow {
+class Logger;
 
 /// Skip past nodes that the CFG does not emit. These nodes are invisible to
 /// flow-sensitive analysis, and should be ignored as they will effectively not
@@ -67,6 +68,11 @@ class DataflowAnalysisContext {
 /// fundamentally limited: some constructs, such as recursion, are
 /// explicitly unsupported.
 std::optional ContextSensitiveOpts;
+
+/// If provided, analysis details will be recorded here.
+/// (This is always non-null within an AnalysisContext, the framework
+/// provides a fallback no-op logger).
+Logger *Log = nullptr;
   };
 
   /// Constructs a dataflow analysis context.
@@ -76,11 +82,9 @@ class DataflowAnalysisContext {
   ///  `S` must not be null.
   DataflowAnalysisContext(std::unique_ptr S,
   Options Opts = Options{
-  /*ContextSensitiveOpts=*/std::nullopt})
-  : S(std::move(S)), TrueVal(createAtomicBoolValue()),
-FalseVal(createAtomicBoolValue()), Opts(Opts) {
-assert(this->S != nullptr);
-  }
+  /*ContextSensitiveOpts=*/std::nullopt,
+  /*Logger=*/nullptr});
+  ~DataflowAnalysisContext();
 
   /// Takes ownership of `Loc` and returns a reference to it.
   ///
@@ -393,6 +397,8 @@ class DataflowAnalysisContext {
 
   // Fields modeled by environments covered by this context.
   llvm::DenseSet ModeledFields;
+
+  std::unique_ptr LogOwner; // If created via flags.
 };
 
 } // namespace dataflow

diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
index e457430a5e64..678e5b871cc8 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -22,6 +22,7 @@
 #include "clang/Analysis/FlowSensitive/ControlFlowContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowAnalysisContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/Logger.h"
 #include "clang/Analysis/FlowSensitive/StorageLocation.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "llvm/ADT/DenseMap.h"
@@ -177,10 +178,12 @@ class Environment {
   /// with a symbolic representation of the `this` pointee.
   Environment(DataflowAnalysisContext &DACtx, const DeclContext &DeclCtx);
 
-  cons

[PATCH] D144730: [FlowSensitive] Log analysis progress for debugging purposes

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG48f97e575137: [FlowSensitive] Log analysis progress for 
debugging purposes (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D144730?vs=507418&id=507678#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144730

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  clang/include/clang/Analysis/FlowSensitive/Logger.h
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
  clang/lib/Analysis/FlowSensitive/Logger.cpp
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp
@@ -0,0 +1,152 @@
+#include "TestingSupport.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
+#include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gtest/gtest.h"
+#include 
+
+namespace clang::dataflow::test {
+namespace {
+
+struct TestLattice {
+  int Elements = 0;
+  int Branches = 0;
+  int Joins = 0;
+
+  LatticeJoinEffect join(const TestLattice &Other) {
+if (Joins < 3) {
+  ++Joins;
+  Elements += Other.Elements;
+  Branches += Other.Branches;
+  return LatticeJoinEffect::Changed;
+}
+return LatticeJoinEffect::Unchanged;
+  }
+  friend bool operator==(const TestLattice &LHS, const TestLattice &RHS) {
+return std::tie(LHS.Elements, LHS.Branches, LHS.Joins) ==
+   std::tie(RHS.Elements, RHS.Branches, RHS.Joins);
+  }
+};
+
+class TestAnalysis : public DataflowAnalysis {
+public:
+  using DataflowAnalysis::DataflowAnalysis;
+
+  static TestLattice initialElement() { return TestLattice{}; }
+  void transfer(const CFGElement &, TestLattice &L, Environment &E) {
+E.logger().log([](llvm::raw_ostream &OS) { OS << "transfer()"; });
+++L.Elements;
+  }
+  void transferBranch(bool Branch, const Stmt *S, TestLattice &L,
+  Environment &E) {
+E.logger().log([&](llvm::raw_ostream &OS) {
+  OS << "transferBranch(" << Branch << ")";
+});
+++L.Branches;
+  }
+};
+
+class TestLogger : public Logger {
+public:
+  TestLogger(std::string &S) : OS(S) {}
+
+private:
+  llvm::raw_string_ostream OS;
+
+  void beginAnalysis(const ControlFlowContext &,
+ TypeErasedDataflowAnalysis &) override {
+logText("beginAnalysis()");
+  }
+  void endAnalysis() override { logText("\nendAnalysis()"); }
+
+  void enterBlock(const CFGBlock &B) override {
+OS << "\nenterBlock(" << B.BlockID << ")\n";
+  }
+  void enterElement(const CFGElement &E) override {
+// we don't want the trailing \n
+std::string S;
+llvm::raw_string_ostream SS(S);
+E.dumpToStream(SS);
+
+OS << "enterElement(" << llvm::StringRef(S).trim() << ")\n";
+  }
+  void recordState(TypeErasedDataflowAnalysisState &S) override {
+const TestLattice &L = llvm::any_cast(S.Lattice.Value);
+OS << "recordState(Elements=" << L.Elements << ", Branches=" << L.Branches
+   << ", Joins=" << L.Joins << ")\n";
+  }
+  /// Records that the analysis state for the current block is now final.
+  void blockConverged() override { logText("blockConverged()"); }
+
+  void logText(llvm::StringRef Text) override { OS << Text << "\n"; }
+};
+
+TEST(LoggerTest, Sequence) {
+  const char *Code = R"cpp(
+int target(bool b, int p, int q) {
+  return b ? p : q;
+}
+)cpp";
+
+  auto Inputs = AnalysisInputs(
+  Code, ast_matchers::hasName("target"),
+  [](ASTContext &C, Environment &) { return TestAnalysis(C); });
+  std::vector Args = {
+  "-fsyntax-only", "-fno-delayed-template-parsing", "-std=c++17"};
+  Inputs.ASTBuildArgs = Args;
+  std::string Log;
+  TestLogger Logger(Log);
+  Inputs.BuiltinOptions.Log = &Logger;
+
+  ASSERT_THAT_ERROR(checkDataflow(std::move(Inputs),
+[](const AnalysisOutputs &) {}),
+llvm::Succeeded());
+
+  EXPECT_EQ(Log, R"(beginAnalysis()
+
+enterBlock(4)
+recordState(Elements=0, Branches=0, Joins=0)
+enterElement(b)
+transfer()
+recordState(Elements=1, Branches=0, Joins=0)
+enterElement(b (ImplicitCastExpr, LValueToRValue, _Bool))
+transfer()
+recordState(Elements=2, Branches=0, Joins=0)
+
+enterBlock(3)
+transferBranch(0)
+recordState(Elements=2, Branches=1, Joins=0)
+enterElement(q)
+transfer()
+recordState(Elements=3, Branches=1, Joins=0)
+
+

[PATCH] D146279: [clangd] Extend CollectMainFileMacros.

[Haojian Wu via Phabricator via cfe-commits]

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

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146279

Files:
  clang-tools-extra/clangd/CollectMacros.cpp
  clang-tools-extra/clangd/CollectMacros.h
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -399,7 +399,7 @@
   #define $Macro_decl[[MACRO_CONCAT]](X, V, T) T foo##X = V
   #define $Macro_decl[[DEF_VAR]](X, V) int X = V
   #define $Macro_decl[[DEF_VAR_T]](T, X, V) T X = V
-  #define $Macro_decl[[DEF_VAR_REV]](V, X) DEF_VAR(X, V)
+  #define $Macro_decl[[DEF_VAR_REV]](V, X) $Macro[[DEF_VAR]](X, V)
   #define $Macro_decl[[CPY]](X) X
   #define $Macro_decl[[DEF_VAR_TYPE]](X, Y) X Y
   #define $Macro_decl[[SOME_NAME]] variable
@@ -431,7 +431,7 @@
 )cpp",
   R"cpp(
   #define $Macro_decl[[fail]](expr) expr
-  #define $Macro_decl[[assert]](COND) if (!(COND)) { fail("assertion failed" #COND); }
+  #define $Macro_decl[[assert]](COND) if (!(COND)) { $Macro[[fail]]("assertion failed" #COND); }
   // Preamble ends.
   int $Variable_def[[x]];
   int $Variable_def[[y]];
Index: clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
===
--- clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
+++ clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
@@ -8,12 +8,14 @@
 #include "AST.h"
 #include "Annotations.h"
 #include "CollectMacros.h"
+#include "Matchers.h"
 #include "SourceCode.h"
 #include "TestTU.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
+#include 
 
 namespace clang {
 namespace clangd {
@@ -21,19 +23,24 @@
 
 using testing::UnorderedElementsAreArray;
 
+MATCHER_P(rangeIs, R, "") { return arg.Rng == R; }
+MATCHER(isDef, "") { return arg.IsDefinition; }
+MATCHER(inConditionalDirective, "") { return arg.InConditionalDirective; }
+
 TEST(CollectMainFileMacros, SelectedMacros) {
   // References of the same symbol must have the ranges with the same
   // name(integer). If there are N different symbols then they must be named
   // from 1 to N. Macros for which SymbolID cannot be computed must be named
-  // "Unknown".
+  // "Unknown". The payload of the annotation describes the extra bit
+  // information of the MacroOccurrence (e.g. $1(def) => IsDefinition).
   const char *Tests[] = {
   R"cpp(// Macros: Cursor on definition.
-#define $1[[FOO]](x,y) (x + y)
+#define $1(def)[[FOO]](x,y) (x + y)
 int main() { int x = $1[[FOO]]($1[[FOO]](3, 4), $1[[FOO]](5, 6)); }
   )cpp",
   R"cpp(
-#define $1[[M]](X) X;
-#define $2[[abc]] 123
+#define $1(def)[[M]](X) X;
+#define $2(def)[[abc]] 123
 int s = $1[[M]]($2[[abc]]);
   )cpp",
   // FIXME: Locating macro in duplicate definitions doesn't work. Enable
@@ -48,31 +55,50 @@
   //   #undef $2[[abc]]
   // )cpp",
   R"cpp(
-#ifdef $Unknown[[UNDEFINED]]
+#ifdef $Unknown(condit)[[UNDEFINED]]
+#endif
+
+#ifndef $Unknown(condit)[[UNDEFINED]]
+#endif
+
+#if defined($Unknown(condit)[[UNDEFINED]])
 #endif
   )cpp",
   R"cpp(
-#ifndef $Unknown[[abc]]
-#define $1[[abc]]
-#ifdef $1[[abc]]
+#ifndef $Unknown(condit)[[abc]]
+#define $1(def)[[abc]]
+#ifdef $1(condit)[[abc]]
 #endif
 #endif
   )cpp",
   R"cpp(
 // Macros from token concatenations not included.
-#define $1[[CONCAT]](X) X##A()
-#define $2[[PREPEND]](X) MACRO##X()
-#define $3[[MACROA]]() 123
+#define $1(def)[[CONCAT]](X) X##A()
+#define $2(def)[[PREPEND]](X) MACRO##X()
+#define $3(def)[[MACROA]]() 123
 int B = $1[[CONCAT]](MACRO);
 int D = $2[[PREPEND]](A);
   )cpp",
   R"cpp(
-// FIXME: Macro names in a definition are not detected.
-#define $1[[MACRO_ARGS2]](X, Y) X Y
-#define $2[[FOO]] BAR
-#define $3[[BAR]] 1
+#define $1(def)[[MACRO_ARGS2]](X, Y) X Y
+#define $3(def)[[BAR]] 1
+#define $2(def)[[FOO]] $3[[BAR]]
 int A = $2[[FOO]];
   )cpp"};
+  auto ExpectedResults = [](const Annotations &T, StringRef Name) {
+std::vector> ExpectedLocations;
+for (const auto &[R, Bits] : T.

[PATCH] D146279: [clangd] Extend CollectMainFileMacros.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/CollectMacros.h:48
 public:
-  explicit CollectMainFileMacros(const SourceManager &SM, MainFileMacros &Out)
-  : SM(SM), Out(Out) {}
+  explicit CollectMainFileMacros(const SourceManager &SM,
+ const Preprocessor &PP, MainFileMacros &Out)

kadircet wrote:
> nit: you can get SM out of PP, no need to pass both.
oh, right!



Comment at: clang-tools-extra/clangd/CollectMacros.h:70
 
   void Ifdef(SourceLocation Loc, const Token &MacroName,
  const MacroDefinition &MD) override {

kadircet wrote:
> nit: can you actually move macro bodies out-of-line ? it's unfortunate that 
> we need to build half of the project everytime we touch this header.
Done (thanks for the define-out-line code action!)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146279

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

[PATCH] D146234: [clang] Fix crash when handling nested immediate invocations

[Mariya Podchishchaeva via Phabricator via cfe-commits]

Fznamznon added a comment.

Ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146234

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

[PATCH] D146704: [clang-format] NFC Format.h and ClangFormatStyleOptions.rst are out of date

[Manuel Klimek via Phabricator via cfe-commits]

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

Thank you!! Sorry for forgetting that I needed to do this, 


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

https://reviews.llvm.org/D146704

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

Re: [PATCH] D144170: [clang-format] Add simple macro replacements in formatting.

[Manuel Klimek via cfe-commits]

I am so sorry, thanks for sending out the patch already and fixing the
layout!

On Thu, Mar 23, 2023 at 10:08 AM MyDeveloperDay via Phabricator <
revi...@reviews.llvm.org> wrote:

> MyDeveloperDay added a comment.
>
> I know this is like "telling my grandmother to suck eggs" but  @klimek the
> change here to Format.h means you need to regenerate
> ClangFormatStyleOptions.rst via docs/tools/dump_format_style.py
>
> Impacting the next change to generate - D125171: Add a new clang-format
> option AlwaysBreakBeforeFunctionParameters <
> https://reviews.llvm.org/D125171>
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D144170/new/
>
> https://reviews.llvm.org/D144170
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D146406: [IncludeCleaner][clangd] Mark umbrella headers as users of private

[Haojian Wu via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/include-cleaner/lib/Analysis.cpp:100
+  // Check if main file is the public interface for a private header. If so
+  // we shouldn't diagnose it as unused.
+  if (auto PHeader = PI->getPublic(I.Resolved); !PHeader.empty()) {

kadircet wrote:
> hokein wrote:
> > The beahvior (no showing the diagnostic) seems reasonable to me as we can 
> > infer that the included header is supposed to be exported by the main file. 
> > Just explore this a bit more.
> > 
> > The sad bit is that we start diverging from the classical IWYU tool (I have 
> > check it, for this case, it gives an unused-include unless you add an 
> > export pragma).
> > 
> > I think the main cause is that we're missing the `// IWYU pragma: export`, 
> > we should still want to recommend users to add the pragma export, right?
> > 
> > My only concern is that without the `export` pragma, whether the include is 
> > used can't be reason about by just "reading" the main-file content by 
> > human, e.g. for the case below, there is no usage of the `private.h` 
> > (previously the trailing `// IWYU pragma: export` comment is considered a 
> > usage), we have to open the private.h and find the private mapping to 
> > verify the usage.
> > 
> > ```
> > // public.h
> > 
> > #include "private.h"
> > ```
> > 
> > It seems better to provide an `adding //IWYU pragma: export` FIXIT.
> > 
> > The sad bit is that we start diverging from the classical IWYU tool (I have 
> > check it, for this case, it gives an unused-include unless you add an 
> > export pragma).
> 
> we're not providing the same behavior with IWYU tool, it's nice to be 
> compatible with it and this change won't break that compatibility (i.e. if 
> IWYU tool drops this include, we're not suggesting to insert or while IWYU 
> tool is suggesting to insert we're not suggesting to remove). so i don't 
> think this argument applies here.
> 
> > I think the main cause is that we're missing the // IWYU pragma: export, we 
> > should still want to recommend users to add the pragma export, right?
> 
> i don't see the reason why. i think we're actually losing value by enforcing 
> people to annotate headers in both places. if the library provider already 
> put a pragma in the included header, marking the umbrella header as the 
> private header, what's the extra value we're getting by making them also 
> annotate the public header with a bunch of export pragmas? i feel like this 
> goes against the nature of letting tooling automate things as much as 
> possible.
> 
> > My only concern is that without the export pragma, whether the include is 
> > used can't be reason about by just "reading" the main-file content by 
> > human, e.g. for the case below, there is no usage of the private.h 
> > (previously the trailing // IWYU pragma: export comment is considered a 
> > usage), we have to open the private.h and find the private mapping to 
> > verify the usage.
> 
> this definitely makes sense, and having an explicit IWYU export/keep pragma 
> on these includes are definitely nice but I believe in the common case, 
> because private-public matching is 1:1, the reason why a private header is 
> included inside a public header is quite obvious hence absence of these 
> pragmas won't really cause confusion, to the contrary forcing people to 
> introduce them will actually create frustration.
> 
> WDYT?
> this change won't break that compatibility (i.e. if IWYU tool drops this 
> include, we're not suggesting to insert or while IWYU tool is suggesting to 
> insert we're not suggesting to remove). so i don't think this argument 
> applies here.

Agree on this point. This is a safe change. But now clangd is diverging from 
the clang-include-cleaner tool.

> i feel like this goes against the nature of letting tooling automate things 
> as much as possible

I think the proposed change is good.

From the tooling automation, for example, we're doing a large cleanup (remove 
unused includes),  we should not remove this include. 

For interactive tools (like clangd), I actually think in addition to that, 
clangd should tell the user that they are missing an IWYU export pragma here, 
and suggest a FIXIT (but that's probably another thread).
 
> but I believe in the common case, because private-public matching is 1:1, the 
> reason why a private header is included inside a public header is quite 
> obvious hence absence of these pragmas won't really cause confusion

I'm not sure this is true, I think private=>public is 1:1, but public=>private 
is not always 1:1 (e.g. public header use `begin_export`/`end_export` to export 
a bunch of headers),
for these public headers, missing export pragmas is hard to justify the purpose.






Comment at: clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp:231
+  {
+Inputs.

[clang-tools-extra] 002c4b7 - [clangd] Extend CollectMainFileMacros.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2023-03-23T11:59:11+01:00
New Revision: 002c4b7b955b1fc8825b4d6b46bb079390bce812

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

LOG: [clangd] Extend CollectMainFileMacros.

Extend the existing MainFileMacros structure:
- record more information (InConditionalDirective) in MacroOccurrence
- collect macro references inside macro body (fix a long-time FIXME)

So that the MainFileMacros preseve enough information, which allows a
just-in-time convertion to interop with include-cleaner::Macro for
include-cleaer features.

See the context in https://reviews.llvm.org/D146017.

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

Added: 


Modified: 
clang-tools-extra/clangd/CollectMacros.cpp
clang-tools-extra/clangd/CollectMacros.h
clang-tools-extra/clangd/ParsedAST.cpp
clang-tools-extra/clangd/Preamble.cpp
clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/CollectMacros.cpp 
b/clang-tools-extra/clangd/CollectMacros.cpp
index 687f86e0a77eb..c0ed8b68ea481 100644
--- a/clang-tools-extra/clangd/CollectMacros.cpp
+++ b/clang-tools-extra/clangd/CollectMacros.cpp
@@ -9,12 +9,13 @@
 #include "CollectMacros.h"
 #include "AST.h"
 #include "clang/Basic/SourceLocation.h"
+#include "llvm/ADT/STLExtras.h"
 
 namespace clang {
 namespace clangd {
 
 void CollectMainFileMacros::add(const Token &MacroNameTok, const MacroInfo *MI,
-bool IsDefinition) {
+bool IsDefinition, bool InIfCondition) {
   if (!InMainFile)
 return;
   auto Loc = MacroNameTok.getLocation();
@@ -26,9 +27,49 @@ void CollectMainFileMacros::add(const Token &MacroNameTok, 
const MacroInfo *MI,
   auto Range = halfOpenToRange(
   SM, CharSourceRange::getCharRange(Loc, MacroNameTok.getEndLoc()));
   if (auto SID = getSymbolID(Name, MI, SM))
-Out.MacroRefs[SID].push_back({Range, IsDefinition});
+Out.MacroRefs[SID].push_back({Range, IsDefinition, InIfCondition});
   else
-Out.UnknownMacros.push_back({Range, IsDefinition});
+Out.UnknownMacros.push_back({Range, IsDefinition, InIfCondition});
+}
+
+void CollectMainFileMacros::FileChanged(SourceLocation Loc, FileChangeReason,
+SrcMgr::CharacteristicKind, FileID) {
+  InMainFile = isInsideMainFile(Loc, SM);
+}
+void CollectMainFileMacros::MacroExpands(const Token &MacroName,
+ const MacroDefinition &MD,
+ SourceRange Range,
+ const MacroArgs *Args) {
+  add(MacroName, MD.getMacroInfo());
+}
+void CollectMainFileMacros::MacroUndefined(const clang::Token &MacroName,
+   const clang::MacroDefinition &MD,
+   const clang::MacroDirective *Undef) 
{
+  add(MacroName, MD.getMacroInfo());
+}
+void CollectMainFileMacros::Ifdef(SourceLocation Loc, const Token &MacroName,
+  const MacroDefinition &MD) {
+  add(MacroName, MD.getMacroInfo(), /*IsDefinition=*/false,
+  /*InConditionalDirective=*/true);
+}
+void CollectMainFileMacros::Ifndef(SourceLocation Loc, const Token &MacroName,
+   const MacroDefinition &MD) {
+  add(MacroName, MD.getMacroInfo(), /*IsDefinition=*/false,
+  /*InConditionalDirective=*/true);
+}
+void CollectMainFileMacros::Defined(const Token &MacroName,
+const MacroDefinition &MD,
+SourceRange Range) {
+  add(MacroName, MD.getMacroInfo(), /*IsDefinition=*/false,
+  /*InConditionalDirective=*/true);
+}
+void CollectMainFileMacros::SourceRangeSkipped(SourceRange R,
+   SourceLocation EndifLoc) {
+  if (!InMainFile)
+return;
+  Position Begin = sourceLocToPosition(SM, R.getBegin());
+  Position End = sourceLocToPosition(SM, R.getEnd());
+  Out.SkippedRanges.push_back(Range{Begin, End});
 }
 
 class CollectPragmaMarks : public PPCallbacks {
@@ -58,5 +99,24 @@ collectPragmaMarksCallback(const SourceManager &SM,
   return std::make_unique(SM, Out);
 }
 
+void CollectMainFileMacros::MacroDefined(const Token &MacroName,
+ const MacroDirective *MD) {
+
+  if (!InMainFile)
+return;
+  const auto *MI = MD->getMacroInfo();
+  add(MacroName, MD->getMacroInfo(), true);
+  if (MI)
+for (const auto &Tok : MI->tokens()) {
+  auto *II = Tok.getIdentifierInfo();
+  // Could this token be a reference to a macro? (Not param to this macro).
+  if (!II || !II->

[PATCH] D146279: [clangd] Extend CollectMainFileMacros.

[Haojian Wu via Phabricator via cfe-commits]

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

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146279

Files:
  clang-tools-extra/clangd/CollectMacros.cpp
  clang-tools-extra/clangd/CollectMacros.h
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -399,7 +399,7 @@
   #define $Macro_decl[[MACRO_CONCAT]](X, V, T) T foo##X = V
   #define $Macro_decl[[DEF_VAR]](X, V) int X = V
   #define $Macro_decl[[DEF_VAR_T]](T, X, V) T X = V
-  #define $Macro_decl[[DEF_VAR_REV]](V, X) DEF_VAR(X, V)
+  #define $Macro_decl[[DEF_VAR_REV]](V, X) $Macro[[DEF_VAR]](X, V)
   #define $Macro_decl[[CPY]](X) X
   #define $Macro_decl[[DEF_VAR_TYPE]](X, Y) X Y
   #define $Macro_decl[[SOME_NAME]] variable
@@ -431,7 +431,7 @@
 )cpp",
   R"cpp(
   #define $Macro_decl[[fail]](expr) expr
-  #define $Macro_decl[[assert]](COND) if (!(COND)) { fail("assertion failed" #COND); }
+  #define $Macro_decl[[assert]](COND) if (!(COND)) { $Macro[[fail]]("assertion failed" #COND); }
   // Preamble ends.
   int $Variable_def[[x]];
   int $Variable_def[[y]];
Index: clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
===
--- clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
+++ clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
@@ -8,12 +8,14 @@
 #include "AST.h"
 #include "Annotations.h"
 #include "CollectMacros.h"
+#include "Matchers.h"
 #include "SourceCode.h"
 #include "TestTU.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/Support/ScopedPrinter.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
+#include 
 
 namespace clang {
 namespace clangd {
@@ -21,19 +23,24 @@
 
 using testing::UnorderedElementsAreArray;
 
+MATCHER_P(rangeIs, R, "") { return arg.Rng == R; }
+MATCHER(isDef, "") { return arg.IsDefinition; }
+MATCHER(inConditionalDirective, "") { return arg.InConditionalDirective; }
+
 TEST(CollectMainFileMacros, SelectedMacros) {
   // References of the same symbol must have the ranges with the same
   // name(integer). If there are N different symbols then they must be named
   // from 1 to N. Macros for which SymbolID cannot be computed must be named
-  // "Unknown".
+  // "Unknown". The payload of the annotation describes the extra bit
+  // information of the MacroOccurrence (e.g. $1(def) => IsDefinition).
   const char *Tests[] = {
   R"cpp(// Macros: Cursor on definition.
-#define $1[[FOO]](x,y) (x + y)
+#define $1(def)[[FOO]](x,y) (x + y)
 int main() { int x = $1[[FOO]]($1[[FOO]](3, 4), $1[[FOO]](5, 6)); }
   )cpp",
   R"cpp(
-#define $1[[M]](X) X;
-#define $2[[abc]] 123
+#define $1(def)[[M]](X) X;
+#define $2(def)[[abc]] 123
 int s = $1[[M]]($2[[abc]]);
   )cpp",
   // FIXME: Locating macro in duplicate definitions doesn't work. Enable
@@ -48,31 +55,50 @@
   //   #undef $2[[abc]]
   // )cpp",
   R"cpp(
-#ifdef $Unknown[[UNDEFINED]]
+#ifdef $Unknown(condit)[[UNDEFINED]]
+#endif
+
+#ifndef $Unknown(condit)[[UNDEFINED]]
+#endif
+
+#if defined($Unknown(condit)[[UNDEFINED]])
 #endif
   )cpp",
   R"cpp(
-#ifndef $Unknown[[abc]]
-#define $1[[abc]]
-#ifdef $1[[abc]]
+#ifndef $Unknown(condit)[[abc]]
+#define $1(def)[[abc]]
+#ifdef $1(condit)[[abc]]
 #endif
 #endif
   )cpp",
   R"cpp(
 // Macros from token concatenations not included.
-#define $1[[CONCAT]](X) X##A()
-#define $2[[PREPEND]](X) MACRO##X()
-#define $3[[MACROA]]() 123
+#define $1(def)[[CONCAT]](X) X##A()
+#define $2(def)[[PREPEND]](X) MACRO##X()
+#define $3(def)[[MACROA]]() 123
 int B = $1[[CONCAT]](MACRO);
 int D = $2[[PREPEND]](A);
   )cpp",
   R"cpp(
-// FIXME: Macro names in a definition are not detected.
-#define $1[[MACRO_ARGS2]](X, Y) X Y
-#define $2[[FOO]] BAR
-#define $3[[BAR]] 1
+#define $1(def)[[MACRO_ARGS2]](X, Y) X Y
+#define $3(def)[[BAR]] 1
+#define $2(def)[[FOO]] $3[[BAR]]
 int A = $2[[FOO]];
   )cpp"};
+  auto ExpectedResults = [](const Annotations

[PATCH] D145579: [Flang][AMDGPU] Add support for AMDGPU to Flang driver

[Dominik Adamski via Phabricator via cfe-commits]

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



Comment at: flang/lib/Frontend/FrontendActions.cpp:139-142
+  // Clang does not append all target features to the clang -cc1 invocation.
+  // Some AMDGPU features are passed implicitly by the Clang frontend.
+  // That's why we need to extract implicit AMDGPU target features and add
+  // them to the target features specified by the user

awarzynski wrote:
> [nit] IMHO this is documenting an implementation detail that would be more 
> relevant inside `getExplicitAndImplicitAMDGPUTargetFeatures`.
> 
> More importantly, you are suggesting that the driver is doing whatever it is 
> doing "because that's what Clang does". Consistency with Clang is important 
> (you could call it out in the commit message) :) However, it would be even 
> nicer to understand the actual rationale behind these implicit features. Any 
> idea? Perhaps there are some clues in git history?
> 
> Also, perhaps a TODO to share this code with Clang? (to make it even clearer 
> that the frontend driver aims for full consistency with Clang here).
I think that the main difference between Clang and Flang is the lack of 
`TargetInfo` class.

[[ https://clang.llvm.org/doxygen/classclang_1_1TargetInfo.html | TargetInfo 
classes ]] are Clang specific and they are responsible for parsing/adding 
default target features. Every target performs initialization in different way 
(compare for example [[ 
https://clang.llvm.org/doxygen/Basic_2Targets_2AArch64_8cpp_source.html#l00960 
| AArch64 ]] vs [[ 
https://clang.llvm.org/doxygen/Basic_2Targets_2AMDGPU_8cpp_source.html#l00179 | 
AMDGPU ]] target initialization.

I don't want to make TargetInfo class Clang indendent (see discussion: 
https://discourse.llvm.org/t/rfc-targetinfo-library/64342 ). I also don't want 
to reimplement the whole TargetInfo class in Flang, because Flang already uses 
LLVM TargetMachine class (see: 
https://llvm.org/doxygen/classllvm_1_1TargetMachine.html and 
https://github.com/llvm/llvm-project/blob/main/flang/lib/Frontend/FrontendActions.cpp#L614
 )  which can play similar role as Clang TargetInfo IMO.

That's why I decided to implement `getExplicitAndImplicitAMDGPUTargetFeatures` 
function which performs initialization of default AMDGPU target features.


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

https://reviews.llvm.org/D145579

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

[PATCH] D144115: [clang] Extend pragma dump to support expressions

[Vlad Serebrennikov via Phabricator via cfe-commits]

Endill added inline comments.



Comment at: clang/lib/Parse/ParsePragma.cpp:731-736
+} else if (E.get()->isTypeDependent()) {
+  PP.Diag(StartLoc, diag::warn_pragma_debug_type_dependent_argument)
+<< SourceRange(StartLoc, Tok.getLocation());
+} else if (E.get()->isValueDependent()) {
+  PP.Diag(StartLoc, diag::warn_pragma_debug_value_dependent_argument)
+<< SourceRange(StartLoc, Tok.getLocation());

aaron.ballman wrote:
> Endill wrote:
> > aaron.ballman wrote:
> > > 
> > I see quite a lot of items inside `ExprDependence`. Are you sure we don't 
> > miss any corner cases by using `isValueDependent()` to select between 
> > value- and type-dependent diagnostic text? 
> I was trying to think of a case where we'd run into problems, but I can't 
> come up with one, so I believe we're fine here.
Apparently, we should do it the other way round, because `An id-expression is 
value-dependent if: — it is type-dependent` ([[ 
http://eel.is/c++draft/temp.dep#constexpr-2.2 | temp.dep.constexpr/2.2]]). I 
observe that in one of the tests I added, `T{}` is TypeValueInstantiation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144115

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

[PATCH] D146671: [clang][ExtractAPI]Fix Declaration fragments for instancetype in the type position degrade to id

[Daniel Grumberg via Phabricator via cfe-commits]

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

LGTM, but you should  also check in the test that `id` still renders as 
expected.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146671

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

[PATCH] D146701: [AMDGPU] Create Subtarget Features for some of 16 bits atomic fadd instructions

[Mariusz Sikora via Phabricator via cfe-commits]

mariusz-sikora-at-amd added inline comments.



Comment at: clang/include/clang/Basic/BuiltinsAMDGPU.def:233
+TARGET_BUILTIN(__builtin_amdgcn_global_atomic_fadd_v2bf16, "V2sV2s*1V2s", "t", 
"atomic-global-pk-add-bf16-inst")
+TARGET_BUILTIN(__builtin_amdgcn_ds_atomic_fadd_v2bf16, "V2sV2s*3V2s", "t", 
"atomic-ds-pk-add-16-insts")
 

foad wrote:
> So __builtin_amdgcn_ds_atomic_fadd_v2f16 is missing here? (Just curious- I am 
> not asking you to add it in this patch.)
I have a different change which will add only 
__builtin_amdgcn_ds_atomic_fadd_v2f16 (not pushed yet, because it depends on 
this change).



Comment at: llvm/lib/Target/AMDGPU/BUFInstructions.td:2889
 
-defm BUFFER_ATOMIC_ADD_F32: MUBUF_Real_Atomic_vi <0x4d>;
+let SubtargetPredicate = HasAtomicBufferGlobalPkAddF16NoRtnInsts in {
 defm BUFFER_ATOMIC_PK_ADD_F16 : MUBUF_Real_Atomic_vi <0x4e>;

foad wrote:
> Could remove the braces if you prefer - then you don't need the "End" comment 
> either.
So, as I understand from other comment:

> Generally Real instructions copy their predicates from the corresponding 
> Pseudo, so this should not be required here. Please check the other places 
> where you have added predicates to Real instructions too.

We do not need this (L2889) Predicate, because it was added to Pseudo 
Instruction ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146701

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

[PATCH] D146497: libclang: Pass Clang install directory to driver via argv[0].

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D146497#4215650 , @Hahnfeld wrote:

> FYI this commit breaks `clang/test/Index/index-file.cu` for me:
>
>   warning: CUDA version 11.8 is only partially supported 
> [-Wunknown-cuda-version]
>   warning: CUDA version 11.8 is only partially supported 
> [-Wunknown-cuda-version]
>   /home/jhahnfel/LLVM/src/clang/test/Index/index-file.cu:8:20: error: 
> CHECK-HOST-NOT: excluded string found in input
>   // CHECK-HOST-NOT: macro definition=__CUDA_ARCH__
>  ^
>   :6218:48: note: found here
>   // CHECK: __clang_cuda_runtime_wrapper.h:70:9: macro 
> definition=__CUDA_ARCH__ Extent=[70:9 - 70:27]
>  
> ^~
>
> It //could// be related to the warning about my locally installed CUDA 
> version, but `__CUDA_ARCH__` should really not be defined when compiling for 
> the host. If you have any idea what's going on here, please let me know - I'm 
> a bit puzzled right now...

This is confirmed on at least this build bot: 
https://lab.llvm.org/buildbot/#/builders/91/builds/15271

I'll investigate locally and revert if it's not something I can fix forward.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146497

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

[PATCH] D143974: [clangd] Inactive regions support via dedicated protocol

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

Thanks, and sorry for late response.

The patch looks good to me in general.




Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:590
   {"foldingRangeProvider", true},
+  {"inactiveRegionsProvider", true},
   };

nit: add trailing `// clangd extension`, probably better to move to below line 
585 (since we group all extension there)



Comment at: clang-tools-extra/clangd/ClangdServer.cpp:123
+  ServerCallbacks->onInactiveRegionsReady(Path,
+  std::move(InactiveRegions));
+}

nit: just `AST.getMacros().SkppedRanges()`?



Comment at: clang-tools-extra/clangd/ClangdServer.cpp:977
+  return CB(InpAST.takeError());
+// Include inactive regions in semantic highlighting tokens only if the
+// client doesn't support a dedicated protocol for being informed about

As discussed in the GitHub thread (the experiment of highlighting the inactive 
regions as comment is considered as a failure),  we should always not include 
the inactive region in the semantic highlighting, this will also simplify the 
existing code in semantic highlighting (e.g. 
https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/clangd/SemanticHighlighting.cpp#L464-L513).
 I think we can do it in a separated patch. 



Comment at: clang-tools-extra/clangd/ClangdServer.h:91
+virtual void onInactiveRegionsReady(PathRef File,
+std::vector InactiveRegions) {}
   };

it would be nice to have a unittest for this, I think it should not be to hard 
to add one in `ClangdTests.cpp` (with a customize Callbacks passing to the 
`ClangdServer`).



Comment at: clang-tools-extra/clangd/Protocol.h:521
+  /// Whether the client supports the textDocument/inactiveRegions
+  /// notificatin. This is a clangd extension.
+  bool InactiveRegions = false;

nit: notificatin => notification


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143974

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

[clang] 18d5688 - Revert "libclang: Pass Clang install directory to driver via argv[0]."

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2023-03-23T08:05:58-04:00
New Revision: 18d56880a89ad7d58f8543d148facebd079cef19

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

LOG: Revert "libclang: Pass Clang install directory to driver via argv[0]."

This reverts commit 201fdef40dd6ec193d18d39638454a3c972f1fec.

There was an issue found in post-commit by:
https://lab.llvm.org/buildbot/#/builders/91/builds/15272

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang-c/Index.h
clang/test/Index/record-completion-invocation.c
clang/test/Index/record-parsing-invocation.c
clang/tools/libclang/CIndex.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 94e0f10a3174..005bf99a6245 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -368,14 +368,6 @@ libclang
   has an evaluable bit width. Fixes undefined behavior when called on a
   bit-field whose width depends on a template paramter.
 
-- ``clang_parseTranslationUnit`` and ``clang_parseTranslationUnit2`` have been
-  changed to automatically locate the Clang installation directory relative to
-  the location of the libclang binary and use it for system headers installed
-  alongside the Clang installation. It is no longer necessary to manually
-  locate such system headers or use the ``clang_parseTranslationUnit2FullArgv``
-  function for this purpose if libclang has been installed in the default
-  location.
- 
 Static Analyzer
 ---
 - Fix incorrect alignment attribute on the this parameter of certain

diff  --git a/clang/include/clang-c/Index.h b/clang/include/clang-c/Index.h
index 8275f2941a41..c7d32e6a152a 100644
--- a/clang/include/clang-c/Index.h
+++ b/clang/include/clang-c/Index.h
@@ -899,13 +899,8 @@ CINDEX_LINKAGE enum CXErrorCode 
clang_parseTranslationUnit2(
 
 /**
  * Same as clang_parseTranslationUnit2 but requires a full command line
- * for \c command_line_args including argv[0].
- *
- * This is useful if the driver uses paths relative to the binary and either
- * you are targeting libclang versions older than Clang 17, or libclang is
- * installed to a non-standard location. Clang 17 and newer will automatically
- * use the correct argv[0] if libclang is installed in the lib directory
- * parallel to the bin directory where the clang binary is installed.
+ * for \c command_line_args including argv[0]. This is useful if the standard
+ * library paths are relative to the binary.
  */
 CINDEX_LINKAGE enum CXErrorCode clang_parseTranslationUnit2FullArgv(
 CXIndex CIdx, const char *source_filename,

diff  --git a/clang/test/Index/record-completion-invocation.c 
b/clang/test/Index/record-completion-invocation.c
index 75eb9083908a..4b667134fa2d 100644
--- a/clang/test/Index/record-completion-invocation.c
+++ b/clang/test/Index/record-completion-invocation.c
@@ -9,4 +9,4 @@
 // RUN: env LIBCLANG_DISABLE_CRASH_RECOVERY=1 
CINDEXTEST_INVOCATION_EMISSION_PATH=%t not --crash c-index-test 
-code-completion-at=%s:10:1 
"-remap-file=%s,%S/Inputs/record-parsing-invocation-remap.c" %s
 // RUN: cat %t/libclang-* | FileCheck %s
 
-// CHECK: 
{"toolchain":"{{.*}}","libclang.operation":"complete","libclang.opts":1,"args":["{{.*}}bin{{.*}}clang","-fno-spell-checking","{{.*}}record-completion-invocation.c","-Xclang","-detailed-preprocessing-record","-fallow-editor-placeholders"],"invocation-args":["-code-completion-at={{.*}}record-completion-invocation.c:10:1"],"unsaved_file_hashes":[{"name":"{{.*}}record-completion-invocation.c","md5":"aee23773de90e665992b48209351d70e"}]}
+// CHECK: 
{"toolchain":"{{.*}}","libclang.operation":"complete","libclang.opts":1,"args":["clang","-fno-spell-checking","{{.*}}record-completion-invocation.c","-Xclang","-detailed-preprocessing-record","-fallow-editor-placeholders"],"invocation-args":["-code-completion-at={{.*}}record-completion-invocation.c:10:1"],"unsaved_file_hashes":[{"name":"{{.*}}record-completion-invocation.c","md5":"aee23773de90e665992b48209351d70e"}]}

diff  --git a/clang/test/Index/record-parsing-invocation.c 
b/clang/test/Index/record-parsing-invocation.c
index f370f014fb1c..e0c4cdb05fb0 100644
--- a/clang/test/Index/record-parsing-invocation.c
+++ b/clang/test/Index/record-parsing-invocation.c
@@ -25,5 +25,5 @@
 #  pragma clang __debug parser_crash
 #endif
 
-// CHECK: 
{"toolchain":"{{.*}}","libclang.operation":"parse","libclang.opts":1,"args":["{{.*}}bin{{.*}}clang","-fno-spell-checking","{{.*}}record-parsing-invocation.c","-Xclang","-detailed-preprocessing-record","-fallow-editor-placeholders"]}
-// CHECK-UNSAVED: 
{"toolchain":"{{.*}}","libclang.operation":"parse","libclang.opts":1,"args":["{{.*}}bin{{.*}}clang","-fno-spell-checking","{{.*}}record-parsing-invocation.c","-Xclang","-detaile

[PATCH] D145584: [libc] Add support for setjmp and longjmp in riscv

[Mikhail Ramalho via Phabricator via cfe-commits]

mikhail.ramalho updated this revision to Diff 507700.
mikhail.ramalho marked 6 inline comments as done.
mikhail.ramalho added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145584

Files:
  clang/docs/tools/clang-formatted-files.txt
  libc/config/linux/riscv64/entrypoints.txt
  libc/config/linux/riscv64/headers.txt
  libc/include/llvm-libc-types/jmp_buf.h
  libc/src/setjmp/CMakeLists.txt
  libc/src/setjmp/longjmp.cpp
  libc/src/setjmp/riscv64/CMakeLists.txt
  libc/src/setjmp/riscv64/longjmp.cpp
  libc/src/setjmp/riscv64/setjmp.cpp
  libc/src/setjmp/setjmp.cpp
  libc/src/setjmp/x86_64/CMakeLists.txt
  libc/src/setjmp/x86_64/longjmp.cpp
  libc/src/setjmp/x86_64/setjmp.cpp

Index: libc/src/setjmp/x86_64/setjmp.cpp
===
--- libc/src/setjmp/x86_64/setjmp.cpp
+++ libc/src/setjmp/x86_64/setjmp.cpp
@@ -7,15 +7,15 @@
 //===--===//
 
 #include "src/__support/common.h"
-#include "src/__support/macros/properties/architectures.h"
 #include "src/setjmp/setjmp_impl.h"
 
-#include 
+#if !defined(LIBC_TARGET_ARCH_IS_X86_64)
+#error "Invalid file include"
+#endif
 
 namespace __llvm_libc {
 
 LLVM_LIBC_FUNCTION(int, setjmp, (__jmp_buf * buf)) {
-#ifdef LIBC_TARGET_ARCH_IS_X86_64
   register __UINT64_TYPE__ rbx __asm__("rbx");
   register __UINT64_TYPE__ r12 __asm__("r12");
   register __UINT64_TYPE__ r13 __asm__("r13");
@@ -50,10 +50,6 @@
   buf->rsp = reinterpret_cast<__UINTPTR_TYPE__>(__builtin_frame_address(0)) +
  sizeof(__UINTPTR_TYPE__) * 2;
   buf->rip = reinterpret_cast<__UINTPTR_TYPE__>(__builtin_return_address(0));
-#else // LIBC_TARGET_ARCH_IS_X86_64
-#error "setjmp implementation not available for the target architecture."
-#endif
-
   return 0;
 }
 
Index: libc/src/setjmp/x86_64/longjmp.cpp
===
--- libc/src/setjmp/x86_64/longjmp.cpp
+++ libc/src/setjmp/x86_64/longjmp.cpp
@@ -8,14 +8,14 @@
 
 #include "src/setjmp/longjmp.h"
 #include "src/__support/common.h"
-#include "src/__support/macros/properties/architectures.h"
 
-#include 
+#if !defined(LIBC_TARGET_ARCH_IS_X86_64)
+#error "Invalid file include"
+#endif
 
 namespace __llvm_libc {
 
 LLVM_LIBC_FUNCTION(void, longjmp, (__jmp_buf * buf, int val)) {
-#ifdef LIBC_TARGET_ARCH_IS_X86_64
   register __UINT64_TYPE__ rbx __asm__("rbx");
   register __UINT64_TYPE__ rbp __asm__("rbp");
   register __UINT64_TYPE__ r12 __asm__("r12");
@@ -38,9 +38,6 @@
   LIBC_INLINE_ASM("mov %1, %0\n\t" : "=r"(r15) : "m"(buf->r15) :);
   LIBC_INLINE_ASM("mov %1, %0\n\t" : "=r"(rsp) : "m"(buf->rsp) :);
   LIBC_INLINE_ASM("jmp *%0\n\t" : : "m"(buf->rip));
-#else // LIBC_TARGET_ARCH_IS_X86_64
-#error "longjmp implementation not available for the target architecture."
-#endif
 }
 
 } // namespace __llvm_libc
Index: libc/src/setjmp/x86_64/CMakeLists.txt
===
--- libc/src/setjmp/x86_64/CMakeLists.txt
+++ libc/src/setjmp/x86_64/CMakeLists.txt
@@ -3,12 +3,12 @@
   SRCS
 setjmp.cpp
   HDRS
-setjmp_impl.h
-  COMPILE_OPTIONS
--O3 # We do not want any local variables in setjmp
--fno-omit-frame-pointer # The implementation assumes frame pointer on to the stack
+../setjmp_impl.h
   DEPENDS
 libc.include.setjmp
+  COMPILE_OPTIONS
+-O3
+-fno-omit-frame-pointer
 )
 
 add_entrypoint_object(
@@ -16,9 +16,10 @@
   SRCS
 longjmp.cpp
   HDRS
-longjmp.h
-  COMPILE_OPTIONS
--O3 # We do not want any local variables in longjmp
+../longjmp.h
   DEPENDS
 libc.include.setjmp
+  COMPILE_OPTIONS
+-O3
+-fno-omit-frame-pointer
 )
Index: libc/src/setjmp/riscv64/setjmp.cpp
===
--- /dev/null
+++ libc/src/setjmp/riscv64/setjmp.cpp
@@ -0,0 +1,56 @@
+//===-- Implementation of setjmp --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "src/__support/common.h"
+#include "src/setjmp/setjmp_impl.h"
+
+#include 
+
+#if !defined(LIBC_TARGET_ARCH_IS_RISCV64)
+#error "Invalid file include"
+#endif
+
+namespace __llvm_libc {
+
+LLVM_LIBC_FUNCTION(int, setjmp, (__jmp_buf * buf)) {
+  LIBC_INLINE_ASM("sd ra, %0\n\t" : : "m"(buf->__pc) :);
+  LIBC_INLINE_ASM("sd s0, %0\n\t" : : "m"(buf->__regs[0]) :);
+  LIBC_INLINE_ASM("sd s1, %0\n\t" : : "m"(buf->__regs[1]) :);
+  LIBC_INLINE_ASM("sd s2, %0\n\t" : : "m"(buf->__regs[2]) :);
+  LIBC_INLINE_ASM("sd s3, %0\n\t" : : "m"(bu

[PATCH] D146497: libclang: Pass Clang install directory to driver via argv[0].

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D146497#4216197 , @aaron.ballman 
wrote:

> In D146497#4215650 , @Hahnfeld 
> wrote:
>
>> FYI this commit breaks `clang/test/Index/index-file.cu` for me:
>>
>>   warning: CUDA version 11.8 is only partially supported 
>> [-Wunknown-cuda-version]
>>   warning: CUDA version 11.8 is only partially supported 
>> [-Wunknown-cuda-version]
>>   /home/jhahnfel/LLVM/src/clang/test/Index/index-file.cu:8:20: error: 
>> CHECK-HOST-NOT: excluded string found in input
>>   // CHECK-HOST-NOT: macro definition=__CUDA_ARCH__
>>  ^
>>   :6218:48: note: found here
>>   // CHECK: __clang_cuda_runtime_wrapper.h:70:9: macro 
>> definition=__CUDA_ARCH__ Extent=[70:9 - 70:27]
>>  
>> ^~
>>
>> It //could// be related to the warning about my locally installed CUDA 
>> version, but `__CUDA_ARCH__` should really not be defined when compiling for 
>> the host. If you have any idea what's going on here, please let me know - 
>> I'm a bit puzzled right now...
>
> This is confirmed on at least this build bot: 
> https://lab.llvm.org/buildbot/#/builders/91/builds/15271
>
> I'll investigate locally and revert if it's not something I can fix forward.

The issue doesn't reproduce for me locally on my Windows machine, so it may be 
something specific to the VE setup. It looks like the macro is being printed on 
the host side when it's expected to not be present, which doesn't seem like an 
expected outcome from this change, so I reverted in 
18d56880a89ad7d58f8543d148facebd079cef19 
 to 
hopefully bring the bot back to green (if the bot stays red for the same 
reason, I'll reapply the changes).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146497

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

[PATCH] D146406: [IncludeCleaner][clangd] Mark umbrella headers as users of private

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

thanks a lot for the review!




Comment at: clang-tools-extra/include-cleaner/lib/Analysis.cpp:100
+  // Check if main file is the public interface for a private header. If so
+  // we shouldn't diagnose it as unused.
+  if (auto PHeader = PI->getPublic(I.Resolved); !PHeader.empty()) {

hokein wrote:
> kadircet wrote:
> > hokein wrote:
> > > The beahvior (no showing the diagnostic) seems reasonable to me as we can 
> > > infer that the included header is supposed to be exported by the main 
> > > file. Just explore this a bit more.
> > > 
> > > The sad bit is that we start diverging from the classical IWYU tool (I 
> > > have check it, for this case, it gives an unused-include unless you add 
> > > an export pragma).
> > > 
> > > I think the main cause is that we're missing the `// IWYU pragma: 
> > > export`, we should still want to recommend users to add the pragma 
> > > export, right?
> > > 
> > > My only concern is that without the `export` pragma, whether the include 
> > > is used can't be reason about by just "reading" the main-file content by 
> > > human, e.g. for the case below, there is no usage of the `private.h` 
> > > (previously the trailing `// IWYU pragma: export` comment is considered a 
> > > usage), we have to open the private.h and find the private mapping to 
> > > verify the usage.
> > > 
> > > ```
> > > // public.h
> > > 
> > > #include "private.h"
> > > ```
> > > 
> > > It seems better to provide an `adding //IWYU pragma: export` FIXIT.
> > > 
> > > The sad bit is that we start diverging from the classical IWYU tool (I 
> > > have check it, for this case, it gives an unused-include unless you add 
> > > an export pragma).
> > 
> > we're not providing the same behavior with IWYU tool, it's nice to be 
> > compatible with it and this change won't break that compatibility (i.e. if 
> > IWYU tool drops this include, we're not suggesting to insert or while IWYU 
> > tool is suggesting to insert we're not suggesting to remove). so i don't 
> > think this argument applies here.
> > 
> > > I think the main cause is that we're missing the // IWYU pragma: export, 
> > > we should still want to recommend users to add the pragma export, right?
> > 
> > i don't see the reason why. i think we're actually losing value by 
> > enforcing people to annotate headers in both places. if the library 
> > provider already put a pragma in the included header, marking the umbrella 
> > header as the private header, what's the extra value we're getting by 
> > making them also annotate the public header with a bunch of export pragmas? 
> > i feel like this goes against the nature of letting tooling automate things 
> > as much as possible.
> > 
> > > My only concern is that without the export pragma, whether the include is 
> > > used can't be reason about by just "reading" the main-file content by 
> > > human, e.g. for the case below, there is no usage of the private.h 
> > > (previously the trailing // IWYU pragma: export comment is considered a 
> > > usage), we have to open the private.h and find the private mapping to 
> > > verify the usage.
> > 
> > this definitely makes sense, and having an explicit IWYU export/keep pragma 
> > on these includes are definitely nice but I believe in the common case, 
> > because private-public matching is 1:1, the reason why a private header is 
> > included inside a public header is quite obvious hence absence of these 
> > pragmas won't really cause confusion, to the contrary forcing people to 
> > introduce them will actually create frustration.
> > 
> > WDYT?
> > this change won't break that compatibility (i.e. if IWYU tool drops this 
> > include, we're not suggesting to insert or while IWYU tool is suggesting to 
> > insert we're not suggesting to remove). so i don't think this argument 
> > applies here.
> 
> Agree on this point. This is a safe change. But now clangd is diverging from 
> the clang-include-cleaner tool.
> 
> > i feel like this goes against the nature of letting tooling automate things 
> > as much as possible
> 
> I think the proposed change is good.
> 
> From the tooling automation, for example, we're doing a large cleanup (remove 
> unused includes),  we should not remove this include. 
> 
> For interactive tools (like clangd), I actually think in addition to that, 
> clangd should tell the user that they are missing an IWYU export pragma here, 
> and suggest a FIXIT (but that's probably another thread).
>  
> > but I believe in the common case, because private-public matching is 1:1, 
> > the reason why a private header is included inside a public header is quite 
> > obvious hence absence of these pragmas won't really cause confusion
> 
> I'm not sure this is true, I think private=>public is 1:1, but 
> public=>private is not always 1:1 (e.g. public header use 
> `begin_export`/`end_export` to export a bunch of headers),
> fo

[PATCH] D146406: [IncludeCleaner][clangd] Mark umbrella headers as users of private

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

- address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146406

Files:
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
  clang-tools-extra/include-cleaner/lib/Analysis.cpp
  clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
  clang/include/clang/Testing/TestAST.h
  clang/lib/Testing/TestAST.cpp

Index: clang/lib/Testing/TestAST.cpp
===
--- clang/lib/Testing/TestAST.cpp
+++ clang/lib/Testing/TestAST.cpp
@@ -16,6 +16,7 @@
 #include "llvm/Support/VirtualFileSystem.h"
 
 #include "gtest/gtest.h"
+#include 
 
 namespace clang {
 namespace {
@@ -91,7 +92,9 @@
 Argv.push_back(S.c_str());
   for (const auto &S : In.ExtraArgs)
 Argv.push_back(S.c_str());
-  std::string Filename = getFilenameForTesting(In.Language).str();
+  std::string Filename = In.FileName;
+  if (Filename.empty())
+Filename = getFilenameForTesting(In.Language).str();
   Argv.push_back(Filename.c_str());
   Clang->setInvocation(std::make_unique());
   if (!CompilerInvocation::CreateFromArgs(Clang->getInvocation(), Argv,
Index: clang/include/clang/Testing/TestAST.h
===
--- clang/include/clang/Testing/TestAST.h
+++ clang/include/clang/Testing/TestAST.h
@@ -49,6 +49,9 @@
   /// Keys are plain filenames ("foo.h"), values are file content.
   llvm::StringMap ExtraFiles = {};
 
+  /// Filename to use for translation unit. A default will be used when empty.
+  std::string FileName;
+
   /// By default, error diagnostics during parsing are reported as gtest errors.
   /// To suppress this, set ErrorOK or include "error-ok" in a comment in Code.
   /// In either case, all diagnostics appear in TestAST::diagnostics().
Index: clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
@@ -24,6 +24,7 @@
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
+#include 
 
 namespace clang::include_cleaner {
 namespace {
@@ -212,17 +213,34 @@
 return std::make_unique(PP, PI);
   };
 
-  TestAST AST(Inputs);
-  auto Decls = AST.context().getTranslationUnitDecl()->decls();
-  auto Results =
-  analyze(std::vector{Decls.begin(), Decls.end()},
-  PP.MacroReferences, PP.Includes, &PI, AST.sourceManager(),
-  AST.preprocessor().getHeaderSearchInfo());
+  {
+TestAST AST(Inputs);
+auto Decls = AST.context().getTranslationUnitDecl()->decls();
+auto Results =
+analyze(std::vector{Decls.begin(), Decls.end()},
+PP.MacroReferences, PP.Includes, &PI, AST.sourceManager(),
+AST.preprocessor().getHeaderSearchInfo());
+
+const Include *B = PP.Includes.atLine(3);
+ASSERT_EQ(B->Spelled, "b.h");
+EXPECT_THAT(Results.Missing, ElementsAre("\"c.h\""));
+EXPECT_THAT(Results.Unused, ElementsAre(B));
+  }
 
-  const Include *B = PP.Includes.atLine(3);
-  ASSERT_EQ(B->Spelled, "b.h");
-  EXPECT_THAT(Results.Missing, ElementsAre("\"c.h\""));
-  EXPECT_THAT(Results.Unused, ElementsAre(B));
+  // Check that umbrella header uses private include.
+  {
+Inputs.Code = R"cpp(#include "private.h")cpp";
+Inputs.ExtraFiles["private.h"] =
+guard("// IWYU pragma: private, include \"public.h\"");
+Inputs.FileName = "public.h";
+PP.Includes = {};
+PI = {};
+TestAST AST(Inputs);
+EXPECT_FALSE(PP.Includes.all().empty());
+auto Results = analyze({}, {}, PP.Includes, &PI, AST.sourceManager(),
+   AST.preprocessor().getHeaderSearchInfo());
+EXPECT_THAT(Results.Unused, testing::IsEmpty());
+  }
 }
 
 TEST(FixIncludes, Basic) {
Index: clang-tools-extra/include-cleaner/lib/Analysis.cpp
===
--- clang-tools-extra/include-cleaner/lib/Analysis.cpp
+++ clang-tools-extra/include-cleaner/lib/Analysis.cpp
@@ -90,9 +90,25 @@
});
 
   AnalysisResults Results;
-  for (const Include &I : Inc.all())
-if (!Used.contains(&I) && PI && !PI->shouldKeep(I.Line))
-  Results.Unused.push_back(&I);
+  for (const Include &I : Inc.all()) {
+if (Used.contains(&I))
+  continue;
+if (PI) {
+  if (PI->shouldKeep(I.Line))
+continue;
+  // Check if main file is the public interface for a private header. If so
+  // we shouldn't diagnose it as unused.
+  if (auto PHeader = PI->getPublic(I.Resolved); !PHeader.empty()) {
+PHeader = PHeader.trim("<>\"");
+// Since most private -> public mappings happen in a verbatim way, we
+// check textually here. This might go

[PATCH] D146406: [IncludeCleaner][clangd] Mark umbrella headers as users of private

[Kadir Cetinkaya via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG43fcfdb1d6a6: [IncludeCleaner][clangd] Mark umbrella headers 
as users of private (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146406

Files:
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
  clang-tools-extra/include-cleaner/lib/Analysis.cpp
  clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
  clang/include/clang/Testing/TestAST.h
  clang/lib/Testing/TestAST.cpp

Index: clang/lib/Testing/TestAST.cpp
===
--- clang/lib/Testing/TestAST.cpp
+++ clang/lib/Testing/TestAST.cpp
@@ -16,6 +16,7 @@
 #include "llvm/Support/VirtualFileSystem.h"
 
 #include "gtest/gtest.h"
+#include 
 
 namespace clang {
 namespace {
@@ -91,7 +92,9 @@
 Argv.push_back(S.c_str());
   for (const auto &S : In.ExtraArgs)
 Argv.push_back(S.c_str());
-  std::string Filename = getFilenameForTesting(In.Language).str();
+  std::string Filename = In.FileName;
+  if (Filename.empty())
+Filename = getFilenameForTesting(In.Language).str();
   Argv.push_back(Filename.c_str());
   Clang->setInvocation(std::make_unique());
   if (!CompilerInvocation::CreateFromArgs(Clang->getInvocation(), Argv,
Index: clang/include/clang/Testing/TestAST.h
===
--- clang/include/clang/Testing/TestAST.h
+++ clang/include/clang/Testing/TestAST.h
@@ -49,6 +49,9 @@
   /// Keys are plain filenames ("foo.h"), values are file content.
   llvm::StringMap ExtraFiles = {};
 
+  /// Filename to use for translation unit. A default will be used when empty.
+  std::string FileName;
+
   /// By default, error diagnostics during parsing are reported as gtest errors.
   /// To suppress this, set ErrorOK or include "error-ok" in a comment in Code.
   /// In either case, all diagnostics appear in TestAST::diagnostics().
Index: clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
@@ -24,6 +24,7 @@
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
+#include 
 
 namespace clang::include_cleaner {
 namespace {
@@ -212,17 +213,34 @@
 return std::make_unique(PP, PI);
   };
 
-  TestAST AST(Inputs);
-  auto Decls = AST.context().getTranslationUnitDecl()->decls();
-  auto Results =
-  analyze(std::vector{Decls.begin(), Decls.end()},
-  PP.MacroReferences, PP.Includes, &PI, AST.sourceManager(),
-  AST.preprocessor().getHeaderSearchInfo());
+  {
+TestAST AST(Inputs);
+auto Decls = AST.context().getTranslationUnitDecl()->decls();
+auto Results =
+analyze(std::vector{Decls.begin(), Decls.end()},
+PP.MacroReferences, PP.Includes, &PI, AST.sourceManager(),
+AST.preprocessor().getHeaderSearchInfo());
+
+const Include *B = PP.Includes.atLine(3);
+ASSERT_EQ(B->Spelled, "b.h");
+EXPECT_THAT(Results.Missing, ElementsAre("\"c.h\""));
+EXPECT_THAT(Results.Unused, ElementsAre(B));
+  }
 
-  const Include *B = PP.Includes.atLine(3);
-  ASSERT_EQ(B->Spelled, "b.h");
-  EXPECT_THAT(Results.Missing, ElementsAre("\"c.h\""));
-  EXPECT_THAT(Results.Unused, ElementsAre(B));
+  // Check that umbrella header uses private include.
+  {
+Inputs.Code = R"cpp(#include "private.h")cpp";
+Inputs.ExtraFiles["private.h"] =
+guard("// IWYU pragma: private, include \"public.h\"");
+Inputs.FileName = "public.h";
+PP.Includes = {};
+PI = {};
+TestAST AST(Inputs);
+EXPECT_FALSE(PP.Includes.all().empty());
+auto Results = analyze({}, {}, PP.Includes, &PI, AST.sourceManager(),
+   AST.preprocessor().getHeaderSearchInfo());
+EXPECT_THAT(Results.Unused, testing::IsEmpty());
+  }
 }
 
 TEST(FixIncludes, Basic) {
Index: clang-tools-extra/include-cleaner/lib/Analysis.cpp
===
--- clang-tools-extra/include-cleaner/lib/Analysis.cpp
+++ clang-tools-extra/include-cleaner/lib/Analysis.cpp
@@ -90,9 +90,25 @@
});
 
   AnalysisResults Results;
-  for (const Include &I : Inc.all())
-if (!Used.contains(&I) && PI && !PI->shouldKeep(I.Line))
-  Results.Unused.push_back(&I);
+  for (const Include &I : Inc.all()) {
+if (Used.contains(&I))
+  continue;
+if (PI) {
+  if (PI->shouldKeep(I.Line))
+continue;
+  // Check if main file is the public interface for a private header. If so
+  // we shouldn't diagnose it as unused.
+  if (auto PHeader = PI->getPublic(I.Resolved); !PHeader.empty()) {
+ 

[clang] 43fcfdb - [IncludeCleaner][clangd] Mark umbrella headers as users of private

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2023-03-23T13:08:07+01:00
New Revision: 43fcfdb1d6a63129ffbb7d77174ccb56863d0b30

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

LOG: [IncludeCleaner][clangd] Mark umbrella headers as users of private

Private headers inside umbrella files shouldn't be marked as unused.

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

Added: 


Modified: 
clang-tools-extra/clangd/IncludeCleaner.cpp
clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
clang-tools-extra/include-cleaner/lib/Analysis.cpp
clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
clang/include/clang/Testing/TestAST.h
clang/lib/Testing/TestAST.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/IncludeCleaner.cpp 
b/clang-tools-extra/clangd/IncludeCleaner.cpp
index 98135529f259..ee470bd8b963 100644
--- a/clang-tools-extra/clangd/IncludeCleaner.cpp
+++ b/clang-tools-extra/clangd/IncludeCleaner.cpp
@@ -93,8 +93,6 @@ bool isFilteredByConfig(const Config &Cfg, llvm::StringRef 
HeaderPath) {
 static bool mayConsiderUnused(const Inclusion &Inc, ParsedAST &AST,
   const Config &Cfg,
   const include_cleaner::PragmaIncludes *PI) {
-  if (PI && PI->shouldKeep(Inc.HashLine + 1))
-return false;
   // FIXME(kirillbobyrev): We currently do not support the umbrella headers.
   // System headers are likely to be standard library headers.
   // Until we have good support for umbrella headers, don't warn about them.
@@ -108,6 +106,20 @@ static bool mayConsiderUnused(const Inclusion &Inc, 
ParsedAST &AST,
   auto FE = AST.getSourceManager().getFileManager().getFileRef(
   AST.getIncludeStructure().getRealPath(HID));
   assert(FE);
+  if (PI) {
+if (PI->shouldKeep(Inc.HashLine + 1))
+  return false;
+// Check if main file is the public interface for a private header. If so 
we
+// shouldn't diagnose it as unused.
+if(auto PHeader = PI->getPublic(*FE); !PHeader.empty()) {
+  PHeader = PHeader.trim("<>\"");
+  // Since most private -> public mappings happen in a verbatim way, we
+  // check textually here. This might go wrong in presence of symlinks or
+  // header mappings. But that's not 
diff erent than rest of the places.
+  if(AST.tuPath().endswith(PHeader))
+return false;
+}
+  }
   // Headers without include guards have side effects and are not
   // self-contained, skip them.
   if 
(!AST.getPreprocessor().getHeaderSearchInfo().isFileMultipleIncludeGuarded(

diff  --git a/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp 
b/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
index 409e3cee791c..69b4e07439c3 100644
--- a/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ b/clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -30,6 +30,7 @@
 #include "gtest/gtest.h"
 #include 
 #include 
+#include 
 #include 
 
 namespace clang {
@@ -328,6 +329,26 @@ TEST(IncludeCleaner, NoDiagsForObjC) {
   ParsedAST AST = TU.build();
   EXPECT_THAT(AST.getDiagnostics(), llvm::ValueIs(IsEmpty()));
 }
+
+TEST(IncludeCleaner, UmbrellaUsesPrivate) {
+  TestTU TU;
+  TU.Code = R"cpp(
+#include "private.h"
+)cpp";
+  TU.AdditionalFiles["private.h"] = guard(R"cpp(
+// IWYU pragma: private, include "public.h"
+void foo() {}
+  )cpp");
+  TU.Filename = "public.h";
+  Config Cfg;
+  Cfg.Diagnostics.UnusedIncludes = Config::IncludesPolicy::Strict;
+  WithContextValue Ctx(Config::Key, std::move(Cfg));
+  ParsedAST AST = TU.build();
+  EXPECT_THAT(AST.getDiagnostics(), llvm::ValueIs(IsEmpty()));
+  IncludeCleanerFindings Findings = computeIncludeCleanerFindings(AST);
+  EXPECT_THAT(Findings.UnusedIncludes, IsEmpty());
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang

diff  --git a/clang-tools-extra/include-cleaner/lib/Analysis.cpp 
b/clang-tools-extra/include-cleaner/lib/Analysis.cpp
index 6237bdb46bab..fb0879b7aab6 100644
--- a/clang-tools-extra/include-cleaner/lib/Analysis.cpp
+++ b/clang-tools-extra/include-cleaner/lib/Analysis.cpp
@@ -90,9 +90,25 @@ AnalysisResults analyze(llvm::ArrayRef ASTRoots,
});
 
   AnalysisResults Results;
-  for (const Include &I : Inc.all())
-if (!Used.contains(&I) && PI && !PI->shouldKeep(I.Line))
-  Results.Unused.push_back(&I);
+  for (const Include &I : Inc.all()) {
+if (Used.contains(&I))
+  continue;
+if (PI) {
+  if (PI->shouldKeep(I.Line))
+continue;
+  // Check if main file is the public interface for a private header. If so
+  // we shouldn't diagnose it as unused.
+  if (auto PHeader = PI->getPublic(I.Resolved); !PHeader.empty()) {
+PHeader = PHeader.trim("<>\"");
+// Since most private -> p

[PATCH] D145584: [libc] Add support for setjmp and longjmp in riscv

[Mikhail Ramalho via Phabricator via cfe-commits]

mikhail.ramalho added inline comments.



Comment at: libc/src/setjmp/riscv64/longjmp.h:56
+
+  LIBC_INLINE_ASM("seqz %0, %1" : "+r"(buf) : "r"(val) :);
+  LIBC_INLINE_ASM("add %0, %0, %1" : "+r"(buf) : "r"(val), "r"(buf) :);

sivachandra wrote:
> Why is this required? Can we just copy `val` to `a0` and return? Or, even 
> better would be just `return val;` if we can make this a `naked` function?
This is the fake return mentioned on the Linux man page:
```
Following  a  successful  longjmp(), execution continues as if setjmp()
had returned for a second time.  This  "fake"  return  can  be  distin-
guished from a true setjmp() call because the "fake" return returns the
value provided in val.  If the programmer mistakenly passes the value 0
in val, the "fake" return will instead return 1.
```

We can't return normally here, since `longjmp` has no return.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145584

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

[PATCH] D146712: [clang-tidy] Add portability-non-portable-integer-constant check

[Discookie via Phabricator via cfe-commits]

Discookie created this revision.
Discookie added reviewers: aaron.ballman, njames93, carlosgalvezp.
Discookie added a project: clang-tools-extra.
Herald added subscribers: PiotrZSL, ChuanqiXu, xazax.hun.
Herald added a project: All.
Discookie requested review of this revision.

This check finds integer literals that are being used in a non-portable manner.

Currently, the check detects cases where maximum or minimum values should be 
used
instead, as well as error-prone integer literals having leading zeroes, or
relying on most significant bits.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146712

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/portability/CMakeLists.txt
  clang-tools-extra/clang-tidy/portability/NonPortableIntegerConstantCheck.cpp
  clang-tools-extra/clang-tidy/portability/NonPortableIntegerConstantCheck.h
  clang-tools-extra/clang-tidy/portability/PortabilityTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert/int17-c.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/portability/non-portable-integer-constant.rst
  
clang-tools-extra/test/clang-tidy/checkers/portability/non-portable-integer-constant.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/portability/non-portable-integer-constant.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/portability/non-portable-integer-constant.cpp
@@ -0,0 +1,258 @@
+// RUN: %check_clang_tidy %s -std=c++17-or-later portability-non-portable-integer-constant %t
+
+using int32_t = decltype(42);
+
+void regular() {
+  // no-warnings
+  0;
+  00;
+  0x0;
+  0x00;
+  0b0;
+  0b00;
+  0b0'0'0;
+
+  -1;
+  -0X1;
+
+  127;
+  0x7'f;
+
+  -128;
+  -0x80;
+
+  256;
+  0X100;
+
+  42;
+  0x2A;
+
+  180079837;
+  0xabbccdd;
+
+  // FIXME: (only 31 bits) False positive, reported as max signed int.
+  0b111;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: non-portable integer literal: hardcoded platform-specific maximum value [portability-non-portable-integer-constant]
+
+  // FIXME: Large numbers represented as hex are the most common false positive,
+  // eg. the following literal is a 64-bit prime.
+  0xff51afd7ed558ccd;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: non-portable integer literal: should not rely on the most significant bit [portability-non-portable-integer-constant]
+
+  // FIXME: Fixed-size integer literals are a common false positive as well.
+  int32_t literal = 0x4000;
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: non-portable integer literal: should not rely on bits of most significant byte [portability-non-portable-integer-constant]
+
+  // FIXME: According to the standard, the type of the integer literal is the
+  // smallest type it can fit into. While technically a false positive, it could
+  // signal literal width confusion regardless.
+  long long int long_literal = 0x7fff;
+  // CHECK-MESSAGES: :[[@LINE-1]]:32: warning: non-portable integer literal: hardcoded platform-specific maximum value [portability-non-portable-integer-constant]
+}
+
+enum LiteralClamp {
+
+};
+
+// INT_MIN, INT_MAX, UINT_MAX, UINT_MAX-1
+// All binary literals are 32 bits long
+void limits_int() {
+  // FIXME: not recognize as Min
+  -214748'3'648;
+  // --CHECK-MESSAGES: :[[@LINE-1]]:4: warning: non-portable integer literal: hardcoded platform-specific minimum value [portability-non-portable-integer-constant]
+
+  -0x80'00'00'00;
+  // CHECK-MESSAGES: :[[@LINE-1]]:4: warning: non-portable integer literal: hardcoded platform-specific minimum value [portability-non-portable-integer-constant]
+
+  -0200;
+  // CHECK-MESSAGES: :[[@LINE-1]]:4: warning: non-portable integer literal: hardcoded platform-specific minimum value [portability-non-portable-integer-constant]
+
+  -0b1000;
+  // CHECK-MESSAGES: :[[@LINE-1]]:4: warning: non-portable integer literal: hardcoded platform-specific minimum value [portability-non-portable-integer-constant]
+
+
+
+  21474'83647;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: non-portable integer literal: hardcoded platform-specific maximum value [portability-non-portable-integer-constant]
+
+  0x7FFF;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: non-portable integer literal: hardcoded platform-specific maximum value [portability-non-portable-integer-constant]
+
+  0177;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: non-portable integer literal: hardcoded platform-specific maximum value [portability-non-portable-integer-constant]
+
+  429'4'96'7295u;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: non-portable integer literal: hardcoded platform-specific maximum value [portability-non-portable-integer-constant]
+
+  0x;
+  // CHECK-MESSAGES

[PATCH] D146713: [clang-tidy][NFC] Improve naming convention in google-readability-avoid-underscore-in-googletest-name

[Carlos Galvez via Phabricator via cfe-commits]

carlosgalvezp created this revision.
Herald added subscribers: PiotrZSL, xazax.hun.
Herald added a reviewer: njames93.
Herald added a project: All.
carlosgalvezp requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

According to the Google docs, the convention is
TEST(TestSuiteName, TestName). Apply that convention to the
source code, test and documentation of the check.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146713

Files:
  clang-tools-extra/clang-tidy/google/AvoidUnderscoreInGoogletestNameCheck.cpp
  
clang-tools-extra/docs/clang-tidy/checks/google/readability-avoid-underscore-in-googletest-name.rst
  
clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/google/avoid-underscore-in-googletest-name.cpp
@@ -1,11 +1,11 @@
 // RUN: %check_clang_tidy %s google-readability-avoid-underscore-in-googletest-name %t
 
-#define TEST(test_case_name, test_name) void test_case_name##test_name()
-#define TEST_F(test_case_name, test_name) void test_case_name##test_name()
-#define TEST_P(test_case_name, test_name) void test_case_name##test_name()
-#define TYPED_TEST(test_case_name, test_name) void test_case_name##test_name()
-#define TYPED_TEST_P(test_case_name, test_name) void test_case_name##test_name()
-#define FRIEND_TEST(test_case_name, test_name) void test_case_name##test_name()
+#define TEST(test_suite_name, test_name) void test_suite_name##test_name()
+#define TEST_F(test_suite_name, test_name) void test_suite_name##test_name()
+#define TEST_P(test_suite_name, test_name) void test_suite_name##test_name()
+#define TYPED_TEST(test_suite_name, test_name) void test_suite_name##test_name()
+#define TYPED_TEST_P(test_suite_name, test_name) void test_suite_name##test_name()
+#define FRIEND_TEST(test_suite_name, test_name) void test_suite_name##test_name()
 
 TEST(TestCaseName, Illegal_TestName) {}
 // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
@@ -15,11 +15,11 @@
 TEST(TestCaseName, Illegal_Test_Name) {}
 // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: avoid using "_" in test name "Illegal_Test_Name" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
 TEST(Illegal_TestCaseName, TestName) {}
-// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_TestCaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test suite name "Illegal_TestCaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
 TEST(Illegal_Test_CaseName, TestName) {}
-// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_Test_CaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test suite name "Illegal_Test_CaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
 TEST(Illegal_TestCaseName, Illegal_TestName) {}
-// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test case name "Illegal_TestCaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: avoid using "_" in test suite name "Illegal_TestCaseName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
 // CHECK-MESSAGES: :[[@LINE-2]]:28: warning: avoid using "_" in test name "Illegal_TestName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
 
 TEST_F(TestCaseFixtureName, Illegal_TestName) {}
@@ -30,13 +30,13 @@
 // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: avoid using "_" in test name "Illegal_Test_Name" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
 
 TEST_F(Illegal_TestCaseFixtureName, TestName) {}
-// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test case name "Illegal_TestCaseFixtureName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test suite name "Illegal_TestCaseFixtureName" according to Googletest FAQ [google-readability-avoid-underscore-in-googletest-name]
 TEST_F(Illegal_TestCaseFixtureName, Illegal_TestName) {}
-// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: avoid using "_" in test case name "Illegal_TestCaseFixtureName" according to Googletest FAQ [

[PATCH] D141824: [clang-repl] Add a command to load dynamic libraries

[Stefan Gränitz via Phabricator via cfe-commits]

sgraenitz added a comment.

Thanks for the update




Comment at: clang/test/Interpreter/dynamic-library.cpp:1
+// RUN: head -n 7 %s | %clang -xc++ -o %T/libdynamic-library-test.so -fPIC 
-shared -
+int ultimate_answer = 0;

The use of `head` and `tail` here is a creative solution, but I wonder how well 
it scales for similar cases in the future in case this becomes a role model. We 
have this situation a lot in LLDB: compile an input file and use the output in 
a RUN line. It typically uses separate input files for such purposes (note that 
"Inputs" folders must be excluded from test discovery somewhere in lit config), 
e.g.:
https://github.com/llvm/llvm-project/blob/release/16.x/lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test

What do you think?



Comment at: clang/test/Interpreter/dynamic-library.cpp:9
+
+// REQUIRES: host-supports-jit, system-linux
+// RUN: tail -n 16 %s | env LD_LIBRARY_PATH=%T:$LD_LIBRARY_PATH clang-repl | 
FileCheck %s

This requirement applies to the entire file right? The arrangement here may 
imply the opposite.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141824

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

[PATCH] D146497: libclang: Pass Clang install directory to driver via argv[0].

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld added a comment.

In D146497#4216226 , @aaron.ballman 
wrote:

> The issue doesn't reproduce for me locally on my Windows machine, so it may 
> be something specific to the VE setup.

FWIW I'm not doing anything specific for VE, just

  set(CMAKE_C_COMPILER "clang" CACHE STRING "")
  set(CMAKE_CXX_COMPILER "clang++" CACHE STRING "")
  set(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING "")
  set(LLVM_APPEND_VC_REV OFF CACHE STRING "")
  set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
  set(LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
  
  set(LLVM_ENABLE_LLD ON CACHE BOOL "")
  set(LLVM_LINK_LLVM_DYLIB ON CACHE BOOL "")

in the file I load as the `initial-cache` (`cmake -C`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146497

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

[PATCH] D146634: [clang][USR] Prevent crashes when parameter lists have nulls

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D146634#4215754 , @kadircet wrote:

> I am aware that this null checking at leaves are not considered a sustainable 
> solution and I agree with the sentiment there. But we're seeing an increasing 
> number of crashes in production on invalid code recently. Happy to take a 
> different course if there are alternatives, but as also explained in D146426 
> , the situation around parameter lists 
> having nullptrs seem to be the state for a long time now, e.g:
>
>   template  auto x = [](__fp16) {};
>   decltype(x);
>
> is a reproducer that crashes even clang-12 due to a nullptr in the paremeter 
> list. Surely it'd be better to fix this invariant, but I am afraid we don't 
> know how to do that immediately and considering people have been dealing with 
> this situation by adding null checks into the places that triggered crashes 
> ever since, I'd like to move forward with this fix until someone can figure 
> out the situation.

IMO, if the increasing number of crashes is a concern, now is the time to fix 
it properly instead of continuing to play whack-a-mole. To me, "fix it 
properly" means ensuring that we don't have null AST nodes, but if during 
investigation there's a more foundational problem that prevents us from doing 
that, we can make a different decision once we have more information.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146634

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

[PATCH] D146671: [clang][ExtractAPI]Fix Declaration fragments for instancetype in the type position degrade to id

[NagaChaitanya Vellanki via Phabricator via cfe-commits]

chaitanyav added a comment.

Will update the test to also include a Id instance method.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146671

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

[PATCH] D141824: [clang-repl] Add a command to load dynamic libraries

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

Thanks for working on this, looks like we are heading in a good direction!




Comment at: clang/test/Interpreter/dynamic-library.cpp:1
+// RUN: head -n 7 %s | %clang -xc++ -o %T/libdynamic-library-test.so -fPIC 
-shared -
+int ultimate_answer = 0;

sgraenitz wrote:
> The use of `head` and `tail` here is a creative solution, but I wonder how 
> well it scales for similar cases in the future in case this becomes a role 
> model. We have this situation a lot in LLDB: compile an input file and use 
> the output in a RUN line. It typically uses separate input files for such 
> purposes (note that "Inputs" folders must be excluded from test discovery 
> somewhere in lit config), e.g.:
> https://github.com/llvm/llvm-project/blob/release/16.x/lldb/test/Shell/Breakpoint/jit-loader_jitlink_elf.test
> 
> What do you think?
I agree with that. I've seen that some clang tests surround the code in 
question with `#ifdef LIB` and then in the invocation they add `-DLIB`.



Comment at: clang/tools/clang-repl/ClangRepl.cpp:126
   }
+  if (Line->rfind(R"(%lib )", 0) == 0) {
+if (auto Err = Interp->LoadDynamicLibrary(Line->data() + 5)) {

argentite wrote:
> sgraenitz wrote:
> > I see this is analog to existing code, but is there a good reason for using 
> > the multi-line string syntax here?
> Yeah I am confused as well. But I tried to maintain the style.
Independently, I think these commands should be available via pragma directives 
as well. Maybe in a separate revision we should create something like `pragma 
clang-repl/clang-interpreter load library name`. That would allow people to use 
that in their "scripts" which can be quite useful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141824

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

[clang] c39dd7c - [RISCV][MC] Add support for RV64E

[Alex Bradbury via cfe-commits]

Author: Job Noorman
Date: 2023-03-23T12:32:25Z
New Revision: c39dd7c1db97fa367cb6282067b74cd8e55ef09a

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

LOG: [RISCV][MC] Add support for RV64E

Implement MC support for the recently ratified RV64E base instruction
set.

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

Added: 
llvm/test/CodeGen/RISCV/rve.ll
llvm/test/MC/RISCV/rv64e-valid.s

Modified: 
clang/test/Driver/riscv-arch.c
clang/test/Driver/riscv-features.c
llvm/docs/RISCVUsage.rst
llvm/docs/ReleaseNotes.rst
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/RISCVELFStreamer.cpp
llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
llvm/lib/Target/RISCV/RISCVFeatures.td
llvm/lib/Target/RISCV/RISCVISelLowering.cpp
llvm/test/MC/RISCV/attribute-arch.s
llvm/test/MC/RISCV/elf-flags.s
llvm/test/MC/RISCV/invalid-attribute.s
llvm/test/MC/RISCV/rv32e-invalid.s
llvm/test/MC/RISCV/rv32e-valid.s
llvm/test/MC/RISCV/target-abi-invalid.s
llvm/test/MC/RISCV/target-abi-valid.s
llvm/unittests/Support/RISCVISAInfoTest.cpp

Removed: 
llvm/test/CodeGen/RISCV/mattr-invalid-combination.ll
llvm/test/CodeGen/RISCV/rv32e.ll
llvm/test/MC/RISCV/mattr-invalid-combination.s



diff  --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 610f79d64ada2..cbc1464cbcd6f 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -198,11 +198,6 @@
 
 // Testing specific messages and unsupported extensions.
 
-// RUN: %clang --target=riscv64-unknown-elf -march=rv64e -### %s \
-// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64E %s
-// RV64E: error: invalid arch name 'rv64e',
-// RV64E: standard user-level extension 'e' requires 'rv32'
-
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32imC -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-LOWER %s
 // RV32-LOWER: error: invalid arch name 'rv32imC',
@@ -223,11 +218,6 @@
 // RV32-ORDER: error: invalid arch name 'rv32imcq',
 // RV32-ORDER: standard user-level extension not given in canonical order 'q'
 
-// RUN: %clang --target=riscv32-unknown-elf -march=rv64e -### %s \
-// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-EER %s
-// RV64-EER: error: invalid arch name 'rv64e',
-// RV64-EER: standard user-level extension 'e' requires 'rv32'
-
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32izve32f -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVE32F-ER %s
 // RV32-ZVE32F-ER: error: invalid arch name 'rv32izve32f',

diff  --git a/clang/test/Driver/riscv-features.c 
b/clang/test/Driver/riscv-features.c
index 98445b1920301..b189fdeacec8c 100644
--- a/clang/test/Driver/riscv-features.c
+++ b/clang/test/Driver/riscv-features.c
@@ -33,10 +33,6 @@
 // DEFAULT-LINUX-SAME: "-target-feature" "+d"
 // DEFAULT-LINUX-SAME: "-target-feature" "+c"
 
-// RUN: not %clang -cc1 -triple riscv64-unknown-elf -target-feature +e 2>&1 | 
FileCheck %s -check-prefix=RV64-WITH-E
-
-// RV64-WITH-E: error: invalid feature combination: standard user-level 
extension 'e' requires 'rv32'
-
 // RUN: not %clang -c --target=riscv64-linux-gnu -gsplit-dwarf %s 2>&1 | 
FileCheck %s --check-prefix=ERR-SPLIT-DWARF
 // RUN: not %clang -c --target=riscv64 -gsplit-dwarf=single %s 2>&1 | 
FileCheck %s --check-prefix=ERR-SPLIT-DWARF
 // RUN: %clang -### -c --target=riscv64 -mno-relax -g -gsplit-dwarf %s 2>&1 | 
FileCheck %s --check-prefix=SPLIT-DWARF

diff  --git a/llvm/docs/RISCVUsage.rst b/llvm/docs/RISCVUsage.rst
index 429b59a8d9404..ffd1028cedd80 100644
--- a/llvm/docs/RISCVUsage.rst
+++ b/llvm/docs/RISCVUsage.rst
@@ -15,9 +15,9 @@ supported variations of the RISC-V specification.  It lives 
in the
 Base ISAs
 =
 
-The specification defines four base instruction sets: RV32I, RV32E, RV64I,
-and RV128I. Currently, LLVM fully supports RV32I, and RV64I.  RV32E is
-supported by the assembly-based tools only.  RV128I is not supported.
+The specification defines five base instruction sets: RV32I, RV32E, RV64I,
+RV64E, and RV128I. Currently, LLVM fully supports RV32I, and RV64I.  RV32E and
+RV64E are supported by the assembly-based tools only.  RV128I is not supported.
 
 To specify the target triple:
 
@@ -27,7 +27,7 @@ To specify the target triple:
  Architecture Description
   
==
  ``riscv32``   RISC-V with XLEN=32 (i.e. RV32I or RV32E)
- ``riscv64``   RISC-V with XLEN=64 

[PATCH] D143570: [RISCV][MC] Add support for RV64E

[Alex Bradbury 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 rGc39dd7c1db97: [RISCV][MC] Add support for RV64E (authored by 
jobnoorman, committed by asb).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143570

Files:
  clang/test/Driver/riscv-arch.c
  clang/test/Driver/riscv-features.c
  llvm/docs/RISCVUsage.rst
  llvm/docs/ReleaseNotes.rst
  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/RISCVELFStreamer.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
  llvm/lib/Target/RISCV/RISCVFeatures.td
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/test/CodeGen/RISCV/mattr-invalid-combination.ll
  llvm/test/CodeGen/RISCV/rv32e.ll
  llvm/test/CodeGen/RISCV/rve.ll
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/elf-flags.s
  llvm/test/MC/RISCV/invalid-attribute.s
  llvm/test/MC/RISCV/mattr-invalid-combination.s
  llvm/test/MC/RISCV/rv32e-invalid.s
  llvm/test/MC/RISCV/rv32e-valid.s
  llvm/test/MC/RISCV/rv64e-valid.s
  llvm/test/MC/RISCV/target-abi-invalid.s
  llvm/test/MC/RISCV/target-abi-valid.s
  llvm/unittests/Support/RISCVISAInfoTest.cpp

Index: llvm/unittests/Support/RISCVISAInfoTest.cpp
===
--- llvm/unittests/Support/RISCVISAInfoTest.cpp
+++ llvm/unittests/Support/RISCVISAInfoTest.cpp
@@ -109,7 +109,7 @@
 TEST(ParseArchString, RejectsInvalidBaseISA) {
   for (StringRef Input : {"rv32", "rv64", "rv65i"}) {
 EXPECT_EQ(toString(RISCVISAInfo::parseArchString(Input, true).takeError()),
-  "string must begin with rv32{i,e,g} or rv64{i,g}");
+  "string must begin with rv32{i,e,g} or rv64{i,e,g}");
   }
   for (StringRef Input : {"rv32j", "rv64k", "rv32_i"}) {
 EXPECT_EQ(toString(RISCVISAInfo::parseArchString(Input, true).takeError()),
@@ -118,11 +118,9 @@
 }
 
 TEST(ParseArchString, RejectsUnsupportedBaseISA) {
-  EXPECT_EQ(toString(RISCVISAInfo::parseArchString("rv64e", true).takeError()),
-"standard user-level extension 'e' requires 'rv32'");
   for (StringRef Input : {"rv128i", "rv128g"}) {
 EXPECT_EQ(toString(RISCVISAInfo::parseArchString(Input, true).takeError()),
-  "string must begin with rv32{i,e,g} or rv64{i,g}");
+  "string must begin with rv32{i,e,g} or rv64{i,e,g}");
   }
 }
 
@@ -167,6 +165,15 @@
   EXPECT_EQ(InfoRV64I.getXLen(), 64U);
   EXPECT_EQ(InfoRV64I.getFLen(), 0U);
 
+  auto MaybeRV64E = RISCVISAInfo::parseArchString("rv64e", true);
+  ASSERT_THAT_EXPECTED(MaybeRV64E, Succeeded());
+  RISCVISAInfo &InfoRV64E = **MaybeRV64E;
+  RISCVISAInfo::OrderedExtensionMap ExtsRV64E = InfoRV64E.getExtensions();
+  EXPECT_EQ(ExtsRV64E.size(), 1UL);
+  EXPECT_TRUE(ExtsRV64E.at("e") == (RISCVExtensionInfo{2, 0}));
+  EXPECT_EQ(InfoRV64E.getXLen(), 64U);
+  EXPECT_EQ(InfoRV64E.getFLen(), 0U);
+
   auto MaybeRV64G = RISCVISAInfo::parseArchString("rv64g", true);
   ASSERT_THAT_EXPECTED(MaybeRV64G, Succeeded());
   RISCVISAInfo &InfoRV64G = **MaybeRV64G;
Index: llvm/test/MC/RISCV/target-abi-valid.s
===
--- llvm/test/MC/RISCV/target-abi-valid.s
+++ llvm/test/MC/RISCV/target-abi-valid.s
@@ -47,6 +47,10 @@
 # RUN:   | llvm-readobj --file-headers - \
 # RUN:   | FileCheck -check-prefix=CHECK-RVE %s
 
+# RUN: llvm-mc -triple=riscv64 -target-abi lp64e -filetype=obj < %s \
+# RUN:   | llvm-readobj --file-headers - \
+# RUN:   | FileCheck -check-prefix=CHECK-RVE %s
+
 # CHECK-NONE:   Flags [ (0x0)
 # CHECK-NONE-NEXT:  ]
 
Index: llvm/test/MC/RISCV/target-abi-invalid.s
===
--- llvm/test/MC/RISCV/target-abi-invalid.s
+++ llvm/test/MC/RISCV/target-abi-invalid.s
@@ -32,6 +32,8 @@
 # RUN:   | FileCheck -check-prefix=RV32EF-LP64F %s
 # RUN: llvm-mc -triple=riscv32 -mattr=+e,+d -target-abi lp64f < %s 2>&1 \
 # RUN:   | FileCheck -check-prefix=RV32EFD-LP64D %s
+# RUN: llvm-mc -triple=riscv32 -mattr=+e -target-abi lp64e %s 2>&1 \
+# RUN:   | FileCheck -check-prefix=RV32E-LP64E %s
 
 # RV32I-LP64: 64-bit ABIs are not supported for 32-bit targets (ignoring target-abi)
 # RV32IF-LP64F: 64-bit ABIs are not supported for 32-bit targets (ignoring target-abi)
@@ -39,6 +41,7 @@
 # RV32E-LP64: 64-bit ABIs are not supported for 32-bit targets (ignoring target-abi)
 # RV32EF-LP64F: 64-bit ABIs are not supported for 32-bit targets (ignoring target-abi)
 # RV32EFD-LP64D: 64-bit ABIs are not supported for 32-bit targets (ignoring target-abi)
+# RV32E-LP64E:

[PATCH] D146715: [NVPTX] Enforce half type support is present for builtins

[Jakub Chlanda via Phabricator via cfe-commits]

jchlanda created this revision.
jchlanda added a reviewer: tra.
Herald added subscribers: mattd, gchakrabarti, asavonic.
Herald added a project: All.
jchlanda requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, jholewinski.
Herald added projects: clang, LLVM.

Follow up to https://reviews.llvm.org/D145238 that enforces native half type 
support is present when using builtins and gives more descriptive error in not.
Tidy up `CodeGenFunction::EmitNVPTXBuiltinExpr` by moving helper lambdas to 
dedicated functions (most of helpers already reside in dedicated functions).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146715

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-nvptx-native-half-type-err.c
  llvm/include/llvm/IR/IntrinsicsNVVM.td

Index: llvm/include/llvm/IR/IntrinsicsNVVM.td
===
--- llvm/include/llvm/IR/IntrinsicsNVVM.td
+++ llvm/include/llvm/IR/IntrinsicsNVVM.td
@@ -583,7 +583,6 @@
   "_xorsign_abs_f16", "_ftz_xorsign_abs_f16", "_nan_xorsign_abs_f16",
   "_ftz_nan_xorsign_abs_f16"] in {
   def int_nvvm_f # operation # variant :
-ClangBuiltin,
 DefaultAttrsIntrinsic<[llvm_half_ty], [llvm_half_ty, llvm_half_ty],
   [IntrNoMem, IntrSpeculatable, Commutative]>;
 }
@@ -592,7 +591,6 @@
   "_ftz_nan_f16x2", "_xorsign_abs_f16x2", "_ftz_xorsign_abs_f16x2",
   "_nan_xorsign_abs_f16x2", "_ftz_nan_xorsign_abs_f16x2"] in {
   def int_nvvm_f # operation # variant :
-ClangBuiltin,
 DefaultAttrsIntrinsic<[llvm_v2f16_ty], [llvm_v2f16_ty, llvm_v2f16_ty],
   [IntrNoMem, IntrSpeculatable, Commutative]>;
 }
@@ -828,9 +826,9 @@
   DefaultAttrsIntrinsic<[llvm_float_ty], [llvm_float_ty], [IntrNoMem]>;
   def int_nvvm_ex2_approx_d : ClangBuiltin<"__nvvm_ex2_approx_d">,
   DefaultAttrsIntrinsic<[llvm_double_ty], [llvm_double_ty], [IntrNoMem]>;
-  def int_nvvm_ex2_approx_f16 : ClangBuiltin<"__nvvm_ex2_approx_f16">,
+  def int_nvvm_ex2_approx_f16 :
   DefaultAttrsIntrinsic<[llvm_half_ty], [llvm_half_ty], [IntrNoMem]>;
-  def int_nvvm_ex2_approx_f16x2 : ClangBuiltin<"__nvvm_ex2_approx_f16x2">,
+  def int_nvvm_ex2_approx_f16x2 :
   DefaultAttrsIntrinsic<[llvm_v2f16_ty], [llvm_v2f16_ty], [IntrNoMem]>;
 
   def int_nvvm_lg2_approx_ftz_f : ClangBuiltin<"__nvvm_lg2_approx_ftz_f">,
@@ -860,18 +858,16 @@
 
   foreach variant = ["_rn_f16", "_rn_ftz_f16", "_rn_sat_f16",
 "_rn_ftz_sat_f16", "_rn_relu_f16", "_rn_ftz_relu_f16"] in {
-def int_nvvm_fma # variant : ClangBuiltin,
-DefaultAttrsIntrinsic<[llvm_half_ty],
-  [llvm_half_ty, llvm_half_ty, llvm_half_ty],
-  [IntrNoMem, IntrSpeculatable]>;
+def int_nvvm_fma # variant : DefaultAttrsIntrinsic<[llvm_half_ty],
+  [llvm_half_ty, llvm_half_ty, llvm_half_ty],
+  [IntrNoMem, IntrSpeculatable]>;
   }
 
   foreach variant = ["_rn_f16x2", "_rn_ftz_f16x2", "_rn_sat_f16x2",
 "_rn_ftz_sat_f16x2", "_rn_relu_f16x2", "_rn_ftz_relu_f16x2"] in {
-def int_nvvm_fma # variant : ClangBuiltin,
-  DefaultAttrsIntrinsic<[llvm_v2f16_ty],
-[llvm_v2f16_ty, llvm_v2f16_ty, llvm_v2f16_ty],
-[IntrNoMem, IntrSpeculatable]>;
+def int_nvvm_fma # variant : DefaultAttrsIntrinsic<[llvm_v2f16_ty],
+  [llvm_v2f16_ty, llvm_v2f16_ty, llvm_v2f16_ty],
+  [IntrNoMem, IntrSpeculatable]>;
   }
 
   foreach variant = ["_rn_bf16", "_rn_relu_bf16"] in {
Index: clang/test/CodeGen/builtins-nvptx-native-half-type-err.c
===
--- clang/test/CodeGen/builtins-nvptx-native-half-type-err.c
+++ clang/test/CodeGen/builtins-nvptx-native-half-type-err.c
@@ -1,21 +1,119 @@
 // REQUIRES: nvptx-registered-target
 //
 // RUN: not %clang_cc1 -fsyntax-only -ffp-contract=off -triple nvptx-unknown-unknown -target-cpu \
-// RUN:   sm_75 -target-feature +ptx70 -fcuda-is-device -x cuda -emit-llvm -o - %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-ERROR %s
+// RUN:   sm_86 -target-feature +ptx72 -fcuda-is-device -x cuda -emit-llvm -o - %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK_ERROR %s
 
 #define __device__ __attribute__((device))
 typedef __fp16 __fp16v2 __attribute__((ext_vector_type(2)));
 
-__device__ void nvvm_ldg_ldu_native_half_types(const void *p) {
-  __nvvm_ldg_h((const __fp16 *)p);
-  __nvvm_ldg_h2((const __fp16v2 *)p);
+__device__ void nvvm_native_half_types(void *a, void*b, void*c, __fp16* out) {
+  __fp16v2 resv2 = {0, 0};
+  *out += __nvvm_ex2_approx_f16(*(__fp16 *)a);
+  resv2 = __nvvm_ex2_approx_f16x2(*(__fp16v2*)a);
 
-  __nvvm_ldu_h((const __fp16 *)p);
-  __nvvm_ldu_h2((const __fp16v2 *)p);
+  *out += __nvvm_fma_rn_relu_f16(*(__fp16*)a, *(__fp16*)b, *(__fp16*)c);
+  *out += __nvvm_fma_rn_ftz_relu_f16(*(__fp16*)a, *(__fp16*)b, *(__fp16 *)c);
+  resv2 += __nvvm_fma_rn_relu_f16x2(*(__fp16v2*)a, *(__fp16v2*)b, *(__fp16v2*)c);
+  resv2 += __nvvm_fm

[PATCH] D146497: libclang: Pass Clang install directory to driver via argv[0].

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D146497#4216278 , @Hahnfeld wrote:

> In D146497#4216226 , @aaron.ballman 
> wrote:
>
>> The issue doesn't reproduce for me locally on my Windows machine, so it may 
>> be something specific to the VE setup.
>
> FWIW I'm not doing anything specific for VE, just
>
>   set(CMAKE_C_COMPILER "clang" CACHE STRING "")
>   set(CMAKE_CXX_COMPILER "clang++" CACHE STRING "")
>   set(CMAKE_BUILD_TYPE "RelWithDebInfo" CACHE STRING "")
>   set(LLVM_APPEND_VC_REV OFF CACHE STRING "")
>   set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
>   set(LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
>   
>   set(LLVM_ENABLE_LLD ON CACHE BOOL "")
>   set(LLVM_LINK_LLVM_DYLIB ON CACHE BOOL "")
>
> in the file I load as the `initial-cache` (`cmake -C`).

Interesting, and I was testing with llvm-lit.py. The revert did get the bot 
back to green in https://lab.llvm.org/buildbot/#/builders/91/builds/15275


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146497

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

[clang] c6e9823 - [C++20][Modules] Introduce an implementation module.

[Iain Sandoe via cfe-commits]

Author: Iain Sandoe
Date: 2023-03-23T12:47:44Z
New Revision: c6e9823724ef6bdfee262289ee34d162db436af0

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

LOG: [C++20][Modules] Introduce an implementation module.

We need to be able to distinguish individual TUs from the same module in cases
where TU-local entities either need to be hidden (or, for some cases of ADL in
template instantiation, need to be detected as exposures).

This creates a module type for the implementation which implicitly imports its
primary module interface per C++20:
[module.unit/8] 'A module-declaration that contains neither an export-keyword
nor a module-partition implicitly imports the primary module interface unit of
the module as if by a module-import-declaration.

Implementation modules are never serialized (-emit-module-interface for an
implementation unit is diagnosed and rejected).

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

Added: 


Modified: 
clang/include/clang/Basic/Module.h
clang/include/clang/Lex/ModuleMap.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/Decl.cpp
clang/lib/CodeGen/CGDeclCXX.cpp
clang/lib/CodeGen/CodeGenModule.cpp
clang/lib/Frontend/FrontendActions.cpp
clang/lib/Lex/ModuleMap.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaModule.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/test/CXX/module/basic/basic.def.odr/p4.cppm
clang/test/CXX/module/basic/basic.link/p2.cppm
clang/test/CodeGenCXX/module-intializer.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Module.h 
b/clang/include/clang/Basic/Module.h
index 387ce4d6e9b17..c0c99eb8b6d62 100644
--- a/clang/include/clang/Basic/Module.h
+++ b/clang/include/clang/Basic/Module.h
@@ -103,16 +103,22 @@ class alignas(8) Module {
   /// The location of the module definition.
   SourceLocation DefinitionLoc;
 
+  // FIXME: Consider if reducing the size of this enum (having Partition and
+  // Named modules only) then representing interface/implementation separately
+  // is more efficient.
   enum ModuleKind {
 /// This is a module that was defined by a module map and built out
 /// of header files.
 ModuleMapModule,
 
+/// This is a C++ 20 header unit.
+ModuleHeaderUnit,
+
 /// This is a C++20 module interface unit.
 ModuleInterfaceUnit,
 
-/// This is a C++ 20 header unit.
-ModuleHeaderUnit,
+/// This is a C++20 module implementation unit.
+ModuleImplementationUnit,
 
 /// This is a C++ 20 module partition interface.
 ModulePartitionInterface,
@@ -169,9 +175,16 @@ class alignas(8) Module {
   /// Does this Module scope describe part of the purview of a standard named
   /// C++ module?
   bool isModulePurview() const {
-return Kind == ModuleInterfaceUnit || Kind == ModulePartitionInterface ||
-   Kind == ModulePartitionImplementation ||
-   Kind == PrivateModuleFragment;
+switch (Kind) {
+case ModuleInterfaceUnit:
+case ModuleImplementationUnit:
+case ModulePartitionInterface:
+case ModulePartitionImplementation:
+case PrivateModuleFragment:
+  return true;
+default:
+  return false;
+}
   }
 
   /// Does this Module scope describe a fragment of the global module within
@@ -561,6 +574,11 @@ class alignas(8) Module {
Kind == ModulePartitionImplementation;
   }
 
+  /// Is this a module implementation.
+  bool isModuleImplementation() const {
+return Kind == ModuleImplementationUnit;
+  }
+
   /// Is this module a header unit.
   bool isHeaderUnit() const { return Kind == ModuleHeaderUnit; }
   // Is this a C++20 module interface or a partition.

diff  --git a/clang/include/clang/Lex/ModuleMap.h 
b/clang/include/clang/Lex/ModuleMap.h
index a0ddd13c11bfd..f155c609b06cb 100644
--- a/clang/include/clang/Lex/ModuleMap.h
+++ b/clang/include/clang/Lex/ModuleMap.h
@@ -560,6 +560,11 @@ class ModuleMap {
   Module *createPrivateModuleFragmentForInterfaceUnit(Module *Parent,
   SourceLocation Loc);
 
+  /// Create a new C++ module with the specified kind, and reparent any pending
+  /// global module fragment(s) to it.
+  Module *createModuleUnitWithKind(SourceLocation Loc, StringRef Name,
+   Module::ModuleKind Kind);
+
   /// Create a new module for a C++ module interface unit.
   /// The module must not already exist, and will be configured for the current
   /// compilation.
@@ -569,6 +574,13 @@ class ModuleMap {
   /// \returns The newly-created module.
   Module *createModuleForInterfaceUnit(SourceLocation Loc, StringRef Name);
 
+  /// Create a new module for a C++ module implementation unit.
+  /// The interface module for this implementation (implicitly i

[PATCH] D126959: [C++20][Modules] Introduce an implementation module.

[Iain Sandoe via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
iains marked an inline comment as done.
Closed by commit rGc6e9823724ef: [C++20][Modules] Introduce an implementation 
module. (authored by iains).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126959

Files:
  clang/include/clang/Basic/Module.h
  clang/include/clang/Lex/ModuleMap.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Lex/ModuleMap.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CXX/module/basic/basic.def.odr/p4.cppm
  clang/test/CXX/module/basic/basic.link/p2.cppm
  clang/test/CodeGenCXX/module-intializer.cpp

Index: clang/test/CodeGenCXX/module-intializer.cpp
===
--- clang/test/CodeGenCXX/module-intializer.cpp
+++ clang/test/CodeGenCXX/module-intializer.cpp
@@ -18,17 +18,17 @@
 // RUN: -emit-llvm -o - | FileCheck %s --check-prefix=CHECK-P
 
 // RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M.cpp \
-// RUN: -fmodule-file=N.pcm -fmodule-file=O.pcm -fmodule-file=M-part.pcm \
+// RUN: -fmodule-file=N=N.pcm -fmodule-file=O=O.pcm -fmodule-file=M:Part=M-part.pcm \
 // RUN:-emit-module-interface -o M.pcm
 // RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M.pcm -S -emit-llvm \
 // RUN:  -o - | FileCheck %s --check-prefix=CHECK-M
 
 // RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 useM.cpp \
-// RUN: -fmodule-file=M.pcm -S -emit-llvm  -o - \
+// RUN: -fmodule-file=M=M.pcm -S -emit-llvm  -o - \
 // RUN: | FileCheck %s --check-prefix=CHECK-USE
 
 // RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M-impl.cpp \
-// RUN: -fmodule-file=M.pcm -S -emit-llvm  -o - \
+// RUN: -fmodule-file=M=M.pcm -S -emit-llvm  -o - \
 // RUN: | FileCheck %s --check-prefix=CHECK-IMPL
 
 // RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 N.cpp -S -emit-llvm \
@@ -41,7 +41,7 @@
 // RUN:   -o - | FileCheck %s --check-prefix=CHECK-P
 
 // RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M.cpp \
-// RUN:   -fmodule-file=N.pcm -fmodule-file=O.pcm -fmodule-file=M-part.pcm \
+// RUN:   -fmodule-file=N.pcm -fmodule-file=O=O.pcm -fmodule-file=M:Part=M-part.pcm \
 // RUN:   -S -emit-llvm -o - | FileCheck %s --check-prefix=CHECK-M
 
 //--- N-h.h
Index: clang/test/CXX/module/basic/basic.link/p2.cppm
===
--- clang/test/CXX/module/basic/basic.link/p2.cppm
+++ clang/test/CXX/module/basic/basic.link/p2.cppm
@@ -39,19 +39,21 @@
 }
 
 //--- M.cpp
-// expected-no-diagnostics
+
 module M;
 
-// FIXME: Use of internal linkage entities should be rejected.
 void use_from_module_impl() {
   external_linkage_fn();
   module_linkage_fn();
-  internal_linkage_fn();
+  internal_linkage_fn(); // expected-error {{no matching function for call to 'internal_linkage_fn'}}
   (void)external_linkage_class{};
   (void)module_linkage_class{};
-  (void)internal_linkage_class{};
   (void)external_linkage_var;
   (void)module_linkage_var;
+
+  // FIXME: Issue #61427 Internal-linkage declarations in the interface TU
+  // should not be not visible here.
+  (void)internal_linkage_class{};
   (void)internal_linkage_var;
 }
 
Index: clang/test/CXX/module/basic/basic.def.odr/p4.cppm
===
--- clang/test/CXX/module/basic/basic.def.odr/p4.cppm
+++ clang/test/CXX/module/basic/basic.def.odr/p4.cppm
@@ -143,9 +143,6 @@
   (void)&inline_var_exported;
   (void)&const_var_exported;
 
-  // CHECK: define {{.*}}@_ZL26used_static_module_linkagev
-  used_static_module_linkage();
-
   // CHECK: define linkonce_odr {{.*}}@_ZW6Module26used_inline_module_linkagev
   used_inline_module_linkage();
 
@@ -154,8 +151,12 @@
 
   (void)&extern_var_module_linkage;
   (void)&inline_var_module_linkage;
+
+  // FIXME: Issue #61427 Internal-linkage declarations in the interface TU
+  // should not be not visible here.
   (void)&static_var_module_linkage; // FIXME: Should not be visible here.
-  (void)&const_var_module_linkage;
+
+  (void)&const_var_module_linkage; // FIXME: will be visible after P2788R0
 }
 
 //--- user.cpp
@@ -176,5 +177,6 @@
   (void)&inline_var_exported;
   (void)&const_var_exported;
 
+  // Internal-linkage declarations are not visible here.
   // Module-linkage declarations are not visible here.
 }
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -2719,7 +2719,7 @@
   Abbrev->Add(BitCodeAbbrevOp(SUBMODULE_DEFINITION));
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // 

[clang] e54cdd0 - [RISCV][clang][test] Fix missed test

[Alex Bradbury via cfe-commits]

Author: Job Noorman
Date: 2023-03-23T12:49:06Z
New Revision: e54cdd058e223bd62840e901b8b462c011d2fae5

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

LOG: [RISCV][clang][test] Fix missed test

c39dd7c1db97fa367cb6282067b74cd8e55ef09a missed the appropriate change
to clang/test/Driver/ricv-arch.c.

Added: 


Modified: 
clang/test/Driver/riscv-arch.c

Removed: 




diff  --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index cbc1464cbcd6f..b13da106df778 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -206,7 +206,7 @@
 // RUN: %clang --target=riscv32-unknown-elf -march=unknown -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-STR %s
 // RV32-STR: error: invalid arch name 'unknown',
-// RV32-STR: string must begin with rv32{i,e,g} or rv64{i,g}
+// RV32-STR: string must begin with rv32{i,e,g} or rv64{i,e,g}
 
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32q -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-LETTER %s



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

[PATCH] D143570: [RISCV][MC] Add support for RV64E

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Apologies, the commited version of this patch missed the 
clang/test/Driver/riscv-arch.c change. 
rGe54cdd058e223bd62840e901b8b462c011d2fae5 
 committed 
to fix this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143570

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

[PATCH] D146717: [clangd] Handle the C++2b elifdef and elindef PP structure in CollectMainFileMacros.

[Haojian Wu via Phabricator via cfe-commits]

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146717

Files:
  clang-tools-extra/clangd/CollectMacros.cpp
  clang-tools-extra/clangd/CollectMacros.h
  clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp

Index: clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
===
--- clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
+++ clang-tools-extra/clangd/unittests/CollectMacrosTests.cpp
@@ -56,6 +56,11 @@
   // )cpp",
   R"cpp(
 #ifdef $Unknown(condit)[[UNDEFINED]]
+#elifdef $Unknown(condit)[[UNDEFINED]]
+#endif
+
+#ifdef $Unknown(condit)[[UNDEFINED]]
+#elifndef $Unknown(condit)[[UNDEFINED]]
 #endif
 
 #ifndef $Unknown(condit)[[UNDEFINED]]
@@ -101,11 +106,12 @@
 
   for (const char *Test : Tests) {
 Annotations T(Test);
-auto AST = TestTU::withCode(T.code()).build();
+auto Inputs = TestTU::withCode(T.code());
+Inputs.ExtraArgs.push_back("-std=c++2b");
+auto AST = Inputs.build();
 auto ActualMacroRefs = AST.getMacros();
 auto &SM = AST.getSourceManager();
 auto &PP = AST.getPreprocessor();
-
 for (const auto &[Name, Ranges] : T.all_ranges()) {
   if (Name == "Unknown") {
 EXPECT_THAT(ActualMacroRefs.UnknownMacros,
Index: clang-tools-extra/clangd/CollectMacros.h
===
--- clang-tools-extra/clangd/CollectMacros.h
+++ clang-tools-extra/clangd/CollectMacros.h
@@ -12,6 +12,7 @@
 #include "Protocol.h"
 #include "SourceCode.h"
 #include "index/SymbolID.h"
+#include "clang/Basic/SourceLocation.h"
 #include "clang/Lex/PPCallbacks.h"
 #include "clang/Lex/Preprocessor.h"
 #include "llvm/ADT/DenseMap.h"
@@ -61,11 +62,16 @@
   const clang::MacroDefinition &MD,
   const clang::MacroDirective *Undef) override;
 
-  // FIXME: handle C++23 #elifdef, #elifndef
   void Ifdef(SourceLocation Loc, const Token &MacroName,
  const MacroDefinition &MD) override;
   void Ifndef(SourceLocation Loc, const Token &MacroName,
   const MacroDefinition &MD) override;
+  using PPCallbacks::Elifdef;
+  using PPCallbacks::Elifndef;
+  void Elifdef(SourceLocation Loc, const Token &MacroNameTok,
+   const MacroDefinition &MD) override;
+  void Elifndef(SourceLocation Loc, const Token &MacroNameTok,
+const MacroDefinition &MD) override;
 
   void Defined(const Token &MacroName, const MacroDefinition &MD,
SourceRange Range) override;
Index: clang-tools-extra/clangd/CollectMacros.cpp
===
--- clang-tools-extra/clangd/CollectMacros.cpp
+++ clang-tools-extra/clangd/CollectMacros.cpp
@@ -36,33 +36,51 @@
 SrcMgr::CharacteristicKind, FileID) {
   InMainFile = isInsideMainFile(Loc, SM);
 }
+
 void CollectMainFileMacros::MacroExpands(const Token &MacroName,
  const MacroDefinition &MD,
  SourceRange Range,
  const MacroArgs *Args) {
   add(MacroName, MD.getMacroInfo());
 }
+
 void CollectMainFileMacros::MacroUndefined(const clang::Token &MacroName,
const clang::MacroDefinition &MD,
const clang::MacroDirective *Undef) {
   add(MacroName, MD.getMacroInfo());
 }
+
 void CollectMainFileMacros::Ifdef(SourceLocation Loc, const Token &MacroName,
   const MacroDefinition &MD) {
   add(MacroName, MD.getMacroInfo(), /*IsDefinition=*/false,
   /*InConditionalDirective=*/true);
 }
+
 void CollectMainFileMacros::Ifndef(SourceLocation Loc, const Token &MacroName,
const MacroDefinition &MD) {
   add(MacroName, MD.getMacroInfo(), /*IsDefinition=*/false,
   /*InConditionalDirective=*/true);
 }
+
+void CollectMainFileMacros::Elifdef(SourceLocation Loc, const Token &MacroName,
+const MacroDefinition &MD) {
+  add(MacroName, MD.getMacroInfo(), /*IsDefinition=*/false,
+  /*InConditionalDirective=*/true);
+}
+
+void CollectMainFileMacros::Elifndef(SourceLocation Loc, const Token &MacroName,
+ const MacroDefinition &MD) {
+  add(MacroName, MD.getMacroInfo(), /*IsDefinition=*/false,
+  /*InConditionalDirective=*/true);
+}
+
 void CollectMainFileMacros::Defined(const Token &MacroName,
 const MacroDefinition &MD,
 Sour

[PATCH] D146503: Fix highlighting issue with _complex and initialization list with more than 2 items

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

The precommit CI failures are unrelated to your changes (the Debian one is 
related to flang failures and the libcxx one seems to be related to 
infrastructure), so no need to worry about them.




Comment at: clang/test/Sema/complex-init-list.c:37
 struct teststruct invalid1 = { 1, 2 }; // expected-warning {{excess elements}}
-_Complex float invalid2 = { 1, 2, 3 }; // expected-warning {{excess elements}}
+_Complex float invalid2 = { 1, 2, 3 }; // expected-warning {{specifying real 
and imaginary components is an extension}} expected-warning {{excess elements 
in scalar initializer}}
 _Complex float invalid3 = {}; // expected-error {{scalar initializer cannot be 
empty}} expected-warning {{GNU empty initializer}}

chaitanyav wrote:
> aaron.ballman wrote:
> > This makes it a bit easier to see that there are two diagnostics being 
> > fired (even though we're not consistently doing that in this test file).
> Yeah, one because its an extension and other because it has excess elements. 
> Checked this file added that on lines its applicable.
I'd still like to see these two changes made (where we use a line continuation 
character to put the diagnostic messages on their own lines instead of mashed 
together on one long line).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146503

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

[PATCH] D146178: [Clang][Sema] Fix comparison of constraint expressions

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D146178#4214972 , 
@alexander-shaposhnikov wrote:

> Add more tests.
> P.S. we already have tests with self-friends (in concepts.cpp), the test from 
> Richard's comment is also included (struct S12) (in a slightly simplified 
> form)

Interesting, that self-friend version did NOT fail for me (see the change I 
made which was much less involved).  I think on this one I'm unable to review 
it without Richard, so hopefully he can come back and give comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146178

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

[PATCH] D146418: Support for OpenMP 5.0 sec 2.12.7 - Declare Target initializer expressions

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/Parse/ParseDecl.cpp:2093-2115
+void ParseImplicitDeclareTargetAttr(Decl *TargetDecl) {
+  if (TargetDecl && TargetDecl->hasAttr() &&
+  isa(TargetDecl)) {
+VarDecl *TargetVarDecl = cast(TargetDecl);
+Expr *Ex = TargetVarDecl->getInit()->IgnoreCasts();
+const DeclRefExpr *DeclRef = nullptr;
+if (Ex && isa(Ex) && TargetVarDecl->hasGlobalStorage()) {

RitanyaB wrote:
> ABataev wrote:
> > It has nothing to do with parsing, sema analysis. Make it part of 
> > Sema::checkDeclIsAllowedInOpenMPTarget
> The Declaration in Sema::checkDeclIsAllowedInOpenMPTarget is incomplete. 
> 
> ```
> VarDecl 0x1582b278  col:7 ptr1 'int **'
> `-OMPDeclareTargetDeclAttr 0x1582b2e0  Implicit MT_To DT_Any 1
>   `-<<>>
> 
> ```  
> At this point, I do not have access to the initializer expression. Any 
> suggestions? 
The try to do it ActOnOpenMPDeclareTargetName


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146418

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

[PATCH] D146701: [AMDGPU] Create Subtarget Features for some of 16 bits atomic fadd instructions

[Jay Foad via Phabricator via cfe-commits]

foad added inline comments.



Comment at: llvm/lib/Target/AMDGPU/BUFInstructions.td:2889
 
-defm BUFFER_ATOMIC_ADD_F32: MUBUF_Real_Atomic_vi <0x4d>;
+let SubtargetPredicate = HasAtomicBufferGlobalPkAddF16NoRtnInsts in {
 defm BUFFER_ATOMIC_PK_ADD_F16 : MUBUF_Real_Atomic_vi <0x4e>;

mariusz-sikora-at-amd wrote:
> foad wrote:
> > Could remove the braces if you prefer - then you don't need the "End" 
> > comment either.
> So, as I understand from other comment:
> 
> > Generally Real instructions copy their predicates from the corresponding 
> > Pseudo, so this should not be required here. Please check the other places 
> > where you have added predicates to Real instructions too.
> 
> We do not need this (L2889) Predicate, because it was added to Pseudo 
> Instruction ?
Correct. See the places commented "copy relevant pseudo op flags" in this file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146701

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

[PATCH] D139705: [clang] fix zero-initialization fix-it for variable template

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D139705#4215653 , 
@tomasz-kaminski-sonarsource wrote:

> As a downstream, we have concerns with this change. From what I saw it breaks 
> the behavior of the fix-it that wants to remove the whole variable definition 
> (including the initializer). For example, I have unused, that I want to 
> remove variable `x` and unnecessary explicit specialization `temp`:
>
>   template
>   T temp = 1;
>   
>   int x  = 10;
>   template<> double temp = 1;
>
> Previously, this could be handled (in case of single variable declaration) by 
> simply removing up the `var->getSourceRange()` with succeeding coma. However, 
> after the change, such code does not work, and in general if 
> `getSourceRange()` is used on `VarDecl` (or even `Decl`), special 
> consideration needs to be taken for the situation when `VarDecl` refers to 
> variable template specialization.
>
> As an alternative, I would suggest introducing an additional function to 
> `VarDecl` (which could be moved up in the hierarchy), that would report a 
> source range that corresponds to //declarator-id//, i.e. for template 
> variable it would include template arguments.

Hmm... I'm being a little dense here I guess, I don't understand what you mean? 
 Does this result in one of our fixits being wrong here?  With the old range, 
wouldn't it have left the `` in that case, and now is removing it?  Or 
what am I missing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139705

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

[PATCH] D146591: [dataflow] add HTML logger: browse code/cfg/analysis timeline/state

[Sam McCall via Phabricator via cfe-commits]

sammccall marked 15 inline comments as done.
sammccall added inline comments.



Comment at: clang/lib/Analysis/FlowSensitive/CMakeLists.txt:22
+add_custom_command(OUTPUT HTMLLogger.inc
+  COMMAND "${Python3_EXECUTABLE}" bundle_resources.py 
+  ${CMAKE_CURRENT_BINARY_DIR}/HTMLLogger.inc

gribozavr2 wrote:
> Is this the right location for the Python script? Aren't they normally under 
> `llvm-project.git/clang/utils`?
I've moved it, though honestly I have no idea if that's the right place :-)

Clang/utils has lots of tools to invoke by hand, test helpers, the sources for 
clang-tablegen, and exactly one build-time python script that I could find.

Python scripts that are part of the build graph seem to usually live somewhere 
under the dir that uses them (libclang/linker-script-to-export-list.py, 
llvm-shlib/gen-msvc-exports.py, libclc/generic/lib/gen_convert.py, 
Tooling/DumpTool/generate_cxx_src_locs.py), but not always.

OTOH, this is fairly generic (there's also a copy under 
clang-tools-extra/pseudo) so probably makes sense to have somewhere sharable.



Comment at: clang/lib/Analysis/FlowSensitive/HTMLLogger.js:128
+  // hex values to subtract from fff to get a base color
+  options = [0x001, 0x010, 0x100, 0x011, 0x101, 0x110, 0x111];
+  function color(hex) {

gribozavr2 wrote:
> Or was the order intentional?
Somehow ordering by {number of set bits, lexicographic} makes sense in my head 
but I've changed it because I can't explain why :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146591

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

[PATCH] D146591: [dataflow] add HTML logger: browse code/cfg/analysis timeline/state

[Sam McCall via Phabricator via cfe-commits]

sammccall updated this revision to Diff 507718.
sammccall marked 2 inline comments as done.
sammccall added a comment.

Address all comments except moving data from HTML => JSON


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146591

Files:
  clang/include/clang/Analysis/FlowSensitive/Logger.h
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
  clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp
  clang/lib/Analysis/FlowSensitive/HTMLLogger.css
  clang/lib/Analysis/FlowSensitive/HTMLLogger.js
  clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp
  clang/utils/bundle_resources.py

Index: clang/utils/bundle_resources.py
===
--- /dev/null
+++ clang/utils/bundle_resources.py
@@ -0,0 +1,29 @@
+#!/usr/bin/env python3
+
+#===- bundle_resources.py - Generate string constants with file contents. ===
+#
+# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+# See https://llvm.org/LICENSE.txt for license information.
+# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+#
+#===--===
+
+# Usage: bundle-resources.py foo.inc a.js path/b.css ...
+# Produces foo.inc containing:
+#   const char a_js[] = "...";
+#   const char b_css[] = "...";
+import os
+import sys
+
+outfile = sys.argv[1]
+infiles = sys.argv[2:]
+
+with open(outfile, 'w') as out:
+  for filename in infiles:
+varname = os.path.basename(filename).replace('.', '_')
+out.write("const char " + varname + "[] = \n");
+# MSVC limits each chunk of string to 2k, so split by lines.
+# The overall limit is 64k, which ought to be enough for anyone.
+for line in open(filename).read().split('\n'):
+  out.write('  R"x(' + line + ')x" "\\n"\n' )
+out.write('  ;\n');
Index: clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp
@@ -9,6 +9,7 @@
 
 namespace clang::dataflow::test {
 namespace {
+using testing::HasSubstr;
 
 struct TestLattice {
   int Elements = 0;
@@ -83,19 +84,24 @@
   void logText(llvm::StringRef Text) override { OS << Text << "\n"; }
 };
 
-TEST(LoggerTest, Sequence) {
+AnalysisInputs makeInputs() {
   const char *Code = R"cpp(
 int target(bool b, int p, int q) {
   return b ? p : q;
 }
 )cpp";
+  static const std::vector Args = {
+  "-fsyntax-only", "-fno-delayed-template-parsing", "-std=c++17"};
 
   auto Inputs = AnalysisInputs(
   Code, ast_matchers::hasName("target"),
   [](ASTContext &C, Environment &) { return TestAnalysis(C); });
-  std::vector Args = {
-  "-fsyntax-only", "-fno-delayed-template-parsing", "-std=c++17"};
   Inputs.ASTBuildArgs = Args;
+  return Inputs;
+}
+
+TEST(LoggerTest, Sequence) {
+  auto Inputs = makeInputs();
   std::string Log;
   TestLogger Logger(Log);
   Inputs.BuiltinOptions.Log = &Logger;
@@ -148,5 +154,29 @@
 )");
 }
 
+TEST(LoggerTest, HTML) {
+  auto Inputs = makeInputs();
+  std::vector Logs;
+  auto Logger = Logger::html([&]() {
+Logs.emplace_back();
+return std::make_unique(Logs.back());
+  });
+  Inputs.BuiltinOptions.Log = Logger.get();
+
+  ASSERT_THAT_ERROR(checkDataflow(std::move(Inputs),
+[](const AnalysisOutputs &) {}),
+llvm::Succeeded());
+
+  // Simple smoke tests: we can't meaningfully test the behavior.
+  ASSERT_THAT(Logs, testing::SizeIs(1));
+  EXPECT_THAT(Logs[0], HasSubstr("function updateSelection")) << "embeds JS";
+  EXPECT_THAT(Logs[0], HasSubstr("html {")) << "embeds CSS";
+  EXPECT_THAT(Logs[0], HasSubstr("b (ImplicitCastExpr")) << "has CFG elements";
+  EXPECT_THAT(Logs[0], HasSubstr("https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+// Based on selected objects, hide/show sections & populate data from templates.
+//
+// For example, if we the selection is {bb=BB4, elt=BB4.6 iter=BB4:2}:
+//   - show the "block" and "element" sections
+//   - load data from template "BB4"
+// (this is the basic block stmt list etc)
+//   - load data from template "BB4:2_BB4.6"
+// (this is the log from executing stmt 6 in the second iteration of BB4)
+//   - apply "bb-select" to items with class class "BB4", etc
+let selection = {};
+function updateSelection(changes) {
+  for (var k in changes) {
+if (selection[k] == changes[k])
+  delete changes[k]; // not actually changed, don't reload data below
+  }
+  Object.assign(selection, changes);
+
+  function showSection(name, visible) {
+document.getElementById(name).hidden = !visi

[PATCH] D146591: [dataflow] add HTML logger: browse code/cfg/analysis timeline/state

[Sam McCall via Phabricator via cfe-commits]

sammccall planned changes to this revision.
sammccall added a comment.

Going to have a go at passing data via JSON


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146591

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

[PATCH] D130181: [clang-tidy] Add readability-use-early-exits check

[Nathan James via Phabricator via cfe-commits]

njames93 added inline comments.



Comment at: clang-tools-extra/clang-tidy/readability/UseEarlyExitsCheck.cpp:359
+void UseEarlyExitsCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(translationUnitDecl(), this);
+}

PiotrZSL wrote:
> This will trigger on all system code, and then users will complain again that 
> they see poor clang-tidy performance...
> 
> when it could be just something like
> 
> ```
> ifStmt(unless(isExpansionInSystemHeader()),
>unless(isConsteval()),
>unless(isConstexpr()),
>unless(hasElse(stmt())),
>unless(hasInitStatement(stmt()),
>hasThen(compoundStmt(hasSizeAboeLineTreshold())),
>...
> ```
> 
> Simply everything that could be put into matcher should be put into matcher 
> (easier to maintain), also what's a point of checking functions that doesn't 
> have if's. On that point also some implicit functions or if statement should 
> be ignored, to avoid checking templates twice.
> 
Not triggering on system headers is a good point, but for raw performance, that 
code is better residing in the visitor,  which can massively outperform 
matchers as we can straight up ignore huge blocks of code that aren't of 
interest.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130181

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

[PATCH] D139705: [clang] fix zero-initialization fix-it for variable template

[Tomasz Kamiński via Phabricator via cfe-commits]

tomasz-kaminski-sonarsource added a comment.

In D139705#4216417 , @erichkeane 
wrote:

> In D139705#4215653 , 
> @tomasz-kaminski-sonarsource wrote:
>
>> As a downstream, we have concerns with this change. From what I saw it 
>> breaks the behavior of the fix-it that wants to remove the whole variable 
>> definition (including the initializer). For example, I have unused, that I 
>> want to remove variable `x` and unnecessary explicit specialization 
>> `temp`:
>>
>>   template
>>   T temp = 1;
>>   
>>   int x  = 10;
>>   template<> double temp = 1;
>>
>> Previously, this could be handled (in case of single variable declaration) 
>> by simply removing up the `var->getSourceRange()` with succeeding coma. 
>> However, after the change, such code does not work, and in general if 
>> `getSourceRange()` is used on `VarDecl` (or even `Decl`), special 
>> consideration needs to be taken for the situation when `VarDecl` refers to 
>> variable template specialization.
>>
>> As an alternative, I would suggest introducing an additional function to 
>> `VarDecl` (which could be moved up in the hierarchy), that would report a 
>> source range that corresponds to //declarator-id//, i.e. for template 
>> variable it would include template arguments.
>
> Hmm... I'm being a little dense here I guess, I don't understand what you 
> mean?  Does this result in one of our fixits being wrong here?  With the old 
> range, wouldn't it have left the `` in that case, and now is removing 
> it?  Or what am I missing?

Before the change, for both `x` and `temp`, prior the change the 
`getSourceRange()` on the `VarDecl` that represents them include initializer 
(they end just before `;`). But now for the variable template specialization, 
we end up just after template arguments. This means that fixit/report that 
previously covered the whole definition, will now not include initializer.
Or in our example:

  `
  template
  T temp = 1;
   // v getSourceRange() ends on this token before and after the change
  int x = 10;
// v getSourceRange() ends on this token prior 
the change, consistently with normal variables
  template<> double temp = 1;
// ^ getSurceRange() ends on this token after the 
change, making it inconsistient
  `


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139705

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

[PATCH] D146719: [Clang] Improve diagnostics when using a concept as template argument

[Corentin Jabot via Phabricator via cfe-commits]

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

When using the name of a template variable or concept in places
where an expression was expected, Clang would drop the cxxscope token
preceeding it, if any.

This leads to subpar diagnostics - complaining about the
identifier being undeclared as clang would not know to look into a
non-global scope.

We make sure the scope is preserved.

When encountering `ns::Concept foo x;`, Clang would also fail
to provide the same quality as it does at global scope.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146719

Files:
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/Parser.cpp
  clang/test/Parser/cxx-template-template-recovery.cpp

Index: clang/test/Parser/cxx-template-template-recovery.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx-template-template-recovery.cpp
@@ -0,0 +1,40 @@
+// RUN: %clang_cc1 -std=c++20 -verify -fsyntax-only %s
+
+namespace a {
+  template 
+  concept C1 = true; //expected-note {{here}}
+
+  template 
+  auto V1 = true; //expected-note {{here}}
+
+  namespace b {
+template 
+concept C2 = true; //expected-note {{here}}
+
+template 
+auto V2 = true; //expected-note {{here}}
+  }
+}
+
+template 
+concept C3 = true; //expected-note {{here}}
+template 
+auto V3 = true; //expected-note {{here}}
+
+template  typename C>
+constexpr bool test = true;
+
+static_assert(test); //expected-error {{too few template arguments for concept 'C1'}}
+static_assert(test); //expected-error {{too few template arguments for concept 'C2'}}
+static_assert(test); //expected-error {{too few template arguments for concept 'C3'}}
+
+static_assert(test); //expected-error {{use of variable template 'V1' requires template arguments}}
+static_assert(test); //expected-error {{use of variable template 'V2' requires template arguments}}
+static_assert(test); //expected-error {{use of variable template 'V3' requires template arguments}}
+
+
+void f() {
+C3 t1 = 0;  // expected-error{{expected 'auto' or 'decltype(auto)' after concept name}}
+a::C1 t2 = 0; // expected-error{{expected 'auto' or 'decltype(auto)' after concept name}}
+a::b::C2 t3 = 0; // expected-error{{expected 'auto' or 'decltype(auto)' after concept name}}
+}
Index: clang/lib/Parse/Parser.cpp
===
--- clang/lib/Parse/Parser.cpp
+++ clang/lib/Parse/Parser.cpp
@@ -1883,31 +1883,25 @@
   return ANK_TemplateName;
 }
 [[fallthrough]];
+  case Sema::NC_Concept:
   case Sema::NC_VarTemplate:
   case Sema::NC_FunctionTemplate:
   case Sema::NC_UndeclaredTemplate: {
-// We have a type, variable or function template followed by '<'.
-ConsumeToken();
-UnqualifiedId Id;
-Id.setIdentifier(Name, NameLoc);
-if (AnnotateTemplateIdToken(
-TemplateTy::make(Classification.getTemplateName()),
-Classification.getTemplateNameKind(), SS, SourceLocation(), Id))
-  return ANK_Error;
-return ANK_Success;
-  }
-  case Sema::NC_Concept: {
-UnqualifiedId Id;
-Id.setIdentifier(Name, NameLoc);
+bool IsConceptName = Classification.getKind() == Sema::NC_Concept;
+// We have a template name followed by '<'. Consume the identifier token so
+// we reach the '<' and annotate it.
 if (Next.is(tok::less))
-  // We have a concept name followed by '<'. Consume the identifier token so
-  // we reach the '<' and annotate it.
   ConsumeToken();
+UnqualifiedId Id;
+Id.setIdentifier(Name, NameLoc);
 if (AnnotateTemplateIdToken(
 TemplateTy::make(Classification.getTemplateName()),
 Classification.getTemplateNameKind(), SS, SourceLocation(), Id,
-/*AllowTypeAnnotation=*/false, /*TypeConstraint=*/true))
+/*AllowTypeAnnotation=*/!IsConceptName,
+/*TypeConstraint=*/IsConceptName))
   return ANK_Error;
+if (SS.isNotEmpty())
+  AnnotateScopeToken(SS, !WasScopeAnnotation);
 return ANK_Success;
   }
   }
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -3448,12 +3448,12 @@
 continue;
   }
 
-  if (TemplateId && TemplateId->Kind == TNK_Concept_template &&
-  GetLookAheadToken(2).isOneOf(tok::kw_auto, tok::kw_decltype)) {
+  if (TemplateId && TemplateId->Kind == TNK_Concept_template) {
 DS.getTypeSpecScope() = SS;
-// This is a qualified placeholder-specifier, e.g., ::C auto ...
-// Consume the scope annotation and continue to consume the template-id
-// as a placeholder-specifier.
+// This is probably a qualified placeholder-specifier, e.g., ::C
+// auto ... Consume the scope annotatio

[PATCH] D146701: [AMDGPU] Create Subtarget Features for some of 16 bits atomic fadd instructions

[Mariusz Sikora via Phabricator via cfe-commits]

mariusz-sikora-at-amd updated this revision to Diff 507722.
mariusz-sikora-at-amd added a comment.

Changes after review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146701

Files:
  clang/include/clang/Basic/BuiltinsAMDGPU.def
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  clang/test/CodeGenOpenCL/builtins-amdgcn-fp-atomics-gfx11-err.cl
  clang/test/CodeGenOpenCL/builtins-amdgcn-fp-atomics-gfx908-err.cl
  clang/test/CodeGenOpenCL/builtins-amdgcn-fp-atomics-gfx90a-err.cl
  llvm/lib/Target/AMDGPU/AMDGPU.td
  llvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp
  llvm/lib/Target/AMDGPU/BUFInstructions.td
  llvm/lib/Target/AMDGPU/DSInstructions.td
  llvm/lib/Target/AMDGPU/FLATInstructions.td
  llvm/lib/Target/AMDGPU/GCNSubtarget.h

Index: llvm/lib/Target/AMDGPU/GCNSubtarget.h
===
--- llvm/lib/Target/AMDGPU/GCNSubtarget.h
+++ llvm/lib/Target/AMDGPU/GCNSubtarget.h
@@ -152,9 +152,13 @@
   bool HasMAIInsts = false;
   bool HasFP8Insts = false;
   bool HasPkFmacF16Inst = false;
+  bool HasAtomicDsPkAdd16Insts = false;
+  bool HasAtomicFlatPkAdd16Insts = false;
   bool HasAtomicFaddRtnInsts = false;
   bool HasAtomicFaddNoRtnInsts = false;
-  bool HasAtomicPkFaddNoRtnInsts = false;
+  bool HasAtomicBufferGlobalPkAddF16NoRtnInsts = false;
+  bool HasAtomicBufferGlobalPkAddF16Insts = false;
+  bool HasAtomicGlobalPkAddBF16Inst = false;
   bool HasFlatAtomicFaddF32Inst = false;
   bool SupportsSRAMECC = false;
 
@@ -758,6 +762,10 @@
 return HasPkFmacF16Inst;
   }
 
+  bool hasAtomicDsPkAdd16Insts() const { return HasAtomicDsPkAdd16Insts; }
+
+  bool hasAtomicFlatPkAdd16Insts() const { return HasAtomicFlatPkAdd16Insts; }
+
   bool hasAtomicFaddInsts() const {
 return HasAtomicFaddRtnInsts || HasAtomicFaddNoRtnInsts;
   }
@@ -766,7 +774,17 @@
 
   bool hasAtomicFaddNoRtnInsts() const { return HasAtomicFaddNoRtnInsts; }
 
-  bool hasAtomicPkFaddNoRtnInsts() const { return HasAtomicPkFaddNoRtnInsts; }
+  bool hasAtomicBufferGlobalPkAddF16NoRtnInsts() const {
+return HasAtomicBufferGlobalPkAddF16NoRtnInsts;
+  }
+
+  bool hasAtomicBufferGlobalPkAddF16Insts() const {
+return HasAtomicBufferGlobalPkAddF16Insts;
+  }
+
+  bool hasAtomicGlobalPkAddBF16Inst() const {
+return HasAtomicGlobalPkAddBF16Inst;
+  }
 
   bool hasFlatAtomicFaddF32Inst() const { return HasFlatAtomicFaddF32Inst; }
 
Index: llvm/lib/Target/AMDGPU/FLATInstructions.td
===
--- llvm/lib/Target/AMDGPU/FLATInstructions.td
+++ llvm/lib/Target/AMDGPU/FLATInstructions.td
@@ -730,11 +730,14 @@
   defm GLOBAL_ATOMIC_MAX_F64 : FLAT_Global_Atomic_Pseudo<"global_atomic_max_f64", VReg_64, f64>;
 } // End SubtargetPredicate = isGFX90APlus
 
-let SubtargetPredicate = isGFX940Plus in {
+let SubtargetPredicate = HasAtomicFlatPkAdd16Insts in {
   defm FLAT_ATOMIC_PK_ADD_F16: FLAT_Atomic_Pseudo<"flat_atomic_pk_add_f16",  VGPR_32, v2f16>;
   defm FLAT_ATOMIC_PK_ADD_BF16   : FLAT_Atomic_Pseudo<"flat_atomic_pk_add_bf16", VGPR_32, v2f16>;
+} // End SubtargetPredicate = HasAtomicFlatPkAdd16Insts
+
+let SubtargetPredicate = HasAtomicGlobalPkAddBF16Inst in {
   defm GLOBAL_ATOMIC_PK_ADD_BF16 : FLAT_Global_Atomic_Pseudo<"global_atomic_pk_add_bf16", VGPR_32, v2f16>;
-} // End SubtargetPredicate = isGFX940Plus
+} // End SubtargetPredicate = HasAtomicGlobalPkAddBF16Inst
 
 // GFX7-, GFX10-, GFX11-only flat instructions.
 let SubtargetPredicate = isGFX7GFX10GFX11 in {
@@ -938,7 +941,7 @@
   defm GLOBAL_ATOMIC_ADD_F32 : FLAT_Global_Atomic_Pseudo_NO_RTN <
 "global_atomic_add_f32", VGPR_32, f32
   >;
-let OtherPredicates = [HasAtomicPkFaddNoRtnInsts] in
+let OtherPredicates = [HasAtomicBufferGlobalPkAddF16NoRtnInsts] in
   defm GLOBAL_ATOMIC_PK_ADD_F16 : FLAT_Global_Atomic_Pseudo_NO_RTN <
 "global_atomic_pk_add_f16", VGPR_32, v2f16
   >;
@@ -946,7 +949,7 @@
   defm GLOBAL_ATOMIC_ADD_F32 : FLAT_Global_Atomic_Pseudo_RTN <
 "global_atomic_add_f32", VGPR_32, f32
   >;
-let OtherPredicates = [isGFX90APlus] in
+let OtherPredicates = [HasAtomicBufferGlobalPkAddF16Insts] in
   defm GLOBAL_ATOMIC_PK_ADD_F16 : FLAT_Global_Atomic_Pseudo_RTN <
 "global_atomic_pk_add_f16", VGPR_32, v2f16
   >;
@@ -1505,7 +1508,7 @@
 defm : GlobalFLATAtomicPatsNoRtnWithAddrSpace <"GLOBAL_ATOMIC_ADD_F32", "int_amdgcn_global_atomic_fadd", "global_addrspace", f32>;
 }
 
-let OtherPredicates = [HasAtomicPkFaddNoRtnInsts] in {
+let OtherPredicates = [HasAtomicBufferGlobalPkAddF16NoRtnInsts] in {
 defm : GlobalFLATAtomicPatsNoRtnWithAddrSpace <"GLOBAL_ATOMIC_PK_ADD_F16", "int_amdgcn_flat_atomic_fadd", "global_addrspace", v2f16>;
 defm : GlobalFLATAtomicPatsNoRtnWithAddrSpace <"GLOBAL_ATOMIC_PK_ADD_F16", "int_amdgcn_global_atomic_fadd", "global_addrspace", v2f16>;
 }
@@ -1516,14 +1519,17 @@
 defm : GlobalFLATAtomicPatsRtnWithAddrSpace <"GLOBAL

[PATCH] D146719: [Clang] Improve diagnostics when using a concept as template argument

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added a comment.

Compiler explorer link demonstrating the issue this fixes 
https://godbolt.org/z/Tj3v5jbnq


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146719

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

[PATCH] D146719: [Clang] Improve diagnostics when using a concept as template argument

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

This generally looks good to me, but I get lost in the parser pretty quick, so 
hoping one of the other reviewers can take a look.




Comment at: clang/test/Parser/cxx-template-template-recovery.cpp:27
+
+static_assert(test); //expected-error {{too few template arguments for 
concept 'C1'}}
+static_assert(test); //expected-error {{too few template arguments 
for concept 'C2'}}

So it appears that lines 27 and 28 are the only behavioral changes here, right? 
 The line 31 and 37 sections are the same, right?

1 Nit here: I REALLY prefer when we use bookmarks, and include the notes next 
to their diagnostic.  Here it isn't hugely necessary, but still a preference if 
you're needing to update this again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146719

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

[PATCH] D146671: [clang][ExtractAPI]Fix Declaration fragments for instancetype in the type position degrade to id

[NagaChaitanya Vellanki via Phabricator via cfe-commits]

chaitanyav updated this revision to Diff 507725.
chaitanyav added a comment.

update test to check for id type


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146671

Files:
  clang/lib/ExtractAPI/DeclarationFragments.cpp
  clang/test/ExtractAPI/objc_instancetype.m

Index: clang/test/ExtractAPI/objc_instancetype.m
===
--- /dev/null
+++ clang/test/ExtractAPI/objc_instancetype.m
@@ -0,0 +1,254 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
+ // RUN: %t/reference.output.json.in >> %t/reference.output.json
+// RUN: %clang_cc1 -extract-api -triple arm64-apple-macosx -x objective-c-header %t/input.h -o %t/output.json -verify
+
+// Generator version is not consistent across test runs, normalize it.
+// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
+ // RUN: %t/output.json >> %t/output-normalized.json
+// RUN: diff %t/reference.output.json %t/output-normalized.json
+
+
+//--- input.h
+@interface Foo
+- (instancetype) init;
+- (id) reset;
+@end
+// expected-no-diagnostics
+
+
+//--- reference.output.json.in
+{
+  "metadata": {
+"formatVersion": {
+  "major": 0,
+  "minor": 5,
+  "patch": 3
+},
+"generator": "?"
+  },
+  "module": {
+"name": "",
+"platform": {
+  "architecture": "arm64",
+  "operatingSystem": {
+"minimumVersion": {
+  "major": 11,
+  "minor": 0,
+  "patch": 0
+},
+"name": "macosx"
+  },
+  "vendor": "apple"
+}
+  },
+  "relationships": [
+{
+  "kind": "memberOf",
+  "source": "c:objc(cs)Foo(im)init",
+  "target": "c:objc(cs)Foo",
+  "targetFallback": "Foo"
+},
+{
+  "kind": "memberOf",
+  "source": "c:objc(cs)Foo(im)reset",
+  "target": "c:objc(cs)Foo",
+  "targetFallback": "Foo"
+}
+  ],
+  "symbols": [
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "keyword",
+  "spelling": "@interface"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "identifier",
+  "spelling": "Foo"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "objective-c",
+"precise": "c:objc(cs)Foo"
+  },
+  "kind": {
+"displayName": "Class",
+"identifier": "objective-c.class"
+  },
+  "location": {
+"position": {
+  "character": 12,
+  "line": 1
+},
+"uri": "file://INPUT_DIR/input.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "Foo"
+  }
+],
+"subHeading": [
+  {
+"kind": "identifier",
+"spelling": "Foo"
+  }
+],
+"title": "Foo"
+  },
+  "pathComponents": [
+"Foo"
+  ]
+},
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "text",
+  "spelling": "- ("
+},
+{
+  "kind": "keyword",
+  "spelling": "instancetype"
+},
+{
+  "kind": "text",
+  "spelling": ") "
+},
+{
+  "kind": "identifier",
+  "spelling": "init"
+},
+{
+  "kind": "text",
+  "spelling": ";"
+}
+  ],
+  "functionSignature": {
+"returns": [
+  {
+"kind": "keyword",
+"spelling": "instancetype"
+  }
+]
+  },
+  "identifier": {
+"interfaceLanguage": "objective-c",
+"precise": "c:objc(cs)Foo(im)init"
+  },
+  "kind": {
+"displayName": "Instance Method",
+"identifier": "objective-c.method"
+  },
+  "location": {
+"position": {
+  "character": 1,
+  "line": 2
+},
+"uri": "file://INPUT_DIR/input.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "init"
+  }
+],
+"subHeading": [
+  {
+"kind": "text",
+"spelling": "- "
+  },
+  {
+"kind": "identifier",
+"spelling": "init"
+  }
+],
+"title": "init"
+  },
+  "pathComponents": [
+"Foo",
+"init"
+  ]
+},
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "text",
+  "spelling": "- ("
+},
+{
+  "kind": "keyword",
+  "spelling": "id"
+},
+{
+  "kind": "text",
+  "spelling": ") "
+},
+{
+  "kind": "identifier",
+  

[clang] 8c7c1f1 - Silence unused variable warning in NDEBUG builds

[Benjamin Kramer via cfe-commits]

Author: Benjamin Kramer
Date: 2023-03-23T14:41:03+01:00
New Revision: 8c7c1f11ffaacf762e612c65440fd2cbb58ee426

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

LOG: Silence unused variable warning in NDEBUG builds

I usually would fold this into the assert, but the comment there
suggests side effects. NFC.

ModuleMap.cpp:938:9: error: unused variable 'MainFile' 
[-Werror,-Wunused-variable]
  auto *MainFile = SourceMgr.getFileEntryForID(SourceMgr.getMainFileID());

Added: 


Modified: 
clang/lib/Lex/ModuleMap.cpp

Removed: 




diff  --git a/clang/lib/Lex/ModuleMap.cpp b/clang/lib/Lex/ModuleMap.cpp
index f2b2d0b8c69f1..44c872336ce9c 100644
--- a/clang/lib/Lex/ModuleMap.cpp
+++ b/clang/lib/Lex/ModuleMap.cpp
@@ -936,6 +936,7 @@ Module 
*ModuleMap::createModuleForImplementationUnit(SourceLocation Loc,
   // Mark the main source file as being within the newly-created module so that
   // declarations and macros are properly visibility-restricted to it.
   auto *MainFile = SourceMgr.getFileEntryForID(SourceMgr.getMainFileID());
+  (void)MainFile;
   assert(MainFile && "no input file for module implementation");
 
   return Result;



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