[clang] 696f8b3 - Revert "[clang-format] Add a space between an overloaded operator and '>'"

2023-03-20 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2023-03-20T08:07:44+01:00
New Revision: 696f8b32d4bfe7e96f6fdb425fb4768a0508da83

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

LOG: Revert "[clang-format] Add a space between an overloaded operator and '>'"

This reverts commit b05dc1b8766a47482cae432011fd2faa04c83a3e.

Makes clang-format crash on `struct Foo { operator enum foo{} };`

Added: 


Modified: 
clang/lib/Format/FormatTokenLexer.cpp
clang/lib/Format/FormatTokenLexer.h
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp
clang/unittests/Format/TokenAnnotatorTest.cpp

Removed: 




diff  --git a/clang/lib/Format/FormatTokenLexer.cpp 
b/clang/lib/Format/FormatTokenLexer.cpp
index ae54de93daf5..f06f9fb9949d 100644
--- a/clang/lib/Format/FormatTokenLexer.cpp
+++ b/clang/lib/Format/FormatTokenLexer.cpp
@@ -103,8 +103,6 @@ void FormatTokenLexer::tryMergePreviousTokens() {
 return;
   if (tryMergeLessLess())
 return;
-  if (tryMergeGreaterGreater())
-return;
   if (tryMergeForEach())
 return;
   if (Style.isCpp() && tryTransformTryUsageForC())
@@ -462,11 +460,12 @@ bool FormatTokenLexer::tryMergeLessLess() {
 return false;
 
   auto X = Tokens.size() > 3 ? First[-1] : nullptr;
-  if (X && X->is(tok::less))
+  auto Y = First[2];
+  if ((X && X->is(tok::less)) || Y->is(tok::less))
 return false;
 
-  auto Y = First[2];
-  if ((!X || X->isNot(tok::kw_operator)) && Y->is(tok::less))
+  // Do not remove a whitespace between the two "<" e.g. "operator< <>".
+  if (X && X->is(tok::kw_operator) && Y->is(tok::greater))
 return false;
 
   First[0]->Tok.setKind(tok::lessless);
@@ -476,30 +475,6 @@ bool FormatTokenLexer::tryMergeLessLess() {
   return true;
 }
 
-bool FormatTokenLexer::tryMergeGreaterGreater() {
-  // Merge kw_operator,greater,greater into kw_operator,greatergreater.
-  if (Tokens.size() < 2)
-return false;
-
-  auto First = Tokens.end() - 2;
-  if (First[0]->isNot(tok::greater) || First[1]->isNot(tok::greater))
-return false;
-
-  // Only merge if there currently is no whitespace between the first two ">".
-  if (First[1]->hasWhitespaceBefore())
-return false;
-
-  auto Tok = Tokens.size() > 2 ? First[-1] : nullptr;
-  if (Tok && Tok->isNot(tok::kw_operator))
-return false;
-
-  First[0]->Tok.setKind(tok::greatergreater);
-  First[0]->TokenText = ">>";
-  First[0]->ColumnWidth += 1;
-  Tokens.erase(Tokens.end() - 1);
-  return true;
-}
-
 bool FormatTokenLexer::tryMergeTokens(ArrayRef Kinds,
   TokenType NewType) {
   if (Tokens.size() < Kinds.size())

diff  --git a/clang/lib/Format/FormatTokenLexer.h 
b/clang/lib/Format/FormatTokenLexer.h
index 0a8123fed293..950305a37d68 100644
--- a/clang/lib/Format/FormatTokenLexer.h
+++ b/clang/lib/Format/FormatTokenLexer.h
@@ -51,7 +51,6 @@ class FormatTokenLexer {
   void tryMergePreviousTokens();
 
   bool tryMergeLessLess();
-  bool tryMergeGreaterGreater();
   bool tryMergeNSStringLiteral();
   bool tryMergeJSPrivateIdentifier();
   bool tryMergeCSharpStringLiteral();

diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 12beeba7c70c..6b6b9eb8d31d 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -1215,25 +1215,19 @@ class AnnotatingParser {
  !CurrentToken->isOneOf(tok::l_paren, tok::semi, tok::r_paren)) {
 if (CurrentToken->isOneOf(tok::star, tok::amp))
   CurrentToken->setType(TT_PointerOrReference);
-auto Next = CurrentToken->getNextNonComment();
-if (!Next)
-  break;
-if (Next->is(tok::less))
-  next();
-else
-  consumeToken();
-assert(CurrentToken);
-auto Previous = CurrentToken->getPreviousNonComment();
-assert(Previous);
-if (CurrentToken->is(tok::comma) && Previous->isNot(tok::kw_operator))
+consumeToken();
+if (!CurrentToken)
+  continue;
+if (CurrentToken->is(tok::comma) &&
+CurrentToken->Previous->isNot(tok::kw_operator)) {
   break;
-if (Previous->isOneOf(TT_BinaryOperator, TT_UnaryOperator, tok::comma,
-  tok::star, tok::arrow, tok::amp, tok::ampamp) ||
+}
+if (CurrentToken->Previous->isOneOf(TT_BinaryOperator, 
TT_UnaryOperator,
+tok::comma, tok::star, tok::arrow,
+tok::amp, tok::ampamp) ||
 // User defined literal.
-Previous->TokenText.startswith("\"\"")) {
-  Previous->setType(TT_OverloadedOperator);
-  if (CurrentToken->isOneOf(tok::less, tok::greater))
-break;
+  

[PATCH] D146269: MIPS: allow o32 abi with 64bit CPU and 64 abi with 32bit triple

2023-03-20 Thread YunQiang Su via Phabricator via cfe-commits
wzssyqa updated this revision to Diff 506482.

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

https://reviews.llvm.org/D146269

Files:
  clang/lib/Basic/Targets/Mips.cpp
  clang/test/Driver/mips-cpu64abi32.c

Index: clang/test/Driver/mips-cpu64abi32.c
===
--- /dev/null
+++ clang/test/Driver/mips-cpu64abi32.c
@@ -0,0 +1,81 @@
+// Check handling the CPU is 64bit while ABI is O32.
+// when build for MIPS platforms.
+//
+// abi-n32
+// RUN: %clang -c %s -target mips-linux-gnu -mabi=n32 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-ABI-N32 %s
+// CHECK-ABI-N32: abi2
+//
+// abi-64
+// RUN: %clang -c %s -target mips-linux-gnu -mabi=64 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-ABI-64 %s
+// CHECK-ABI-64: ELF64
+//
+//
+// -march=mips3
+// RUN: %clang -c %s -target mips-linux-gnu -march=mips3 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-MIPS-MIPS3 %s
+// CHECK-MIPS-MIPS3: o32, mips3
+//
+// -march=mips4
+// RUN: %clang -c %s -target mips-linux-gnu -march=mips4 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-MIPS-MIPS4 %s
+// CHECK-MIPS-MIPS4: o32, mips4
+//
+// FIXME: MIPS V is not implemented yet.
+//
+// -march=mips64
+/// RUN: %clang -c %s -target mips-linux-gnu -march=mips64 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-MIPS-MIPS64 %s
+// CHECK-MIPS-MIPS64: o32, mips64
+//
+// -march=mips64r2
+/// RUN: %clang -c %s -target mips-linux-gnu -march=mips64r2 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-MIPS-MIPS64R2 %s
+// CHECK-MIPS-MIPS64R2: o32, mips64r2
+//
+// -march=mips64r6
+/// RUN: %clang -c %s -target mips-linux-gnu -march=mips64r6 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-MIPS-MIPS64R6 %s
+// CHECK-MIPS-MIPS64R6: o32, mips64r6
+//
+//
+// mipsisa3
+// RUN: %clang -c %s -target mips64-linux-gnu -march=mips3 -mabi=32 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-MIPS-MIPSISA3 %s
+// CHECK-MIPS-MIPSISA3: o32, mips3
+//
+// mipsisa4
+// RUN: %clang -c %s -target mips64-linux-gnu -march=mips4 -mabi=32 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-MIPS-MIPSISA4 %s
+// CHECK-MIPS-MIPSISA4: o32, mips4
+//
+// FIXME: MIPS V is not implemented yet.
+//
+// mipsisa64
+/// RUN: %clang -c %s -target mips64-linux-gnu -march=mips64 -mabi=32 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-MIPS-MIPSISA64 %s
+// CHECK-MIPS-MIPSISA64: o32, mips64
+//
+// mipsisa64r2
+/// RUN: %clang -c %s -target mips64-linux-gnu -march=mips64r2 -mabi=32 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-MIPS-MIPSISA64R2 %s
+// CHECK-MIPS-MIPSISA64R2: o32, mips64r2
+//
+// mipsisa64r6
+/// RUN: %clang -c %s -target mips64-linux-gnu -march=mips64r6 -mabi=32 -o - \
+// RUN:   | llvm-readelf -h - \
+// RUN:   | FileCheck --check-prefix=CHECK-MIPS-MIPSISA64R6 %s
+// CHECK-MIPS-MIPSISA64R6: o32, mips64r6
+//
Index: clang/lib/Basic/Targets/Mips.cpp
===
--- clang/lib/Basic/Targets/Mips.cpp
+++ clang/lib/Basic/Targets/Mips.cpp
@@ -238,12 +238,6 @@
 Diags.Report(diag::err_target_unsupported_cpu_for_micromips) << CPU;
 return false;
   }
-  // FIXME: It's valid to use O32 on a 64-bit CPU but the backend can't handle
-  //this yet. It's better to fail here than on the backend assertion.
-  if (processorSupportsGPR64() && ABI == "o32") {
-Diags.Report(diag::err_target_unsupported_abi) << ABI << CPU;
-return false;
-  }
 
   // 64-bit ABI's require 64-bit CPU's.
   if (!processorSupportsGPR64() && (ABI == "n32" || ABI == "n64")) {
@@ -251,24 +245,6 @@
 return false;
   }
 
-  // FIXME: It's valid to use O32 on a mips64/mips64el triple but the backend
-  //can't handle this yet. It's better to fail here than on the
-  //backend assertion.
-  if (getTriple().isMIPS64() && ABI == "o32") {
-Diags.Report(diag::err_target_unsupported_abi_for_triple)
-<< ABI << getTriple().str();
-return false;
-  }
-
-  // FIXME: It's valid to use N32/N64 on a mips/mipsel triple but the backend
-  //can't handle this yet. It's better to fail here than on the
-  //backend assertion.
-  if (getTriple().isMIPS32() && (ABI == "n32" || ABI == "n64")) {
-Diags.Report(diag::err_target_unsupported_abi_for_triple)
-<< ABI << getTriple().str();
-return false;
-  }
-
   // -fpxx is valid only for the o32 ABI
   if (FPMode == FPXX && (ABI == "n32" || ABI == "n64")) {
 Diags.Report(diag::err_unsupported_abi_for_opt) << "-mfpxx" << "o32";
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h

[PATCH] D146269: MIPS: allow o32 abi with 64bit CPU and 64 abi with 32bit triple

2023-03-20 Thread YunQiang Su via Phabricator via cfe-commits
wzssyqa added a comment.

In D146269#4201150 , @jrtc27 wrote:

> Tests?

Added.


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

https://reviews.llvm.org/D146269

___
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

2023-03-20 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
kadircet added a reviewer: hokein.
Herald added a subscriber: arphaman.
Herald added a project: All.
kadircet requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added projects: clang, clang-tools-extra.

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


Repository:
  rG LLVM Github Monorepo

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
@@ -212,17 +212,38 @@
 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());
-
-  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));
+  {
+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));
+  }
+
+  // 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);
+auto Results = analyze({}, {}, PP.Includes, &PI, AST.sourceManager(),
+   AST.preprocessor().getHeaderSearchInfo());
+
+const Include *Private = PP.Includes.atLine(2);
+ASSERT_EQ(Private->Spelled, "private.h");
+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("<>\"");
+   

[PATCH] D146377: [clangd] Remove reundant use of getSpellingLoc()

2023-03-20 Thread 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!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146377

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


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

2023-03-20 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder created this revision.
tbaeder added reviewers: aaron.ballman, erichkeane, tahonermann, shafik.
Herald added a project: All.
tbaeder requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Trying a different approach here where I split the implementation into smaller 
patches so they are easier to review.


Repository:
  rG LLVM Github Monorepo

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

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->emitArrayElemPtrPopUint8(E);
+  }
   case UO_Extension:
   case UO_Coawait:
 assert(false && "Unhandled opcode");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D139010: [clang][WebAssembly] Implement support for table types and builtins

2023-03-20 Thread Paulo Matos via Phabricator via cfe-commits
pmatos updated this revision to Diff 506499.
pmatos added a comment.

Rebase on main.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139010

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Type.cpp
  clang/lib/Basic/Targets/WebAssembly.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGValue.h
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExceptionSpec.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/WebAssembly/builtins-table.c
  clang/test/CodeGen/WebAssembly/table.c
  clang/test/Sema/builtins-wasm.c
  clang/test/Sema/wasm-refs.c
  clang/test/SemaCXX/wasm-refs-and-tables.cpp
  clang/test/SemaCXX/wasm-refs.cpp
  llvm/include/llvm/CodeGen/WasmAddressSpaces.h
  llvm/include/llvm/IR/Type.h
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.cpp
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp

Index: llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp
@@ -62,8 +62,9 @@
   for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I) {
 PtrToIntInst *PTI = dyn_cast(&*I);
 IntToPtrInst *ITP = dyn_cast(&*I);
-if (!(PTI && WebAssembly::isRefType(PTI->getPointerOperand()->getType())) &&
-!(ITP && WebAssembly::isRefType(ITP->getDestTy(
+if (!(PTI &&
+  PTI->getPointerOperand()->getType()->isWebAssemblyReferenceType()) &&
+!(ITP && ITP->getDestTy()->isWebAssemblyReferenceType()))
   continue;
 
 UndefValue *U = UndefValue::get(I->getType());
Index: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
@@ -1202,7 +1202,7 @@
   // Lastly, if this is a call to a funcref we need to add an instruction
   // table.set to the chain and transform the call.
   if (CLI.CB &&
-  WebAssembly::isFuncrefType(CLI.CB->getCalledOperand()->getType())) {
+  CLI.CB->getCalledOperand()->getType()->isWebAssemblyFuncrefType()) {
 // In the absence of function references proposal where a funcref call is
 // lowered to call_ref, using reference types we generate a table.set to set
 // the funcref to a special table used solely for this purpose, followed by
Index: llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
===
--- llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
+++ llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
@@ -27,43 +27,6 @@
 
 namespace WebAssembly {
 
-enum WasmAddressSpace : unsigned {
-  // Default address space, for pointers to linear memory (stack, heap, data).
-  WASM_ADDRESS_SPACE_DEFAULT = 0,
-  // A non-integral address space for pointers to named objects outside of
-  // linear memory: WebAssembly globals or WebAssembly locals.  Loads and stores
-  // to these pointers are lowered to global.get / global.set or local.get /
-  // local.set, as appropriate.
-  WASM_ADDRESS_SPACE_VAR = 1,
-  // A non-integral address space for externref values
-  WASM_ADDRESS_SPACE_EXTERNREF = 10,
-  // A non-integral address space for funcref values
-  WASM_ADDRESS_SPACE_FUNCREF = 20,
-};
-
-inline bool isDefaultAddressSpace(unsigned AS) {
-  return AS == WASM_ADDRESS_SPACE_DEFAULT;
-}
-inline bool isWasmVarAddressSpace(unsigned AS) {
-  return AS == WASM_ADDRESS_SPACE_VAR;
-}
-inline bool isValidAddressSpace(unsigned AS) {
-  return isDefaultAddressSpace(AS) || isWasmVarAddressSpace(AS);
-}
-inline bool isFuncrefType(const Type *Ty) {
-  return isa(Ty) &&
- Ty->getPointerAddressSpace() ==
- WasmAddressSpace::WASM_ADDRESS_SPACE_FUNCREF;
-}
-inline bool isExternrefType(const Type *Ty) {
-  return isa(Ty) &&
- Ty->getPointerAddressSpace() ==
- WasmAddressSpace::WASM_ADDRESS_SPACE_EXTERNREF;
-}
-inline bool isRefType(const Type *Ty) {
-  return isFuncrefType(Ty) || isExternrefType(Ty);
-}
-
 // Convert StringRef to ValType / HealType / BlockType
 
 MVT parseMVT(StringRef Type);
Index: llvm/lib/Target/

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

2023-03-20 Thread Martin Böhme via Phabricator via cfe-commits
mboehme updated this revision to Diff 506507.
mboehme added a comment.

Changes in response to review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145581

Files:
  clang-tools-extra/clang-tidy/utils/ExprSequence.cpp
  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
@@ -1,3 +1,4 @@
+// RUN: %check_clang_tidy -std=c++11 -check-suffixes=,CXX11 %s 
bugprone-use-after-move %t -- -- -fno-delayed-template-parsing
 // RUN: %check_clang_tidy -std=c++17-or-later %s bugprone-use-after-move %t -- 
-- -fno-delayed-template-parsing
 
 typedef decltype(nullptr) nullptr_t;
@@ -123,6 +124,7 @@
   A &operator=(A &&);
 
   void foo() const;
+  void bar(int i) const;
   int getInt() const;
 
   operator bool() const;
@@ -1307,6 +1309,30 @@
   }
 }
 
+// In a function call, the expression that determines the callee is sequenced
+// before the arguments -- but only in C++17 and later.
+namespace CalleeSequencedBeforeArguments {
+int consumeA(std::unique_ptr a);
+
+void calleeSequencedBeforeArguments() {
+  {
+std::unique_ptr a;
+a->bar(consumeA(std::move(a)));
+// CHECK-NOTES-CXX11: [[@LINE-1]]:5: warning: 'a' used after it was moved
+// CHECK-NOTES-CXX11: [[@LINE-2]]:21: note: move occurred here
+// CHECK-NOTES-CXX11: [[@LINE-3]]:5: note: the use and move are unsequenced
+  }
+  {
+std::unique_ptr a;
+std::unique_ptr getArg(std::unique_ptr a);
+getArg(std::move(a))->bar(a->getInt());
+// CHECK-NOTES: [[@LINE-1]]:31: warning: 'a' used after it was moved
+// CHECK-NOTES: [[@LINE-2]]:12: note: move occurred here
+// CHECK-NOTES-CXX11: [[@LINE-3]]:31: note: the use and move are 
unsequenced
+  }
+}
+} // namespace CalleeSequencedBeforeArguments
+
 // Some statements in templates (e.g. null, break and continue statements) may
 // be shared between the uninstantiated and instantiated versions of the
 // template and therefore have multiple parents. Make sure the sequencing code
Index: clang-tools-extra/clang-tidy/utils/ExprSequence.cpp
===
--- clang-tools-extra/clang-tidy/utils/ExprSequence.cpp
+++ clang-tools-extra/clang-tidy/utils/ExprSequence.cpp
@@ -95,9 +95,29 @@
   return true;
   }
 
+  SmallVector BeforeParents = getParentStmts(Before, Context);
+
+  // Since C++17, the callee of a call expression is guaranteed to be sequenced
+  // before all of the arguments.
+  // We handle this as a special case rather than using the general
+  // `getSequenceSuccessor` logic above because the callee expression doesn't
+  // have an unambiguous successor; the order in which arguments are evaluated
+  // is indeterminate.
+  if (Context->getLangOpts().CPlusPlus17) {
+for (const Stmt *Parent : BeforeParents) {
+  if (const auto *call = dyn_cast(Parent);
+  call && call->getCallee() == Before) {
+for (const Expr *arg : call->arguments()) {
+  if (isDescendantOrEqual(After, arg, Context))
+return true;
+}
+  }
+}
+  }
+
   // If 'After' is a parent of 'Before' or is sequenced after one of these
   // parents, we know that it is sequenced after 'Before'.
-  for (const Stmt *Parent : getParentStmts(Before, Context)) {
+  for (const Stmt *Parent : BeforeParents) {
 if (Parent == After || inSequence(Parent, After))
   return true;
   }


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
@@ -1,3 +1,4 @@
+// RUN: %check_clang_tidy -std=c++11 -check-suffixes=,CXX11 %s bugprone-use-after-move %t -- -- -fno-delayed-template-parsing
 // RUN: %check_clang_tidy -std=c++17-or-later %s bugprone-use-after-move %t -- -- -fno-delayed-template-parsing
 
 typedef decltype(nullptr) nullptr_t;
@@ -123,6 +124,7 @@
   A &operator=(A &&);
 
   void foo() const;
+  void bar(int i) const;
   int getInt() const;
 
   operator bool() const;
@@ -1307,6 +1309,30 @@
   }
 }
 
+// In a function call, the expression that determines the callee is sequenced
+// before the arguments -- but only in C++17 and later.
+namespace CalleeSequencedBeforeArguments {
+int consumeA(std::unique_ptr a);
+
+void calleeSequencedBeforeArguments() {
+  {
+std::unique_ptr a;
+a->bar(consumeA(std::move(a)));
+// CHECK-NOTES-CXX11: [[@LINE-1]]:5: warning: 'a' used after it was moved
+// CHECK-NOTES-CXX11: [[@LINE-2]]:21: note: move occurred here
+

[PATCH] D143755: [clang-format] Add a space between an overloaded operator and '>'

2023-03-20 Thread Owen Pan via Phabricator via cfe-commits
owenpan added a comment.

@kadircet thanks for reporting the crash and reverting the commit. I will fix 
it and reland the patch.




Comment at: clang/lib/Format/TokenAnnotator.cpp:1229
+  consumeToken();
+assert(CurrentToken);
+auto Previous = CurrentToken->getPreviousNonComment();

After `next()` or `consumeToken()`, `CurrentToken` would advance and could 
become null.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143755

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


[PATCH] D144987: [clang][dataflow] Fix missed fields in field set construction.

2023-03-20 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added inline comments.



Comment at: 
clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp:141
+ };
+ S foo();
+  )cc";

Is `foo()` used for anything in this test?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144987

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

2023-03-20 Thread Martin Böhme via Phabricator via cfe-commits
mboehme updated this revision to Diff 506510.
mboehme added a comment.

Added entry to release notes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145581

Files:
  clang-tools-extra/clang-tidy/utils/ExprSequence.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
@@ -1,3 +1,4 @@
+// RUN: %check_clang_tidy -std=c++11 -check-suffixes=,CXX11 %s bugprone-use-after-move %t -- -- -fno-delayed-template-parsing
 // RUN: %check_clang_tidy -std=c++17-or-later %s bugprone-use-after-move %t -- -- -fno-delayed-template-parsing
 
 typedef decltype(nullptr) nullptr_t;
@@ -123,6 +124,7 @@
   A &operator=(A &&);
 
   void foo() const;
+  void bar(int i) const;
   int getInt() const;
 
   operator bool() const;
@@ -1307,6 +1309,30 @@
   }
 }
 
+// In a function call, the expression that determines the callee is sequenced
+// before the arguments -- but only in C++17 and later.
+namespace CalleeSequencedBeforeArguments {
+int consumeA(std::unique_ptr a);
+
+void calleeSequencedBeforeArguments() {
+  {
+std::unique_ptr a;
+a->bar(consumeA(std::move(a)));
+// CHECK-NOTES-CXX11: [[@LINE-1]]:5: warning: 'a' used after it was moved
+// CHECK-NOTES-CXX11: [[@LINE-2]]:21: note: move occurred here
+// CHECK-NOTES-CXX11: [[@LINE-3]]:5: note: the use and move are unsequenced
+  }
+  {
+std::unique_ptr a;
+std::unique_ptr getArg(std::unique_ptr a);
+getArg(std::move(a))->bar(a->getInt());
+// CHECK-NOTES: [[@LINE-1]]:31: warning: 'a' used after it was moved
+// CHECK-NOTES: [[@LINE-2]]:12: note: move occurred here
+// CHECK-NOTES-CXX11: [[@LINE-3]]:31: note: the use and move are unsequenced
+  }
+}
+} // namespace CalleeSequencedBeforeArguments
+
 // Some statements in templates (e.g. null, break and continue statements) may
 // be shared between the uninstantiated and instantiated versions of the
 // template and therefore have multiple parents. Make sure the sequencing code
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -219,9 +219,12 @@
   ` check when warning would be
   emitted in constructor for virtual base class initialization.
 
-- Improved :doc:`bugprone-use-after-move
-  ` to understand that there is a
-  sequence point between designated initializers.
+- In :doc:`bugprone-use-after-move
+  `:
+  - Fixed handling for designated initializers.
+  - Fix: In C++17 and later, the callee of a function is guaranteed to be
+sequenced before the arguments, so don't warn if the use happens in the
+callee and the move happens in one of the arguments.
 
 Removed checks
 ^^
Index: clang-tools-extra/clang-tidy/utils/ExprSequence.cpp
===
--- clang-tools-extra/clang-tidy/utils/ExprSequence.cpp
+++ clang-tools-extra/clang-tidy/utils/ExprSequence.cpp
@@ -95,9 +95,29 @@
   return true;
   }
 
+  SmallVector BeforeParents = getParentStmts(Before, Context);
+
+  // Since C++17, the callee of a call expression is guaranteed to be sequenced
+  // before all of the arguments.
+  // We handle this as a special case rather than using the general
+  // `getSequenceSuccessor` logic above because the callee expression doesn't
+  // have an unambiguous successor; the order in which arguments are evaluated
+  // is indeterminate.
+  if (Context->getLangOpts().CPlusPlus17) {
+for (const Stmt *Parent : BeforeParents) {
+  if (const auto *call = dyn_cast(Parent);
+  call && call->getCallee() == Before) {
+for (const Expr *arg : call->arguments()) {
+  if (isDescendantOrEqual(After, arg, Context))
+return true;
+}
+  }
+}
+  }
+
   // If 'After' is a parent of 'Before' or is sequenced after one of these
   // parents, we know that it is sequenced after 'Before'.
-  for (const Stmt *Parent : getParentStmts(Before, Context)) {
+  for (const Stmt *Parent : BeforeParents) {
 if (Parent == After || inSequence(Parent, After))
   return true;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 28997fe - [LLVM][OHOS] Clang toolchain and targets

2023-03-20 Thread Pavel Kosov via cfe-commits

Author: Pavel Kosov
Date: 2023-03-20T12:53:24+03:00
New Revision: 28997feb0c3ac243cb5cc89d7682993e23463ca7

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

LOG: [LLVM][OHOS] Clang toolchain and targets

Add a clang part of OpenHarmony target

Related LLVM part: D138202

~~~

Huawei RRI, OS Lab

Reviewed By: DavidSpickett

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

Added: 
clang/lib/Driver/ToolChains/OHOS.cpp
clang/lib/Driver/ToolChains/OHOS.h
clang/test/Driver/Inputs/ohos_native_tree/llvm/bin/.keep
clang/test/Driver/Inputs/ohos_native_tree/llvm/include/c++/v1/.keep

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/libc++.so

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/a7_soft/libc++.so

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/libc++.so

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/c++/a7_hard_neon-vfpv4/libc++.so

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/c++/a7_soft/libc++.so

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/c++/a7_softfp_neon-vfpv4/libc++.so
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/libc++.so

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/.keep

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/.keep

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/clang_rt.crtbegin.o

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/clang_rt.crtend.o

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/libclang_rt.builtins.a

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/libclang_rt.profile.a

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_soft/.keep

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_soft/clang_rt.crtbegin.o

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_soft/clang_rt.crtend.o

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_soft/libclang_rt.builtins.a

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_soft/libclang_rt.profile.a

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/.keep

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/clang_rt.crtbegin.o

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/clang_rt.crtend.o

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/libclang_rt.builtins.a

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/libclang_rt.profile.a

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/clang_rt.crtbegin.o

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/clang_rt.crtend.o

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/libclang_rt.builtins.a

clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/libclang_rt.profile.a
clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/include/.keep

clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/include/arm-liteos-ohos/.keep
clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/lib/.keep

clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/lib/arm-liteos-ohos/.keep

clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/.keep

clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/lib/arm-liteos-ohos/a7_soft/.keep

clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/.keep
clang/test/Driver/ohos.c
clang/test/Driver/ohos.cpp
clang/test/Preprocessor/ohos.c

Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Driver/ToolChain.h
clang/lib/Basic/TargetInfo.cpp
clang/lib/Basic/Targets.cpp
clang/lib/Basic/Targets/ARM.cpp
clang/lib/Basic/Targets/OSTargets.h
clang/lib/Basic/Targets/X86.h
clang/lib/CodeGen/ABIInfo.h
clang/lib/CodeGen/TargetInfo.cpp
clang/lib/Driver/CMakeLists.txt
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/lib/Driver/ToolChains/Arch/ARM.cpp
c

[PATCH] D145227: [LLVM][OHOS] Clang toolchain and targets

2023-03-20 Thread Pavel Kosov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG28997feb0c3a: [LLVM][OHOS] Clang toolchain and targets 
(authored by kpdev42).
Herald added a subscriber: asb.

Changed prior to commit:
  https://reviews.llvm.org/D145227?vs=504994&id=506511#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145227

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/ABIInfo.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/OHOS.cpp
  clang/lib/Driver/ToolChains/OHOS.h
  clang/test/CodeGen/aarch64-fix-cortex-a53-835769.c
  clang/test/Driver/Inputs/ohos_native_tree/llvm/bin/.keep
  clang/test/Driver/Inputs/ohos_native_tree/llvm/include/c++/v1/.keep
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/libc++.so
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/a7_soft/libc++.so
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/libc++.so
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/c++/a7_hard_neon-vfpv4/libc++.so
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/c++/a7_soft/libc++.so
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/c++/a7_softfp_neon-vfpv4/libc++.so
  clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/arm-liteos-ohos/libc++.so
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/.keep
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/.keep
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/clang_rt.crtbegin.o
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/clang_rt.crtend.o
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/libclang_rt.builtins.a
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/libclang_rt.profile.a
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_soft/.keep
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_soft/clang_rt.crtbegin.o
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_soft/clang_rt.crtend.o
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_soft/libclang_rt.builtins.a
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_soft/libclang_rt.profile.a
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/.keep
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/clang_rt.crtbegin.o
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/clang_rt.crtend.o
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/libclang_rt.builtins.a
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/libclang_rt.profile.a
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/clang_rt.crtbegin.o
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/clang_rt.crtend.o
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/libclang_rt.builtins.a
  
clang/test/Driver/Inputs/ohos_native_tree/llvm/lib/clang/x.y.z/lib/arm-liteos-ohos/libclang_rt.profile.a
  clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/include/.keep
  
clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/include/arm-liteos-ohos/.keep
  clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/lib/.keep
  
clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/lib/arm-liteos-ohos/.keep
  
clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/lib/arm-liteos-ohos/a7_hard_neon-vfpv4/.keep
  
clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/lib/arm-liteos-ohos/a7_soft/.keep
  
clang/test/Driver/Inputs/ohos_native_tree/sysroot/usr/lib/arm-liteos-ohos/a7_softfp_neon-vfpv4/.keep
  clang/test/Driver/ohos.c
  clang/test/Driver/ohos.cpp
  clang/test/Preprocessor/ohos.c

Index: clang/test/Preprocessor/ohos.c

[PATCH] D145906: [clang-tidy] Correctly handle evaluation order of designated initializers.

2023-03-20 Thread Martin Böhme via Phabricator via cfe-commits
mboehme added a comment.

In D145906#4198583 , @PiotrZSL wrote:

> Regarding release-notes:
> I would probably wrote something like "fixed handling for designated 
> initializers", nonene will understand things like "sequence point".

Thanks, makes sense.

I've got another fix for the same checker in the pipeline anyway, so I've 
decided to roll this rewording into that patch: https://reviews.llvm.org/D145581

> If you decide to change this, the just commit this as an [NFC] without review.
> And checks in this section should be in alphabetical order (so this one 
> shouldn't be at the end), but that's a different story that can be corrected 
> later for all those entrys.

Right, I remember that too now...

As there are other entries that are also out of order, I'll just leave this 
where it is for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145906

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


[PATCH] D145227: [LLVM][OHOS] Clang toolchain and targets

2023-03-20 Thread Pavel Kosov via Phabricator via cfe-commits
kpdev42 added a comment.

In D145227#4192628 , @DavidSpickett 
wrote:

> Also failing on our Windows on Arm bot: 
> https://lab.llvm.org/buildbot/#/builders/65/builds/8607
>
> I think some lines need to account for Windows slashes, `{{/|}}` should 
> do that.

Yes, sorry... Fixed 
https://github.com/llvm/llvm-project/commit/28997feb0c3ac243cb5cc89d7682993e23463ca7


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145227

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


[clang] 682808d - Reland [clang-format] Add a space between an overloaded operator and '>'

2023-03-20 Thread Owen Pan via cfe-commits

Author: Owen Pan
Date: 2023-03-20T03:01:22-07:00
New Revision: 682808d9c9c81306c0a08a1fdb496b4f572566b4

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

LOG: Reland [clang-format] Add a space between an overloaded operator and '>'

The token annotator doesn't annotate the template opener and closer
as such if they enclose an overloaded operator. This causes the
space between the operator and the closer to be removed, resulting
in invalid C++ code.

Fixes #58602.

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

Added: 


Modified: 
clang/lib/Format/FormatTokenLexer.cpp
clang/lib/Format/FormatTokenLexer.h
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp
clang/unittests/Format/TokenAnnotatorTest.cpp

Removed: 




diff  --git a/clang/lib/Format/FormatTokenLexer.cpp 
b/clang/lib/Format/FormatTokenLexer.cpp
index f06f9fb9949d..ae54de93daf5 100644
--- a/clang/lib/Format/FormatTokenLexer.cpp
+++ b/clang/lib/Format/FormatTokenLexer.cpp
@@ -103,6 +103,8 @@ void FormatTokenLexer::tryMergePreviousTokens() {
 return;
   if (tryMergeLessLess())
 return;
+  if (tryMergeGreaterGreater())
+return;
   if (tryMergeForEach())
 return;
   if (Style.isCpp() && tryTransformTryUsageForC())
@@ -460,12 +462,11 @@ bool FormatTokenLexer::tryMergeLessLess() {
 return false;
 
   auto X = Tokens.size() > 3 ? First[-1] : nullptr;
-  auto Y = First[2];
-  if ((X && X->is(tok::less)) || Y->is(tok::less))
+  if (X && X->is(tok::less))
 return false;
 
-  // Do not remove a whitespace between the two "<" e.g. "operator< <>".
-  if (X && X->is(tok::kw_operator) && Y->is(tok::greater))
+  auto Y = First[2];
+  if ((!X || X->isNot(tok::kw_operator)) && Y->is(tok::less))
 return false;
 
   First[0]->Tok.setKind(tok::lessless);
@@ -475,6 +476,30 @@ bool FormatTokenLexer::tryMergeLessLess() {
   return true;
 }
 
+bool FormatTokenLexer::tryMergeGreaterGreater() {
+  // Merge kw_operator,greater,greater into kw_operator,greatergreater.
+  if (Tokens.size() < 2)
+return false;
+
+  auto First = Tokens.end() - 2;
+  if (First[0]->isNot(tok::greater) || First[1]->isNot(tok::greater))
+return false;
+
+  // Only merge if there currently is no whitespace between the first two ">".
+  if (First[1]->hasWhitespaceBefore())
+return false;
+
+  auto Tok = Tokens.size() > 2 ? First[-1] : nullptr;
+  if (Tok && Tok->isNot(tok::kw_operator))
+return false;
+
+  First[0]->Tok.setKind(tok::greatergreater);
+  First[0]->TokenText = ">>";
+  First[0]->ColumnWidth += 1;
+  Tokens.erase(Tokens.end() - 1);
+  return true;
+}
+
 bool FormatTokenLexer::tryMergeTokens(ArrayRef Kinds,
   TokenType NewType) {
   if (Tokens.size() < Kinds.size())

diff  --git a/clang/lib/Format/FormatTokenLexer.h 
b/clang/lib/Format/FormatTokenLexer.h
index 950305a37d68..0a8123fed293 100644
--- a/clang/lib/Format/FormatTokenLexer.h
+++ b/clang/lib/Format/FormatTokenLexer.h
@@ -51,6 +51,7 @@ class FormatTokenLexer {
   void tryMergePreviousTokens();
 
   bool tryMergeLessLess();
+  bool tryMergeGreaterGreater();
   bool tryMergeNSStringLiteral();
   bool tryMergeJSPrivateIdentifier();
   bool tryMergeCSharpStringLiteral();

diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 6b6b9eb8d31d..c5644c5bfea1 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -1215,19 +1215,26 @@ class AnnotatingParser {
  !CurrentToken->isOneOf(tok::l_paren, tok::semi, tok::r_paren)) {
 if (CurrentToken->isOneOf(tok::star, tok::amp))
   CurrentToken->setType(TT_PointerOrReference);
-consumeToken();
+auto Next = CurrentToken->getNextNonComment();
+if (!Next)
+  break;
+if (Next->is(tok::less))
+  next();
+else
+  consumeToken();
 if (!CurrentToken)
-  continue;
-if (CurrentToken->is(tok::comma) &&
-CurrentToken->Previous->isNot(tok::kw_operator)) {
   break;
-}
-if (CurrentToken->Previous->isOneOf(TT_BinaryOperator, 
TT_UnaryOperator,
-tok::comma, tok::star, tok::arrow,
-tok::amp, tok::ampamp) ||
+auto Previous = CurrentToken->getPreviousNonComment();
+assert(Previous);
+if (CurrentToken->is(tok::comma) && Previous->isNot(tok::kw_operator))
+  break;
+if (Previous->isOneOf(TT_BinaryOperator, TT_UnaryOperator, tok::comma,
+  tok::star, tok::arrow, tok::amp, tok::ampamp) ||
 // User defined literal.
-CurrentToken->Previous->TokenText.startswith("\"

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

2023-03-20 Thread Martin Böhme via Phabricator via cfe-commits
mboehme added a comment.

Sorry for the delay in replying -- I was caught up in other projects.




Comment at: clang-tools-extra/docs/ReleaseNotes.rst:224
+  `:
+  - Fixed handling for designated initializers.
+  - Fix: In C++17 and later, the callee of a function is guaranteed to be

Reworded according to comments in https://reviews.llvm.org/D145906.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp:1296
 
+// In a function call, the expression that determines the callee is sequenced
+// before the arguments.

PiotrZSL wrote:
> This entire file tests only C++17 and later, when std::move is C++11 feature.
> Add separate test file for C++11 (or even better split this one between C++11 
> and C++17)
> 
> Scenario to test in C++11, should warn ?
> ```
> a->foo(std::move(a));
> ```
> This entire file tests only C++17 and later, when std::move is C++11 feature.
> Add separate test file for C++11 (or even better split this one between C++11 
> and C++17)

Good point. I've added a new `RUN` line that also runs this in C++11 mode.

> Scenario to test in C++11, should warn ?

See below -- this does produce a warning in C++11 mode (but not C++17 mode).

I've also redone the tests to reuse the existing class `A` without having to 
define a new one.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp:1304
+  std::unique_ptr a;
+  a->foo(std::move(a));
+}

PiotrZSL wrote:
> What about scenario like this:
> 
> ```
> b.foo(a->saveBIntoAAndReturnBool(std::move(b)));
> ```
> 
> Is first "b" still guaranteed to be alive after std::move ?
I'm not exactly sure what you're asking here... or how this scenario is 
materially different from the other scenarios we already have?

> Is first "b" still guaranteed to be alive after std::move ?

The `b` in `b.foo` is guaranteed to be evaluated before the call 
`a->saveBIntoAAndReturnBool(std::move(b))` -- but I'm not sure if this is what 
you're asking?

Or are you asking whether the `a->saveBIntoAAndReturnBool(std::move(b))` can 
cause the underlying object to be destroyed before the call to `b.foo` 
happenss? In other words, do we potentially have a use-after-free here?

I think the answer to this depends on what exactly `saveBIntoAAndReturnBool()` 
does (what was your intent here?). I also think it's probably beyond the scope 
of this check in any case, as this check is about diagnosing use-after-move, 
not use-after-free.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp:1305
+  a->foo(std::move(a));
+}
+} // namespace CalleeSequencedBeforeArguments

PiotrZSL wrote:
> I didn't found any test for correct warning in this case:
> 
> ```
> std::unique_ptr getArg(std::unique_ptr);
> getArg(std::move(a))->foo(std::move(a));
> ```
Good point -- added below (in slightly different form, but testing the same 
thing).

Note that this is an error in both C++11 and C++17, but in C++11 the use and 
move are unsequenced, whereas in C++17 the use definitely comes after the move.


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


[PATCH] D146396: [clang-tidy] Use checks dependences for Analyzer checks

2023-03-20 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added a comment.

I have feeling that hidden checks that none other check depend on should be 
enabled by default.
Also I have feeling that those hidden checks shouldn't be visible to end user.
But need to confirm this first with Static Analyser developers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146396

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

2023-03-20 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp:1304
+  std::unique_ptr a;
+  a->foo(std::move(a));
+}

mboehme wrote:
> PiotrZSL wrote:
> > What about scenario like this:
> > 
> > ```
> > b.foo(a->saveBIntoAAndReturnBool(std::move(b)));
> > ```
> > 
> > Is first "b" still guaranteed to be alive after std::move ?
> I'm not exactly sure what you're asking here... or how this scenario is 
> materially different from the other scenarios we already have?
> 
> > Is first "b" still guaranteed to be alive after std::move ?
> 
> The `b` in `b.foo` is guaranteed to be evaluated before the call 
> `a->saveBIntoAAndReturnBool(std::move(b))` -- but I'm not sure if this is 
> what you're asking?
> 
> Or are you asking whether the `a->saveBIntoAAndReturnBool(std::move(b))` can 
> cause the underlying object to be destroyed before the call to `b.foo` 
> happenss? In other words, do we potentially have a use-after-free here?
> 
> I think the answer to this depends on what exactly 
> `saveBIntoAAndReturnBool()` does (what was your intent here?). I also think 
> it's probably beyond the scope of this check in any case, as this check is 
> about diagnosing use-after-move, not use-after-free.
I see this ```b.foo(a->saveBIntoAAndReturnBool(std::move(b)));``` like this:
we call saveBIntoAAndReturnBool, that takes b by std::move, then we call foo on 
already moved object.
For me this is use after move, that's why I was asking.

And in "b.foo" there is almost nothing to evaluate, maybe address of foo, but 
at the end foo will be called on already moved object.
If we would have something like "getSomeObj(b).boo(std::move(b))" then we can 
think about "evaluate", but when we directly call method on moved object, then 
we got use after move




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


[PATCH] D139010: [clang][WebAssembly] Implement support for table types and builtins

2023-03-20 Thread Paulo Matos via Phabricator via cfe-commits
pmatos updated this revision to Diff 506521.
pmatos added a comment.

Remove references to table subscript. Simplify patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139010

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Type.cpp
  clang/lib/Basic/Targets/WebAssembly.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExceptionSpec.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/WebAssembly/builtins-table.c
  clang/test/Sema/builtins-wasm.c
  clang/test/Sema/wasm-refs.c
  clang/test/SemaCXX/wasm-refs-and-tables.cpp
  clang/test/SemaCXX/wasm-refs.cpp
  llvm/include/llvm/CodeGen/WasmAddressSpaces.h
  llvm/include/llvm/IR/Type.h
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.cpp
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp

Index: llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp
@@ -62,8 +62,9 @@
   for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I) {
 PtrToIntInst *PTI = dyn_cast(&*I);
 IntToPtrInst *ITP = dyn_cast(&*I);
-if (!(PTI && WebAssembly::isRefType(PTI->getPointerOperand()->getType())) &&
-!(ITP && WebAssembly::isRefType(ITP->getDestTy(
+if (!(PTI &&
+  PTI->getPointerOperand()->getType()->isWebAssemblyReferenceType()) &&
+!(ITP && ITP->getDestTy()->isWebAssemblyReferenceType()))
   continue;
 
 UndefValue *U = UndefValue::get(I->getType());
Index: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
@@ -1202,7 +1202,7 @@
   // Lastly, if this is a call to a funcref we need to add an instruction
   // table.set to the chain and transform the call.
   if (CLI.CB &&
-  WebAssembly::isFuncrefType(CLI.CB->getCalledOperand()->getType())) {
+  CLI.CB->getCalledOperand()->getType()->isWebAssemblyFuncrefType()) {
 // In the absence of function references proposal where a funcref call is
 // lowered to call_ref, using reference types we generate a table.set to set
 // the funcref to a special table used solely for this purpose, followed by
Index: llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
===
--- llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
+++ llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
@@ -27,43 +27,6 @@
 
 namespace WebAssembly {
 
-enum WasmAddressSpace : unsigned {
-  // Default address space, for pointers to linear memory (stack, heap, data).
-  WASM_ADDRESS_SPACE_DEFAULT = 0,
-  // A non-integral address space for pointers to named objects outside of
-  // linear memory: WebAssembly globals or WebAssembly locals.  Loads and stores
-  // to these pointers are lowered to global.get / global.set or local.get /
-  // local.set, as appropriate.
-  WASM_ADDRESS_SPACE_VAR = 1,
-  // A non-integral address space for externref values
-  WASM_ADDRESS_SPACE_EXTERNREF = 10,
-  // A non-integral address space for funcref values
-  WASM_ADDRESS_SPACE_FUNCREF = 20,
-};
-
-inline bool isDefaultAddressSpace(unsigned AS) {
-  return AS == WASM_ADDRESS_SPACE_DEFAULT;
-}
-inline bool isWasmVarAddressSpace(unsigned AS) {
-  return AS == WASM_ADDRESS_SPACE_VAR;
-}
-inline bool isValidAddressSpace(unsigned AS) {
-  return isDefaultAddressSpace(AS) || isWasmVarAddressSpace(AS);
-}
-inline bool isFuncrefType(const Type *Ty) {
-  return isa(Ty) &&
- Ty->getPointerAddressSpace() ==
- WasmAddressSpace::WASM_ADDRESS_SPACE_FUNCREF;
-}
-inline bool isExternrefType(const Type *Ty) {
-  return isa(Ty) &&
- Ty->getPointerAddressSpace() ==
- WasmAddressSpace::WASM_ADDRESS_SPACE_EXTERNREF;
-}
-inline bool isRefType(const Type *Ty) {
-  return isFuncrefType(Ty) || isExternrefType(Ty);
-}
-
 // Convert StringRef to ValType / HealType / BlockType
 
 MVT parseMVT(StringRef Type);
Index: llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.cpp
===

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

2023-03-20 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

Thanks, this looks great, some more comments (most are nits)




Comment at: clang-tools-extra/clangd/Hover.cpp:1099
+  const SourceManager &SM = AST.getSourceManager();
+  llvm::SmallVector Headers =
+  include_cleaner::headersForSymbol(Sym, SM, AST.getPragmaIncludes());

maybe name it `SortedProviders`, it contains the main-file (calling Headers is 
a bit confusing).



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

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...);
```



Comment at: clang-tools-extra/clangd/Hover.h:71
   std::string Name;
+  /// Header providing the symbol (best match).
+  std::string Provider;

nit: mention this header is with `""<>`.



Comment at: clang-tools-extra/clangd/IncludeCleaner.h:71
 
+include_cleaner::Includes
+convertIncludes(const SourceManager &SM,

nit: can you add some document comment on these two functions?



Comment at: clang-tools-extra/clangd/unittests/HoverTests.cpp:2896
+  struct Foo {}; 
+  Foo F = [[Fo^o]]{};
+)cpp"),

looks like `[[]]` is not used in the test, we only use the `^` point. Remove 
them?



Comment at: clang-tools-extra/clangd/unittests/HoverTests.cpp:2897
+  Foo F = [[Fo^o]]{};
+)cpp"),
+[](HoverInfo &HI) { HI.Provider = ""; }},

I think making the indentation like below is cleaer:

```
{Annotations(R"cpp(
   struct Foo {}; 
   int F = [[FO^O]]{};
 )cpp"),
 [](HoverInfo &HI) { HI.Provider = ""; }},
```



Comment at: clang-tools-extra/clangd/unittests/HoverTests.cpp:2911
+#define FOO 5
+int F = [[^FOO]];
+  )cpp"),

The indentation of the code block doesn't seem to align with the above cases. 

Unfortunately, clang-format doesn't format the codeblock inside the `cpp()cpp` 
string literal, we need to do it manually.






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

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.



Comment at: 
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Analysis.h:16
 #include "clang-include-cleaner/Types.h"
+#include "clang/Basic/SourceLocation.h"
 #include "clang/Format/Format.h"

we have been using forward declaration for the `SourceLocation`, we can add a 
forward declaration `class SourceManager` on Line 26, and get rid of the 
#include here.



Comment at: 
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Analysis.h:84
+/// likely provider for the symbol.
+llvm::SmallVector headersForSymbol(const Symbol &S,
+   const SourceManager &SM,

since we move it from `AnalysisInternal.h`, can you remove the one in 
`AnalysisInternal.h`? I think we need to add `#include "Analysis.h"` to 
`AnalysisInternal.h`.


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] D146412: [NFC] Fix potential use-after-free in DumpModuleInfoAction::ExecuteAction()

2023-03-20 Thread Mariya Podchishchaeva via Phabricator via cfe-commits
Fznamznon created this revision.
Herald added a project: All.
Fznamznon requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Since each `DumpModuleInfoAction` can now contain a pointer to a
`raw_ostream`, saving there a poiter that owned by a local `unique_ptr`
may cause use-after-free.
Found by static analyzer.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146412

Files:
  clang/lib/Frontend/FrontendActions.cpp


Index: clang/lib/Frontend/FrontendActions.cpp
===
--- clang/lib/Frontend/FrontendActions.cpp
+++ clang/lib/Frontend/FrontendActions.cpp
@@ -781,13 +781,16 @@
   std::unique_ptr OutFile;
   CompilerInstance &CI = getCompilerInstance();
   StringRef OutputFileName = CI.getFrontendOpts().OutputFile;
+  llvm::raw_ostream *POut = &llvm::outs();
   if (!OutputFileName.empty() && OutputFileName != "-") {
 std::error_code EC;
 OutFile.reset(new llvm::raw_fd_ostream(OutputFileName.str(), EC,
llvm::sys::fs::OF_TextWithCRLF));
-OutputStream = OutFile.get();
+POut = OutFile.get();
+  } else if (OutputStream) {
+POut = OutputStream;
   }
-  llvm::raw_ostream &Out = OutputStream ? *OutputStream : llvm::outs();
+  llvm::raw_ostream &Out = *POut;
 
   Out << "Information for module file '" << getCurrentFile() << "':\n";
   auto &FileMgr = CI.getFileManager();


Index: clang/lib/Frontend/FrontendActions.cpp
===
--- clang/lib/Frontend/FrontendActions.cpp
+++ clang/lib/Frontend/FrontendActions.cpp
@@ -781,13 +781,16 @@
   std::unique_ptr OutFile;
   CompilerInstance &CI = getCompilerInstance();
   StringRef OutputFileName = CI.getFrontendOpts().OutputFile;
+  llvm::raw_ostream *POut = &llvm::outs();
   if (!OutputFileName.empty() && OutputFileName != "-") {
 std::error_code EC;
 OutFile.reset(new llvm::raw_fd_ostream(OutputFileName.str(), EC,
llvm::sys::fs::OF_TextWithCRLF));
-OutputStream = OutFile.get();
+POut = OutFile.get();
+  } else if (OutputStream) {
+POut = OutputStream;
   }
-  llvm::raw_ostream &Out = OutputStream ? *OutputStream : llvm::outs();
+  llvm::raw_ostream &Out = *POut;
 
   Out << "Information for module file '" << getCurrentFile() << "':\n";
   auto &FileMgr = CI.getFileManager();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D142907: LangRef: Add "dynamic" option to "denormal-fp-math"

2023-03-20 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

ping


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

https://reviews.llvm.org/D142907

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


[PATCH] D146417: [clangd] Fix AddUsing in the face of typo-correction

2023-03-20 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
kadircet added a reviewer: hokein.
Herald added a subscriber: arphaman.
Herald added a project: All.
kadircet requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Fixes https://github.com/clangd/clangd/issues/559


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146417

Files:
  clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
  clang-tools-extra/clangd/unittests/tweaks/AddUsingTests.cpp

Index: clang-tools-extra/clangd/unittests/tweaks/AddUsingTests.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/AddUsingTests.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/AddUsingTests.cpp
@@ -8,8 +8,11 @@
 
 #include "Config.h"
 #include "TweakTesting.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringRef.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
+#include 
 
 namespace clang {
 namespace clangd {
@@ -30,7 +33,7 @@
 void oo() {}
 template class tt {};
 namespace two {
-enum ee {};
+enum ee { ee_enum_value };
 void ff() {}
 class cc {
 public:
@@ -64,9 +67,6 @@
   EXPECT_UNAVAILABLE(Header + "void fun() { ::ban::fo^o(); }");
   EXPECT_AVAILABLE(Header + "void fun() { banana::fo^o(); }");
 
-  // Do not offer code action on typo-corrections.
-  EXPECT_UNAVAILABLE(Header + "/*error-ok*/c^c C;");
-
   // NestedNameSpecifier, but no namespace.
   EXPECT_UNAVAILABLE(Header + "class Foo {}; class F^oo foo;");
 
@@ -466,7 +466,37 @@
 using one::vec;
 
 vec foo;
-)cpp"}};
+)cpp"},
+  // Typo correction.
+  {R"cpp(
+// error-ok
+#include "test.hpp"
+c^c C;
+)cpp",
+   R"cpp(
+// error-ok
+#include "test.hpp"
+using one::two::cc;
+
+cc C;
+)cpp"},
+  {R"cpp(
+// error-ok
+#include "test.hpp"
+void foo() {
+  switch(one::two::ee{}) { case two::ee_^one:break; }
+}
+)cpp",
+   R"cpp(
+// error-ok
+#include "test.hpp"
+using one::two::ee_one;
+
+void foo() {
+  switch(one::two::ee{}) { case ee_one:break; }
+}
+)cpp"},
+  };
   llvm::StringMap EditedFiles;
   for (const auto &Case : Cases) {
 ExtraFiles["test.hpp"] = R"cpp(
Index: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
@@ -8,10 +8,25 @@
 
 #include "AST.h"
 #include "Config.h"
+#include "SourceCode.h"
 #include "refactor/Tweak.h"
 #include "support/Logger.h"
 #include "clang/AST/Decl.h"
+#include "clang/AST/Expr.h"
+#include "clang/AST/NestedNameSpecifier.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/Type.h"
+#include "clang/AST/TypeLoc.h"
+#include "clang/Basic/LLVM.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Tooling/Core/Replacement.h"
+#include "clang/Tooling/Syntax/Tokens.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+#include 
+#include 
 
 namespace clang {
 namespace clangd {
@@ -45,8 +60,12 @@
   // All of the following are set by prepare().
   // The qualifier to remove.
   NestedNameSpecifierLoc QualifierToRemove;
-  // The name following QualifierToRemove.
-  llvm::StringRef Name;
+  // Qualified name to use when spelling the using declaration. This might be
+  // different than SpelledQualifier in presence of error correction.
+  std::string QualifierToSpell;
+  // The name and qualifier as spelled in the code.
+  llvm::StringRef SpelledQualifier;
+  llvm::StringRef SpelledName;
   // If valid, the insertion point for "using" statement must come after this.
   // This is relevant when the type is defined in the main file, to make sure
   // the type/function is already defined at the point where "using" is added.
@@ -56,7 +75,7 @@
 
 std::string AddUsing::title() const {
   return std::string(llvm::formatv(
-  "Add using-declaration for {0} and remove qualifier", Name));
+  "Add using-declaration for {0} and remove qualifier", SpelledName));
 }
 
 // Locates all "using" statements relevant to SelectionDeclContext.
@@ -269,36 +288,23 @@
   if (Node == nullptr)
 return false;
 
+  SourceRange SpelledNameRange;
   if (auto *D = Node->ASTNode.get()) {
 if (auto *II = D->getDecl()->getIdentifier()) {
   QualifierToRemove = D->getQualifierLoc();
-  Name = II->getName();
+  SpelledNameRange = D->getSourceRange();
   MustInsertAfterLoc = D->getDecl()->getBeginLoc();
 }
   } else if (auto *T = Node->ASTNode.get()) {
 if (auto E = T->getAs()) {
   QualifierToRemove = E.getQualifierLoc();
-  if (!QualifierToRemove)
-return false;
 
-  auto NameRange = E.getSourceRange();
+  SpelledNameRange = E.getSourceRange();
   if (auto T = E.getNamedTypeLoc().getAs()) {
 // Remove the template arguments from the name.
-NameRange.setEnd(T.get

[PATCH] D146278: [flang] add -flang-experimental-hlfir flag to flang-new

2023-03-20 Thread Tom Eccles via Phabricator via cfe-commits
tblah updated this revision to Diff 506544.
tblah marked 2 inline comments as done.
tblah added a comment.
Herald added subscribers: Moerafaat, zero9178, bzcheeseman, sdasgup3, 
wenzhicui, wrengr, cota, teijeong, rdzhabarov, tatianashp, msifontes, jurahul, 
Kayjukh, grosul1, Joonsoo, stephenneuendorffer, liufengdb, aartbik, mgester, 
arpith-jacob, nicolasvasilache, antiagainst, shauheen, rriddle, mehdi_amini, 
thopre.

Thanks for the review. Changes are as follows:

- Move `createHLFIRToFIRPassPipeline` before `#if 
!defined(FLANG_EXCCLUDE_CODEGEN`
- Only canonicalize HLFIR (creating hlfir.matmul_transpose) if we are 
optimizing for speed
- Unconditionally run HLFIR passes
- Add tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146278

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Tools/CLOptions.inc
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/mlir-pass-pipeline.f90
  flang/test/Fir/basic-program.fir

Index: flang/test/Fir/basic-program.fir
===
--- flang/test/Fir/basic-program.fir
+++ flang/test/Fir/basic-program.fir
@@ -16,7 +16,11 @@
 
 // PASSES: Pass statistics report
 
-// PASSES:  CSE
+// PASSES:Canonicalizer
+// PASSES-NEXT:   LowerHLFIRIntrinsics
+// PASSES-NEXT:   BufferizeHLFIR
+// PASSES-NEXT:   ConvertHLFIRtoFIR
+// PASSES-NEXT:   CSE
 // PASSES-NEXT:   (S) 0 num-cse'd - Number of operations CSE'd
 // PASSES-NEXT:   (S) 0 num-dce'd - Number of operations DCE'd
 
Index: flang/test/Driver/mlir-pass-pipeline.f90
===
--- flang/test/Driver/mlir-pass-pipeline.f90
+++ flang/test/Driver/mlir-pass-pipeline.f90
@@ -12,6 +12,10 @@
 ! ALL: Pass statistics report
 
 ! ALL: Fortran::lower::VerifierPass
+! O2-NEXT: Canonicalizer
+! ALL-NEXT: LowerHLFIRIntrinsics
+! ALL-NEXT: BufferizeHLFIR
+! ALL-NEXT: ConvertHLFIRtoFIR
 ! ALL-NEXT: CSE
 ! Ideally, we need an output with only the pass names, but
 ! there is currently no way to get that, so in order to
Index: flang/test/Driver/driver-help-hidden.f90
===
--- flang/test/Driver/driver-help-hidden.f90
+++ flang/test/Driver/driver-help-hidden.f90
@@ -41,6 +41,8 @@
 ! CHECK-NEXT:Specify where to find the compiled intrinsic modules
 ! CHECK-NEXT: -flang-experimental-exec
 ! CHECK-NEXT:Enable support for generating executables (experimental)
+! CHECK-NEXT: -flang-experimental-hlfir
+! CHECK-NEXT:Use HLFIR lowering (experimental)
 ! CHECK-NEXT: -flarge-sizes  Use INTEGER(KIND=8) for the result type in size-related intrinsics
 ! CHECK-NEXT: -flogical-abbreviations Enable logical abbreviations
 ! CHECK-NEXT: -flto= Set LTO mode
Index: flang/lib/Frontend/CompilerInvocation.cpp
===
--- flang/lib/Frontend/CompilerInvocation.cpp
+++ flang/lib/Frontend/CompilerInvocation.cpp
@@ -818,6 +818,11 @@
 success = false;
   }
 
+  // -flang-experimental-hlfir
+  if (args.hasArg(clang::driver::options::OPT_flang_experimental_hlfir)) {
+res.loweringOpts.setLowerToHighLevelFIR(true);
+  }
+
   success &= parseFrontendArgs(res.getFrontendOpts(), args, diags);
   parseTargetArgs(res.getTargetOpts(), args);
   parsePreprocessorArgs(res.getPreprocessorOpts(), args);
Index: flang/include/flang/Tools/CLOptions.inc
===
--- flang/include/flang/Tools/CLOptions.inc
+++ flang/include/flang/Tools/CLOptions.inc
@@ -14,6 +14,7 @@
 #include "mlir/Transforms/GreedyPatternRewriteDriver.h"
 #include "mlir/Transforms/Passes.h"
 #include "flang/Optimizer/CodeGen/CodeGen.h"
+#include "flang/Optimizer/HLFIR/Passes.h"
 #include "flang/Optimizer/Transforms/Passes.h"
 #include "llvm/Passes/OptimizationLevel.h"
 #include "llvm/Support/CommandLine.h"
@@ -211,6 +212,20 @@
   pm.addPass(mlir::createCSEPass());
 }
 
+/// Create a pass pipeline for lowering from HLFIR to FIR
+///
+/// \param pm - MLIR pass manager that will hold the pipeline definition
+/// \param optLevel - optimization level used for creating FIR optimization
+///   passes pipeline
+inline void createHLFIRToFIRPassPipeline(mlir::PassManager &pm,
+llvm::OptimizationLevel optLevel = defaultOptLevel) {
+  if (optLevel.isOptimizingForSpeed())
+pm.addPass(mlir::createCanonicalizerPass());
+  pm.addPass(hlfir::createLowerHLFIRIntrinsicsPass());
+  pm.addPass(hlfir::createBufferizeHLFIRPass());
+  pm.addPass(hlfir::createConvertHLFIRtoFIRPass());
+}
+
 #if !defined(FLANG_EXCLUDE_CODEGEN)
 inline void createDefaultFIRCodeGenPassPipeline(mlir::PassManager &pm,
 llvm::OptimizationLevel optLevel = defaultOptLevel,
@@ -234,6

[PATCH] D146187: [docs] Update the status for coroutines

2023-03-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D146187#4205271 , @ChuanqiXu wrote:

>> Ugh, that does sort of change the calculus for whether we do or don't claim 
>> support on Windows. If removing the definition of that macro on Windows 
>> causes significant code breakage, that would be a reason we should leave it 
>> defined. But do we have evidence of that?
>
> Ah, yes. This is what I want to say. Simply, if we remove the definition for 
> `__cpp_impl_coroutines`, the coroutine header in MS/STL and libstdc++ can't 
> work anymore. For libstdc++, all the coroutine things are only defined if 
> `__cpp_impl_coroutines ` is defined 
> (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/coroutine#L58-L69).
>  And this is the same for MS/STL: 
> https://github.com/microsoft/STL/blob/5116678ea11245b232a6e43824aad25fb60b9c6e/stl/inc/yvals_core.h#L1587-L1589
>  and 
> https://github.com/microsoft/STL/blob/be29af22c049774ae93f2c33e4eb5d801e12216c/stl/inc/coroutine#L17-L39.
>  So I can image that many uses of coroutines in Windows may get useless after 
> we undefined the `__cpp_impl_coroutines` macros.

Okay, that pretty much paints us into a corner, I guess. If we don't define it 
any longer, we break existing (working) uses of the feature on Windows, but we 
defined it prematurely. In this case, let's leave the macro defined so we don't 
break existing uses -- in the future, I think we should be more conservative 
with defining feature test macros.


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

https://reviews.llvm.org/D146187

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


[PATCH] D146187: [docs] Update the status for coroutines

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

LGTM, thank you!


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

https://reviews.llvm.org/D146187

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

2023-03-20 Thread Haojian Wu via Phabricator via cfe-commits
hokein added inline comments.



Comment at: clang-tools-extra/clangd/Hover.cpp:1141
 
+std::string getRefName(include_cleaner::SymbolReference Ref) {
+  std::string Name;

we have a similar function `symbolName` in include-cleaner's `FindHeaders.cpp`, 
but it is not exposed. I think it would be nice to share the implementation 
(probably add a `name()` method in the `include_cleaner::Symbol` structure). No 
action required, can you add a FIXME here?



Comment at: clang-tools-extra/clangd/Hover.cpp:1145
+  case include_cleaner::Symbol::Declaration:
+Name = llvm::dyn_cast(&Ref.Target.declaration())
+   ->getDeclName()

we need to check whether the dyn_cast is a null



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

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



Comment at: clang-tools-extra/clangd/Hover.cpp:1166
+if (Ref.RT != include_cleaner::RefType::Explicit ||
+!SM.isWrittenInMainFile(SM.getSpellingLoc(Ref.RefLocation))) {
+  return;

the indentation seems wrong here.



Comment at: clang-tools-extra/clangd/Hover.cpp:1171
+for (const include_cleaner::Header &H : Providers) {
+  switch (H.kind()) {
+  case include_cleaner::Header::Physical:

since we expose `convertIncludes` in your previous patch, we can construct a 
`include_cleaner::Includes` struct from the parssing `Inc`, and use the 
`match()` method to match the header.



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

if the UsedSymbolNames.size() > 5, we will show the last element rather than 
the fifth one, my reading of the code this is not intended, right?



Comment at: clang-tools-extra/clangd/Hover.cpp:1449
+P.appendCode((*UsedSymbolNames)[UsedSymbolNames->size() - 1]);
+if (UsedSymbolNames->size() > 5) {
+  P.appendText(" and ");

let's abstract a const variable e.g. `SymbolNamesLimit` for this magic number 
5, and use it in all related places



Comment at: clang-tools-extra/clangd/Hover.h:116
+  // from a #include'd file that are used in the main file.
+  std::optional> UsedSymbolNames;
 

we can use just a vector, we can use `.empty()` to the unused-include case.

`llvm::SmallVector` is preferred, per 
https://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h.



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

the `[[]]` range doesn't seem to be used, remove?



Comment at: clang-tools-extra/clangd/unittests/HoverTests.cpp:3000
+   {Annotations(R"cpp(
+  #include "foo.h"  
+  [[#include ^"bar.h"]]

nit: please fix the code indentation.


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


[PATCH] D144006: [DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (5/7)

2023-03-20 Thread Juan Manuel Martinez Caamaño via Phabricator via cfe-commits
jmmartinez accepted this revision.
jmmartinez added inline comments.
This revision is now accepted and ready to land.



Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:712-714
+  assert(!getAbstractScopeDIEs().count(DS) &&
+ "Abstract DIE for this scope exists!");
+  getAbstractScopeDIEs()[DS] = ScopeDIE;

krisb wrote:
> jmmartinez wrote:
> > NIT: You could use `insert/try_emplace` instead of using `count` and 
> > `operator[]`. The assertion would become something like:
> > ```
> > auto Inserted = getAbstractScopeDIEs().try_emplace(DS, ScopeDIE);
> > assert(Inserted.second && "Abstract DIE for this scope exists!");
> > return ScopeDIE;
> > ```
> I'd slightly prefer to keep the original code as it looks a bit more readable 
> to me (in your example, there should be another line to void out unused 
> `Inserted` variable, otherwise it'd cause a warning). 
> Additional `count()` call in the `assert()` doesn't seem too expensive to me, 
> but if you still think `try_emplace()` is better, I'll change to it.
Ok for me. If the use of count was outside the assert I would have argued 
against.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144006

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


[PATCH] D139010: [clang][WebAssembly] Implement support for table types and builtins

2023-03-20 Thread Paulo Matos via Phabricator via cfe-commits
pmatos added inline comments.



Comment at: clang/test/SemaCXX/wasm-refs-and-tables.cpp:16-17
+__externref_t **t2;  // expected-error {{pointer to WebAssembly 
reference type is not allowed}}
+__externref_t **t3;  // expected-error {{pointer to WebAssembly 
reference type is not allowed}}
+static __externref_t t4[3];  // expected-error {{only zero-length 
WebAssembly tables are currently supported}}
+static __externref_t t5[];   // expected-error {{only zero-length 
WebAssembly tables are currently supported}}

aaron.ballman wrote:
> This seems really... confused. We can't form a pointer to the type, but we 
> can form an array of the type (which decays into a pointer when you sneeze 
> near it, and it's not clear whether that should be allowed or not) so long as 
> it's a zero-length array (which is an extension in C and C++, so do we need 
> to silence pedantic warnings in WASM for this?).
As it stands, tables are declared as static arrays of size zero. Then to access 
them we need to use builtins. No subscripting, no comparison, no pointer decay, 
etc. No passing into functions, returning from functions, etc. Nothing besides 
using them as arguments to wasm_table... builtins.



Comment at: clang/test/SemaCXX/wasm-refs-and-tables.cpp:88
+  varargs(1, table);  // expected-error {{cannot use WebAssembly 
table as a function parameter}}
+  table == 1; // expected-error {{invalid operands to 
binary expression ('__attribute__((address_space(1))) __externref_t[0]' and 
'int')}}
+  1 >= table; // expected-error {{invalid operands to 
binary expression ('int' and '__attribute__((address_space(1))) 
__externref_t[0]')}}

aaron.ballman wrote:
> 
No comparisons are allowed - I have added a few tests to that effect.



Comment at: clang/test/SemaCXX/wasm-refs-and-tables.cpp:95
+  table ? : other_table;  // expected-error {{cannot use a WebAssembly 
table within a branch of a conditional expression}}
+  (void *)table;  // expected-error {{cannot cast from a 
WebAssembly table}}
+  void *u;

aaron.ballman wrote:
> 
(void)table; is allowed.



Comment at: clang/test/SemaCXX/wasm-refs-and-tables.cpp:102
+
+  table[0];
+  table[0] = ref;

aaron.ballman wrote:
> This involves array to pointer decay, so we're forming a pointer to the table 
> here. Why is this pointer fine but others are not?
I have disallowed this to avoid the problems you mention. Table set happens 
only through the builtin wasm_table_set.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139010

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


[PATCH] D139010: [clang][WebAssembly] Implement support for table types and builtins

2023-03-20 Thread Paulo Matos via Phabricator via cfe-commits
pmatos updated this revision to Diff 506552.
pmatos marked 4 inline comments as done.
pmatos added a comment.

Address concerns about table subscripting. Add warnings for that.

Address a few other smaller comments like testing for table comparisons.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139010

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Type.cpp
  clang/lib/Basic/Targets/WebAssembly.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExceptionSpec.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/WebAssembly/builtins-table.c
  clang/test/Sema/builtins-wasm.c
  clang/test/Sema/wasm-refs-and-tables.c
  clang/test/Sema/wasm-refs.c
  clang/test/SemaCXX/wasm-refs-and-tables.cpp
  clang/test/SemaCXX/wasm-refs.cpp
  llvm/include/llvm/CodeGen/WasmAddressSpaces.h
  llvm/include/llvm/IR/Type.h
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.cpp
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp

Index: llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyLowerRefTypesIntPtrConv.cpp
@@ -62,8 +62,9 @@
   for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I) {
 PtrToIntInst *PTI = dyn_cast(&*I);
 IntToPtrInst *ITP = dyn_cast(&*I);
-if (!(PTI && WebAssembly::isRefType(PTI->getPointerOperand()->getType())) &&
-!(ITP && WebAssembly::isRefType(ITP->getDestTy(
+if (!(PTI &&
+  PTI->getPointerOperand()->getType()->isWebAssemblyReferenceType()) &&
+!(ITP && ITP->getDestTy()->isWebAssemblyReferenceType()))
   continue;
 
 UndefValue *U = UndefValue::get(I->getType());
Index: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
@@ -1202,7 +1202,7 @@
   // Lastly, if this is a call to a funcref we need to add an instruction
   // table.set to the chain and transform the call.
   if (CLI.CB &&
-  WebAssembly::isFuncrefType(CLI.CB->getCalledOperand()->getType())) {
+  CLI.CB->getCalledOperand()->getType()->isWebAssemblyFuncrefType()) {
 // In the absence of function references proposal where a funcref call is
 // lowered to call_ref, using reference types we generate a table.set to set
 // the funcref to a special table used solely for this purpose, followed by
Index: llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
===
--- llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
+++ llvm/lib/Target/WebAssembly/Utils/WebAssemblyTypeUtilities.h
@@ -27,43 +27,6 @@
 
 namespace WebAssembly {
 
-enum WasmAddressSpace : unsigned {
-  // Default address space, for pointers to linear memory (stack, heap, data).
-  WASM_ADDRESS_SPACE_DEFAULT = 0,
-  // A non-integral address space for pointers to named objects outside of
-  // linear memory: WebAssembly globals or WebAssembly locals.  Loads and stores
-  // to these pointers are lowered to global.get / global.set or local.get /
-  // local.set, as appropriate.
-  WASM_ADDRESS_SPACE_VAR = 1,
-  // A non-integral address space for externref values
-  WASM_ADDRESS_SPACE_EXTERNREF = 10,
-  // A non-integral address space for funcref values
-  WASM_ADDRESS_SPACE_FUNCREF = 20,
-};
-
-inline bool isDefaultAddressSpace(unsigned AS) {
-  return AS == WASM_ADDRESS_SPACE_DEFAULT;
-}
-inline bool isWasmVarAddressSpace(unsigned AS) {
-  return AS == WASM_ADDRESS_SPACE_VAR;
-}
-inline bool isValidAddressSpace(unsigned AS) {
-  return isDefaultAddressSpace(AS) || isWasmVarAddressSpace(AS);
-}
-inline bool isFuncrefType(const Type *Ty) {
-  return isa(Ty) &&
- Ty->getPointerAddressSpace() ==
- WasmAddressSpace::WASM_ADDRESS_SPACE_FUNCREF;
-}
-inline bool isExternrefType(const Type *Ty) {
-  return isa(Ty) &&
- Ty->getPointerAddressSpace() ==
- WasmAddressSpace::WASM_ADDRESS_SPACE_EXTERNREF;
-}
-inline bool isRefType(const Type *Ty) {
-  return isFuncrefType(Ty) || isExternrefType(Ty);
-}
-
 // Convert String

[PATCH] D146279: [clangd] Extend CollectMainFileMacros.

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

thanks!




Comment at: clang-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)

nit: you can get SM out of PP, no need to pass both.



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

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.



Comment at: clang-tools-extra/clangd/ParsedAST.cpp:615
+  std::make_unique(
+  Clang->getSourceManager(), Clang->getPreprocessor(), Macros));
 

nit: we seem to be calling `Clang->getPreprocessor()` in many places, maybe 
extract it into a variable instead?


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] D146418: Support for OpenMP 5.0 sec 2.12.7 - Declare Target initializer expressions

2023-03-20 Thread Ritanya via Phabricator via cfe-commits
RitanyaB created this revision.
RitanyaB added reviewers: sandeepkosuri, koops, soumitra, dreachem, ABataev, 
cchen.
Herald added subscribers: sunshaoce, mattd, asavonic, guansong, yaxunl.
Herald added a project: All.
RitanyaB requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, jplehr, sstefan1.
Herald added a project: clang.

Initial support for OpenMP 5.0 declare target "as if" behavior for "initializer 
expressions".
If a variable with static storage duration or a function (except lambda for 
C++) is referenced in the initializer expression list of a variable with static 
storage duration that appears as a list item in a to clause on a declare target 
directive then the name of the referenced variable or function is treated as if 
it had appeared in a to clause on a declare target directive.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146418

Files:
  clang/lib/Parse/ParseDecl.cpp
  clang/test/OpenMP/declare_target_messages.cpp
  clang/test/OpenMP/declare_target_variables_ast_print.cpp
  clang/test/OpenMP/nvptx_target_exceptions_messages.cpp

Index: clang/test/OpenMP/nvptx_target_exceptions_messages.cpp
===
--- clang/test/OpenMP/nvptx_target_exceptions_messages.cpp
+++ clang/test/OpenMP/nvptx_target_exceptions_messages.cpp
@@ -95,7 +95,7 @@
 int (*D)() = C; // expected-note {{used here}}
 // host-note@-1 {{used here}}
 #pragma omp end declare target
-int foobar3() { throw 1; }
+int foobar3() { throw 1; } // expected-error {{cannot use 'throw' with exceptions disabled}}
 
 // Check no infinite recursion in deferred diagnostic emitter.
 long E = (long)&E;
Index: clang/test/OpenMP/declare_target_variables_ast_print.cpp
===
--- /dev/null
+++ clang/test/OpenMP/declare_target_variables_ast_print.cpp
@@ -0,0 +1,88 @@
+// RUN: %clang_cc1 -w -verify -fopenmp -I %S/Inputs -ast-print %s | FileCheck %s --check-prefix=CHECK
+// expected-no-diagnostics
+
+static int var = 1;
+
+static int var1 = 10;
+static int *var2 = &var1;
+static int **ptr1 = &var2;
+
+int arr[2] = {1,2};
+int (*arrptr)[2] = &arr;
+
+class declare{
+  public: int x;
+  void print();
+};
+declare obj1;
+declare *obj2 = &obj1;
+
+struct target{
+  int x;
+  void print();
+};
+static target S;
+
+#pragma omp declare target
+int *ptr = &var;
+int ***ptr2 = &ptr1;
+int (**ptr3)[2] = &arrptr;
+declare **obj3 = &obj2;
+target *S1 = &S;
+#pragma omp end declare target
+// CHECK: #pragma omp declare target
+// CHECK-NEXT: static int var = 1;
+// CHECK-NEXT: #pragma omp end declare target
+
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: static int var1 = 10;
+// CHECK-NEXT: #pragma omp end declare target
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: static int *var2 = &var1;
+// CHECK-NEXT: #pragma omp end declare target
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: static int **ptr1 = &var2;
+// CHECK-NEXT: #pragma omp end declare target
+
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: int arr[2] = {1, 2};
+// CHECK-NEXT: #pragma omp end declare target
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: int (*arrptr)[2] = &arr;
+// CHECK-NEXT: #pragma omp end declare target
+
+// CHECK-NEXT: class declare {
+// CHECK-NEXT: public: 
+// CHECK-NEXT:  int x;
+// CHECK-NEXT:  void print();
+// CHECK-NEXT: };
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: declare obj1;
+// CHECK-NEXT: #pragma omp end declare target
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: declare *obj2 = &obj1;
+// CHECK-NEXT: #pragma omp end declare target
+
+// CHECK-NEXT: struct target {
+// CHECK-NEXT:  int x;
+// CHECK-NEXT:  void print();
+// CHECK-NEXT: };
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: static target S;
+// CHECK-NEXT: #pragma omp end declare target
+
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: int *ptr = &var;
+// CHECK-NEXT: #pragma omp end declare target
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: int ***ptr2 = &ptr1;
+// CHECK-NEXT: #pragma omp end declare target
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: int (**ptr3)[2] = &arrptr;
+// CHECK-NEXT: #pragma omp end declare target
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: declare **obj3 = &obj2; 
+// CHECK-NEXT: #pragma omp end declare target
+// CHECK-NEXT: #pragma omp declare target
+// CHECK-NEXT: target *S1 = &S;
+// CHECK-NEXT: #pragma omp end declare target
Index: clang/test/OpenMP/declare_target_messages.cpp
===
--- clang/test/OpenMP/declare_target_messages.cpp
+++ clang/test/OpenMP/declare_target_messages.cpp
@@ -233,6 +233,36 @@
 #pragma omp declare target to(MultiDevTy) device_type(host)   // omp45-error {{unexpected 'device_type' clause, only 'to' or 'link' c

[PATCH] D146386: [MS ABI] Fix mangling references to declarations.

2023-03-20 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Added the code owners here.  There doesn't seem to be anything questionable 
here to me, but I want to make sure someone who really knows what is going on 
takes a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146386

___
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

2023-03-20 Thread Haojian Wu via Phabricator via cfe-commits
hokein added inline comments.



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()) {

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.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146406

___
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

2023-03-20 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



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:
> 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?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146406

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


[PATCH] D146417: [clangd] Fix AddUsing in the face of typo-correction

2023-03-20 Thread 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!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146417

___
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

2023-03-20 Thread 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()) {

It has nothing to do with parsing, sema analysis. Make it part of 
Sema::checkDeclIsAllowedInOpenMPTarget



Comment at: clang/lib/Parse/ParseDecl.cpp:2107
+  
DeclVar->addAttr(TargetDecl->getAttr());
+  ParseImplicitDeclareTargetAttr(DeclVar);
+}

Try to avoid recursion here


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


[clang-tools-extra] 6f23fee - [clangd] Fix AddUsing in the face of typo-correction

2023-03-20 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2023-03-20T14:30:36+01:00
New Revision: 6f23fee4ef98a695062aa128a177478ba7d742d4

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

LOG: [clangd] Fix AddUsing in the face of typo-correction

Fixes https://github.com/clangd/clangd/issues/559

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

Added: 


Modified: 
clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
clang-tools-extra/clangd/unittests/tweaks/AddUsingTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp 
b/clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
index 103e13f44d060..1e51d8fb9a518 100644
--- a/clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
+++ b/clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
@@ -8,10 +8,25 @@
 
 #include "AST.h"
 #include "Config.h"
+#include "SourceCode.h"
 #include "refactor/Tweak.h"
 #include "support/Logger.h"
 #include "clang/AST/Decl.h"
+#include "clang/AST/Expr.h"
+#include "clang/AST/NestedNameSpecifier.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/Type.h"
+#include "clang/AST/TypeLoc.h"
+#include "clang/Basic/LLVM.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Tooling/Core/Replacement.h"
+#include "clang/Tooling/Syntax/Tokens.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+#include 
+#include 
 
 namespace clang {
 namespace clangd {
@@ -45,8 +60,12 @@ class AddUsing : public Tweak {
   // All of the following are set by prepare().
   // The qualifier to remove.
   NestedNameSpecifierLoc QualifierToRemove;
-  // The name following QualifierToRemove.
-  llvm::StringRef Name;
+  // Qualified name to use when spelling the using declaration. This might be
+  // 
diff erent than SpelledQualifier in presence of error correction.
+  std::string QualifierToSpell;
+  // The name and qualifier as spelled in the code.
+  llvm::StringRef SpelledQualifier;
+  llvm::StringRef SpelledName;
   // If valid, the insertion point for "using" statement must come after this.
   // This is relevant when the type is defined in the main file, to make sure
   // the type/function is already defined at the point where "using" is added.
@@ -56,7 +75,7 @@ REGISTER_TWEAK(AddUsing)
 
 std::string AddUsing::title() const {
   return std::string(llvm::formatv(
-  "Add using-declaration for {0} and remove qualifier", Name));
+  "Add using-declaration for {0} and remove qualifier", SpelledName));
 }
 
 // Locates all "using" statements relevant to SelectionDeclContext.
@@ -269,36 +288,23 @@ bool AddUsing::prepare(const Selection &Inputs) {
   if (Node == nullptr)
 return false;
 
+  SourceRange SpelledNameRange;
   if (auto *D = Node->ASTNode.get()) {
 if (auto *II = D->getDecl()->getIdentifier()) {
   QualifierToRemove = D->getQualifierLoc();
-  Name = II->getName();
+  SpelledNameRange = D->getSourceRange();
   MustInsertAfterLoc = D->getDecl()->getBeginLoc();
 }
   } else if (auto *T = Node->ASTNode.get()) {
 if (auto E = T->getAs()) {
   QualifierToRemove = E.getQualifierLoc();
-  if (!QualifierToRemove)
-return false;
 
-  auto NameRange = E.getSourceRange();
+  SpelledNameRange = E.getSourceRange();
   if (auto T = E.getNamedTypeLoc().getAs()) 
{
 // Remove the template arguments from the name.
-NameRange.setEnd(T.getLAngleLoc().getLocWithOffset(-1));
+SpelledNameRange.setEnd(T.getLAngleLoc().getLocWithOffset(-1));
   }
 
-  auto SpelledTokens = TB.spelledForExpanded(TB.expandedTokens(NameRange));
-  if (!SpelledTokens)
-return false;
-  auto SpelledRange = syntax::Token::range(SM, SpelledTokens->front(),
-   SpelledTokens->back());
-  Name = SpelledRange.text(SM);
-
-  std::string QualifierToRemoveStr = getNNSLAsString(
-  QualifierToRemove, Inputs.AST->getASTContext().getPrintingPolicy());
-  if (!Name.consume_front(QualifierToRemoveStr))
-return false; // What's spelled doesn't match the qualifier.
-
   if (const auto *ET = E.getTypePtr()) {
 if (const auto *TDT =
 dyn_cast(ET->getNamedType().getTypePtr())) {
@@ -309,19 +315,14 @@ bool AddUsing::prepare(const Selection &Inputs) {
   }
 }
   }
-
-  // FIXME: This only supports removing qualifiers that are made up of just
-  // namespace names. If qualifier contains a type, we could take the longest
-  // namespace prefix and remove that.
-  if (!QualifierToRemove.hasQualifier() ||
+  if (!QualifierToRemove ||
+  // FIXME: This only supports removing qualifiers that are made up of just
+  // namespace names. If qualifier

[PATCH] D146417: [clangd] Fix AddUsing in the face of typo-correction

2023-03-20 Thread 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 rG6f23fee4ef98: [clangd] Fix AddUsing in the face of 
typo-correction (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146417

Files:
  clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
  clang-tools-extra/clangd/unittests/tweaks/AddUsingTests.cpp

Index: clang-tools-extra/clangd/unittests/tweaks/AddUsingTests.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/AddUsingTests.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/AddUsingTests.cpp
@@ -8,8 +8,11 @@
 
 #include "Config.h"
 #include "TweakTesting.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringRef.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
+#include 
 
 namespace clang {
 namespace clangd {
@@ -30,7 +33,7 @@
 void oo() {}
 template class tt {};
 namespace two {
-enum ee {};
+enum ee { ee_enum_value };
 void ff() {}
 class cc {
 public:
@@ -64,9 +67,6 @@
   EXPECT_UNAVAILABLE(Header + "void fun() { ::ban::fo^o(); }");
   EXPECT_AVAILABLE(Header + "void fun() { banana::fo^o(); }");
 
-  // Do not offer code action on typo-corrections.
-  EXPECT_UNAVAILABLE(Header + "/*error-ok*/c^c C;");
-
   // NestedNameSpecifier, but no namespace.
   EXPECT_UNAVAILABLE(Header + "class Foo {}; class F^oo foo;");
 
@@ -466,7 +466,37 @@
 using one::vec;
 
 vec foo;
-)cpp"}};
+)cpp"},
+  // Typo correction.
+  {R"cpp(
+// error-ok
+#include "test.hpp"
+c^c C;
+)cpp",
+   R"cpp(
+// error-ok
+#include "test.hpp"
+using one::two::cc;
+
+cc C;
+)cpp"},
+  {R"cpp(
+// error-ok
+#include "test.hpp"
+void foo() {
+  switch(one::two::ee{}) { case two::ee_^one:break; }
+}
+)cpp",
+   R"cpp(
+// error-ok
+#include "test.hpp"
+using one::two::ee_one;
+
+void foo() {
+  switch(one::two::ee{}) { case ee_one:break; }
+}
+)cpp"},
+  };
   llvm::StringMap EditedFiles;
   for (const auto &Case : Cases) {
 ExtraFiles["test.hpp"] = R"cpp(
Index: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp
@@ -8,10 +8,25 @@
 
 #include "AST.h"
 #include "Config.h"
+#include "SourceCode.h"
 #include "refactor/Tweak.h"
 #include "support/Logger.h"
 #include "clang/AST/Decl.h"
+#include "clang/AST/Expr.h"
+#include "clang/AST/NestedNameSpecifier.h"
 #include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/Type.h"
+#include "clang/AST/TypeLoc.h"
+#include "clang/Basic/LLVM.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Tooling/Core/Replacement.h"
+#include "clang/Tooling/Syntax/Tokens.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+#include 
+#include 
 
 namespace clang {
 namespace clangd {
@@ -45,8 +60,12 @@
   // All of the following are set by prepare().
   // The qualifier to remove.
   NestedNameSpecifierLoc QualifierToRemove;
-  // The name following QualifierToRemove.
-  llvm::StringRef Name;
+  // Qualified name to use when spelling the using declaration. This might be
+  // different than SpelledQualifier in presence of error correction.
+  std::string QualifierToSpell;
+  // The name and qualifier as spelled in the code.
+  llvm::StringRef SpelledQualifier;
+  llvm::StringRef SpelledName;
   // If valid, the insertion point for "using" statement must come after this.
   // This is relevant when the type is defined in the main file, to make sure
   // the type/function is already defined at the point where "using" is added.
@@ -56,7 +75,7 @@
 
 std::string AddUsing::title() const {
   return std::string(llvm::formatv(
-  "Add using-declaration for {0} and remove qualifier", Name));
+  "Add using-declaration for {0} and remove qualifier", SpelledName));
 }
 
 // Locates all "using" statements relevant to SelectionDeclContext.
@@ -269,36 +288,23 @@
   if (Node == nullptr)
 return false;
 
+  SourceRange SpelledNameRange;
   if (auto *D = Node->ASTNode.get()) {
 if (auto *II = D->getDecl()->getIdentifier()) {
   QualifierToRemove = D->getQualifierLoc();
-  Name = II->getName();
+  SpelledNameRange = D->getSourceRange();
   MustInsertAfterLoc = D->getDecl()->getBeginLoc();
 }
   } else if (auto *T = Node->ASTNode.get()) {
 if (auto E = T->getAs()) {
   QualifierToRemove = E.getQualifierLoc();
-  if (!QualifierToRemove)
-return false;
 
-  auto NameRange = E.getSourceRange();
+  SpelledNameRange = E.getSourceRange();
   if (auto T = E.getNamedTypeLoc().getAs()) {
 // Remove the template arguments from the name.
-NameRange.setEnd(T.getLAngleLoc().getLocWithOffse

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

2023-03-20 Thread Akash Banerjee via Phabricator via cfe-commits
TIFitis updated this revision to Diff 506563.
TIFitis added a comment.

Rebased.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

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

Index: mlir/test/Target/LLVMIR/omptarget-llvm.mlir
===
--- /dev/null
+++ mlir/test/Target/LLVMIR/omptarget-llvm.mlir
@@ -0,0 +1,176 @@
+// RUN: mlir-translate -mlir-to-llvmir -split-input-file %s | FileCheck %s
+
+llvm.func @_QPopenmp_target_data() {
+  %0 = llvm.mlir.constant(1 : i64) : i64
+  %1 = llvm.alloca %0 x i32 {bindc_name = "i", in_type = i32, operand_segment_sizes = array, uniq_name = "_QFopenmp_target_dataEi"} : (i64) -> !llvm.ptr
+  omp.target_data   map((tofrom -> %1 : !llvm.ptr)) {
+%2 = llvm.mlir.constant(99 : i32) : i32
+llvm.store %2, %1 : !llvm.ptr
+omp.terminator
+  }
+  llvm.return
+}
+
+// CHECK: @.offload_maptypes = private unnamed_addr constant [1 x i64] [i64 3]
+// CHECK-LABEL: define void @_QPopenmp_target_data() {
+// CHECK: %[[VAL_0:.*]] = alloca [1 x ptr], align 8
+// CHECK: %[[VAL_1:.*]] = alloca [1 x ptr], align 8
+// CHECK: %[[VAL_2:.*]] = alloca [1 x i64], align 8
+// CHECK: %[[VAL_3:.*]] = alloca i32, i64 1, align 4
+// CHECK: br label %[[VAL_4:.*]]
+// CHECK:   entry:; preds = %[[VAL_5:.*]]
+// CHECK: %[[VAL_6:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_0]], i32 0, i32 0
+// CHECK: store ptr %[[VAL_3]], ptr %[[VAL_6]], align 8
+// CHECK: %[[VAL_7:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_1]], i32 0, i32 0
+// CHECK: store ptr %[[VAL_3]], ptr %[[VAL_7]], align 8
+// CHECK: %[[VAL_8:.*]] = getelementptr inbounds [1 x i64], ptr %[[VAL_2]], i32 0, i32 0
+// CHECK: store i64 ptrtoint (ptr getelementptr (ptr, ptr null, i32 1) to i64), ptr %[[VAL_8]], align 4
+// CHECK: %[[VAL_9:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_0]], i32 0, i32 0
+// CHECK: %[[VAL_10:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_1]], i32 0, i32 0
+// CHECK: %[[VAL_11:.*]] = getelementptr inbounds [1 x i64], ptr %[[VAL_2]], i32 0, i32 0
+// CHECK: call void @__tgt_target_data_begin_mapper(ptr @2, i64 -1, i32 1, ptr %[[VAL_9]], ptr %[[VAL_10]], ptr %[[VAL_11]], ptr @.offload_maptypes, ptr @.offload_mapnames, ptr null)
+// CHECK: br label %[[VAL_12:.*]]
+// CHECK:   omp.data.region:  ; preds = %[[VAL_4]]
+// CHECK: store i32 99, ptr %[[VAL_3]], align 4
+// CHECK: br label %[[VAL_13:.*]]
+// CHECK:   omp.region.cont:  ; preds = %[[VAL_12]]
+// CHECK: %[[VAL_14:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_0]], i32 0, i32 0
+// CHECK: %[[VAL_15:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_1]], i32 0, i32 0
+// CHECK: %[[VAL_16:.*]] = getelementptr inbounds [1 x i64], ptr %[[VAL_2]], i32 0, i32 0
+// CHECK: call void @__tgt_target_data_end_mapper(ptr @2, i64 -1, i32 1, ptr %[[VAL_14]], ptr %[[VAL_15]], ptr %[[VAL_16]], ptr @.offload_maptypes, ptr @.offload_mapnames, ptr null)
+// CHECK: ret void
+
+// -
+
+llvm.func @_QPopenmp_target_data_region(%1 : !llvm.ptr>) {
+  omp.target_data   map((from -> %1 : !llvm.ptr>)) {
+%2 = llvm.mlir.constant(99 : i32) : i32
+%3 = llvm.mlir.constant(1 : i64) : i64
+%4 = llvm.mlir.constant(1 : i64) : i64
+%5 = llvm.mlir.constant(0 : i64) : i64
+%6 = llvm.getelementptr %1[0, %5] : (!llvm.ptr>, i64) -> !llvm.ptr
+llvm.store %2, %6 : !llvm.ptr
+omp.terminator
+  }
+  llvm.return
+}
+
+// CHECK: @.offload_maptypes = private unnamed_addr constant [1 x i64] [i64 2]
+// CHECK-LABEL: define void @_QPopenmp_target_data_region
+// CHECK: (ptr %[[ARG_0:.*]]) {
+// CHECK: %[[VAL_0:.*]] = alloca [1 x ptr], align 8
+// CHECK: %[[VAL_1:.*]] = alloca [1 x ptr], align 8
+// CHECK: %[[VAL_2:.*]] = alloca [1 x i64], align 8
+// CHECK: br label %[[VAL_3:.*]]
+// CHECK:   entry:; preds = %[[VAL_4:.*]]
+// CHECK: %[[VAL_5:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_0]], i32 0, i32 0
+// CHECK: store ptr %[[VAL_6:.*]], ptr %[[VAL_5]], alig

[PATCH] D146278: [flang] add -flang-experimental-hlfir flag to flang-new

2023-03-20 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added inline comments.



Comment at: flang/test/Driver/mlir-pass-pipeline.f90:15-18
+! O2-NEXT: Canonicalizer
+! ALL-NEXT: LowerHLFIRIntrinsics
+! ALL-NEXT: BufferizeHLFIR
+! ALL-NEXT: ConvertHLFIRtoFIR

It looks like these passes are run unconditionally - what's the 
`-flang-experimental-hlfir` flag for then?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146278

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


[PATCH] D145899: [AIX][Clang] Respect -r when invoking the linker

2023-03-20 Thread David Tenty via Phabricator via cfe-commits
daltenty added a comment.

LGTM, with a small nit about the test that should be addressed before committing




Comment at: clang/test/Driver/aix-ld.c:1085
+// RUN:--sysroot %S/Inputs/aix_ppc_tree \
+// RUN:--unwindlib=libunwind \
+// RUN:-r \

nit: add the user `-L` option to the test to reflect the changes above


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145899

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


[PATCH] D144987: [clang][dataflow] Fix missed fields in field set construction.

2023-03-20 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added inline comments.



Comment at: 
clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp:141
+ };
+ S foo();
+  )cc";

gribozavr2 wrote:
> Is `foo()` used for anything in this test?
not that I can see. looks left over from some previous version. want to remove 
it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144987

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


[PATCH] D146385: [clang][ExtractAPI] Complete declaration fragments for TagDecl types defined in a typedef

2023-03-20 Thread Daniel Grumberg via Phabricator via cfe-commits
dang requested changes to this revision.
dang added a comment.
This revision now requires changes to proceed.

I think there might be some code missing here. Also can you add a test?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146385

___
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

2023-03-20 Thread Ritanya via Phabricator via cfe-commits
RitanyaB added inline comments.



Comment at: clang/lib/Parse/ParseDecl.cpp:2107
+  
DeclVar->addAttr(TargetDecl->getAttr());
+  ParseImplicitDeclareTargetAttr(DeclVar);
+}

ABataev wrote:
> Try to avoid recursion here
Consider the following example-

```static int var1 = 10; 
static int *var2 = &var1;
#pragma omp declare target
int **ptr1=&var2;
#pragma omp end declare target
```
In this case, by default ptr1 gets OMPDeclareTargetDeclAttr and the function 
mentioned above (ParseImplicitDeclareTargetAttr) would add 
OMPDeclareTargetDeclAttr to var2. But, in order to add OMPDeclareTargetDeclAttr 
to var1, recursion would be required.


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] D140996: [c++20] P1907R1: Support for generalized non-type template arguments of scalar type.

2023-03-20 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a subscriber: asl.
erichkeane added a comment.

I've got the 1 concern with the mangling that I REALLY want one of our codegen 
owners to chime in on, otherwise this LGTM.




Comment at: clang/lib/AST/ItaniumMangle.cpp:4397
+// argument.
+// As proposed in https://github.com/itanium-cxx-abi/cxx-abi/issues/111.
+auto *SNTTPE = cast(E);

erichkeane wrote:
> aaron.ballman wrote:
> > We should get this nailed down. It was proposed in Nov 2020 and the issue 
> > is still open. CC @rjmccall 
> This definitely needs to happen.  @rjmccall or @eli.friedman ^^ Any idea what 
> the actual mangling should be?
This is still an open, and we need @rjmccall @eli.friedman or @asl to help out 
here.


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

https://reviews.llvm.org/D140996

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


[PATCH] D146354: [clang][ExtractAPI] Add semicolons for enum, typedef, struct declaration fragments

2023-03-20 Thread 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! I think it's fine to go ahead and land this (premerge check are not a 
requirement). Have you contributed to LLVM before? If not I will need to commit 
it on your behalf. Once that is done you should follow the instructions at 
https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access to gain 
commit access if you wish to continue contributing to the project and LLVM in 
general.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146354

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


[PATCH] D146420: Document the Clang policies on claiming support for a feature

2023-03-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman created this revision.
aaron.ballman added reviewers: clang-language-wg, rsmith.
Herald added a project: All.
aaron.ballman requested review of this revision.
Herald added a project: clang.

We do not currently have this written down anywhere, and as a result, we're 
sometimes inconsistent with how we handle feature test macros and the feature 
status pages. This is an attempt to document what I understand our existing 
policies to be instead of defining a new policy.

Note, this is being added to the Clang internals manual because we don't have a 
separate document for Clang developer policies. At some point, I think we may 
want a standalone document for that, and this content can be moved there at 
that time.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146420

Files:
  clang/docs/InternalsManual.rst


Index: clang/docs/InternalsManual.rst
===
--- clang/docs/InternalsManual.rst
+++ clang/docs/InternalsManual.rst
@@ -3268,3 +3268,39 @@
  proper visitation for your expression, enabling various IDE features such
  as syntax highlighting, cross-referencing, and so on.  The
  ``c-index-test`` helper program can be used to test these features.
+
+Feature Test Macros
+===
+Clang implements several ways to test whether a feature is supported or not.
+Some of these feature tests are standardized, like ``__has_cpp_attribute`` or
+``__cpp_decltype``, while others are Clang extensions, like ``__has_builtin``.
+The common theme among all the various feature tests is that they are a utility
+to tell users that we think a particular feature is complete. However,
+completeness is a difficult property to define because features may still have
+lingering bugs, may only work on some targets, etc. We use the following
+criteria when deciding whether to expose a feature test macro (or particular
+result value for the feature test):
+
+  * Are there known issues with the feature that reject valid code?
+  * Are there known issues that fail to reject invalid code?
+  * Are there known crashes, failed assertions, or miscompilations?
+  * Are there known issues on a particular relevant target?
+
+If the answer to any of these is "yes", you should either not define the
+feature test macro or have very strong rationale for why the issues should not
+prevent defining it. Note, it is acceptable to define the feature test macro on
+a per-target basis if needed.
+
+When in doubt, being conservative is better than being aggressive. If we don't
+claim support for the feature but it does useful things, users can still use it
+and provide us with useful feedback on what is missing. But if we claim support
+for a feature that has significant bugs, we've eliminated most of the utility
+of having a feature testing macro at all because users are then forced to test
+what compiler version is in use to get a more accurate answer.
+
+The status reported by the feature test macro should always be reflected in the
+language support page for the feature (`C++
+`_, `C
+`_) if applicable. This page can give
+more nuanced information to the user as well, such claiming partial support for
+a feature and specifying details as to what remains to be done.


Index: clang/docs/InternalsManual.rst
===
--- clang/docs/InternalsManual.rst
+++ clang/docs/InternalsManual.rst
@@ -3268,3 +3268,39 @@
  proper visitation for your expression, enabling various IDE features such
  as syntax highlighting, cross-referencing, and so on.  The
  ``c-index-test`` helper program can be used to test these features.
+
+Feature Test Macros
+===
+Clang implements several ways to test whether a feature is supported or not.
+Some of these feature tests are standardized, like ``__has_cpp_attribute`` or
+``__cpp_decltype``, while others are Clang extensions, like ``__has_builtin``.
+The common theme among all the various feature tests is that they are a utility
+to tell users that we think a particular feature is complete. However,
+completeness is a difficult property to define because features may still have
+lingering bugs, may only work on some targets, etc. We use the following
+criteria when deciding whether to expose a feature test macro (or particular
+result value for the feature test):
+
+  * Are there known issues with the feature that reject valid code?
+  * Are there known issues that fail to reject invalid code?
+  * Are there known crashes, failed assertions, or miscompilations?
+  * Are there known issues on a particular relevant target?
+
+If the answer to any of these is "yes", you should either not define the
+feature test macro or have very strong rationale for why the issues should not
+prevent defining it. Note, it is acceptable to define the feature test macro on
+a pe

[PATCH] D146165: docs: add some documentation on Windows SDK search

2023-03-20 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd added a comment.

> Looks reasonable I guess - but I think it would be good to mention the env 
> variables INCLUDE and LIB too, for alternative ways of finding the same 
> things - even if it's not strictly the same as what this new section talks 
> about.

Yes, I agree, I did miss that in this.  I don't think that the point is 
entirely correct though, because `Include` **does** impact the WinSDK lookup.  
That means that it is reflective of what the section is talking about.  `LIB` 
belongs in both I believe as that impacts the lookup for the libraries for both 
the SDK and Visual C++ tools (for VC Runtime).  Basically, I think that your 
point is more important than what you were attributing to it and this needs to 
be further refined for precision.




Comment at: clang/docs/UsersManual.rst:4537
+
+TODO: This is not yet implemented.
+

hans wrote:
> But isn't this how clang-cl finds stuff when running in a "Visual Studio 
> Command Prompt" / setenv / vcvars or whatever it's called these days?
> 
> I think this would be the most common case for people building from the 
> command line, and I'd suggest perhaps starting the list with this one (I 
> realize they're currently sorted by precedence, but sorting by most common 
> first would also be valid I think).
> But isn't this how clang-cl finds stuff when running in a "Visual Studio 
> Command Prompt" / setenv / vcvars or whatever it's called these days?

No, it isn't, because this is the Windows SDK portion.  The environment 
variable is for the Visual C++ tools only, the environment based SDK lookup is 
unimplemented.

Something something complexity something.

This is part of why I structured this the way as I have.  There are two parts 
of the lookup here, the part dealing with the SDK and the part dealing with the 
VC++ tools.  Now, it could be argued that this is finer point of detail that 
most will not care about, and I am concerned that is very much true, but the 
reality is that there is a bunch of complexity in the lookup and the value in 
documenting the behaviour is that we can easily lookup how to control the 
behaviour of the driver.

> I think this would be the most common case for people building from the 
> command line, and I'd suggest perhaps starting the list with this one (I 
> realize they're currently sorted by precedence, but sorting by most common 
> first would also be valid I think).

I think that common behaviour should be listed in prose.  If someone has more 
than one mechanism in the command line, the resulting behaviour would not match 
the written one and that can lead to confusion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146165

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


[PATCH] D146420: Document the Clang policies on claiming support for a feature

2023-03-20 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/docs/InternalsManual.rst:3276
+Some of these feature tests are standardized, like ``__has_cpp_attribute`` or
+``__cpp_decltype``, while others are Clang extensions, like ``__has_builtin``.
+The common theme among all the various feature tests is that they are a utility

Phab won't let me suggest it, but instead of `__cpp_decltype` (which to my 
mind, suggested it was a function-style FTM?), I might suggest something like 
`__cpp_lambdas`.



Comment at: clang/docs/InternalsManual.rst:3289
+
+If the answer to any of these is "yes", you should either not define the
+feature test macro or have very strong rationale for why the issues should not

you -> we?  Rest of the doc is in 3rd person, this is in 2nd?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146420

___
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

2023-03-20 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: clang/lib/Parse/ParseDecl.cpp:2107
+  
DeclVar->addAttr(TargetDecl->getAttr());
+  ParseImplicitDeclareTargetAttr(DeclVar);
+}

RitanyaB wrote:
> ABataev wrote:
> > Try to avoid recursion here
> Consider the following example-
> 
> ```static int var1 = 10; 
> static int *var2 = &var1;
> #pragma omp declare target
> int **ptr1=&var2;
> #pragma omp end declare target
> ```
> In this case, by default ptr1 gets OMPDeclareTargetDeclAttr and the function 
> mentioned above (ParseImplicitDeclareTargetAttr) would add 
> OMPDeclareTargetDeclAttr to var2. But, in order to add 
> OMPDeclareTargetDeclAttr to var1, recursion would be required.
I do not ask to remove it, but use extra memory (SamllVector) to save the 
decls, requiring analysis, and iterate through this vector.


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] D146278: [flang] add -flang-experimental-hlfir flag to flang-new

2023-03-20 Thread Tom Eccles via Phabricator via cfe-commits
tblah added inline comments.



Comment at: flang/include/flang/Tools/CLOptions.inc:235
+///   passes pipeline
+inline void createHLFIRToFIRPassPipeline(mlir::PassManager &pm,
+llvm::OptimizationLevel optLevel = defaultOptLevel) {

vzakhari wrote:
> Would you mind also calling this in `bbc`  driver?
Adding this to bbc will have to wait until after `-emit-fir` and `-emit-hlfir` 
are different flags. Otherwise hlfir ops will be lowered to fir, breaking some 
tests (and presumably people's workflows).



Comment at: flang/include/flang/Tools/CLOptions.inc:238
+  pm.addPass(mlir::createCanonicalizerPass());
+  pm.addPass(hlfir::createLowerHLFIRIntrinsicsPass());
+  pm.addPass(hlfir::createBufferizeHLFIRPass());

vzakhari wrote:
> I would imagine we may not want to optimize MATMUL(TRANSPOSE) into 
> MATMUL_TRANSPOSE at O0.  What is the best way to control this?  We may either 
> disable canonicalization or let `LowerHLFIRIntrinsicsPass` lower 
> MATMUL_TRANSPOSE differently based on the optimization level.  Or is it 
> always okay to implement it as a combined operation?
So far as I know, there should be no loss to precision from implementing it as 
a combined operation. Memory usage should be reduced as we need one fewer 
temporary.

If static linking is used, including MATMUL_TRANSPOSE in the runtime library 
will increase code size (so long as both matmul and transpose are also called 
elsewhere). I haven't measured this, but I wouldn't expect this to be a large 
change relative to the size of a real world application.

If dynamic linking is used, whether or not this pass runs, MATMUL_TRANSPOSE 
will make the runtime library a little larger (there are a lot of template 
instantiations, but MATMUL_TRANSPOSE is only one of many similar functions so 
the effect as a proportion of the whole shouldn't be much).

But I'll set the canonicalization pass to only run when we are optimizing for 
speed. Later canonicalisation passes (after createLowerHLFIRIntrinsicsPass) 
won't find any hlfir.matmul operations to canonicalise and so won't create a 
hlfir.matmul_transpose operation.



Comment at: flang/include/flang/Tools/CLOptions.inc:251
+bool stackArrays = false, bool underscoring = true, bool useHLFIR = false) 
{
+  if (useHLFIR)
+fir::createHLFIRToFIRPassPipeline(pm, optLevel);

vzakhari wrote:
> Is this check and the option really needed?  Except for the extra 
> canonicalizer pass the newly added passes will be no-ops, so maybe we should 
> just run them unconditionally.
> 
> It may be too much to ask for, but will it make sense not to bundle these 
> passes into `MLIRToLLVM` pipeline and have the possibility to let driver emit 
> post-HLFIR-lowering MLIR (under `-emit-fir`) and pre-HLFIR-lowering (under 
> some new option)?
Okay I'll run the HLFIR passes unconditionally.

I made -emit-fir output HLFIR to match what bbc already does, but I can see the 
usefulness of having both -emit-fir and -emit-hlfir. I won't do it in this 
patch but I will get around to this at some point (but feel free to jump in 
sooner if you need the flag for something).



Comment at: flang/test/Driver/mlir-pass-pipeline.f90:15-18
+! O2-NEXT: Canonicalizer
+! ALL-NEXT: LowerHLFIRIntrinsics
+! ALL-NEXT: BufferizeHLFIR
+! ALL-NEXT: ConvertHLFIRtoFIR

awarzynski wrote:
> It looks like these passes are run unconditionally - what's the 
> `-flang-experimental-hlfir` flag for then?
Yes. @vzakhari requested the passes should run unconditionally.

`-flang-experimental-hlfir` controls whether the HLFIR lowering is used. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146278

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


[PATCH] D146420: Document the Clang policies on claiming support for a feature

2023-03-20 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/docs/InternalsManual.rst:3285
+  * Are there known issues with the feature that reject valid code?
+  * Are there known issues that fail to reject invalid code?
+  * Are there known crashes, failed assertions, or miscompilations?

any way to rephrase that, "that cause clamg to reject" maybe?



Comment at: clang/docs/InternalsManual.rst:3292
+prevent defining it. Note, it is acceptable to define the feature test macro on
+a per-target basis if needed.
+

Is that desirable?
If i have a build system checking for support through feature macros, I'm not 
sure they do that on a target per target basis.



Comment at: clang/docs/InternalsManual.rst:3294-3299
+When in doubt, being conservative is better than being aggressive. If we don't
+claim support for the feature but it does useful things, users can still use it
+and provide us with useful feedback on what is missing. But if we claim support
+for a feature that has significant bugs, we've eliminated most of the utility
+of having a feature testing macro at all because users are then forced to test
+what compiler version is in use to get a more accurate answer.

+1 :)



Comment at: clang/docs/InternalsManual.rst:3300-3306
+
+The status reported by the feature test macro should always be reflected in the
+language support page for the feature (`C++
+`_, `C
+`_) if applicable. This page can give
+more nuanced information to the user as well, such claiming partial support for
+a feature and specifying details as to what remains to be done.

The status reported by a feature test macro should always be reflected in the
language support page for the coresponding feature 

such as claiming partial 

(i can't suggest edits, for some reason?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146420

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


[PATCH] D146399: [AIX][Clang][K] Create `-K` Option for AIX.

2023-03-20 Thread Michael Francis via Phabricator via cfe-commits
francii updated this revision to Diff 506575.
francii added a comment.

Add test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146399

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/aix-ld.c


Index: clang/test/Driver/aix-ld.c
===
--- clang/test/Driver/aix-ld.c
+++ clang/test/Driver/aix-ld.c
@@ -1077,3 +1077,19 @@
 // RUN:-fopenmp=libfoo \
 // RUN:   | FileCheck --check-prefixes=CHECK-FOPENMP-FOO %s
 // CHECK-FOPENMP-FOO: error: unsupported argument 'libfoo' to option 
'-fopenmp='
+
+// Check powerpc-ibm-aix7.1.0.0. -K is a passthrough linker option.
+// RUN: %clang %s 2>&1 -### \
+// RUN:--target=powerpc-ibm-aix7.1.0.0 \
+// RUN:--sysroot %S/Inputs/aix_ppc_tree \
+// RUN:--unwindlib=libunwind \
+// RUN:-K \
+// RUN:   | FileCheck --check-prefixes=CHECK-K %s
+// CHECK-K: "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
+// CHECK-K: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-K: "{{.*}}ld{{(.exe)?}}"
+// CHECK-K: "-b32"
+// CHECK-K: "-bpT:0x1000" "-bpD:0x2000"
+// CHECK-K: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-K: "[[SYSROOT]]/usr/lib{{/|}}crti.o"
+// CHECK-K: "-K"`
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6328,6 +6328,11 @@
 }
   }
 
+  if (Arg *A = Args.getLastArgNoClaim(options::OPT_K);
+  A && !TC.getTriple().isOSAIX())
+D.Diag(diag::err_drv_unsupported_opt_for_target)
+<< A->getAsString(Args) << TripleStr;
+
   if (Args.getLastArg(options::OPT_fapple_kext) ||
   (Args.hasArg(options::OPT_mkernel) && types::isCXX(InputType)))
 CmdArgs.push_back("-fapple-kext");
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3405,6 +3405,7 @@
   HelpText<"Overlay the virtual filesystem described by file over the real 
file system. "
"Additionally, pass this overlay file to the linker if it supports 
it">;
 def imultilib : Separate<["-"], "imultilib">, Group;
+def K : Flag<["-"], "K">, Flags<[LinkerInput, NoArgumentUnused]>;
 def keep__private__externs : Flag<["-"], "keep_private_externs">;
 def l : JoinedOrSeparate<["-"], "l">, Flags<[LinkerInput, RenderJoined]>,
 Group;


Index: clang/test/Driver/aix-ld.c
===
--- clang/test/Driver/aix-ld.c
+++ clang/test/Driver/aix-ld.c
@@ -1077,3 +1077,19 @@
 // RUN:-fopenmp=libfoo \
 // RUN:   | FileCheck --check-prefixes=CHECK-FOPENMP-FOO %s
 // CHECK-FOPENMP-FOO: error: unsupported argument 'libfoo' to option '-fopenmp='
+
+// Check powerpc-ibm-aix7.1.0.0. -K is a passthrough linker option.
+// RUN: %clang %s 2>&1 -### \
+// RUN:--target=powerpc-ibm-aix7.1.0.0 \
+// RUN:--sysroot %S/Inputs/aix_ppc_tree \
+// RUN:--unwindlib=libunwind \
+// RUN:-K \
+// RUN:   | FileCheck --check-prefixes=CHECK-K %s
+// CHECK-K: "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
+// CHECK-K: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-K: "{{.*}}ld{{(.exe)?}}"
+// CHECK-K: "-b32"
+// CHECK-K: "-bpT:0x1000" "-bpD:0x2000"
+// CHECK-K: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-K: "[[SYSROOT]]/usr/lib{{/|}}crti.o"
+// CHECK-K: "-K"`
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6328,6 +6328,11 @@
 }
   }
 
+  if (Arg *A = Args.getLastArgNoClaim(options::OPT_K);
+  A && !TC.getTriple().isOSAIX())
+D.Diag(diag::err_drv_unsupported_opt_for_target)
+<< A->getAsString(Args) << TripleStr;
+
   if (Args.getLastArg(options::OPT_fapple_kext) ||
   (Args.hasArg(options::OPT_mkernel) && types::isCXX(InputType)))
 CmdArgs.push_back("-fapple-kext");
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3405,6 +3405,7 @@
   HelpText<"Overlay the virtual filesystem described by file over the real file system. "
"Additionally, pass this overlay file to the linker if it supports it">;
 def imultilib : Separate<["-"], "imultilib">, Group;
+def K : Flag<["-"], "K">, Flags<[LinkerInput, NoArgumentUnused]>;
 def keep__private__externs : Flag<["-"], "keep_private_externs">;
 def l : JoinedOrSeparate<["-"], "l">, Flags<[LinkerInput, RenderJoined]>,
 Group;
__

[PATCH] D144190: [AIX][clang] Storage Locations for Constant Pointers

2023-03-20 Thread Qiongsi Wu via Phabricator via cfe-commits
qiongsiwu1 added a comment.

Ping for review/comments. Thanks so much!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144190

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


[PATCH] D144870: [Clang][DebugInfo] Emit zero size bitfields in the debug info to delimit bitfields in different allocation units.

2023-03-20 Thread Juan Manuel Martinez Caamaño via Phabricator via cfe-commits
jmmartinez added a comment.

In D144870#4202121 , @probinson wrote:

> (Of course it's possible that finding the preceding field can be done only by 
> iterating, but I'd hope that isn't necessary.)

Sadly, this is the case. `field_iterator` and the underlying `decl_iterator` 
used to implement it are forward iterators.

However, your comment made me realize that we could forward the `elements` 
array from `CGDebugInfoCollectRecordNormalFields`  which contains the already 
created debug-info for the previous fields. By using this array I could get 
pretty much the same effect. What do you think?

In D144870#4202121 , @probinson wrote:

>   struct non_adjacent_bitfields {
> char d;
> char : 0;
> char e;
> char f : 8;
>   };
>
> (1) Is `e` affected by the presence of the zero-length bitfield? (2) is `f` 
> affected? (3) If the answers are "no" and "yes" then you do need to iterate 
> looking for the zero-length bitfield, but otherwise I think it's sufficient 
> to look only at the preceding field.

(1) and (2): They do not get affected by the precense of the annonymous 
bitfield. Only sequences of bitfields get "squashed" in the same integer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144870

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


[PATCH] D146422: Fix typo

2023-03-20 Thread Ilyas Mustafazade via Phabricator via cfe-commits
1lyasm created this revision.
1lyasm added reviewers: evansmal, zero9178.
Herald added a project: All.
1lyasm requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146422

Files:
  clang/lib/Sema/SemaInit.cpp


Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -5437,7 +5437,7 @@
   }
 
   // Not all of the args have been processed, so there must've been more args
-  // then were required to initialize the element.
+  // than were required to initialize the element.
   if (ArgIndexToProcess < Args.size()) {
 Sequence.SetFailed(InitializationSequence::FK_ParenthesizedListInitFailed);
 if (!VerifyOnly) {


Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -5437,7 +5437,7 @@
   }
 
   // Not all of the args have been processed, so there must've been more args
-  // then were required to initialize the element.
+  // than were required to initialize the element.
   if (ArgIndexToProcess < Args.size()) {
 Sequence.SetFailed(InitializationSequence::FK_ParenthesizedListInitFailed);
 if (!VerifyOnly) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D145899: [AIX][Clang] Respect -r when invoking the linker

2023-03-20 Thread Michael Francis via Phabricator via cfe-commits
francii updated this revision to Diff 506577.
francii added a comment.

Update test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145899

Files:
  clang/lib/Driver/ToolChains/AIX.cpp
  clang/test/Driver/aix-ld.c

Index: clang/test/Driver/aix-ld.c
===
--- clang/test/Driver/aix-ld.c
+++ clang/test/Driver/aix-ld.c
@@ -1077,3 +1077,22 @@
 // RUN:-fopenmp=libfoo \
 // RUN:   | FileCheck --check-prefixes=CHECK-FOPENMP-FOO %s
 // CHECK-FOPENMP-FOO: error: unsupported argument 'libfoo' to option '-fopenmp='
+
+// Check powerpc-ibm-aix7.1.0.0. -r does not link object files or libraries
+// RUN: %clang %s 2>&1 -### \
+// RUN:--target=powerpc-ibm-aix7.1.0.0 \
+// RUN:--sysroot %S/Inputs/aix_ppc_tree \
+// RUN:--unwindlib=libunwind \
+// RUN:-L/foo/bar \
+// RUN:-r \
+// RUN:   | FileCheck --check-prefixes=CHECK-RELOCATABLE %s
+
+// CHECK-RELOCATABLE: "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
+// CHECK-RELOCATABLE: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-RELOCATABLE: "{{.*}}ld{{(.exe)?}}"
+// CHECK-RELOCATABLE: "-r"
+// CHECK-RELOCATABLE: "-L/foo/bar"
+// CHECK-RELOCATABLE-NOT: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-RELOCATABLE-NOT: "[[SYSROOT]]/usr/lib{{/|}}crti.o"
+// CHECK-RELOCATABLE-NOT: "-l{{.*}}"
+// CHECK-RELOCATABLE-NOT: "-L{{.*}}"
Index: clang/lib/Driver/ToolChains/AIX.cpp
===
--- clang/lib/Driver/ToolChains/AIX.cpp
+++ clang/lib/Driver/ToolChains/AIX.cpp
@@ -175,7 +175,7 @@
   };
 
   if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles,
-   options::OPT_shared)) {
+   options::OPT_shared, options::OPT_r)) {
 CmdArgs.push_back(
 Args.MakeArgString(ToolChain.GetFilePath(getCrt0Basename(;
 
@@ -235,47 +235,49 @@
   // Add directory to library search path.
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   ToolChain.AddFilePathLibArgs(Args, CmdArgs);
-  ToolChain.addProfileRTLibs(Args, CmdArgs);
-
-  if (getToolChain().ShouldLinkCXXStdlib(Args))
-getToolChain().AddCXXStdlibLibArgs(Args, CmdArgs);
-
-  if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs)) {
-AddRunTimeLibs(ToolChain, D, CmdArgs, Args);
-
-// Add OpenMP runtime if -fopenmp is specified.
-if (Args.hasFlag(options::OPT_fopenmp, options::OPT_fopenmp_EQ,
- options::OPT_fno_openmp, false)) {
-  switch (ToolChain.getDriver().getOpenMPRuntime(Args)) {
-  case Driver::OMPRT_OMP:
-CmdArgs.push_back("-lomp");
-break;
-  case Driver::OMPRT_IOMP5:
-CmdArgs.push_back("-liomp5");
-break;
-  case Driver::OMPRT_GOMP:
-CmdArgs.push_back("-lgomp");
-break;
-  case Driver::OMPRT_Unknown:
-// Already diagnosed.
-break;
+  if (!Args.hasArg(options::OPT_r)) {
+ToolChain.addProfileRTLibs(Args, CmdArgs);
+
+if (getToolChain().ShouldLinkCXXStdlib(Args))
+  getToolChain().AddCXXStdlibLibArgs(Args, CmdArgs);
+
+if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs)) {
+  AddRunTimeLibs(ToolChain, D, CmdArgs, Args);
+
+  // Add OpenMP runtime if -fopenmp is specified.
+  if (Args.hasFlag(options::OPT_fopenmp, options::OPT_fopenmp_EQ,
+   options::OPT_fno_openmp, false)) {
+switch (ToolChain.getDriver().getOpenMPRuntime(Args)) {
+case Driver::OMPRT_OMP:
+  CmdArgs.push_back("-lomp");
+  break;
+case Driver::OMPRT_IOMP5:
+  CmdArgs.push_back("-liomp5");
+  break;
+case Driver::OMPRT_GOMP:
+  CmdArgs.push_back("-lgomp");
+  break;
+case Driver::OMPRT_Unknown:
+  // Already diagnosed.
+  break;
+}
   }
-}
 
-// Support POSIX threads if "-pthreads" or "-pthread" is present.
-if (Args.hasArg(options::OPT_pthreads, options::OPT_pthread))
-  CmdArgs.push_back("-lpthreads");
+  // Support POSIX threads if "-pthreads" or "-pthread" is present.
+  if (Args.hasArg(options::OPT_pthreads, options::OPT_pthread))
+CmdArgs.push_back("-lpthreads");
 
-if (D.CCCIsCXX())
-  CmdArgs.push_back("-lm");
+  if (D.CCCIsCXX())
+CmdArgs.push_back("-lm");
 
-CmdArgs.push_back("-lc");
+  CmdArgs.push_back("-lc");
 
-if (Args.hasArgNoClaim(options::OPT_p, options::OPT_pg)) {
-  CmdArgs.push_back(Args.MakeArgString((llvm::Twine("-L") + D.SysRoot) +
-   "/lib/profiled"));
-  CmdArgs.push_back(Args.MakeArgString((llvm::Twine("-L") + D.SysRoot) +
-   "/usr/lib/profiled"));
+  if (Args.hasArgNoClaim(options::OPT_p, options::OPT_pg)) {
+CmdArgs.push_back(Args.MakeArgStrin

[PATCH] D146338: [MSVC compatibility][dllimport/dllexport][PS] Allow dllexport/dllimport for classes with UniqueExternalLinkage

2023-03-20 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

> In D145271  it was suggested that we drop 
> the attribute in such contexts, and this is effectively what happens. The 
> compiler does not produce any exported definitions (or import any symbols) 
> for such classes. The patch is simply to suppress the diagnostic for MSVC 
> mode and Playstation.

With the current patch, we still end up with the attribute on the base class in 
the AST. Also, does this make the compiler accept dllexport of classes in 
anonymous namespaces? I'm not sure we want that.

Is it not possible to check the linkage and bail out in 
`Sema::propagateDLLAttrToBaseClassTemplate` instead?


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

https://reviews.llvm.org/D146338

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


[PATCH] D145057: [clang][ASTImport] Add support for import of empty records

2023-03-20 Thread Pavel Kosov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
kpdev42 marked an inline comment as done.
Closed by commit rG21cd04c46fe0: [clang][ASTImport] Add support for import of 
empty records (authored by kpdev42).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145057

Files:
  clang/include/clang/AST/ASTImporter.h
  clang/include/clang/AST/DeclCXX.h
  clang/lib/AST/ASTImporter.cpp
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -8478,6 +8478,29 @@
   ToVaList->getUnderlyingType(), ToBuiltinVaList->getUnderlyingType()));
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase,
+   ImportDefinitionOfEmptyClassWithNoUniqueAddressField) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  struct B {};
+  struct A { B b; };
+  )",
+  Lang_CXX20);
+
+  CXXRecordDecl *FromD = FirstDeclMatcher().match(
+  FromTU, cxxRecordDecl(hasName("A")));
+
+  for (auto *FD : FromD->fields())
+FD->addAttr(clang::NoUniqueAddressAttr::Create(FromD->getASTContext(),
+   clang::SourceRange()));
+  FromD->markEmpty();
+
+  CXXRecordDecl *ToD = cast(Import(FromD, Lang_CXX20));
+  EXPECT_EQ(true, ToD->isEmpty());
+  for (auto *FD : ToD->fields())
+EXPECT_EQ(true, FD->hasAttr());
+}
+
 INSTANTIATE_TEST_SUITE_P(ParameterizedTests, ASTImporterLookupTableTest,
  DefaultTestValuesForRunOptions);
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -3895,6 +3895,12 @@
   D->getInClassInitStyle()))
 return ToField;
 
+  // We need [[no_unqiue_address]] attributes to be added to FieldDecl, before
+  // we add fields in CXXRecordDecl::addedMember, otherwise record will be
+  // marked as having non-zero size.
+  Err = Importer.ImportAttrs(ToField, D);
+  if (Err)
+return std::move(Err);
   ToField->setAccess(D->getAccess());
   ToField->setLexicalDeclContext(LexicalDC);
   if (ToInitializer)
@@ -8981,6 +8987,19 @@
   return FromDPos->second->getTranslationUnitDecl();
 }
 
+Error ASTImporter::ImportAttrs(Decl *ToD, Decl *FromD) {
+  if (!FromD->hasAttrs() || ToD->hasAttrs())
+return Error::success();
+  for (const Attr *FromAttr : FromD->getAttrs()) {
+auto ToAttrOrErr = Import(FromAttr);
+if (ToAttrOrErr)
+  ToD->addAttr(*ToAttrOrErr);
+else
+  return ToAttrOrErr.takeError();
+  }
+  return Error::success();
+}
+
 Expected ASTImporter::Import(Decl *FromD) {
   if (!FromD)
 return nullptr;
@@ -9115,15 +9134,8 @@
 
   // Make sure that ImportImpl registered the imported decl.
   assert(ImportedDecls.count(FromD) != 0 && "Missing call to MapImported?");
-
-  if (FromD->hasAttrs())
-for (const Attr *FromAttr : FromD->getAttrs()) {
-  auto ToAttrOrErr = Import(FromAttr);
-  if (ToAttrOrErr)
-ToD->addAttr(*ToAttrOrErr);
-  else
-return ToAttrOrErr.takeError();
-}
+  if (auto Error = ImportAttrs(ToD, FromD))
+return std::move(Error);
 
   // Notify subclasses.
   Imported(FromD, ToD);
Index: clang/include/clang/AST/DeclCXX.h
===
--- clang/include/clang/AST/DeclCXX.h
+++ clang/include/clang/AST/DeclCXX.h
@@ -1165,6 +1165,10 @@
   ///
   /// \note This does NOT include a check for union-ness.
   bool isEmpty() const { return data().Empty; }
+  /// Marks this record as empty. This is used by DWARFASTParserClang
+  /// when parsing records with empty fields having [[no_unique_address]]
+  /// attribute
+  void markEmpty() { data().Empty = true; }
 
   void setInitMethod(bool Val) { data().HasInitMethod = Val; }
   bool hasInitMethod() const { return data().HasInitMethod; }
Index: clang/include/clang/AST/ASTImporter.h
===
--- clang/include/clang/AST/ASTImporter.h
+++ clang/include/clang/AST/ASTImporter.h
@@ -258,6 +258,7 @@
 FoundDeclsTy findDeclsInToCtx(DeclContext *DC, DeclarationName Name);
 
 void AddToLookupTable(Decl *ToD);
+llvm::Error ImportAttrs(Decl *ToD, Decl *FromD);
 
   protected:
 /// Can be overwritten by subclasses to implement their own import logic.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D146399: [AIX][Clang][K] Create `-K` Option for AIX.

2023-03-20 Thread Michael Francis via Phabricator via cfe-commits
francii updated this revision to Diff 506580.
francii added a comment.

Clean up test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146399

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/aix-ld.c


Index: clang/test/Driver/aix-ld.c
===
--- clang/test/Driver/aix-ld.c
+++ clang/test/Driver/aix-ld.c
@@ -1077,3 +1077,17 @@
 // RUN:-fopenmp=libfoo \
 // RUN:   | FileCheck --check-prefixes=CHECK-FOPENMP-FOO %s
 // CHECK-FOPENMP-FOO: error: unsupported argument 'libfoo' to option 
'-fopenmp='
+
+// Check powerpc-ibm-aix7.1.0.0. -K is a passthrough linker option.
+// RUN: %clang %s 2>&1 -### \
+// RUN:--target=powerpc-ibm-aix7.1.0.0 \
+// RUN:--sysroot %S/Inputs/aix_ppc_tree \
+// RUN:--unwindlib=libunwind \
+// RUN:-K \
+// RUN:   | FileCheck --check-prefixes=CHECK-K %s
+// CHECK-K: "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
+// CHECK-K: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-K: "{{.*}}ld{{(.exe)?}}"
+// CHECK-K: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-K: "[[SYSROOT]]/usr/lib{{/|}}crti.o"
+// CHECK-K: "-K"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6328,6 +6328,11 @@
 }
   }
 
+  if (Arg *A = Args.getLastArgNoClaim(options::OPT_K);
+  A && !TC.getTriple().isOSAIX())
+D.Diag(diag::err_drv_unsupported_opt_for_target)
+<< A->getAsString(Args) << TripleStr;
+
   if (Args.getLastArg(options::OPT_fapple_kext) ||
   (Args.hasArg(options::OPT_mkernel) && types::isCXX(InputType)))
 CmdArgs.push_back("-fapple-kext");
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3405,6 +3405,7 @@
   HelpText<"Overlay the virtual filesystem described by file over the real 
file system. "
"Additionally, pass this overlay file to the linker if it supports 
it">;
 def imultilib : Separate<["-"], "imultilib">, Group;
+def K : Flag<["-"], "K">, Flags<[LinkerInput, NoArgumentUnused]>;
 def keep__private__externs : Flag<["-"], "keep_private_externs">;
 def l : JoinedOrSeparate<["-"], "l">, Flags<[LinkerInput, RenderJoined]>,
 Group;


Index: clang/test/Driver/aix-ld.c
===
--- clang/test/Driver/aix-ld.c
+++ clang/test/Driver/aix-ld.c
@@ -1077,3 +1077,17 @@
 // RUN:-fopenmp=libfoo \
 // RUN:   | FileCheck --check-prefixes=CHECK-FOPENMP-FOO %s
 // CHECK-FOPENMP-FOO: error: unsupported argument 'libfoo' to option '-fopenmp='
+
+// Check powerpc-ibm-aix7.1.0.0. -K is a passthrough linker option.
+// RUN: %clang %s 2>&1 -### \
+// RUN:--target=powerpc-ibm-aix7.1.0.0 \
+// RUN:--sysroot %S/Inputs/aix_ppc_tree \
+// RUN:--unwindlib=libunwind \
+// RUN:-K \
+// RUN:   | FileCheck --check-prefixes=CHECK-K %s
+// CHECK-K: "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
+// CHECK-K: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-K: "{{.*}}ld{{(.exe)?}}"
+// CHECK-K: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-K: "[[SYSROOT]]/usr/lib{{/|}}crti.o"
+// CHECK-K: "-K"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6328,6 +6328,11 @@
 }
   }
 
+  if (Arg *A = Args.getLastArgNoClaim(options::OPT_K);
+  A && !TC.getTriple().isOSAIX())
+D.Diag(diag::err_drv_unsupported_opt_for_target)
+<< A->getAsString(Args) << TripleStr;
+
   if (Args.getLastArg(options::OPT_fapple_kext) ||
   (Args.hasArg(options::OPT_mkernel) && types::isCXX(InputType)))
 CmdArgs.push_back("-fapple-kext");
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3405,6 +3405,7 @@
   HelpText<"Overlay the virtual filesystem described by file over the real file system. "
"Additionally, pass this overlay file to the linker if it supports it">;
 def imultilib : Separate<["-"], "imultilib">, Group;
+def K : Flag<["-"], "K">, Flags<[LinkerInput, NoArgumentUnused]>;
 def keep__private__externs : Flag<["-"], "keep_private_externs">;
 def l : JoinedOrSeparate<["-"], "l">, Flags<[LinkerInput, RenderJoined]>,
 Group;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 21cd04c - [clang][ASTImport] Add support for import of empty records

2023-03-20 Thread Pavel Kosov via cfe-commits

Author: Pavel Kosov
Date: 2023-03-20T17:33:04+03:00
New Revision: 21cd04c46fe0a2bee224899f56518a09bce5306e

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

LOG: [clang][ASTImport] Add support for import of empty records

Patch represents the clang part of changes in D143347

Reviewed By: balazske

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

Added: 


Modified: 
clang/include/clang/AST/ASTImporter.h
clang/include/clang/AST/DeclCXX.h
clang/lib/AST/ASTImporter.cpp
clang/unittests/AST/ASTImporterTest.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTImporter.h 
b/clang/include/clang/AST/ASTImporter.h
index f851decd0965c..4ffd913846575 100644
--- a/clang/include/clang/AST/ASTImporter.h
+++ b/clang/include/clang/AST/ASTImporter.h
@@ -258,6 +258,7 @@ class TypeSourceInfo;
 FoundDeclsTy findDeclsInToCtx(DeclContext *DC, DeclarationName Name);
 
 void AddToLookupTable(Decl *ToD);
+llvm::Error ImportAttrs(Decl *ToD, Decl *FromD);
 
   protected:
 /// Can be overwritten by subclasses to implement their own import logic.

diff  --git a/clang/include/clang/AST/DeclCXX.h 
b/clang/include/clang/AST/DeclCXX.h
index ff8f8a1bb12d6..dd35ef4adfd70 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -1165,6 +1165,10 @@ class CXXRecordDecl : public RecordDecl {
   ///
   /// \note This does NOT include a check for union-ness.
   bool isEmpty() const { return data().Empty; }
+  /// Marks this record as empty. This is used by DWARFASTParserClang
+  /// when parsing records with empty fields having [[no_unique_address]]
+  /// attribute
+  void markEmpty() { data().Empty = true; }
 
   void setInitMethod(bool Val) { data().HasInitMethod = Val; }
   bool hasInitMethod() const { return data().HasInitMethod; }

diff  --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index bd055082778df..d0da2dae3aa23 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -3895,6 +3895,12 @@ ExpectedDecl ASTNodeImporter::VisitFieldDecl(FieldDecl 
*D) {
   D->getInClassInitStyle()))
 return ToField;
 
+  // We need [[no_unqiue_address]] attributes to be added to FieldDecl, before
+  // we add fields in CXXRecordDecl::addedMember, otherwise record will be
+  // marked as having non-zero size.
+  Err = Importer.ImportAttrs(ToField, D);
+  if (Err)
+return std::move(Err);
   ToField->setAccess(D->getAccess());
   ToField->setLexicalDeclContext(LexicalDC);
   if (ToInitializer)
@@ -8981,6 +8987,19 @@ TranslationUnitDecl *ASTImporter::GetFromTU(Decl *ToD) {
   return FromDPos->second->getTranslationUnitDecl();
 }
 
+Error ASTImporter::ImportAttrs(Decl *ToD, Decl *FromD) {
+  if (!FromD->hasAttrs() || ToD->hasAttrs())
+return Error::success();
+  for (const Attr *FromAttr : FromD->getAttrs()) {
+auto ToAttrOrErr = Import(FromAttr);
+if (ToAttrOrErr)
+  ToD->addAttr(*ToAttrOrErr);
+else
+  return ToAttrOrErr.takeError();
+  }
+  return Error::success();
+}
+
 Expected ASTImporter::Import(Decl *FromD) {
   if (!FromD)
 return nullptr;
@@ -9115,15 +9134,8 @@ Expected ASTImporter::Import(Decl *FromD) {
 
   // Make sure that ImportImpl registered the imported decl.
   assert(ImportedDecls.count(FromD) != 0 && "Missing call to MapImported?");
-
-  if (FromD->hasAttrs())
-for (const Attr *FromAttr : FromD->getAttrs()) {
-  auto ToAttrOrErr = Import(FromAttr);
-  if (ToAttrOrErr)
-ToD->addAttr(*ToAttrOrErr);
-  else
-return ToAttrOrErr.takeError();
-}
+  if (auto Error = ImportAttrs(ToD, FromD))
+return std::move(Error);
 
   // Notify subclasses.
   Imported(FromD, ToD);

diff  --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index 6300551ca4469..7dd4c81074c76 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -8478,6 +8478,29 @@ TEST_P(ASTImporterOptionSpecificTestBase, VaListCpp) {
   ToVaList->getUnderlyingType(), ToBuiltinVaList->getUnderlyingType()));
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase,
+   ImportDefinitionOfEmptyClassWithNoUniqueAddressField) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  struct B {};
+  struct A { B b; };
+  )",
+  Lang_CXX20);
+
+  CXXRecordDecl *FromD = FirstDeclMatcher().match(
+  FromTU, cxxRecordDecl(hasName("A")));
+
+  for (auto *FD : FromD->fields())
+FD->addAttr(clang::NoUniqueAddressAttr::Create(FromD->getASTContext(),
+   clang::SourceRange()));
+  FromD->markEmpty();
+
+  CXXRecordDecl *ToD = cast(Import(FromD, Lang_CXX20));
+  EXPECT_EQ(true, ToD->isEmpty());
+  for (auto *FD : ToD->

[PATCH] D146165: docs: add some documentation on Windows SDK search

2023-03-20 Thread Hans Wennborg via Phabricator via cfe-commits
hans accepted this revision.
hans added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/docs/UsersManual.rst:4504
+programs against the Windows system packages.  Underlying the Windows SDK is 
the
+UCRT, the universal C runtime.
+

Optionally, If you wanted to be ultra pedagogical, this paragraph could perhaps 
list an example library/header as part of explaining the SDK, UCRT, and tools.



Comment at: clang/docs/UsersManual.rst:4537
+
+TODO: This is not yet implemented.
+

compnerd wrote:
> hans wrote:
> > But isn't this how clang-cl finds stuff when running in a "Visual Studio 
> > Command Prompt" / setenv / vcvars or whatever it's called these days?
> > 
> > I think this would be the most common case for people building from the 
> > command line, and I'd suggest perhaps starting the list with this one (I 
> > realize they're currently sorted by precedence, but sorting by most common 
> > first would also be valid I think).
> > But isn't this how clang-cl finds stuff when running in a "Visual Studio 
> > Command Prompt" / setenv / vcvars or whatever it's called these days?
> 
> No, it isn't, because this is the Windows SDK portion.  The environment 
> variable is for the Visual C++ tools only, the environment based SDK lookup 
> is unimplemented.
> 
> Something something complexity something.
> 
> This is part of why I structured this the way as I have.  There are two parts 
> of the lookup here, the part dealing with the SDK and the part dealing with 
> the VC++ tools.  Now, it could be argued that this is finer point of detail 
> that most will not care about, and I am concerned that is very much true, but 
> the reality is that there is a bunch of complexity in the lookup and the 
> value in documenting the behaviour is that we can easily lookup how to 
> control the behaviour of the driver.
> 
> > I think this would be the most common case for people building from the 
> > command line, and I'd suggest perhaps starting the list with this one (I 
> > realize they're currently sorted by precedence, but sorting by most common 
> > first would also be valid I think).
> 
> I think that common behaviour should be listed in prose.  If someone has more 
> than one mechanism in the command line, the resulting behaviour would not 
> match the written one and that can lead to confusion.
> No, it isn't, because this is the Windows SDK portion.

Oh, I see. I clearly missed that detail :)

> I think that common behaviour should be listed in prose.

Fair enough.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146165

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


[PATCH] D145843: [clangd] Add option to always insert headers with <> instead of ""

2023-03-20 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

sorry but I am not sure what's the value proposed by this patch in its current 
form. in https://github.com/clangd/clangd/issues/1247 and other places we've 
discussed this, i believe the sentiment was towards providing a config option 
that'll let people customize header insertion style in combination with a 
directory filter, e.g:

  Style:
IncludeInsertion:
Directory: foo/
Delimeter: <
 ... More IncludeInsertion customizations.

Any specific reasons for going with the hard-coded approach? As I don't think 
we can accept all this extra code to make sure it works for a "handful" 
projects/users (in the wild I haven't seen many projects that strictly use `<` 
includes). The use case you want can still be accommodated by such a generic 
approach, you can have `Directory: /` or we can even treat absence of 
`Directory` field as an "always" matcher.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145843

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


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

2023-03-20 Thread Marco Falke via Phabricator via cfe-commits
MarcoFalke updated this revision to Diff 506586.
MarcoFalke marked an inline comment as done.
MarcoFalke added a comment.

Took some review suggestions (Thanks!)


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;
@@ -1353,6 +1365,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); }()}, CtorC{b} {}
+// };
+
+struct Derived2 : Base, CtorC {
+  Derived2(Obj b)
+// TODO? is this a false positive, considering that we don't know whether Base(Call &&c) will actually call 'c'?
+  : Base{[&] mutable { return std::move(b); }},
+// CHECK-NOTES: [[@LINE-1]]:15: warning: 'b' used after it was moved
+// CHECK-NOTES: [[@LINE-2]]:35: note: move occurred here
+// CHECK-NOTES: [[@LINE-3]]:15: note: the use and move are unsequenced, i.e. there is no guarantee about the order in which they are evaluated
+CtorC{b} {}
+  // CHECK-NOTES: [[@LINE-1]]:15: warning: 'b' used after it was moved
+  // CHECK-NOTES: [[@LINE-6]]:35: note: move occurred here
+};
+
+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 t

[PATCH] D146426: [Sema] Fix crash on __fp16 parameters in template instantiations

2023-03-20 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov created this revision.
ilya-biryukov added a reviewer: kadircet.
Herald added a project: All.
ilya-biryukov requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Currently, Clang stores `nullptr` in the parameter lists inside
`FunctionProtoTypeLoc` if `__fp16` is used without pointer qualifiers.

Any code path that calls `Declarator::setInvalidType()` before
`GetFullTypeForDeclarator` will lead to the same problem downstream.

The relevant code is:

  cpp
  if (D.isInvalidType())
return Context.getTrivialTypeSourceInfo(T);
  
  return GetTypeSourceInfoForDeclarator(state, T, TInfo);

`GetTypeSourceInfoForDeclarator` sets the parameter `Decl`, but we can't
call it when `isInvalidType() == true` as this causes other assertion
failures that seem harder to fix.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146426

Files:
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/SemaCXX/crash-params.cpp


Index: clang/test/SemaCXX/crash-params.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/crash-params.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+template 
+int foo() {
+  auto x = [&](__fp16) { return 0; }; // expected-error {{parameters cannot 
have __fp16 type}}
+  return 0;
+}
+
+int bar() { return foo(); }
Index: clang/lib/Sema/SemaTemplateInstantiate.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -1343,7 +1343,7 @@
 
   CXXMethodDecl *MD = Result.getAs()->getCallOperator();
   for (ParmVarDecl *PVD : MD->parameters()) {
-if (!PVD->hasDefaultArg())
+if (!PVD || !PVD->hasDefaultArg())
   continue;
 Expr *UninstExpr = PVD->getUninstantiatedDefaultArg();
 // FIXME: Obtain the source location for the '=' token.
Index: clang/lib/Sema/SemaLambda.cpp
===
--- clang/lib/Sema/SemaLambda.cpp
+++ clang/lib/Sema/SemaLambda.cpp
@@ -966,8 +966,11 @@
   if (!Params.empty()) {
 CheckParmsForFunctionDef(Params, /*CheckParameterNames=*/false);
 Method->setParams(Params);
-for (auto P : Method->parameters())
+for (auto P : Method->parameters()) {
+  if (!P)
+continue;
   P->setOwningFunction(Method);
+}
   }
 
   buildLambdaScopeReturnType(*this, LSI, Method, HasExplicitResultType);
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -1721,6 +1721,8 @@
   e = FT->param_type_end();
i != e; ++i, ++ArgIndex) {
 const ParmVarDecl *PD = FD->getParamDecl(ArgIndex);
+if (!PD)
+  return false;
 SourceLocation ParamLoc = PD->getLocation();
 if (CheckLiteralType(SemaRef, Kind, ParamLoc, *i,
  diag::err_constexpr_non_literal_param, ArgIndex + 1,
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -15879,6 +15879,10 @@
 bool CheckParameterNames) {
   bool HasInvalidParm = false;
   for (ParmVarDecl *Param : Parameters) {
+if (!Param) {
+  HasInvalidParm = true;
+  continue;
+}
 // C99 6.7.5.3p4: the parameters in a parameter type list in a
 // function declarator that is part of a function definition of
 // that function shall not have incomplete type.


Index: clang/test/SemaCXX/crash-params.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/crash-params.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+template 
+int foo() {
+  auto x = [&](__fp16) { return 0; }; // expected-error {{parameters cannot have __fp16 type}}
+  return 0;
+}
+
+int bar() { return foo(); }
Index: clang/lib/Sema/SemaTemplateInstantiate.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -1343,7 +1343,7 @@
 
   CXXMethodDecl *MD = Result.getAs()->getCallOperator();
   for (ParmVarDecl *PVD : MD->parameters()) {
-if (!PVD->hasDefaultArg())
+if (!PVD || !PVD->hasDefaultArg())
   continue;
 Expr *UninstExpr = PVD->getUninstantiatedDefaultArg();
 // FIXME: Obtain the source location for the '=' token.
Index: clang/lib/Sema/SemaLambda.cpp
===
--- clang/lib/Sema/SemaLambda.cpp
+++ clang/lib/Sema/SemaLambda.cpp
@@ -966,8 +966,

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

2023-03-20 Thread Marco Falke via Phabricator via cfe-commits
MarcoFalke added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp:400
 void UseAfterMoveCheck::registerMatchers(MatchFinder *Finder) {
   auto CallMoveMatcher =
+  callExpr(

PiotrZSL wrote:
> This is correct but consider this:
> 
> ```
> auto TryEmplaceMatcher = 
> cxxMemberCallExpr(callee(cxxMethodDecl(hasName("try_emplace";
> 
> auto CallMoveMatcher =
> callExpr(argumentCountIs(1), // because matching this will be faster than 
> checking name.
>  callee(functionDecl(hasName("::std::move"))),
>  unless(inDecltypeOrTemplateArg()),
>  expr().bind("call-move"),
>  unless(hasParent(TryEmplaceMatcher)),
>  
> anyOf(hasAncestor(compoundStmt(hasParent(lambdaExpr().bind("containing-lambda",
> 
> hasAncestor(functionDecl(anyOf(cxxConstructorDecl(hasAnyConstructorInitializer(
>   
>  withInitializer(expr(
>   
> 
> anyOf(equalsBounNode("call-move"), 
>   
>
> hasDescendant(equalsBounNode("call-move")))
>   
>).bind("containing-ctor-init-stmt")
>   
> ))
>   
>).bind("containing-ctor"),
>  
> functionDecl().bind("containing-func")
> );
> ```
>   
I get:

```
error: no matching function for call to object of type 'const 
internal::ArgumentAdaptingMatcherFunc'

anyOf(equalsBoundNode("call-move"),hasDescendant(equalsBoundNode("call-move")))
   ^
./llvm-project/clang/include/clang/ASTMatchers/ASTMatchersInternal.h:1491:3: 
note: candidate template ignored: could not match 'Matcher' against 
'PolymorphicMatcher'
  operator()(const Matcher &InnerMatcher) const {
  ^
./llvm-project/clang/include/clang/ASTMatchers/ASTMatchersInternal.h:1498:3: 
note: candidate template ignored: could not match 'MapAnyOfHelper' against 
'PolymorphicMatcher'
  operator()(const MapAnyOfHelper &InnerMatcher) const {
  ^
1 error generated.
```



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp:1431
   std::string val_;
 };

PiotrZSL wrote:
> Missing tests:
> - Test with A derive from B, C, D, and argument is moved into C, but D 
> initialization also uses it.
> - Test with lambda call inside init, and in lambda std::move of captured by 
> reference constructor parameter, and lambda could be mutable, and lambda 
> could be saved into member (or passed to base class), or called instantly 
> (better both tests).
> - Test with lambda that takes argument into capture by move
> 
> In short:
> ```
> struct Obj {};
> struct D
> {
> D(Obj b);
> };
> 
> struct C
> {
>  C(Obj b);
> };
> 
> struct B
> {
>  B(Obj& b);
> }
> 
> struct A : B, C, D
> {
> A(Obj b)
>   : B(b), C(std::move(b)), D(b)
> {
> }
> };
> 
> and second:
> 
> struct Base
> {
> Base(Obj b) : bb(std::move(b)) {}
>  template
>  Base(T&& b) : bb(b()) {};
>
>  Obj bb;
> };
> 
> struct Derived : Base, C
> {
>  Derived(Obj b) 
>: Base([&] mutable { return std::move(b); }()), C(b)
>{
>}
> };
> 
> struct Derived2 : Base, C
> {
>  Derived2(Obj b) 
>: Base([&] mutable { return std::move(b); }), C(b)
>{
>}
> };
> 
> struct Derived3 : Base, C
> {
>  Derived3(Obj b) 
>: Base([c = std::move(b)] mutable { return std::move(c); }), C(b)
>{
>}
> };
> ```
I added the test `Derived2`, however, I wonder if it should throw a warning. In 
the general case, I don't think we can know whether `Base(Call&&call)` will 
actually call `call` and execute the `std::move`, no?


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

https://reviews.llvm.org/D146288

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


[PATCH] D145803: [clang][DebugInfo] Emit DW_AT_type of preferred name if available

2023-03-20 Thread Michael Buch via Phabricator via cfe-commits
Michael137 updated this revision to Diff 506588.
Michael137 added a comment.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

- Fix cycle in `DIDerivedType` when we deal with forward declarations and 
complete explicitly via `completeClassData` (e.g., with `-gmodules`)
- Add tests for `-gmodules`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145803

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/test/CodeGen/preferred_name.cpp
  clang/test/Modules/Inputs/gmodules-preferred-name-alias.h
  clang/test/Modules/Inputs/gmodules-preferred-name-alias.modulemap
  clang/test/Modules/Inputs/gmodules-preferred-name-typedef.h
  clang/test/Modules/Inputs/gmodules-preferred-name-typedef.modulemap
  clang/test/Modules/gmodules-preferred-name-alias.cpp
  clang/test/Modules/gmodules-preferred-name-typedef.cpp
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
  
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py

Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/unique_ptr/TestDataFormatterLibcxxUniquePtr.py
@@ -22,7 +22,7 @@
 
 def make_expected_basic_string_ptr(self) -> str:
 if self.expectedCompiler(["clang"]) and self.expectedCompilerVersion(['>', '16.0']):
-return f'std::unique_ptr >'
+return f'std::unique_ptr'
 else:
 return 'std::unique_ptr, std::allocator >, ' \
'std::default_delete, std::allocator > > >'
Index: lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/shared_ptr/TestDataFormatterLibcxxSharedPtr.py
@@ -59,13 +59,13 @@
 self.assertNotEqual(valobj.child[0].unsigned, 0)
 
 if self.expectedCompiler(["clang"]) and self.expectedCompilerVersion(['>', '16.0']):
-string_type = "std::basic_string"
+string_type = "std::string"
 else:
-string_type = "std::basic_string, std::allocator >"
+string_type = "std::basic_string, std::allocator > "
 
 valobj = self.expect_var_path(
 "sp_str",
-type="std::shared_ptr<" + string_type + " >",
+type="std::shared_ptr<" + string_type + ">",
 children=[ValueCheck(name="__ptr_", summary='"hello"')],
 )
 self.assertRegex(valobj.summary, r'^"hello"( strong=1)? weak=1$')
Index: clang/test/Modules/gmodules-preferred-name-typedef.cpp
===
--- /dev/null
+++ clang/test/Modules/gmodules-preferred-name-typedef.cpp
@@ -0,0 +1,12 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -std=c++11 -dwarf-ext-refs -fmodule-format=obj \
+// RUN: -fmodule-map-file=%S/Inputs/gmodules-preferred-name-typedef.modulemap \
+// RUN: -fmodules-cache-path=%t -debug-info-kind=standalone -debugger-tuning=lldb \
+// RUN: -fmodules -mllvm -debug-only=pchcontainer -x c++ \
+// RUN: -I %S/Inputs %s &> %t.ll
+// RUN: cat %t.ll | FileCheck %s
+
+#include "gmodules-preferred-name-typedef.h"
+
+// CHECK: ![[#]] = !DIDerivedType(tag: DW_TAG_typedef, name: "Bar", scope: ![[#]], file: ![[#]], line: [[#]], baseType: ![[PREF_BASE:[0-9]+]])
+// CHECK: ![[PREF_BASE]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Foo"
Index: clang/test/Modules/gmodules-preferred-name-alias.cpp
===
--- /dev/null
+++ clang/test/Modules/gmodules-preferred-name-alias.cpp
@@ -0,0 +1,12 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -std=c++11 -dwarf-ext-refs -fmodule-format=obj \
+// RUN: -fmodule-map-file=%S/Inputs/gmodules-preferred-name-alias.modulemap \
+// RUN: -fmodules-cache-path=%t -debug-info-kind=standalone -debugger-tuning=lldb \
+// RUN: -fmodules -mllvm -debug-only=pchcontainer -x c++ \
+// RUN: -I %S/Inputs %s &> %t.ll
+// RUN: cat %t.ll | FileCheck %s
+
+#include "gmodules-preferred-name-alias.h"
+
+// CHECK: ![[#]] = !DIDerivedType(tag: DW_TAG_typedef, name: "Bar", scope: ![[#]], file: ![[#]], line: [[#]], baseType: ![[PREF_BASE:[0-9]+]])
+// CHECK: ![[PREF_BASE]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name:

[PATCH] D146420: Document the Clang policies on claiming support for a feature

2023-03-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman marked 5 inline comments as done.
aaron.ballman added inline comments.



Comment at: clang/docs/InternalsManual.rst:3285
+  * Are there known issues with the feature that reject valid code?
+  * Are there known issues that fail to reject invalid code?
+  * Are there known crashes, failed assertions, or miscompilations?

cor3ntin wrote:
> any way to rephrase that, "that cause clamg to reject" maybe?
Sure, we can go with "accept invalid code" instead of "fail to reject invalid".



Comment at: clang/docs/InternalsManual.rst:3289
+
+If the answer to any of these is "yes", you should either not define the
+feature test macro or have very strong rationale for why the issues should not

erichkeane wrote:
> you -> we?  Rest of the doc is in 3rd person, this is in 2nd?
Reworded to remove the pronoun entirely.



Comment at: clang/docs/InternalsManual.rst:3292
+prevent defining it. Note, it is acceptable to define the feature test macro on
+a per-target basis if needed.
+

cor3ntin wrote:
> Is that desirable?
> If i have a build system checking for support through feature macros, I'm not 
> sure they do that on a target per target basis.
Maybe it's not desirable, I'm happy to hear arguments either way. The reason 
why I think this is reasonable is because we'll sometimes have a feature that 
works just fine everywhere EXCEPT a target (like coroutines work everywhere but 
have known miscompilation issues on 32-bit Windows). It seems somewhat 
unfortunate to not claim support anywhere because it's not supported on all 
targets -- some users likely never target 32-bit Windows in the first place.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146420

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


[PATCH] D146420: Document the Clang policies on claiming support for a feature

2023-03-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman updated this revision to Diff 506591.
aaron.ballman marked 2 inline comments as done.
aaron.ballman added a comment.

Updating based on review feedback.

(Note: Phab seems to be confused about the changes being at the end of the file 
-- it claims there's no trailing context for the patch and that's what seems to 
disable the ability to make suggested edits.)


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

https://reviews.llvm.org/D146420

Files:
  clang/docs/InternalsManual.rst


Index: clang/docs/InternalsManual.rst
===
--- clang/docs/InternalsManual.rst
+++ clang/docs/InternalsManual.rst
@@ -3268,3 +3268,39 @@
  proper visitation for your expression, enabling various IDE features such
  as syntax highlighting, cross-referencing, and so on.  The
  ``c-index-test`` helper program can be used to test these features.
+
+Feature Test Macros
+===
+Clang implements several ways to test whether a feature is supported or not.
+Some of these feature tests are standardized, like ``__has_cpp_attribute`` or
+``__cpp_lambdas``, while others are Clang extensions, like ``__has_builtin``.
+The common theme among all the various feature tests is that they are a utility
+to tell users that we think a particular feature is complete. However,
+completeness is a difficult property to define because features may still have
+lingering bugs, may only work on some targets, etc. We use the following
+criteria when deciding whether to expose a feature test macro (or particular
+result value for the feature test):
+
+  * Are there known issues with the feature that reject valid code?
+  * Are there known issues that accept invalid code?
+  * Are there known crashes, failed assertions, or miscompilations?
+  * Are there known issues on a particular relevant target?
+
+If the answer to any of these is "yes", the feature test macro should either
+not be defined or there should be very strong rationale for why the issues
+should not prevent defining it. Note, it is acceptable to define the feature
+test macro on a per-target basis if needed.
+
+When in doubt, being conservative is better than being aggressive. If we don't
+claim support for the feature but it does useful things, users can still use it
+and provide us with useful feedback on what is missing. But if we claim support
+for a feature that has significant bugs, we've eliminated most of the utility
+of having a feature testing macro at all because users are then forced to test
+what compiler version is in use to get a more accurate answer.
+
+The status reported by the feature test macro should always be reflected in the
+language support page for the corresponding feature (`C++
+`_, `C
+`_) if applicable. This page can give
+more nuanced information to the user as well, such claiming partial support for
+a feature and specifying details as to what remains to be done.


Index: clang/docs/InternalsManual.rst
===
--- clang/docs/InternalsManual.rst
+++ clang/docs/InternalsManual.rst
@@ -3268,3 +3268,39 @@
  proper visitation for your expression, enabling various IDE features such
  as syntax highlighting, cross-referencing, and so on.  The
  ``c-index-test`` helper program can be used to test these features.
+
+Feature Test Macros
+===
+Clang implements several ways to test whether a feature is supported or not.
+Some of these feature tests are standardized, like ``__has_cpp_attribute`` or
+``__cpp_lambdas``, while others are Clang extensions, like ``__has_builtin``.
+The common theme among all the various feature tests is that they are a utility
+to tell users that we think a particular feature is complete. However,
+completeness is a difficult property to define because features may still have
+lingering bugs, may only work on some targets, etc. We use the following
+criteria when deciding whether to expose a feature test macro (or particular
+result value for the feature test):
+
+  * Are there known issues with the feature that reject valid code?
+  * Are there known issues that accept invalid code?
+  * Are there known crashes, failed assertions, or miscompilations?
+  * Are there known issues on a particular relevant target?
+
+If the answer to any of these is "yes", the feature test macro should either
+not be defined or there should be very strong rationale for why the issues
+should not prevent defining it. Note, it is acceptable to define the feature
+test macro on a per-target basis if needed.
+
+When in doubt, being conservative is better than being aggressive. If we don't
+claim support for the feature but it does useful things, users can still use it
+and provide us with useful feedback on what is missing. But if we claim support
+for a feature that has significant bugs, we

[PATCH] D146427: [clang-tools-extra] Fix linking ClangdTests when using libclang-cpp

2023-03-20 Thread Michał Górny via Phabricator via cfe-commits
mgorny created this revision.
mgorny added reviewers: DmitryPolukhin, kadircet, tstellar, MaskRay.
Herald added subscribers: mikhail.ramalho, arphaman.
Herald added a project: All.
mgorny requested review of this revision.
Herald added a subscriber: ilya-biryukov.
Herald added a project: clang-tools-extra.

Fix linking ClangdTests to specify the dependency on the private
clangTesting library via target_link_libraries() rather than
clang_target_link_libraries().  The latter uses libclang-cpp when
CLANG_LINK_CLANG_DYLIB is used, and clangTesting is not included
in this library.

This fixes d60d3455eb2b375d026a4aa74c4ba0c38f5d323c 
.


https://reviews.llvm.org/D146427

Files:
  clang-tools-extra/clangd/unittests/CMakeLists.txt


Index: clang-tools-extra/clangd/unittests/CMakeLists.txt
===
--- clang-tools-extra/clangd/unittests/CMakeLists.txt
+++ clang-tools-extra/clangd/unittests/CMakeLists.txt
@@ -157,7 +157,6 @@
   clangLex
   clangSema
   clangSerialization
-  clangTesting
   clangTooling
   clangToolingCore
   clangToolingInclusions
@@ -172,6 +171,7 @@
 
   clangDaemon
   clangIncludeCleaner
+  clangTesting
   clangTidy
   clangdSupport
   )


Index: clang-tools-extra/clangd/unittests/CMakeLists.txt
===
--- clang-tools-extra/clangd/unittests/CMakeLists.txt
+++ clang-tools-extra/clangd/unittests/CMakeLists.txt
@@ -157,7 +157,6 @@
   clangLex
   clangSema
   clangSerialization
-  clangTesting
   clangTooling
   clangToolingCore
   clangToolingInclusions
@@ -172,6 +171,7 @@
 
   clangDaemon
   clangIncludeCleaner
+  clangTesting
   clangTidy
   clangdSupport
   )
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] fa326c2 - Revert "[clang][ASTImport] Add support for import of empty records"

2023-03-20 Thread Pavel Kosov via cfe-commits

Author: Pavel Kosov
Date: 2023-03-20T18:20:41+03:00
New Revision: fa326c21919faea33b0470b7083dccbd3c1fc3f2

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

LOG: Revert "[clang][ASTImport] Add support for import of empty records"

This reverts commit 21cd04c46fe0a2bee224899f56518a09bce5306e.

Added: 


Modified: 
clang/include/clang/AST/ASTImporter.h
clang/include/clang/AST/DeclCXX.h
clang/lib/AST/ASTImporter.cpp
clang/unittests/AST/ASTImporterTest.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTImporter.h 
b/clang/include/clang/AST/ASTImporter.h
index 4ffd913846575..f851decd0965c 100644
--- a/clang/include/clang/AST/ASTImporter.h
+++ b/clang/include/clang/AST/ASTImporter.h
@@ -258,7 +258,6 @@ class TypeSourceInfo;
 FoundDeclsTy findDeclsInToCtx(DeclContext *DC, DeclarationName Name);
 
 void AddToLookupTable(Decl *ToD);
-llvm::Error ImportAttrs(Decl *ToD, Decl *FromD);
 
   protected:
 /// Can be overwritten by subclasses to implement their own import logic.

diff  --git a/clang/include/clang/AST/DeclCXX.h 
b/clang/include/clang/AST/DeclCXX.h
index dd35ef4adfd70..ff8f8a1bb12d6 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -1165,10 +1165,6 @@ class CXXRecordDecl : public RecordDecl {
   ///
   /// \note This does NOT include a check for union-ness.
   bool isEmpty() const { return data().Empty; }
-  /// Marks this record as empty. This is used by DWARFASTParserClang
-  /// when parsing records with empty fields having [[no_unique_address]]
-  /// attribute
-  void markEmpty() { data().Empty = true; }
 
   void setInitMethod(bool Val) { data().HasInitMethod = Val; }
   bool hasInitMethod() const { return data().HasInitMethod; }

diff  --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index d0da2dae3aa23..bd055082778df 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -3895,12 +3895,6 @@ ExpectedDecl ASTNodeImporter::VisitFieldDecl(FieldDecl 
*D) {
   D->getInClassInitStyle()))
 return ToField;
 
-  // We need [[no_unqiue_address]] attributes to be added to FieldDecl, before
-  // we add fields in CXXRecordDecl::addedMember, otherwise record will be
-  // marked as having non-zero size.
-  Err = Importer.ImportAttrs(ToField, D);
-  if (Err)
-return std::move(Err);
   ToField->setAccess(D->getAccess());
   ToField->setLexicalDeclContext(LexicalDC);
   if (ToInitializer)
@@ -8987,19 +8981,6 @@ TranslationUnitDecl *ASTImporter::GetFromTU(Decl *ToD) {
   return FromDPos->second->getTranslationUnitDecl();
 }
 
-Error ASTImporter::ImportAttrs(Decl *ToD, Decl *FromD) {
-  if (!FromD->hasAttrs() || ToD->hasAttrs())
-return Error::success();
-  for (const Attr *FromAttr : FromD->getAttrs()) {
-auto ToAttrOrErr = Import(FromAttr);
-if (ToAttrOrErr)
-  ToD->addAttr(*ToAttrOrErr);
-else
-  return ToAttrOrErr.takeError();
-  }
-  return Error::success();
-}
-
 Expected ASTImporter::Import(Decl *FromD) {
   if (!FromD)
 return nullptr;
@@ -9134,8 +9115,15 @@ Expected ASTImporter::Import(Decl *FromD) {
 
   // Make sure that ImportImpl registered the imported decl.
   assert(ImportedDecls.count(FromD) != 0 && "Missing call to MapImported?");
-  if (auto Error = ImportAttrs(ToD, FromD))
-return std::move(Error);
+
+  if (FromD->hasAttrs())
+for (const Attr *FromAttr : FromD->getAttrs()) {
+  auto ToAttrOrErr = Import(FromAttr);
+  if (ToAttrOrErr)
+ToD->addAttr(*ToAttrOrErr);
+  else
+return ToAttrOrErr.takeError();
+}
 
   // Notify subclasses.
   Imported(FromD, ToD);

diff  --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index 7dd4c81074c76..6300551ca4469 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -8478,29 +8478,6 @@ TEST_P(ASTImporterOptionSpecificTestBase, VaListCpp) {
   ToVaList->getUnderlyingType(), ToBuiltinVaList->getUnderlyingType()));
 }
 
-TEST_P(ASTImporterOptionSpecificTestBase,
-   ImportDefinitionOfEmptyClassWithNoUniqueAddressField) {
-  Decl *FromTU = getTuDecl(
-  R"(
-  struct B {};
-  struct A { B b; };
-  )",
-  Lang_CXX20);
-
-  CXXRecordDecl *FromD = FirstDeclMatcher().match(
-  FromTU, cxxRecordDecl(hasName("A")));
-
-  for (auto *FD : FromD->fields())
-FD->addAttr(clang::NoUniqueAddressAttr::Create(FromD->getASTContext(),
-   clang::SourceRange()));
-  FromD->markEmpty();
-
-  CXXRecordDecl *ToD = cast(Import(FromD, Lang_CXX20));
-  EXPECT_EQ(true, ToD->isEmpty());
-  for (auto *FD : ToD->fields())
-EXPECT_EQ(true, FD->hasAttr());
-}
-
 INSTANTIAT

[PATCH] D146393: [Clang] Support free positioning of labels inside compound statements in C

2023-03-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added subscribers: jyu2, mikerice, jdoerfert.
aaron.ballman added inline comments.



Comment at: clang/lib/Parse/ParseStmt.cpp:745
 SubStmt = Actions.ActOnNullStmt(ColonLoc);
 
   LabelDecl *LD = Actions.LookupOrCreateLabel(IdentTok.getIdentifierInfo(),

At this point, you know whether you've parsed a declaration statement or not, 
so you could potentially add the extension diagnostic logic here.



Comment at: clang/test/OpenMP/threadprivate_messages.cpp:141
 label:
-#pragma omp threadprivate(d4) // expected-error {{'#pragma omp threadprivate' 
cannot be an immediate substatement}}
+#pragma omp threadprivate(d4)
 

Izaron wrote:
> TODO: find out if this is okay? (I've got no idea what it does)
CC @mikerice @jyu2 @jdoerfert for opinions on OpenMP impact. There are FIXMEs 
in the code related to this: 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseOpenMP.cpp#L2671



Comment at: clang/test/Parser/c2x-label.c:5-6
 void test_label_in_func() {
-int x;
 label1:
+int x;
+label2:

Izaron wrote:
> TODO: make sure a warning is printed. I couldn't find correct conditions for 
> the warning, I tried and it produced false positive warnings in some other 
> tests =(
> 
> P.S. Its C++'s counterpart: 
> https://github.com/llvm/llvm-project/blob/main/clang/test/Parser/cxx2b-label.cpp
Yeah, this would be specific to C because C++ has always allowed a declaration 
there. I left a comment above with a potential idea.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146393

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


[PATCH] D146354: [clang][ExtractAPI] Add semicolons for enum, typedef, struct declaration fragments

2023-03-20 Thread NagaChaitanya Vellanki via Phabricator via cfe-commits
chaitanyav added a comment.

Thank you, Please go ahead and Commit the change. I don't have commit access, 
Will follow the instructions on the page to get access.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146354

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


[PATCH] D146278: [flang] add -flang-experimental-hlfir flag to flang-new

2023-03-20 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added inline comments.



Comment at: flang/test/Driver/mlir-pass-pipeline.f90:15-18
+! O2-NEXT: Canonicalizer
+! ALL-NEXT: LowerHLFIRIntrinsics
+! ALL-NEXT: BufferizeHLFIR
+! ALL-NEXT: ConvertHLFIRtoFIR

tblah wrote:
> awarzynski wrote:
> > It looks like these passes are run unconditionally - what's the 
> > `-flang-experimental-hlfir` flag for then?
> Yes. @vzakhari requested the passes should run unconditionally.
> 
> `-flang-experimental-hlfir` controls whether the HLFIR lowering is used. 
Ok, so so far you have updated the default pass pipelines and that's what you 
are testing here. However, this patch is about `-flang-experimental-hlfir` - 
can you add a test for this flag?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146278

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


[PATCH] D146354: [clang][ExtractAPI] Add semicolons for enum, typedef, struct declaration fragments

2023-03-20 Thread NagaChaitanya Vellanki via Phabricator via cfe-commits
chaitanyav added a comment.

Name: NagaChaitanya Vellanki
email: pnag...@protonmail.com


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146354

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


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

2023-03-20 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp:400
 void UseAfterMoveCheck::registerMatchers(MatchFinder *Finder) {
   auto CallMoveMatcher =
+  callExpr(

MarcoFalke wrote:
> PiotrZSL wrote:
> > This is correct but consider this:
> > 
> > ```
> > auto TryEmplaceMatcher = 
> > cxxMemberCallExpr(callee(cxxMethodDecl(hasName("try_emplace";
> > 
> > auto CallMoveMatcher =
> > callExpr(argumentCountIs(1), // because matching this will be faster than 
> > checking name.
> >  callee(functionDecl(hasName("::std::move"))),
> >  unless(inDecltypeOrTemplateArg()),
> >  expr().bind("call-move"),
> >  unless(hasParent(TryEmplaceMatcher)),
> >  
> > anyOf(hasAncestor(compoundStmt(hasParent(lambdaExpr().bind("containing-lambda",
> > 
> > hasAncestor(functionDecl(anyOf(cxxConstructorDecl(hasAnyConstructorInitializer(
> > 
> >withInitializer(expr(
> > 
> >   
> > anyOf(equalsBounNode("call-move"), 
> > 
> >  
> > hasDescendant(equalsBounNode("call-move")))
> > 
> >  ).bind("containing-ctor-init-stmt")
> > 
> >   ))
> > 
> >  ).bind("containing-ctor"),
> > 
> >  functionDecl().bind("containing-func")
> > );
> > ```
> >   
> I get:
> 
> ```
> error: no matching function for call to object of type 'const 
> internal::ArgumentAdaptingMatcherFunc'
> 
> anyOf(equalsBoundNode("call-move"),hasDescendant(equalsBoundNode("call-move")))
>^
> ./llvm-project/clang/include/clang/ASTMatchers/ASTMatchersInternal.h:1491:3: 
> note: candidate template ignored: could not match 'Matcher' against 
> 'PolymorphicMatcher'
>   operator()(const Matcher &InnerMatcher) const {
>   ^
> ./llvm-project/clang/include/clang/ASTMatchers/ASTMatchersInternal.h:1498:3: 
> note: candidate template ignored: could not match 'MapAnyOfHelper' against 
> 'PolymorphicMatcher'
>   operator()(const MapAnyOfHelper &InnerMatcher) const {
>   ^
> 1 error generated.
> ```
yee, forgot type: `hasDescendant(callExpr(equalsBoundNode("call-move"`
+- something like this..


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

https://reviews.llvm.org/D146288

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


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

2023-03-20 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp:1431
   std::string val_;
 };

MarcoFalke wrote:
> PiotrZSL wrote:
> > Missing tests:
> > - Test with A derive from B, C, D, and argument is moved into C, but D 
> > initialization also uses it.
> > - Test with lambda call inside init, and in lambda std::move of captured by 
> > reference constructor parameter, and lambda could be mutable, and lambda 
> > could be saved into member (or passed to base class), or called instantly 
> > (better both tests).
> > - Test with lambda that takes argument into capture by move
> > 
> > In short:
> > ```
> > struct Obj {};
> > struct D
> > {
> > D(Obj b);
> > };
> > 
> > struct C
> > {
> >  C(Obj b);
> > };
> > 
> > struct B
> > {
> >  B(Obj& b);
> > }
> > 
> > struct A : B, C, D
> > {
> > A(Obj b)
> >   : B(b), C(std::move(b)), D(b)
> > {
> > }
> > };
> > 
> > and second:
> > 
> > struct Base
> > {
> > Base(Obj b) : bb(std::move(b)) {}
> >  template
> >  Base(T&& b) : bb(b()) {};
> >
> >  Obj bb;
> > };
> > 
> > struct Derived : Base, C
> > {
> >  Derived(Obj b) 
> >: Base([&] mutable { return std::move(b); }()), C(b)
> >{
> >}
> > };
> > 
> > struct Derived2 : Base, C
> > {
> >  Derived2(Obj b) 
> >: Base([&] mutable { return std::move(b); }), C(b)
> >{
> >}
> > };
> > 
> > struct Derived3 : Base, C
> > {
> >  Derived3(Obj b) 
> >: Base([c = std::move(b)] mutable { return std::move(c); }), C(b)
> >{
> >}
> > };
> > ```
> I added the test `Derived2`, however, I wonder if it should throw a warning. 
> In the general case, I don't think we can know whether `Base(Call&&call)` 
> will actually call `call` and execute the `std::move`, no?
For me:
Derived - should throw a warning - same type used before C(b) (but questionable)
Derived 2 -> also should throw warning (but questionable)
Derived 3 -> also should throw warning

Note that Derived & Derived 2 could be considered different issue, like use 
after free (because we take reference to argument), it's safe to assume that it 
would be called anyway, because later that argument reference could become 
invalid. But it could be also fine to not throw issue. For is better to throw & 
nolint than ignore and crash.
But thats your call.


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

https://reviews.llvm.org/D146288

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


[PATCH] D146354: [clang][ExtractAPI] Add semicolons for enum, typedef, struct declaration fragments

2023-03-20 Thread Daniel Grumberg 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 rGafce10c5b60f: [clang][ExtractAPI] Add semicolons for enum, 
typedef, struct declaration… (authored by chaitanyav, committed by dang).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146354

Files:
  clang/lib/ExtractAPI/DeclarationFragments.cpp
  clang/test/ExtractAPI/anonymous_record_no_typedef.c
  clang/test/ExtractAPI/enum.c
  clang/test/ExtractAPI/struct.c
  clang/test/ExtractAPI/typedef.c
  clang/test/ExtractAPI/typedef_anonymous_record.c
  clang/test/ExtractAPI/typedef_chain.c
  clang/test/ExtractAPI/underscored.c

Index: clang/test/ExtractAPI/underscored.c
===
--- clang/test/ExtractAPI/underscored.c
+++ clang/test/ExtractAPI/underscored.c
@@ -135,6 +135,10 @@
 {
   "kind": "identifier",
   "spelling": "ExposedRecord"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
@@ -296,6 +300,10 @@
 {
   "kind": "identifier",
   "spelling": "ExposedTypedef"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
@@ -356,6 +364,10 @@
 {
   "kind": "identifier",
   "spelling": "ExposedTypedefToHidden"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
Index: clang/test/ExtractAPI/typedef_chain.c
===
--- clang/test/ExtractAPI/typedef_chain.c
+++ clang/test/ExtractAPI/typedef_chain.c
@@ -68,6 +68,10 @@
 {
   "kind": "identifier",
   "spelling": "MyInt"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
@@ -128,6 +132,10 @@
 {
   "kind": "identifier",
   "spelling": "MyIntInt"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
@@ -188,6 +196,10 @@
 {
   "kind": "identifier",
   "spelling": "MyIntIntInt"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
Index: clang/test/ExtractAPI/typedef_anonymous_record.c
===
--- clang/test/ExtractAPI/typedef_anonymous_record.c
+++ clang/test/ExtractAPI/typedef_anonymous_record.c
@@ -75,6 +75,10 @@
 {
   "kind": "identifier",
   "spelling": "MyEnum"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
@@ -170,6 +174,10 @@
 {
   "kind": "identifier",
   "spelling": "MyStruct"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
@@ -223,6 +231,10 @@
 {
   "kind": "identifier",
   "spelling": "MyStructStruct"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
@@ -283,6 +295,10 @@
 {
   "kind": "identifier",
   "spelling": "MyStructStructStruct"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
@@ -343,6 +359,10 @@
 {
   "kind": "identifier",
   "spelling": "MyEnumEnum"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
@@ -403,6 +423,10 @@
 {
   "kind": "identifier",
   "spelling": "MyEnumEnumEnum"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
Index: clang/test/ExtractAPI/typedef.c
===
--- clang/test/ExtractAPI/typedef.c
+++ clang/test/ExtractAPI/typedef.c
@@ -66,6 +66,10 @@
 {
   "kind": "identifier",
   "spelling": "MyInt"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
Index: clang/test/ExtractAPI/struct.c
===
--- clang/test/ExtractAPI/struct.c
+++ clang/test/ExtractAPI/struct.c
@@ -89,6 +89,10 @@
 {
   "kind": "identifier",
   "spelling": "Color"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "docComment": {
Index: clang/test/ExtractAPI/enum.c
===
--- clang/test/ExtractAPI/enum.c
+++ clang/tes

[clang] afce10c - [clang][ExtractAPI] Add semicolons for enum, typedef, struct declaration fragments

2023-03-20 Thread Daniel Grumberg via cfe-commits

Author: NagaChaitanya Vellanki
Date: 2023-03-20T15:43:00Z
New Revision: afce10c5b60fada1db369d3770f4389da7ef30ef

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

LOG: [clang][ExtractAPI] Add semicolons for enum, typedef, struct declaration 
fragments

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

Reviewed By: dang

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

Added: 


Modified: 
clang/lib/ExtractAPI/DeclarationFragments.cpp
clang/test/ExtractAPI/anonymous_record_no_typedef.c
clang/test/ExtractAPI/enum.c
clang/test/ExtractAPI/struct.c
clang/test/ExtractAPI/typedef.c
clang/test/ExtractAPI/typedef_anonymous_record.c
clang/test/ExtractAPI/typedef_chain.c
clang/test/ExtractAPI/underscored.c

Removed: 




diff  --git a/clang/lib/ExtractAPI/DeclarationFragments.cpp 
b/clang/lib/ExtractAPI/DeclarationFragments.cpp
index 12c91c582aa98..b8de1270b5f02 100644
--- a/clang/lib/ExtractAPI/DeclarationFragments.cpp
+++ b/clang/lib/ExtractAPI/DeclarationFragments.cpp
@@ -470,7 +470,7 @@ DeclarationFragmentsBuilder::getFragmentsForEnum(const 
EnumDecl *EnumDecl) {
 getFragmentsForType(IntegerType, EnumDecl->getASTContext(), After))
 .append(std::move(After));
 
-  return Fragments;
+  return Fragments.append(";", DeclarationFragments::FragmentKind::Text);
 }
 
 DeclarationFragments
@@ -493,7 +493,8 @@ DeclarationFragmentsBuilder::getFragmentsForStruct(const 
RecordDecl *Record) {
   if (!Record->getName().empty())
 Fragments.appendSpace().append(
 Record->getName(), DeclarationFragments::FragmentKind::Identifier);
-  return Fragments;
+
+  return Fragments.append(";", DeclarationFragments::FragmentKind::Text);
 }
 
 DeclarationFragments
@@ -743,7 +744,7 @@ DeclarationFragments 
DeclarationFragmentsBuilder::getFragmentsForTypedef(
   .appendSpace()
   .append(Decl->getName(), DeclarationFragments::FragmentKind::Identifier);
 
-  return Fragments;
+  return Fragments.append(";", DeclarationFragments::FragmentKind::Text);
 }
 
 template 

diff  --git a/clang/test/ExtractAPI/anonymous_record_no_typedef.c 
b/clang/test/ExtractAPI/anonymous_record_no_typedef.c
index abb96db058dbf..880a42c30ceb8 100644
--- a/clang/test/ExtractAPI/anonymous_record_no_typedef.c
+++ b/clang/test/ExtractAPI/anonymous_record_no_typedef.c
@@ -94,6 +94,10 @@ struct Vehicle {
   "kind": "typeIdentifier",
   "preciseIdentifier": "c:i",
   "spelling": "unsigned int"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "docComment": {
@@ -241,6 +245,10 @@ struct Vehicle {
 {
   "kind": "identifier",
   "spelling": "Vehicle"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "docComment": {

diff  --git a/clang/test/ExtractAPI/enum.c b/clang/test/ExtractAPI/enum.c
index 7b345464cb982..a6c749028bd17 100644
--- a/clang/test/ExtractAPI/enum.c
+++ b/clang/test/ExtractAPI/enum.c
@@ -153,6 +153,10 @@ enum {
   "kind": "typeIdentifier",
   "preciseIdentifier": "c:i",
   "spelling": "unsigned int"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "docComment": {
@@ -461,6 +465,10 @@ enum {
   "kind": "typeIdentifier",
   "preciseIdentifier": "c:c",
   "spelling": "unsigned char"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
@@ -684,6 +692,10 @@ enum {
   "kind": "typeIdentifier",
   "preciseIdentifier": "c:i",
   "spelling": "unsigned int"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {
@@ -772,6 +784,10 @@ enum {
   "kind": "typeIdentifier",
   "preciseIdentifier": "c:i",
   "spelling": "unsigned int"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "identifier": {

diff  --git a/clang/test/ExtractAPI/struct.c b/clang/test/ExtractAPI/struct.c
index 7e93f0d7e7bfa..cd6d25d835821 100644
--- a/clang/test/ExtractAPI/struct.c
+++ b/clang/test/ExtractAPI/struct.c
@@ -89,6 +89,10 @@ struct Color {
 {
   "kind": "identifier",
   "spelling": "Color"
+},
+{
+  "kind": "text",
+  "spelling": ";"
 }
   ],
   "docComment": {

diff  --git a/clang/test/ExtractAPI/typedef.c b/clang/test/ExtractAPI/typedef.c
index fb9b8ef32cdc1..89df9db8b362d 100644
--- a/clang/test/ExtractAPI/typedef.c
+++ b/clang/test/ExtractAPI/typedef.c
@@ -66,6 +66,10 @@ typedef int MyInt;
 {
   "kind": "id

[PATCH] D144870: [Clang][DebugInfo] Emit zero size bitfields in the debug info to delimit bitfields in different allocation units.

2023-03-20 Thread Juan Manuel Martinez Caamaño via Phabricator via cfe-commits
jmmartinez updated this revision to Diff 506611.
jmmartinez added a comment.

- Updated to use `elements` array to avoid the complicated loop.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144870

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/test/CodeGen/debug-info-bitfield-0-struct.c

Index: clang/test/CodeGen/debug-info-bitfield-0-struct.c
===
--- /dev/null
+++ clang/test/CodeGen/debug-info-bitfield-0-struct.c
@@ -0,0 +1,119 @@
+// RUN: %clang_cc1 -triple x86_64-unk-unk -o - -emit-llvm -debug-info-kind=limited %s | FileCheck --check-prefixes NOSEPARATOR,BOTH %s
+// RUN: %clang_cc1 -triple amdgcn-unk-unk -o - -emit-llvm -debug-info-kind=limited %s | FileCheck --check-prefixes SEPARATOR,BOTH %s
+
+struct First {
+  // BOTH-DAG: ![[FIRST:[0-9]+]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "First", file: !{{[0-9]+}}, line: {{[0-9]+}}, size: 32, elements: ![[FIRST_ELEMENTS:[0-9]+]])
+  // BOTH-DAG: ![[FIRST_ELEMENTS]] = !{![[FIRST_X:[0-9]+]], ![[FIRST_Y:[0-9]+]]}
+  // BOTH-DAG: ![[FIRST_X]] = !DIDerivedType(tag: DW_TAG_member, name: "x", scope: ![[FIRST]], file: !{{[0-9]+}}, line: {{[0-9]+}}, baseType: !{{[0-9]+}}, size: 4, flags: DIFlagBitField, extraData: i64 0)
+  // BOTH-DAG: ![[FIRST_Y]] = !DIDerivedType(tag: DW_TAG_member, name: "y", scope: ![[FIRST]], file: !{{[0-9]+}}, line: {{[0-9]+}}, baseType: !{{[0-9]+}}, size: 4, offset: 4, flags: DIFlagBitField, extraData: i64 0)
+  int : 0;
+  int x : 4;
+  int y : 4;
+};
+
+struct FirstDuplicate {
+  // BOTH-DAG: ![[FIRSTD:[0-9]+]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "FirstDuplicate", file: !{{[0-9]+}}, line: {{[0-9]+}}, size: 32, elements: ![[FIRSTD_ELEMENTS:[0-9]+]])
+  // BOTH-DAG: ![[FIRSTD_ELEMENTS]] = !{![[FIRSTD_X:[0-9]+]], ![[FIRSTD_Y:[0-9]+]]}
+  // BOTH-DAG: ![[FIRSTD_X]] = !DIDerivedType(tag: DW_TAG_member, name: "x", scope: ![[FIRSTD]], file: !{{[0-9]+}}, line: {{[0-9]+}}, baseType: !{{[0-9]+}}, size: 4, flags: DIFlagBitField, extraData: i64 0)
+  // BOTH-DAG: ![[FIRSTD_Y]] = !DIDerivedType(tag: DW_TAG_member, name: "y", scope: ![[FIRSTD]], file: !{{[0-9]+}}, line: {{[0-9]+}}, baseType: !{{[0-9]+}}, size: 4, offset: 4, flags: DIFlagBitField, extraData: i64 0)
+  int : 0;
+  int : 0;
+  int x : 4;
+  int y : 4;
+};
+
+struct Second {
+  // BOTH-DAG: ![[SECOND:[0-9]+]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Second", file: !{{[0-9]+}}, line: {{[0-9]+}}, size: 64, elements: ![[SECOND_ELEMENTS:[0-9]+]])
+
+  // NOSEPARATOR-DAG: ![[SECOND_ELEMENTS]] = !{![[SECOND_X:[0-9]+]], ![[SECOND_Y:[0-9]+]]}
+  // SEPARATOR-DAG: ![[SECOND_ELEMENTS]] = !{![[SECOND_X:[0-9]+]], ![[SECOND_ZERO:[0-9]+]], ![[SECOND_Y:[0-9]+]]}
+
+  // BOTH-DAG: ![[SECOND_X]] = !DIDerivedType(tag: DW_TAG_member, name: "x", scope: ![[SECOND]], file: !{{[0-9]+}}, line: {{[0-9]+}}, baseType: !{{[0-9]+}}, size: 4, flags: DIFlagBitField, extraData: i64 0)
+  // SEPARATOR-DAG: ![[SECOND_ZERO]] = !DIDerivedType(tag: DW_TAG_member, scope: ![[SECOND]], file: !{{[0-9]+}}, line: {{[0-9]+}}, baseType: !{{[0-9]+}}, offset: 32, flags: DIFlagBitField, extraData: i64 32)
+  // BOTH-DAG: ![[SECOND_Y]] = !DIDerivedType(tag: DW_TAG_member, name: "y", scope: ![[SECOND]], file: !{{[0-9]+}}, line: {{[0-9]+}}, baseType: !{{[0-9]+}}, size: 4, offset: 32, flags: DIFlagBitField, extraData: i64 32)
+  int x : 4;
+  int : 0;
+  int y : 4;
+};
+
+struct SecondDuplicate {
+  // BOTH-DAG: ![[SECONDD:[0-9]+]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "SecondDuplicate", file: !{{[0-9]+}}, line: {{[0-9]+}}, size: 64, elements: ![[SECONDD_ELEMENTS:[0-9]+]])
+
+  // NOSEPARATOR-DAG: ![[SECONDD_ELEMENTS]] = !{![[SECONDD_X:[0-9]+]], ![[SECONDD_Y:[0-9]+]]}
+  // SEPARATOR-DAG: ![[SECONDD_ELEMENTS]] = !{![[SECONDD_X:[0-9]+]], ![[SECONDD_ZERO:[0-9]+]], ![[SECONDD_Y:[0-9]+]]}
+
+  // BOTH-DAG: ![[SECONDD_X]] = !DIDerivedType(tag: DW_TAG_member, name: "x", scope: ![[SECONDD]], file: !{{[0-9]+}}, line: {{[0-9]+}}, baseType: !{{[0-9]+}}, size: 4, flags: DIFlagBitField, extraData: i64 0)
+  // SEPARATOR-DAG: ![[SECONDD_ZERO]] = !DIDerivedType(tag: DW_TAG_member, scope: ![[SECONDD]], file: !{{[0-9]+}}, line: {{[0-9]+}}, baseType: !{{[0-9]+}}, offset: 32, flags: DIFlagBitField, extraData: i64 32)
+  // BOTH-DAG: ![[SECONDD_Y]] = !DIDerivedType(tag: DW_TAG_member, name: "y", scope: ![[SECONDD]], file: !{{[0-9]+}}, line: {{[0-9]+}}, baseType: !{{[0-9]+}}, size: 4, offset: 32, flags: DIFlagBitField, extraData: i64 32)
+  int x : 4;
+  int : 0;
+  int : 0;
+  int y : 4;
+};
+
+struct Last {
+  // BOTH-DAG: ![[LAST:[0-9]+]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "Last", file: !{{[0-9]+}}, line: {{[0-9]+}}, size: 32, elements: ![[LAST_ELEMENTS:[0-9]+]])
+  // BOTH-DAG: ![[LAST

[PATCH] D146426: [Sema] Fix crash on __fp16 parameters in template instantiations

2023-03-20 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added a comment.

Please edit the summary to indicate this fixes: 
https://github.com/llvm/llvm-project/issues/61441

I am happy someone had more time to dig into this problem after my initial 
investigation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146426

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


[PATCH] D146426: [Sema] Fix crash on __fp16 parameters in template instantiations

2023-03-20 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

In D146426#4206519 , @shafik wrote:

> Please edit the summary to indicate this fixes: 
> https://github.com/llvm/llvm-project/issues/61441
> I am happy someone had more time to dig into this problem after my initial 
> investigation.

Thanks, done!
I wasn't aware of the upstream bug and your prior investigation. It would have 
definitely saved some time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146426

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


[PATCH] D146426: [Sema] Fix crash on __fp16 parameters in template instantiations

2023-03-20 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added inline comments.



Comment at: clang/test/SemaCXX/crash-params.cpp:3
+
+template 
+int foo() {

If this test really does not fit into any other test set the please rename the 
test file `GH61441.cpp` so we know it is a regression test for that github bug 
report.

Otherwise if we add a test from a bug report into an existing test file then we 
wrap it something like `namespace GH61441` so we know that test is a regression 
test for github bug 61441.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146426

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


[PATCH] D146426: [Sema] Fix crash on __fp16 parameters in template instantiations

2023-03-20 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added inline comments.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:1714
 /// Check whether a function's parameter types are all literal types. If so,
 /// return true. If not, produce a suitable diagnostic and return false.
 static bool CheckConstexprParameterTypes(Sema &SemaRef,

This comment seems to no longer be true since we don't emit a diagnostic for 
the `!PD` case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146426

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


[PATCH] D146426: [Sema] Fix crash on __fp16 parameters in template instantiations

2023-03-20 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added a comment.

In D146426#4206525 , @ilya-biryukov 
wrote:

> In D146426#4206519 , @shafik wrote:
>
>> Please edit the summary to indicate this fixes: 
>> https://github.com/llvm/llvm-project/issues/61441
>> I am happy someone had more time to dig into this problem after my initial 
>> investigation.
>
> Thanks, done!
> I wasn't aware of the upstream bug and your prior investigation. It would 
> have definitely saved some time.

That is unfortunate, I definitely would have preferred for you to have 
benefitted from my work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146426

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


[PATCH] D146426: [Sema] Fix crash on __fp16 parameters in template instantiations

2023-03-20 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added a reviewer: clang-language-wg.
shafik added a comment.

Adding clang-language-wg for more visibility


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146426

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


[PATCH] D146420: Document the Clang policies on claiming support for a feature

2023-03-20 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/docs/InternalsManual.rst:3285
+  * Are there known issues with the feature that reject valid code?
+  * Are there known issues that fail to reject invalid code?
+  * Are there known crashes, failed assertions, or miscompilations?

aaron.ballman wrote:
> cor3ntin wrote:
> > any way to rephrase that, "that cause clamg to reject" maybe?
> Sure, we can go with "accept invalid code" instead of "fail to reject 
> invalid".
is the issue the thing that accepts the code? that's what bugs me


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

https://reviews.llvm.org/D146420

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


[PATCH] D146420: Document the Clang policies on claiming support for a feature

2023-03-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/docs/InternalsManual.rst:3285
+  * Are there known issues with the feature that reject valid code?
+  * Are there known issues that fail to reject invalid code?
+  * Are there known crashes, failed assertions, or miscompilations?

cor3ntin wrote:
> aaron.ballman wrote:
> > cor3ntin wrote:
> > > any way to rephrase that, "that cause clamg to reject" maybe?
> > Sure, we can go with "accept invalid code" instead of "fail to reject 
> > invalid".
> is the issue the thing that accepts the code? that's what bugs me
I'm trying to list out two problems separately: the first is when we reject 
code that we should be accepting, and the second is when we accept code that we 
should be rejecting. I think I see where your confusion is coming from, how 
about:
```
* Are there known issues where we reject valid code that should be accepted?
* Are there known issues where we accept invalid code that should be rejected?
```


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

https://reviews.llvm.org/D146420

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


[PATCH] D146420: Document the Clang policies on claiming support for a feature

2023-03-20 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/docs/InternalsManual.rst:3285
+  * Are there known issues with the feature that reject valid code?
+  * Are there known issues that fail to reject invalid code?
+  * Are there known crashes, failed assertions, or miscompilations?

aaron.ballman wrote:
> cor3ntin wrote:
> > aaron.ballman wrote:
> > > cor3ntin wrote:
> > > > any way to rephrase that, "that cause clamg to reject" maybe?
> > > Sure, we can go with "accept invalid code" instead of "fail to reject 
> > > invalid".
> > is the issue the thing that accepts the code? that's what bugs me
> I'm trying to list out two problems separately: the first is when we reject 
> code that we should be accepting, and the second is when we accept code that 
> we should be rejecting. I think I see where your confusion is coming from, 
> how about:
> ```
> * Are there known issues where we reject valid code that should be accepted?
> * Are there known issues where we accept invalid code that should be rejected?
> ```
that sounds good to me!


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

https://reviews.llvm.org/D146420

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


[PATCH] D146426: [Sema] Fix crash on __fp16 parameters in template instantiations

2023-03-20 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov updated this revision to Diff 506623.
ilya-biryukov marked an inline comment as done.
ilya-biryukov added a comment.

- rename test file to GH61441.cpp, add a comment this checks for no crash
- Update outdated comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146426

Files:
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/SemaCXX/GH61441.cpp


Index: clang/test/SemaCXX/GH61441.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/GH61441.cpp
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// Checks Clang does not crash.
+
+template 
+int foo() {
+  auto x = [&](__fp16) { return 0; }; // expected-error {{parameters cannot 
have __fp16 type}}
+  return 0;
+}
+
+int bar() { return foo(); }
Index: clang/lib/Sema/SemaTemplateInstantiate.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -1343,7 +1343,7 @@
 
   CXXMethodDecl *MD = Result.getAs()->getCallOperator();
   for (ParmVarDecl *PVD : MD->parameters()) {
-if (!PVD->hasDefaultArg())
+if (!PVD || !PVD->hasDefaultArg())
   continue;
 Expr *UninstExpr = PVD->getUninstantiatedDefaultArg();
 // FIXME: Obtain the source location for the '=' token.
Index: clang/lib/Sema/SemaLambda.cpp
===
--- clang/lib/Sema/SemaLambda.cpp
+++ clang/lib/Sema/SemaLambda.cpp
@@ -966,8 +966,11 @@
   if (!Params.empty()) {
 CheckParmsForFunctionDef(Params, /*CheckParameterNames=*/false);
 Method->setParams(Params);
-for (auto P : Method->parameters())
+for (auto P : Method->parameters()) {
+  if (!P)
+continue;
   P->setOwningFunction(Method);
+}
   }
 
   buildLambdaScopeReturnType(*this, LSI, Method, HasExplicitResultType);
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -1712,6 +1712,8 @@
 
 /// Check whether a function's parameter types are all literal types. If so,
 /// return true. If not, produce a suitable diagnostic and return false.
+/// If any ParamDecl is null, return false without producing a diagnostic.
+/// The code creating null parameters is responsible for producing a 
diagnostic.
 static bool CheckConstexprParameterTypes(Sema &SemaRef,
  const FunctionDecl *FD,
  Sema::CheckConstexprKind Kind) {
@@ -1721,6 +1723,8 @@
   e = FT->param_type_end();
i != e; ++i, ++ArgIndex) {
 const ParmVarDecl *PD = FD->getParamDecl(ArgIndex);
+if (!PD)
+  return false;
 SourceLocation ParamLoc = PD->getLocation();
 if (CheckLiteralType(SemaRef, Kind, ParamLoc, *i,
  diag::err_constexpr_non_literal_param, ArgIndex + 1,
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -15879,6 +15879,10 @@
 bool CheckParameterNames) {
   bool HasInvalidParm = false;
   for (ParmVarDecl *Param : Parameters) {
+if (!Param) {
+  HasInvalidParm = true;
+  continue;
+}
 // C99 6.7.5.3p4: the parameters in a parameter type list in a
 // function declarator that is part of a function definition of
 // that function shall not have incomplete type.


Index: clang/test/SemaCXX/GH61441.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/GH61441.cpp
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// Checks Clang does not crash.
+
+template 
+int foo() {
+  auto x = [&](__fp16) { return 0; }; // expected-error {{parameters cannot have __fp16 type}}
+  return 0;
+}
+
+int bar() { return foo(); }
Index: clang/lib/Sema/SemaTemplateInstantiate.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -1343,7 +1343,7 @@
 
   CXXMethodDecl *MD = Result.getAs()->getCallOperator();
   for (ParmVarDecl *PVD : MD->parameters()) {
-if (!PVD->hasDefaultArg())
+if (!PVD || !PVD->hasDefaultArg())
   continue;
 Expr *UninstExpr = PVD->getUninstantiatedDefaultArg();
 // FIXME: Obtain the source location for the '=' token.
Index: clang/lib/Sema/SemaLambda.cpp
===
--- clang/lib/Sema/SemaLambda.cpp
+++ clang/lib

[PATCH] D146426: [Sema] Fix crash on __fp16 parameters in template instantiations

2023-03-20 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added inline comments.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:1714
 /// Check whether a function's parameter types are all literal types. If so,
 /// return true. If not, produce a suitable diagnostic and return false.
 static bool CheckConstexprParameterTypes(Sema &SemaRef,

shafik wrote:
> This comment seems to no longer be true since we don't emit a diagnostic for 
> the `!PD` case.
Good catch! Updated the comment.



Comment at: clang/test/SemaCXX/crash-params.cpp:3
+
+template 
+int foo() {

shafik wrote:
> If this test really does not fit into any other test set the please rename 
> the test file `GH61441.cpp` so we know it is a regression test for that 
> github bug report.
> 
> Otherwise if we add a test from a bug report into an existing test file then 
> we wrap it something like `namespace GH61441` so we know that test is a 
> regression test for github bug 61441.
I am not very good at navigating the test files and couldn't find a good 
existing file for the test.
Ended up creating `GH61441.cpp`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146426

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


[PATCH] D146434: [clang-format] Fix support for ObjC blocks with pointer return types

2023-03-20 Thread Jared Grubb via Phabricator via cfe-commits
jaredgrubb created this revision.
jaredgrubb added reviewers: djasper, egorzhdan, benhamilton.
jaredgrubb added a project: clang-format.
Herald added a project: All.
jaredgrubb requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The ObjC-block detection code only supports a single token as the return type. 
Add support to detect pointers, too (ObjC has lots of object-pointers).

For example, using `BasedOnStyle: WebKit`, the following is stable output:

  int* p = ^int*(void)
  { //
  return nullptr;
  }
  ();

After the patch:

  int* p = ^int*(void) { //
  return nullptr;
  }();


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D146434

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


Index: clang/unittests/Format/FormatTestObjC.cpp
===
--- clang/unittests/Format/FormatTestObjC.cpp
+++ clang/unittests/Format/FormatTestObjC.cpp
@@ -994,6 +994,20 @@
   verifyFormat("int (^foo[kNumEntries])(char, float);");
   verifyFormat("int (^foo[kNumEntries + 10])(char, float);");
   verifyFormat("int (^foo[(kNumEntries + 10)])(char, float);");
+
+  verifyFormat("int *p = ^int *() { //\n"
+   "  return nullptr;\n"
+   "}();");
+
+  verifyFormat("int * (^p)(void) = ^int *(void) { //\n"
+   "  return nullptr;\n"
+   "};");
+
+  // WebKit forces function braces onto a newline, but blocks should not.
+  Style = getWebKitStyle();
+  verifyFormat("int* p = ^int*() { //\n"
+   "return nullptr;\n"
+   "}();");
 }
 
 TEST_F(FormatTestObjC, ObjCSnippets) {
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -22175,7 +22175,8 @@
"}\n"
"  }\n"
"});");
-  verifyFormat("Block b = ^int *(A *a, B *b) {}");
+  verifyFormat("Block b = ^int *(A *a, B *b) {\n"
+   "};");
   verifyFormat("BOOL (^aaa)(void) = ^BOOL {\n"
"};");
 
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1773,12 +1773,18 @@
   break;
 case tok::caret:
   nextToken();
+  // Block return type.
   if (FormatTok->Tok.isAnyIdentifier() ||
   FormatTok->isSimpleTypeSpecifier()) {
 nextToken();
+// Return types: pointers are ok too.
+while (FormatTok->is(tok::star))
+  nextToken();
   }
+  // Block argument list.
   if (FormatTok->is(tok::l_paren))
 parseParens();
+  // Block body.
   if (FormatTok->is(tok::l_brace))
 parseChildBlock();
   break;


Index: clang/unittests/Format/FormatTestObjC.cpp
===
--- clang/unittests/Format/FormatTestObjC.cpp
+++ clang/unittests/Format/FormatTestObjC.cpp
@@ -994,6 +994,20 @@
   verifyFormat("int (^foo[kNumEntries])(char, float);");
   verifyFormat("int (^foo[kNumEntries + 10])(char, float);");
   verifyFormat("int (^foo[(kNumEntries + 10)])(char, float);");
+
+  verifyFormat("int *p = ^int *() { //\n"
+   "  return nullptr;\n"
+   "}();");
+
+  verifyFormat("int * (^p)(void) = ^int *(void) { //\n"
+   "  return nullptr;\n"
+   "};");
+
+  // WebKit forces function braces onto a newline, but blocks should not.
+  Style = getWebKitStyle();
+  verifyFormat("int* p = ^int*() { //\n"
+   "return nullptr;\n"
+   "}();");
 }
 
 TEST_F(FormatTestObjC, ObjCSnippets) {
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -22175,7 +22175,8 @@
"}\n"
"  }\n"
"});");
-  verifyFormat("Block b = ^int *(A *a, B *b) {}");
+  verifyFormat("Block b = ^int *(A *a, B *b) {\n"
+   "};");
   verifyFormat("BOOL (^aaa)(void) = ^BOOL {\n"
"};");
 
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1773,12 +1773,18 @@
   break;
 case tok::caret:
   nextToken();
+  // Block return type.
   if (FormatTok->Tok.isAnyIdentifier() ||
   FormatTok->isSimpleTypeSpecifier()) {
 nextToken();
+// Return types: pointers are ok too.
+while (FormatTok->is(tok::star))
+  nextToken();
   }
+  // Block argument list.
   

[PATCH] D145391: [HIP] Supports env var HIP_PATH

2023-03-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

ping


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

https://reviews.llvm.org/D145391

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


[PATCH] D146420: Document the Clang policies on claiming support for a feature

2023-03-20 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman updated this revision to Diff 506624.
aaron.ballman marked 2 inline comments as done.
aaron.ballman added a comment.

Update based on review feedback.


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

https://reviews.llvm.org/D146420

Files:
  clang/docs/InternalsManual.rst


Index: clang/docs/InternalsManual.rst
===
--- clang/docs/InternalsManual.rst
+++ clang/docs/InternalsManual.rst
@@ -3268,3 +3268,39 @@
  proper visitation for your expression, enabling various IDE features such
  as syntax highlighting, cross-referencing, and so on.  The
  ``c-index-test`` helper program can be used to test these features.
+
+Feature Test Macros
+===
+Clang implements several ways to test whether a feature is supported or not.
+Some of these feature tests are standardized, like ``__has_cpp_attribute`` or
+``__cpp_lambdas``, while others are Clang extensions, like ``__has_builtin``.
+The common theme among all the various feature tests is that they are a utility
+to tell users that we think a particular feature is complete. However,
+completeness is a difficult property to define because features may still have
+lingering bugs, may only work on some targets, etc. We use the following
+criteria when deciding whether to expose a feature test macro (or particular
+result value for the feature test):
+
+  * Are there known issues where we reject valid code that should be accepted?
+  * Are there known issues where we accept invalid code that should be 
rejected?
+  * Are there known crashes, failed assertions, or miscompilations?
+  * Are there known issues on a particular relevant target?
+
+If the answer to any of these is "yes", the feature test macro should either
+not be defined or there should be very strong rationale for why the issues
+should not prevent defining it. Note, it is acceptable to define the feature
+test macro on a per-target basis if needed.
+
+When in doubt, being conservative is better than being aggressive. If we don't
+claim support for the feature but it does useful things, users can still use it
+and provide us with useful feedback on what is missing. But if we claim support
+for a feature that has significant bugs, we've eliminated most of the utility
+of having a feature testing macro at all because users are then forced to test
+what compiler version is in use to get a more accurate answer.
+
+The status reported by the feature test macro should always be reflected in the
+language support page for the corresponding feature (`C++
+`_, `C
+`_) if applicable. This page can give
+more nuanced information to the user as well, such claiming partial support for
+a feature and specifying details as to what remains to be done.


Index: clang/docs/InternalsManual.rst
===
--- clang/docs/InternalsManual.rst
+++ clang/docs/InternalsManual.rst
@@ -3268,3 +3268,39 @@
  proper visitation for your expression, enabling various IDE features such
  as syntax highlighting, cross-referencing, and so on.  The
  ``c-index-test`` helper program can be used to test these features.
+
+Feature Test Macros
+===
+Clang implements several ways to test whether a feature is supported or not.
+Some of these feature tests are standardized, like ``__has_cpp_attribute`` or
+``__cpp_lambdas``, while others are Clang extensions, like ``__has_builtin``.
+The common theme among all the various feature tests is that they are a utility
+to tell users that we think a particular feature is complete. However,
+completeness is a difficult property to define because features may still have
+lingering bugs, may only work on some targets, etc. We use the following
+criteria when deciding whether to expose a feature test macro (or particular
+result value for the feature test):
+
+  * Are there known issues where we reject valid code that should be accepted?
+  * Are there known issues where we accept invalid code that should be rejected?
+  * Are there known crashes, failed assertions, or miscompilations?
+  * Are there known issues on a particular relevant target?
+
+If the answer to any of these is "yes", the feature test macro should either
+not be defined or there should be very strong rationale for why the issues
+should not prevent defining it. Note, it is acceptable to define the feature
+test macro on a per-target basis if needed.
+
+When in doubt, being conservative is better than being aggressive. If we don't
+claim support for the feature but it does useful things, users can still use it
+and provide us with useful feedback on what is missing. But if we claim support
+for a feature that has significant bugs, we've eliminated most of the utility
+of having a feature testing macro at all because users are then forced to test
+what compiler ve

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

2023-03-20 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder created this revision.
tbaeder added reviewers: aaron.ballman, erichkeane, tahonermann, shafik.
Herald added a project: All.
tbaeder requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This should already work just fine since our `Floating` just wraps an `APFloat` 
with the appropriate semantics.


Repository:
  rG LLVM Github Monorepo

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.0f == 3, ""); // ref-error {{invalid argument type 'float' 
to unary expression}} \
+ // expected-error {{invalid argument type 
'float' 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.0f == 3, ""); // ref-error {{invalid argument type 'float' to unary expression}} \
+ // expected-error {{invalid argument type 'float' 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;
+

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

2023-03-20 Thread Marco Falke via Phabricator via cfe-commits
MarcoFalke updated this revision to Diff 506632.
MarcoFalke added a comment.

address feedback about matcher, clang-format


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;
@@ -1353,6 +1365,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.
Index: clang-tools-extra/clang-tidy/bugprone/UseAfterMoveCheck.cpp

[PATCH] D143467: [PowerPC] Add target feature requirement to builtins

2023-03-20 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai added a comment.

In D143467#4195474 , @qiucf wrote:

> - For builtins with matching instruction, use the required ISA/vector version
> - For the rest builtins used in altivec.h, use requirements specified by the 
> header
> - Keep the feature checks in SemaChecking as-is, since they give user useful 
> message (`only available on POWER8 or later CPUs` instead of `requires 
> isa-v207-instructions to be enabled`)
>   - `lharx` and similar instructions exist since ISA v2.06 (Power 7), while 
> SemaChecking.cpp requires ISA v2.07 (Power 8)

There are quite a number of Power7 CPU's that do not have `l[bh]arx`. These 
were a late addition (i.e. in 2.06b). We should only emit it on Power8.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143467

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


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

2023-03-20 Thread Marco Falke via Phabricator via cfe-commits
MarcoFalke marked 3 inline comments as done.
MarcoFalke added a comment.

Thanks, addressed some more review comments.




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone/use-after-move.cpp:1431
   std::string val_;
 };

PiotrZSL wrote:
> MarcoFalke wrote:
> > PiotrZSL wrote:
> > > Missing tests:
> > > - Test with A derive from B, C, D, and argument is moved into C, but D 
> > > initialization also uses it.
> > > - Test with lambda call inside init, and in lambda std::move of captured 
> > > by reference constructor parameter, and lambda could be mutable, and 
> > > lambda could be saved into member (or passed to base class), or called 
> > > instantly (better both tests).
> > > - Test with lambda that takes argument into capture by move
> > > 
> > > In short:
> > > ```
> > > struct Obj {};
> > > struct D
> > > {
> > > D(Obj b);
> > > };
> > > 
> > > struct C
> > > {
> > >  C(Obj b);
> > > };
> > > 
> > > struct B
> > > {
> > >  B(Obj& b);
> > > }
> > > 
> > > struct A : B, C, D
> > > {
> > > A(Obj b)
> > >   : B(b), C(std::move(b)), D(b)
> > > {
> > > }
> > > };
> > > 
> > > and second:
> > > 
> > > struct Base
> > > {
> > > Base(Obj b) : bb(std::move(b)) {}
> > >  template
> > >  Base(T&& b) : bb(b()) {};
> > >
> > >  Obj bb;
> > > };
> > > 
> > > struct Derived : Base, C
> > > {
> > >  Derived(Obj b) 
> > >: Base([&] mutable { return std::move(b); }()), C(b)
> > >{
> > >}
> > > };
> > > 
> > > struct Derived2 : Base, C
> > > {
> > >  Derived2(Obj b) 
> > >: Base([&] mutable { return std::move(b); }), C(b)
> > >{
> > >}
> > > };
> > > 
> > > struct Derived3 : Base, C
> > > {
> > >  Derived3(Obj b) 
> > >: Base([c = std::move(b)] mutable { return std::move(c); }), 
> > > C(b)
> > >{
> > >}
> > > };
> > > ```
> > I added the test `Derived2`, however, I wonder if it should throw a 
> > warning. In the general case, I don't think we can know whether 
> > `Base(Call&&call)` will actually call `call` and execute the `std::move`, 
> > no?
> For me:
> Derived - should throw a warning - same type used before C(b) (but 
> questionable)
> Derived 2 -> also should throw warning (but questionable)
> Derived 3 -> also should throw warning
> 
> Note that Derived & Derived 2 could be considered different issue, like use 
> after free (because we take reference to argument), it's safe to assume that 
> it would be called anyway, because later that argument reference could become 
> invalid. But it could be also fine to not throw issue. For is better to throw 
> & nolint than ignore and crash.
> But thats your call.
Ok, maybe it can be done in a follow-up? This should be a separate and 
pre-existing issue on `main` already (see also my other added test case about 
lambdas).


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

https://reviews.llvm.org/D146288

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


  1   2   3   >