[PATCH] D129160: libclang.so: Make SONAME the same as LLVM version

2022-07-05 Thread H. Vetinari via Phabricator via cfe-commits
h-vetinari added a comment.

Thanks for the ping. It's unfortunate that this didn't work out as intended. 
It's certainly fine though (for our purposes) to go back to the way things were 
before.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129160

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


[PATCH] D128314: [Clang-tidy] Fixing a bug in clang-tidy infinite-loop checker

2022-07-05 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

Sounds great! I have a nitpick but other than that I think this fix is good to 
go.




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:3841
 
+/// matches if ObjCMessageExpr's callee declaration matches
+///

It looks like documentation traditionally starts with a capital letter and ends 
with `.`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128314

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


[PATCH] D129170: [Sema] Add deprecation warnings for some compiler provided __has_* type traits

2022-07-05 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson created this revision.
Herald added a project: All.
royjacobson requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Some compiler provided type traits like __has_trivial_constructor have been 
documented
as deprecated for quite some time.
Still, some people apparently still use them, even though mixing them with 
concepts
and with deleted functions leads to weird results. There's also disagreement 
about some
edge cases between GCC (which Clang claims to follow) and MSVC.

This patch adds deprecation warnings for the usage of those builtins, except 
for __has_trivial_destructor
which doesn't have a GCC alternative.

I made the warning on by default, so I had to silence it for some tests but 
it's not too many.

Some (decade old) history of issues with those builtins:
https://github.com/llvm/llvm-project/issues/18187
https://github.com/llvm/llvm-project/issues/18559
https://github.com/llvm/llvm-project/issues/22161
https://github.com/llvm/llvm-project/issues/33063

The abseil usage of them that triggered me to add this warning:
https://github.com/abseil/abseil-cpp/issues/1201

Weird interaction of those builtins with C++20's conditionally trivial special 
member functions:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106085


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129170

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CXX/dcl.decl/dcl.init/p5.cpp
  clang/test/CXX/drs/dr18xx.cpp
  clang/test/CXX/drs/dr21xx.cpp
  clang/test/CXX/special/class.copy/p12-0x.cpp
  clang/test/CXX/special/class.copy/p25-0x.cpp
  clang/test/CXX/special/class.ctor/p5-0x.cpp
  clang/test/Modules/cxx-decls.cpp
  clang/test/SemaCXX/cxx0x-defaulted-functions.cpp
  clang/test/SemaCXX/cxx11-crashes.cpp
  clang/test/SemaCXX/deprecated-builtins.cpp
  clang/test/SemaCXX/sizeless-1.cpp
  clang/test/SemaCXX/trivial-constructor.cpp
  clang/test/SemaCXX/trivial-destructor.cpp
  clang/test/SemaCXX/type-traits.cpp
  clang/test/SemaObjCXX/arc-type-traits.mm
  clang/test/SemaObjCXX/objc-weak-type-traits.mm

Index: clang/test/SemaObjCXX/objc-weak-type-traits.mm
===
--- clang/test/SemaObjCXX/objc-weak-type-traits.mm
+++ clang/test/SemaObjCXX/objc-weak-type-traits.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-weak -fobjc-runtime-has-weak -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-weak -fobjc-runtime-has-weak -verify -std=c++11 %s -Wno-deprecated-has-builtins
 // expected-no-diagnostics
 
 // Check the results of the various type-trait query functions on
Index: clang/test/SemaObjCXX/arc-type-traits.mm
===
--- clang/test/SemaObjCXX/arc-type-traits.mm
+++ clang/test/SemaObjCXX/arc-type-traits.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -verify -std=c++11 %s -Wno-deprecated-has-builtins
 // expected-no-diagnostics
 
 // Check the results of the various type-trait query functions on
Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++11 -fms-extensions -Wno-microsoft %s
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++14 -fms-extensions -Wno-microsoft %s
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++1z -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++11 -Wno-deprecated-has-builtins -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++14 -Wno-deprecated-has-builtins -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++1z -Wno-deprecated-has-builtins -fms-extensions -Wno-microsoft %s
 
 #define T(b) (b) ? 1 : -1
 #define F(b) (b) ? -1 : 1
Index: clang/test/SemaCXX/trivial-destructor.cpp
===
--- clang/test/SemaCXX/trivial-destructor.cpp
+++ clang/test/SemaCXX/trivial-destructor.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11 -Wno-deprecated-has-builtins
 // expected-no-diagnostics
 struct T1 {
 };
Index: clang/test/SemaCXX/trivial-constructor.cpp
===
--- clang/test/SemaCXX/trivial-constructor.cpp
+++ clang/test/SemaCXX/trivial-constructor.cpp
@@ -1,4 

[PATCH] D111617: [RISCV] Lazily add RVV C intrinsics.

2022-07-05 Thread Kito Cheng via Phabricator via cfe-commits
kito-cheng updated this revision to Diff 442431.
kito-cheng added a comment.

Changes:

Restore the patch, I just accidentally updated wrong revision here...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111617

Files:
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/RISCVIntrinsicManager.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Support/RISCVVIntrinsicUtils.h
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/CMakeLists.txt
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaRISCVVectorLookup.cpp
  clang/lib/Support/RISCVVIntrinsicUtils.cpp
  clang/test/Sema/riscv-bad-intrnisic-pragma.c
  clang/test/Sema/riscv-intrnisic-pragma.c
  clang/utils/TableGen/RISCVVEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -110,6 +110,7 @@
 void EmitRVVHeader(llvm::RecordKeeper , llvm::raw_ostream );
 void EmitRVVBuiltins(llvm::RecordKeeper , llvm::raw_ostream );
 void EmitRVVBuiltinCG(llvm::RecordKeeper , llvm::raw_ostream );
+void EmitRVVBuiltinSema(llvm::RecordKeeper , llvm::raw_ostream );
 
 void EmitCdeHeader(llvm::RecordKeeper , llvm::raw_ostream );
 void EmitCdeBuiltinDef(llvm::RecordKeeper , llvm::raw_ostream );
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -88,6 +88,7 @@
   GenRISCVVectorHeader,
   GenRISCVVectorBuiltins,
   GenRISCVVectorBuiltinCG,
+  GenRISCVVectorBuiltinSema,
   GenAttrDocs,
   GenDiagDocs,
   GenOptDocs,
@@ -243,6 +244,8 @@
"Generate riscv_vector_builtins.inc for clang"),
 clEnumValN(GenRISCVVectorBuiltinCG, "gen-riscv-vector-builtin-codegen",
"Generate riscv_vector_builtin_cg.inc for clang"),
+clEnumValN(GenRISCVVectorBuiltinSema, "gen-riscv-vector-builtin-sema",
+   "Generate riscv_vector_builtin_sema.inc for clang"),
 clEnumValN(GenAttrDocs, "gen-attr-docs",
"Generate attribute documentation"),
 clEnumValN(GenDiagDocs, "gen-diag-docs",
@@ -458,6 +461,9 @@
   case GenRISCVVectorBuiltinCG:
 EmitRVVBuiltinCG(Records, OS);
 break;
+  case GenRISCVVectorBuiltinSema:
+EmitRVVBuiltinSema(Records, OS);
+break;
   case GenAttrDocs:
 EmitClangAttrDocs(Records, OS);
 break;
Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -20,6 +20,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringSet.h"
+#include "llvm/ADT/StringSwitch.h"
 #include "llvm/ADT/Twine.h"
 #include "llvm/TableGen/Error.h"
 #include "llvm/TableGen/Record.h"
@@ -29,6 +30,59 @@
 using namespace clang::RISCV;
 
 namespace {
+struct SemaRecord {
+  // Intrinsic name, e.g. vadd_vv
+  std::string Name;
+
+  // Overloaded intrinsic name, could be empty if can be computed from Name
+  // e.g. vadd
+  std::string OverloadedName;
+
+  // Supported type, mask of BasicType.
+  unsigned TypeRangeMask;
+
+  // Supported LMUL.
+  unsigned Log2LMULMask;
+
+  // Required extensions for this intrinsic.
+  unsigned RequiredExtensions;
+
+  // Prototype for this intrinsic.
+  SmallVector Prototype;
+
+  // Prototype for masked intrinsic.
+  SmallVector MaskedPrototype;
+
+  // Suffix of intrinsic name.
+  SmallVector Suffix;
+
+  // Suffix of overloaded intrinsic name.
+  SmallVector OverloadedSuffix;
+
+  // Number of field, large than 1 if it's segment load/store.
+  unsigned NF;
+};
+
+// Compressed function signature table.
+class SemaSignatureTable {
+private:
+  std::vector SignatureTable;
+
+  void insert(ArrayRef Signature);
+
+public:
+  static constexpr unsigned INVALID_INDEX = ~0U;
+
+  // Create compressed signature table from SemaRecords.
+  void init(ArrayRef SemaRecords);
+
+  // Query the Signature, return INVALID_INDEX if not found.
+  unsigned getIndex(ArrayRef Signature);
+
+  /// Print signature table in RVVHeader Record to \p OS
+  void print(raw_ostream );
+};
+
 class RVVEmitter {
 private:
   RecordKeeper 
@@ -45,22 +99,22 @@
   /// Emit all the information needed to map builtin -> LLVM IR intrinsic.
   void createCodeGen(raw_ostream );
 
+  /// Emit all the information needed by SemaRISCVVectorLookup.cpp.
+  /// We've large number of intrinsic function for RVV, creating a customized
+  /// could speed up the compilation time.
+  void createSema(raw_ostream );
+
 private:
-  /// Create all 

[PATCH] D111617: [RISCV] Lazily add RVV C intrinsics.

2022-07-05 Thread Kito Cheng via Phabricator via cfe-commits
kito-cheng updated this revision to Diff 442429.
kito-cheng added a comment.

Changes:

- Less invasive way to fix this issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111617

Files:
  llvm/lib/Target/RISCV/RISCVMakeCompressible.cpp
  llvm/test/CodeGen/RISCV/make-compressible-for-store-address.mir


Index: llvm/test/CodeGen/RISCV/make-compressible-for-store-address.mir
===
--- llvm/test/CodeGen/RISCV/make-compressible-for-store-address.mir
+++ llvm/test/CodeGen/RISCV/make-compressible-for-store-address.mir
@@ -33,7 +33,7 @@
 ; CHECK-NEXT: renamable $x11 = ADDI $x0, 1
 ; CHECK-NEXT: $x12 = ADDI $x10, 768
 ; CHECK-NEXT: SD killed renamable $x11, $x12, 32 :: (store (s64) into 
%ir.1)
-; CHECK-NEXT: SD $x12, $x12, 40 :: (store (s64) into %ir.2)
+; CHECK-NEXT: SD renamable $x10, $x12, 40 :: (store (s64) into %ir.2)
 ; CHECK-NEXT: renamable $x11 = ADDI $x0, 2
 ; CHECK-NEXT: SD killed renamable $x11, killed $x12, 48 :: (store (s64) 
into %ir.3)
 ; CHECK-NEXT: PseudoRET
Index: llvm/lib/Target/RISCV/RISCVMakeCompressible.cpp
===
--- llvm/lib/Target/RISCV/RISCVMakeCompressible.cpp
+++ llvm/lib/Target/RISCV/RISCVMakeCompressible.cpp
@@ -293,8 +293,15 @@
   assert((isCompressibleLoad(MI) || isCompressibleStore(MI)) &&
  "Unsupported instruction for this optimization.");
 
+  int SkipN = 0;
+
+  // Skip first operand for store instruction, it's operand for store value,
+  // it's unsafe to rename if offset is non-zero.
+  if (isCompressibleStore(MI) && OldRegImm.Imm != 0)
+SkipN = 1;
+
   // Update registers
-  for (MachineOperand  : MI.operands())
+  for (MachineOperand  : drop_begin(MI.operands(), SkipN))
 if (MO.isReg() && MO.getReg() == OldRegImm.Reg) {
   // Do not update operands that define the old register.
   //


Index: llvm/test/CodeGen/RISCV/make-compressible-for-store-address.mir
===
--- llvm/test/CodeGen/RISCV/make-compressible-for-store-address.mir
+++ llvm/test/CodeGen/RISCV/make-compressible-for-store-address.mir
@@ -33,7 +33,7 @@
 ; CHECK-NEXT: renamable $x11 = ADDI $x0, 1
 ; CHECK-NEXT: $x12 = ADDI $x10, 768
 ; CHECK-NEXT: SD killed renamable $x11, $x12, 32 :: (store (s64) into %ir.1)
-; CHECK-NEXT: SD $x12, $x12, 40 :: (store (s64) into %ir.2)
+; CHECK-NEXT: SD renamable $x10, $x12, 40 :: (store (s64) into %ir.2)
 ; CHECK-NEXT: renamable $x11 = ADDI $x0, 2
 ; CHECK-NEXT: SD killed renamable $x11, killed $x12, 48 :: (store (s64) into %ir.3)
 ; CHECK-NEXT: PseudoRET
Index: llvm/lib/Target/RISCV/RISCVMakeCompressible.cpp
===
--- llvm/lib/Target/RISCV/RISCVMakeCompressible.cpp
+++ llvm/lib/Target/RISCV/RISCVMakeCompressible.cpp
@@ -293,8 +293,15 @@
   assert((isCompressibleLoad(MI) || isCompressibleStore(MI)) &&
  "Unsupported instruction for this optimization.");
 
+  int SkipN = 0;
+
+  // Skip first operand for store instruction, it's operand for store value,
+  // it's unsafe to rename if offset is non-zero.
+  if (isCompressibleStore(MI) && OldRegImm.Imm != 0)
+SkipN = 1;
+
   // Update registers
-  for (MachineOperand  : MI.operands())
+  for (MachineOperand  : drop_begin(MI.operands(), SkipN))
 if (MO.isReg() && MO.getReg() == OldRegImm.Reg) {
   // Do not update operands that define the old register.
   //
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129105: [clang-format][NFC] Clean up IndentForLevel in LevelIndentTracker

2022-07-05 Thread Owen Pan via Phabricator via cfe-commits
owenpan added inline comments.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:82-83
+if (Size <= Line.Level)
+  IndentForLevel.insert(IndentForLevel.end(), Line.Level - Size + 1,
+UnknownIndent ? -1 : Indent);
   }

HazardyKnusperkeks wrote:
> Could we do this with with `resize` similar to my proposal in D129064?
Good idea!


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

https://reviews.llvm.org/D129105

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


[PATCH] D129105: [clang-format][NFC] Clean up IndentForLevel in LevelIndentTracker

2022-07-05 Thread Owen Pan via Phabricator via cfe-commits
owenpan updated this revision to Diff 442427.
owenpan added a comment.

Use `resize()` instead of `insert()`.


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

https://reviews.llvm.org/D129105

Files:
  clang/lib/Format/UnwrappedLineFormatter.cpp


Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -59,8 +59,7 @@
 Offset = getIndentOffset(*Line.First);
 // Update the indent level cache size so that we can rely on it
 // having the right size in adjustToUnmodifiedline.
-while (IndentForLevel.size() <= Line.Level)
-  IndentForLevel.push_back(-1);
+skipLine(Line, /*UnknownIndent=*/true);
 if (Line.InPPDirective) {
   unsigned IndentWidth =
   (Style.PPIndentWidth >= 0) ? Style.PPIndentWidth : Style.IndentWidth;
@@ -77,9 +76,9 @@
 
   /// Update the indent state given that \p Line indent should be
   /// skipped.
-  void skipLine(const AnnotatedLine ) {
-while (IndentForLevel.size() <= Line.Level)
-  IndentForLevel.push_back(Indent);
+  void skipLine(const AnnotatedLine , bool UnknownIndent = false) {
+if (Line.Level >= IndentForLevel.size())
+  IndentForLevel.resize(Line.Level + 1, UnknownIndent ? -1 : Indent);
   }
 
   /// Update the level indent to adapt to the given \p Line.
@@ -159,7 +158,7 @@
   const unsigned AdditionalIndent;
 
   /// The indent in characters for each level.
-  std::vector IndentForLevel;
+  SmallVector IndentForLevel;
 
   /// Offset of the current line relative to the indent level.
   ///


Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -59,8 +59,7 @@
 Offset = getIndentOffset(*Line.First);
 // Update the indent level cache size so that we can rely on it
 // having the right size in adjustToUnmodifiedline.
-while (IndentForLevel.size() <= Line.Level)
-  IndentForLevel.push_back(-1);
+skipLine(Line, /*UnknownIndent=*/true);
 if (Line.InPPDirective) {
   unsigned IndentWidth =
   (Style.PPIndentWidth >= 0) ? Style.PPIndentWidth : Style.IndentWidth;
@@ -77,9 +76,9 @@
 
   /// Update the indent state given that \p Line indent should be
   /// skipped.
-  void skipLine(const AnnotatedLine ) {
-while (IndentForLevel.size() <= Line.Level)
-  IndentForLevel.push_back(Indent);
+  void skipLine(const AnnotatedLine , bool UnknownIndent = false) {
+if (Line.Level >= IndentForLevel.size())
+  IndentForLevel.resize(Line.Level + 1, UnknownIndent ? -1 : Indent);
   }
 
   /// Update the level indent to adapt to the given \p Line.
@@ -159,7 +158,7 @@
   const unsigned AdditionalIndent;
 
   /// The indent in characters for each level.
-  std::vector IndentForLevel;
+  SmallVector IndentForLevel;
 
   /// Offset of the current line relative to the indent level.
   ///
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D129104: [Modules] Add ODR Check for concepts

2022-07-05 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:6532
+  const Expr *XCE = ConceptX->getConstraintExpr();
+  const Expr *YCE = ConceptY->getConstraintExpr();
+  assert(XCE && YCE && "ConceptDecl wihtout constraint expression?");

erichkeane wrote:
> This isn't necessarily valid here, you did a dyn_cast above.
Oh, my bad. I should use `cast`. We could find the style at line 6525-6526 and 
line 6519-6520.


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

https://reviews.llvm.org/D129104

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


[PATCH] D129104: [Modules] Add ODR Check for concepts

2022-07-05 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu updated this revision to Diff 442425.
ChuanqiXu added a comment.

Address comments.


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

https://reviews.llvm.org/D129104

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/Modules/concept_differ.cpp
  clang/test/Modules/concept_differ.cppm

Index: clang/test/Modules/concept_differ.cppm
===
--- /dev/null
+++ clang/test/Modules/concept_differ.cppm
@@ -0,0 +1,39 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -x c++ -std=c++20 %t/A.cppm -I%t -emit-module-interface -o %t/A.pcm
+// RUN: %clang_cc1 -x c++ -std=c++20 %t/B.cppm -I%t -emit-module-interface -o %t/B.pcm
+// RUN: %clang_cc1 -x c++ -std=c++20 -fprebuilt-module-path=%t %t/foo.cpp -verify
+
+//--- foo.h
+template 
+concept A = true;
+
+//--- bar.h
+template 
+concept A = false;
+
+//--- A.cppm
+module;
+#include "foo.h"
+export module A;
+export using ::A;
+
+//--- B.cppm
+module;
+#include "bar.h"
+export module B;
+export using ::A;
+
+//--- foo.cpp
+import A;
+import B;
+
+template  void foo() requires A {}  // expected-error 1+{{reference to 'A' is ambiguous}}
+// expected-note@* 1+{{candidate found by name lookup}}
+
+int main() {
+  foo();
+  return 0;
+}
Index: clang/test/Modules/concept_differ.cpp
===
--- /dev/null
+++ clang/test/Modules/concept_differ.cpp
@@ -0,0 +1,35 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -x c++ -std=c++20 -fmodules -fmodules-cache-path=%t -fmodule-map-file=%t/module.map %t/foo.cpp -verify
+
+//--- module.map
+module "foo" {
+  export * 
+  header "foo.h"
+}
+module "bar" {
+  export * 
+  header "bar.h"
+}
+
+//--- foo.h
+template 
+concept A = true;
+
+//--- bar.h
+template 
+concept A = false;
+
+//--- foo.cpp
+#include "bar.h"
+#include "foo.h"
+
+template  void foo() requires A {}  // expected-error 1+{{reference to 'A' is ambiguous}}
+// expected-note@* 1+{{candidate found by name lookup}}
+
+int main() {
+  foo();
+  return 0;
+}
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -6524,6 +6524,20 @@
   // and patterns match.
   if (const auto *TemplateX = dyn_cast(X)) {
 const auto *TemplateY = cast(Y);
+
+// ConceptDecl wouldn't be the same if their constraint expression differs.
+if (const auto *ConceptX = dyn_cast(X)) {
+  const auto *ConceptY = cast(Y);
+  const Expr *XCE = ConceptX->getConstraintExpr();
+  const Expr *YCE = ConceptY->getConstraintExpr();
+  assert(XCE && YCE && "ConceptDecl without constraint expression?");
+  llvm::FoldingSetNodeID XID, YID;
+  XCE->Profile(XID, *this, /*Canonical=*/true);
+  YCE->Profile(YID, *this, /*Canonical=*/true);
+  if (XID != YID)
+return false;
+}
+
 return isSameEntity(TemplateX->getTemplatedDecl(),
 TemplateY->getTemplatedDecl()) &&
isSameTemplateParameterList(TemplateX->getTemplateParameters(),
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D118034: [C++20] [Modules] Don't complain about duplicated default template argument across modules

2022-07-05 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

Given @rsmith and @iains is busy and this revision is relatively small, 
innocent and looks good to me, I plan to land this in Friday in case there is 
no further comments.


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

https://reviews.llvm.org/D118034

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


[PATCH] D124159: [SimplifyCFG] Thread branches on same condition in more cases (PR54980)

2022-07-05 Thread Nathan Chancellor via Phabricator via cfe-commits
nathanchance added a comment.

I ended up reducing something down anyways. At the parent commit of 
dc969061c68e62328607d68215ed8b9ef4a1e4b1 
, there is 
no crash.

  _Bool fpsimd_context_busy;
  enum { false, true } arch_static_branch_jump() {
asm goto("" : : : : l_yes);
return false;
  l_yes:
return true;
  }
  _Bool __preempt_count_dec_and_test();
  void preempt_schedule_notrace();
  long __percpu_read_8();
  _Bool may_use_simd() {
return ({ ({ arch_static_branch_jump(); }); }) && ({
 typeof(fpsimd_context_busy) pscr_ret__ = ({
   typeof(fpsimd_context_busy) __retval = __percpu_read_8();
   if (__builtin_expect(__preempt_count_dec_and_test(), 0))
 preempt_schedule_notrace();
   __retval;
 });
 pscr_ret__;
   });
  }
  void aes_cipher_encrypt() {
if (may_use_simd())
  preempt_schedule_notrace();
  }



  $ clang --target=aarch64-linux-gnu -O2 -c -o /dev/null aes-ce-glue.i
  clang: 
/home/nathan/cbl/src/llvm-project/llvm/lib/Transforms/Utils/BasicBlockUtils.cpp:1136:
 llvm::BasicBlock *SplitBlockPredecessorsImpl(llvm::BasicBlock *, 
ArrayRef, const char *, llvm::DomTreeUpdater *, 
llvm::DominatorTree *, llvm::LoopInfo *, llvm::MemorySSAUpdater *, bool): 
Assertion `!isa(Preds[i]->getTerminator()) && "Cannot split an edge 
from a CallBrInst"' failed.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.  Program arguments: clang --target=aarch64-linux-gnu -O2 -c -o 
/dev/null aes-ce-glue.i
  1.   parser at end of file
  2.  Optimizer
   #0 0xd1ad36b8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/home/nathan/tmp/install/llvm/dc969061c68e62328607d68215ed8b9ef4a1e4b1/bin/clang-15+0x35336b8)
   #1 0xd1ad18d8 llvm::sys::RunSignalHandlers() 
(/home/nathan/tmp/install/llvm/dc969061c68e62328607d68215ed8b9ef4a1e4b1/bin/clang-15+0x35318d8)
   #2 0xd1a5e6e4 (anonymous 
namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) 
CrashRecoveryContext.cpp:0:0
   #3 0xd1a5e894 CrashRecoverySignalHandler(int) 
CrashRecoveryContext.cpp:0:0
   #4 0xa099e854 (linux-vdso.so.1+0x854)
   #5 0xa04b28a8 __pthread_kill_implementation 
(/lib64/libc.so.6+0x828a8)
   #6 0xa046ae40 gsignal (/lib64/libc.so.6+0x3ae40)
   #7 0xa04572f8 abort (/lib64/libc.so.6+0x272f8)
   #8 0xa0464538 __assert_fail_base (/lib64/libc.so.6+0x34538)
   #9 0xa04645a0 __assert_perror_fail (/lib64/libc.so.6+0x345a0)
  #10 0xd1ae30c0 SplitBlockPredecessorsImpl(llvm::BasicBlock*, 
llvm::ArrayRef, char const*, llvm::DomTreeUpdater*, 
llvm::DominatorTree*, llvm::LoopInfo*, llvm::MemorySSAUpdater*, bool) 
BasicBlockUtils.cpp:0:0
  ...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124159

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


[PATCH] D125095: [Clang][AIX] Add .ref in frontend for AIX XCOFF to support `-bcdtors:csect` linker option

2022-07-05 Thread Ting Wang via Phabricator via cfe-commits
tingwang updated this revision to Diff 442419.
tingwang added a comment.

Update according to comments:
(1) Merged cleanupAssoc() into genAssocMeta(), and renamed genAssocMeta() to 
EmitAssociatedMetadata().
(2) Removed "-debug-info-kind=limited" from all test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125095

Files:
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/test/CodeGen/PowerPC/aix-init-ref-null.cpp
  clang/test/CodeGen/PowerPC/aix-ref-static-var.cpp
  clang/test/CodeGen/PowerPC/aix-ref-tls_init.cpp
  clang/test/CodeGenCXX/aix-static-init-debug-info.cpp
  clang/test/CodeGenCXX/aix-static-init-temp-spec-and-inline-var.cpp
  clang/test/CodeGenCXX/aix-static-init.cpp
  llvm/docs/LangRef.rst

Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -7091,6 +7091,10 @@
 @b = internal global i32 2, comdat $a, section "abc", !associated !0
 !0 = !{i32* @a}
 
+On XCOFF target, the ``associated`` metadata indicates connection among static
+variables (static global variable, static class member etc.) and static init/
+term functions. This metadata lowers to ``.ref`` assembler pseudo-operation
+which prevents discarding of the functions in linker GC.
 
 '``prof``' Metadata
 ^^^
Index: clang/test/CodeGenCXX/aix-static-init.cpp
===
--- clang/test/CodeGenCXX/aix-static-init.cpp
+++ clang/test/CodeGenCXX/aix-static-init.cpp
@@ -38,6 +38,10 @@
   }
 } // namespace test4
 
+// CHECK: @_ZN5test12t1E = global %"struct.test1::Test1" zeroinitializer, align {{[0-9]+}}, !associated ![[ASSOC0:[0-9]+]]
+// CHECK: @_ZN5test12t2E = global %"struct.test1::Test1" zeroinitializer, align {{[0-9]+}}, !associated ![[ASSOC0:[0-9]+]]
+// CHECK: @_ZN5test21xE = global i32 0, align {{[0-9]+}}, !associated ![[ASSOC1:[0-9]+]]
+// CHECK: @_ZN5test31tE = global %"struct.test3::Test3" undef, align {{[0-9]+}}, !associated ![[ASSOC0:[0-9]+]]
 // CHECK: @_ZGVZN5test41fEvE11staticLocal = internal global i64 0, align 8
 // CHECK: @llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 65535, void ()* @_GLOBAL__sub_I__, i8* null }]
 // CHECK: @llvm.global_dtors = appending global [1 x { i32, void ()*, i8* }] [{ i32, void ()*, i8* } { i32 65535, void ()* @_GLOBAL__D_a, i8* null }]
@@ -49,7 +53,7 @@
 // CHECK:   ret void
 // CHECK: }
 
-// CHECK: define internal void @__dtor__ZN5test12t1E() [[ATTR:#[0-9]+]] {
+// CHECK: define internal void @__dtor__ZN5test12t1E() [[ATTR:#[0-9]+]] !associated ![[ASSOC2:[0-9]+]] {
 // CHECK: entry:
 // CHECK:   call void @_ZN5test15Test1D1Ev(%"struct.test1::Test1"* @_ZN5test12t1E)
 // CHECK:   ret void
@@ -80,7 +84,7 @@
 // CHECK:   ret void
 // CHECK: }
 
-// CHECK: define internal void @__dtor__ZN5test12t2E() [[ATTR:#[0-9]+]] {
+// CHECK: define internal void @__dtor__ZN5test12t2E() [[ATTR:#[0-9]+]] !associated ![[ASSOC2:[0-9]+]] {
 // CHECK: entry:
 // CHECK:   call void @_ZN5test15Test1D1Ev(%"struct.test1::Test1"* @_ZN5test12t2E)
 // CHECK:   ret void
@@ -114,7 +118,7 @@
 // CHECK:   ret void
 // CHECK: }
 
-// CHECK: define internal void @__dtor__ZN5test31tE() [[ATTR:#[0-9]+]] {
+// CHECK: define internal void @__dtor__ZN5test31tE() [[ATTR:#[0-9]+]] !associated ![[ASSOC2:[0-9]+]] {
 // CHECK: entry:
 // CHECK:   call void @_ZN5test35Test3D1Ev(%"struct.test3::Test3"* @_ZN5test31tE)
 // CHECK:   ret void
@@ -155,7 +159,7 @@
 // CHECK:   ret void
 // CHECK: }
 
-// CHECK: define internal void @__dtor__ZZN5test41fEvE11staticLocal() [[ATTR:#[0-9]+]] {
+// CHECK: define internal void @__dtor__ZZN5test41fEvE11staticLocal() [[ATTR:#[0-9]+]] !associated ![[ASSOC2:[0-9]+]] {
 // CHECK: entry:
 // CHECK:   call void @_ZN5test45Test4D1Ev(%"struct.test4::Test4"* @_ZZN5test41fEvE11staticLocal)
 // CHECK:   ret void
@@ -192,3 +196,7 @@
 // CHECK:   call void @__finalize__ZN5test12t1E()
 // CHECK:   ret void
 // CHECK: }
+
+// CHECK: ![[ASSOC0]] = !{void ()* @{{_GLOBAL__sub_I__|_GLOBAL__D_a}}, void ()* @{{_GLOBAL__sub_I__|_GLOBAL__D_a}}}
+// CHECK: ![[ASSOC1]] = !{void ()* @_GLOBAL__sub_I__}
+// CHECK: ![[ASSOC2]] = !{void ()* @_GLOBAL__D_a}
Index: clang/test/CodeGenCXX/aix-static-init-temp-spec-and-inline-var.cpp
===
--- clang/test/CodeGenCXX/aix-static-init-temp-spec-and-inline-var.cpp
+++ clang/test/CodeGenCXX/aix-static-init-temp-spec-and-inline-var.cpp
@@ -44,8 +44,13 @@
 A A::instance = bar();
 } // namespace test2
 
+// CHECK: @_ZN5test12t0E = global %"struct.test1::Test1" zeroinitializer, align {{[0-9]+}}, !associated ![[ASSOC0:[0-9]+]]
+// CHECK: @_ZN5test12t2E = linkonce_odr global 

[PATCH] D125095: [Clang][AIX] Add .ref in frontend for AIX XCOFF to support `-bcdtors:csect` linker option

2022-07-05 Thread Ting Wang via Phabricator via cfe-commits
tingwang added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:522
   EmitCXXThreadLocalInitFunc();
+  if (getTriple().isOSAIX()) {
+genAssocMeta();

shchenz wrote:
> Seems this dos not follow other functions call's style. Can we call a 
> function like `EmitAssociatedMetadata()` here and do the clean up 
> (`cleanupAssoc()` may not be needed) in the `EmitAssociatedMetadata()`? 
Thanks! I will update the code.



Comment at: clang/test/CodeGen/PowerPC/aix-init-ref-null.cpp:2
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -emit-llvm -O3 -x c++ \
+// RUN: -debug-info-kind=limited < %s | \
+// RUN:   FileCheck %s

shchenz wrote:
> is `-debug-info-kind=limited` or `-O3` necessary in this test? Same as other 
> new added cases.
Oh, "-debug-info-kind=limited" is not required. I will remove those. The "-O3" 
flag is required to show that associated metadata can be `nullptr`. Without 
"-O3", normal llvm.global_ctors will be generated.



Comment at: clang/test/CodeGen/PowerPC/aix-ref-tls_init.cpp:10
+// CHECK: @r = thread_local global ptr null, align [[ALIGN:[0-9]+]], !dbg 
![[DBG0:[0-9]+]], !associated ![[ASSOC0:[0-9]+]]
+// CHECK: ![[ASSOC0]] = !{ptr @__tls_init}

shchenz wrote:
> Not sure if this is right or not. XLC on AIX seems refer to `__tls_get_addr` 
> instead  of `__tls_init`...
I saw some case that AIX generated tls related association, and I was 
postulating that the association should be linked to _tls_init. I will revisit 
my case and update with more info or correct the association later.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125095

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


[PATCH] D129152: [Clang][unittests] Silence trucation warning with MSVC

2022-07-05 Thread Alexandre Ganea 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 rG0880b9d52620: [Clang][unittests] Silence trucation warning 
with MSVC 2022 (authored by aganea).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129152

Files:
  clang/unittests/StaticAnalyzer/RangeSetTest.cpp


Index: clang/unittests/StaticAnalyzer/RangeSetTest.cpp
===
--- clang/unittests/StaticAnalyzer/RangeSetTest.cpp
+++ clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -88,6 +88,12 @@
   template 
   static constexpr T X555TruncZeroOf = TruncZeroOf; // 0x'5600
 
+// Silence 'warning C4309: 'initializing': truncation of constant value'
+//   in RangeSetCastToPromotionConversionTest.
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(push)
+#pragma warning(disable : 4309)
+#endif
   // Numbers for ranges with the same bits in the lowest byte.
   // 0x'AA2A
   static constexpr T FromA = ClearLowBytes + 42;
@@ -95,6 +101,10 @@
   // 0x'552A
   static constexpr T FromB = ClearLowBytes + 42;
   static constexpr T ToB = FromB + 2; // 0x'552C
+
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(pop)
+#endif
 };
 
 template 


Index: clang/unittests/StaticAnalyzer/RangeSetTest.cpp
===
--- clang/unittests/StaticAnalyzer/RangeSetTest.cpp
+++ clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -88,6 +88,12 @@
   template 
   static constexpr T X555TruncZeroOf = TruncZeroOf; // 0x'5600
 
+// Silence 'warning C4309: 'initializing': truncation of constant value'
+//   in RangeSetCastToPromotionConversionTest.
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(push)
+#pragma warning(disable : 4309)
+#endif
   // Numbers for ranges with the same bits in the lowest byte.
   // 0x'AA2A
   static constexpr T FromA = ClearLowBytes + 42;
@@ -95,6 +101,10 @@
   // 0x'552A
   static constexpr T FromB = ClearLowBytes + 42;
   static constexpr T ToB = FromB + 2; // 0x'552C
+
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(pop)
+#endif
 };
 
 template 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 0880b9d - [Clang][unittests] Silence trucation warning with MSVC 2022

2022-07-05 Thread Alexandre Ganea via cfe-commits

Author: Alexandre Ganea
Date: 2022-07-05T20:31:54-04:00
New Revision: 0880b9d52620ca3c46456095f6040a2e4de6c871

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

LOG: [Clang][unittests] Silence trucation warning with MSVC 2022

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

Added: 


Modified: 
clang/unittests/StaticAnalyzer/RangeSetTest.cpp

Removed: 




diff  --git a/clang/unittests/StaticAnalyzer/RangeSetTest.cpp 
b/clang/unittests/StaticAnalyzer/RangeSetTest.cpp
index 91a6351c8e3b3..892c1ac23f92f 100644
--- a/clang/unittests/StaticAnalyzer/RangeSetTest.cpp
+++ b/clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -88,6 +88,12 @@ template  struct TestValues {
   template 
   static constexpr T X555TruncZeroOf = TruncZeroOf; // 0x'5600
 
+// Silence 'warning C4309: 'initializing': truncation of constant value'
+//   in RangeSetCastToPromotionConversionTest.
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(push)
+#pragma warning(disable : 4309)
+#endif
   // Numbers for ranges with the same bits in the lowest byte.
   // 0x'AA2A
   static constexpr T FromA = ClearLowBytes + 42;
@@ -95,6 +101,10 @@ template  struct TestValues {
   // 0x'552A
   static constexpr T FromB = ClearLowBytes + 42;
   static constexpr T ToB = FromB + 2; // 0x'552C
+
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(pop)
+#endif
 };
 
 template 



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


[clang] 18f230a - [Clang] Silence warning when building with MSVC 2022

2022-07-05 Thread Alexandre Ganea via cfe-commits

Author: Alexandre Ganea
Date: 2022-07-05T20:31:54-04:00
New Revision: 18f230a89aa234ac58be4fb8cee2bfa95ea67be4

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

LOG: [Clang] Silence warning when building with MSVC 2022

Previously, the warning seen:

[22/95] Building CXX object 
tools\clang\lib\StaticAnalyzer\Checker...bj.clangStaticAnalyzerCheckers.dir\NoReturnFunctionChecker.cpp.objC:\git\llvm-project\clang\lib\StaticAnalyzer\Checkers\NoReturnFunctionChecker.cpp(149):
 warning C4305: 'if': truncation from 'size_t' to 'bool'
C:\git\llvm-project\clang\include\clang/Analysis/SelectorExtras.h(28): note: 
see reference to function template instantiation 'clang::Selector 
clang::getKeywordSelector(clang::ASTContext &,const char *,const char *,const char *,const char *)' 
being compiled
C:\git\llvm-project\clang\lib\StaticAnalyzer\Checkers\NoReturnFunctionChecker.cpp(125):
 note: see reference to function template instantiation 'void 
clang::lazyInitKeywordSelector(clang::Selector &,clang::ASTContext &,const char *,const char *,const 
char *,const char *)' being compiled

Added: 


Modified: 
clang/include/clang/Analysis/SelectorExtras.h

Removed: 




diff  --git a/clang/include/clang/Analysis/SelectorExtras.h 
b/clang/include/clang/Analysis/SelectorExtras.h
index 278f20e87cc69..1e1daf5706bbf 100644
--- a/clang/include/clang/Analysis/SelectorExtras.h
+++ b/clang/include/clang/Analysis/SelectorExtras.h
@@ -16,7 +16,7 @@ namespace clang {
 template 
 static inline Selector getKeywordSelector(ASTContext ,
   IdentifierInfos *... IIs) {
-  static_assert(sizeof...(IdentifierInfos),
+  static_assert(sizeof...(IdentifierInfos) > 0,
 "keyword selectors must have at least one argument");
   SmallVector II({(IIs)...});
 



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


[PATCH] D127082: [clangd] Add Macro Expansion to Hover

2022-07-05 Thread Qingyuan Zheng via Phabricator via cfe-commits
daiyousei-qz added a comment.

It looks like my inline comment wasn't submitted (didn't click the submit 
button in the bottom). Here's my old comment.




Comment at: clang-tools-extra/clangd/Hover.cpp:1091
+
+  // Reformat Macro Expansion
+  if (!HI->MacroExpansion.empty()) {

nridge wrote:
> It would be interesting to have a couple of test cases that exercise the 
> reformatting in non-trivial ways, e.g. long expansions that need to be 
> wrapped onto multiple lines
> 
> I would suggest two such test cases, one with the expansion being in a 
> declaration context, and the second an expression context (for this one, to 
> make it long enough, the expansion could contain e.g. an `a ? b : c` 
> expression)
> 
> (I'm suggesting the expression-context testcase in part as a sanity check to 
> make sure that `format::reformat()` handles such code reasonably in the first 
> place)
Somehow, this comment goes out of the position. 

In my opinion, such test should be written against `format::reformat()` 
directly instead of hover message in clangd. One problem is that we are using 
the current style in users' workspace to reformat the definition/expansion, 
which means the same tokens might present differently given different 
`.clang-format` or fallback style that the user has specified. I do agree that, 
if tokens don't conform a regular c++ expression, like `) . field`, the 
presentation could be bad. But I suppose there's no obvious solution for that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127082

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


[PATCH] D129152: [Clang][unittests] Silence trucation warning with MSVC

2022-07-05 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea added a comment.

Thanks all for reviewing!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129152

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


[PATCH] D127082: [clangd] Add Macro Expansion to Hover

2022-07-05 Thread Qingyuan Zheng via Phabricator via cfe-commits
daiyousei-qz updated this revision to Diff 442416.
daiyousei-qz marked an inline comment as done.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127082

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

Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -478,15 +478,46 @@
  HI.Definition = "Foo";
}},
 
-  // macro
+  // variable-like macro
+  {R"cpp(
+#define MACRO 41
+int x = [[MAC^RO]];
+)cpp",
+   [](HoverInfo ) {
+ HI.Name = "MACRO";
+ HI.Kind = index::SymbolKind::Macro;
+ HI.Definition = "#define MACRO 41";
+ HI.MacroExpansion = "41";
+   }},
+
+  // function-like macro
   {R"cpp(
 // Best MACRO ever.
-#define MACRO(x,y,z) void foo(x, y, z);
+#define MACRO(x,y,z) void foo(x, y, z)
 [[MAC^RO]](int, double d, bool z = false);
 )cpp",
[](HoverInfo ) {
- HI.Name = "MACRO", HI.Kind = index::SymbolKind::Macro,
- HI.Definition = "#define MACRO(x, y, z) void foo(x, y, z);";
+ HI.Name = "MACRO";
+ HI.Kind = index::SymbolKind::Macro;
+ HI.Definition = "#define MACRO(x, y, z) void foo(x, y, z)";
+ HI.MacroExpansion = "void foo(int, double d, bool z = false)";
+   }},
+
+  // nested macro
+  {R"cpp(
+#define STRINGIFY_AUX(s) #s
+#define STRINGIFY(s) STRINGIFY_AUX(s)
+#define DECL_STR(NAME, VALUE) const char *v_##NAME = STRINGIFY(VALUE)
+#define FOO 41
+
+[[DECL^_STR]](foo, FOO);
+)cpp",
+   [](HoverInfo ) {
+ HI.Name = "DECL_STR";
+ HI.Kind = index::SymbolKind::Macro;
+ HI.Definition = "#define DECL_STR(NAME, VALUE) const char *v_##NAME = "
+ "STRINGIFY(VALUE)";
+ HI.MacroExpansion = "const char *v_foo = \"41\"";
}},
 
   // constexprs
@@ -1070,6 +1101,7 @@
 EXPECT_EQ(H->Kind, Expected.Kind);
 EXPECT_EQ(H->Documentation, Expected.Documentation);
 EXPECT_EQ(H->Definition, Expected.Definition);
+EXPECT_EQ(H->MacroExpansion, Expected.MacroExpansion);
 EXPECT_EQ(H->Type, Expected.Type);
 EXPECT_EQ(H->ReturnType, Expected.ReturnType);
 EXPECT_EQ(H->Parameters, Expected.Parameters);
@@ -1567,6 +1599,7 @@
 HI.Name = "MACRO";
 HI.Kind = index::SymbolKind::Macro;
 HI.Definition = "#define MACRO 0";
+HI.MacroExpansion = "0";
   }},
   {
   R"cpp(// Macro
@@ -1577,6 +1610,8 @@
 HI.Name = "MACRO";
 HI.Kind = index::SymbolKind::Macro;
 HI.Definition = "#define MACRO 0";
+// FIXME: expansion of MACRO isn't available in macro
+// definition/arguments
   }},
   {
   R"cpp(// Macro
@@ -1591,6 +1626,7 @@
 HI.Definition =
 R"cpp(#define MACRO  \
   { return 0; })cpp";
+HI.MacroExpansion = "{ return 0; }";
   }},
   {
   R"cpp(// Forward class declaration
@@ -2625,6 +2661,7 @@
 EXPECT_EQ(H->Kind, Expected.Kind);
 EXPECT_EQ(H->Documentation, Expected.Documentation);
 EXPECT_EQ(H->Definition, Expected.Definition);
+EXPECT_EQ(H->MacroExpansion, Expected.MacroExpansion);
 EXPECT_EQ(H->Type, Expected.Type);
 EXPECT_EQ(H->ReturnType, Expected.ReturnType);
 EXPECT_EQ(H->Parameters, Expected.Parameters);
Index: clang-tools-extra/clangd/Hover.h
===
--- clang-tools-extra/clangd/Hover.h
+++ clang-tools-extra/clangd/Hover.h
@@ -71,6 +71,7 @@
   std::string Documentation;
   /// Source code containing the definition of the symbol.
   std::string Definition;
+  std::string MacroExpansion;
   const char *DefinitionLanguage = "cpp";
   /// Access specifier for declarations inside class/struct/unions, empty for
   /// others.
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -641,7 +641,8 @@
 }
 
 /// Generate a \p Hover object given the macro \p MacroDecl.
-HoverInfo getHoverContents(const DefinedMacro , ParsedAST ) {
+HoverInfo getHoverContents(const syntax::Token , const DefinedMacro ,
+   ParsedAST ) {
   HoverInfo HI;
   SourceManager  = AST.getSourceManager();
   HI.Name = std::string(Macro.Name);
@@ -670,6 +671,28 @@
 HI.Definition =
 ("#define " + Buffer.substr(StartOffset, EndOffset - StartOffset))

[PATCH] D112579: Allow non-variadic functions to be attributed with `__attribute__((format))`

2022-07-05 Thread Félix Cloutier via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG92edd74b37c7: Allow non-variadic functions to be attributed 
with `__attribute__((format))` (authored by fcloutier).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112579

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/FormatString.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/attr-format.c
  clang/test/Sema/format-strings.c
  clang/test/SemaCXX/attr-format.cpp

Index: clang/test/SemaCXX/attr-format.cpp
===
--- clang/test/SemaCXX/attr-format.cpp
+++ clang/test/SemaCXX/attr-format.cpp
@@ -1,7 +1,11 @@
 // RUN: %clang_cc1 -fsyntax-only -Wformat-nonliteral -verify %s
+#include 
+
+int printf(const char *fmt, ...) __attribute__((format(printf, 1, 2)));
+
 struct S {
-  static void f(const char*, ...) __attribute__((format(printf, 1, 2)));
-  static const char* f2(const char*) __attribute__((format_arg(1)));
+  static void f(const char *, ...) __attribute__((format(printf, 1, 2)));
+  static const char *f2(const char *) __attribute__((format_arg(1)));
 
   // GCC has a hidden 'this' argument in member functions which is why
   // the format argument is argument 2 here.
@@ -38,6 +42,47 @@
 
 // Make sure we interpret member operator calls as having an implicit
 // this argument.
-void test_operator_call(S s, const char* str) {
+void test_operator_call(S s, const char *str) {
   s("%s", str);
 }
+
+template 
+void format(const char *fmt, Args &&...args) // expected-warning{{GCC requires a function with the 'format' attribute to be variadic}}
+__attribute__((format(printf, 1, 2)));
+
+template 
+Arg (Arg ) { return a; }
+
+struct foo {
+  int big[10];
+  foo();
+  ~foo();
+
+  template 
+  void format(const char *const fmt, Args &&...args) // expected-warning{{GCC requires a function with the 'format' attribute to be variadic}}
+  __attribute__((format(printf, 2, 3))) {
+printf(fmt, expand(args)...);
+  }
+};
+
+void format_invalid_nonpod(const char *fmt, struct foo f) // expected-warning{{GCC requires a function with the 'format' attribute to be variadic}}
+__attribute__((format(printf, 1, 2)));
+
+void do_format() {
+  int x = 123;
+  int  = x;
+  const char *s = "world";
+  format("bare string");
+  format("%s", 123); // expected-warning{{format specifies type 'char *' but the argument has type 'int'}}
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, do_format);
+  format("bad format %s"); // expected-warning{{more '%' conversions than data arguments}}
+
+  struct foo f;
+  format_invalid_nonpod("hello %i", f); // expected-warning{{format specifies type 'int' but the argument has type 'struct foo'}}
+
+  f.format("%s", 123); // expected-warning{{format specifies type 'char *' but the argument has type 'int'}}
+  f.format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);
+  f.format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, do_format);
+  f.format("bad format %s"); // expected-warning{{more '%' conversions than data arguments}}
+}
Index: clang/test/Sema/format-strings.c
===
--- clang/test/Sema/format-strings.c
+++ clang/test/Sema/format-strings.c
@@ -816,6 +816,7 @@
   __attribute__((__format__(__printf__, 2, 3))) {
 va_list ap;
 va_start(ap, fmt);
+vprintf(fmt, ap);
 vprintf(not_fmt, ap); // expected-warning{{format string is not a string literal}}
 va_end(ap);
   };
Index: clang/test/Sema/attr-format.c
===
--- clang/test/Sema/attr-format.c
+++ clang/test/Sema/attr-format.c
@@ -2,18 +2,18 @@
 
 #include 
 
-void a(const char *a, ...) __attribute__((format(printf, 1,2))); // no-error
-void b(const char *a, ...) __attribute__((format(printf, 1,1))); // expected-error {{'format' attribute parameter 3 is out of bounds}}
-void c(const char *a, ...) __attribute__((format(printf, 0,2))); // expected-error {{'format' attribute parameter 2 is out of bounds}}
-void d(const char *a, int c) __attribute__((format(printf, 1,2))); // expected-error {{format attribute requires variadic function}}
-void e(char *str, int c, ...) __attribute__((format(printf, 2,3))); // expected-error {{format argument not a string type}}
+void a(const char *a, ...) __attribute__((format(printf, 1, 2)));// no-error
+void b(const char *a, ...) __attribute__((format(printf, 1, 1)));// expected-error {{'format' attribute parameter 3 is out of bounds}}
+void c(const char *a, ...) __attribute__((format(printf, 0, 2)));// expected-error {{'format' attribute parameter 2 is out of 

[clang] 92edd74 - Allow non-variadic functions to be attributed with `__attribute__((format))`

2022-07-05 Thread Félix Cloutier via cfe-commits

Author: Félix Cloutier
Date: 2022-07-05T17:26:11-07:00
New Revision: 92edd74b37c7a96b1d47dc67cda7f92b65066025

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

LOG: Allow non-variadic functions to be attributed with 
`__attribute__((format))`

Clang only allows you to use __attribute__((format)) on variadic functions. 
There are legit use cases for __attribute__((format)) on non-variadic 
functions, such as:

(1) variadic templates

```c++
template
void print(const char *fmt, Args… &) __attribute__((format(1, 2))); // 
error: format attribute requires variadic function
```

(2) functions which take fixed arguments and a custom format:

```c++
void print_number_string(const char *fmt, unsigned number, const char *string) 
__attribute__((format(1, 2)));
// ^error: format attribute requires variadic function

void foo(void) {
print_number_string(“%08x %s\n”, 0xdeadbeef, “hello”);
print_number_string(“%d %s”, 0xcafebabe, “bar”);
}
```

This change allows Clang users to attach __attribute__((format)) to 
non-variadic functions, including functions with C++ variadic templates. It 
replaces the error with a GCC compatibility warning and improves the type 
checker to ensure that received arrays are treated like pointers (this is a 
possibility in C++ since references to template types can bind to arrays).

Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D112579
rdar://84629099

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/Sema.h
clang/lib/AST/FormatString.cpp
clang/lib/Sema/SemaChecking.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/Sema/attr-format.c
clang/test/Sema/format-strings.c
clang/test/SemaCXX/attr-format.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 1be63b539441f..98153fd6e68d8 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -385,6 +385,10 @@ Attribute Changes in Clang
 
 - Added half float to types that can be represented by 
``__attribute__((mode(XX)))``.
 
+- The ``format`` attribute can now be applied to non-variadic functions. The
+  format string must correctly format the fixed parameter types of the 
function.
+  Using the attribute this way emits a GCC compatibility diagnostic.
+
 Windows Support
 ---
 

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 4e4d871a58a7f..27a3c2f2a69c3 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -3088,8 +3088,8 @@ def FormatDocs : Documentation {
   let Content = [{
 
 Clang supports the ``format`` attribute, which indicates that the function
-accepts a ``printf`` or ``scanf``-like format string and corresponding
-arguments or a ``va_list`` that contains these arguments.
+accepts (among other possibilities) a ``printf`` or ``scanf``-like format 
string
+and corresponding arguments or a ``va_list`` that contains these arguments.
 
 Please see `GCC documentation about format attribute
 `_ to find details
@@ -3143,6 +3143,27 @@ Clang implements two kinds of checks with this attribute.
In this case Clang does not warn because the format string ``s`` and
the corresponding arguments are annotated. If the arguments are
incorrect, the caller of ``foo`` will receive a warning.
+
+As an extension to GCC's behavior, Clang accepts the ``format`` attribute on
+non-variadic functions. Clang checks non-variadic format functions for the same
+classes of issues that can be found on variadic functions, as controlled by the
+same warning flags, except that the types of formatted arguments is forced by
+the function signature. For example:
+
+.. code-block:: c
+
+  __attribute__((__format__(__printf__, 1, 2)))
+  void fmt(const char *s, const char *a, int b);
+
+  void bar(void) {
+fmt("%s %i", "hello", 123); // OK
+fmt("%i %g", "hello", 123); // warning: arguments don't match format
+extern const char *fmt;
+fmt(fmt, "hello", 123); // warning: format string is not a string literal
+  }
+
+Using the ``format`` attribute on a non-variadic function emits a GCC
+compatibility diagnostic.
   }];
 }
 

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index bc7aec3803e82..9e589c70a86d7 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3115,8 +3115,6 @@ def note_ownership_returns_index_mismatch : Note<
   "declared with index %0 here">;
 def 

[PATCH] D129165: [AIX][clang/test] Set/propagate AIXTHREAD_STK for AIX

2022-07-05 Thread Xing Xue via Phabricator via cfe-commits
xingxue accepted this revision.
xingxue added a comment.
This revision is now accepted and ready to land.

LGTM; thanks!  The IBM OpenMP runtime sets the default thread stack size to 
4MiB on AIX as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129165

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


[PATCH] D129165: [AIX][clang/test] Set/propagate AIXTHREAD_STK for AIX

2022-07-05 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast created this revision.
hubert.reinterpretcast added reviewers: xingxue, daltenty, Jake-Egan, 
cebowleratibm.
Herald added subscribers: ormris, arphaman, steven_wu, hiraditya, kristof.beyls.
Herald added a project: All.
hubert.reinterpretcast requested review of this revision.
Herald added a project: clang.

Some tests perform deep recursion, which requires a larger pthread stack
size than the relatively low default of 192 KiB for 64-bit processes on
AIX. The `AIXTHREAD_STK` environment variable provides a non-intrusive
way to request a larger pthread stack size for the tests. The required
pthread stack size depends on the build configuration.

A 4 MiB default is generous compared to the 512 KiB of macOS; however,
it is known that some compilers on AIX produce code that uses
comparatively more stack space.

This patch expands the solution from D65688  
to apply to all Clang LIT
tests.

This also reverts commit c3c75d805c2174388417080f762230961b3433d6 
,
"[clang][test] Mark test arm-float-abi-lto.c unsupported on AIX".

The problem was caused by the test running up against the per-thread
stack limit on AIX. This is resolved by having the tests run with
`AIXTHREAD_STK` set for 4 MiB.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129165

Files:
  clang/test/Driver/arm-float-abi-lto.c
  clang/test/Index/lit.local.cfg
  clang/test/lit.cfg.py


Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -264,3 +264,13 @@
   '/ASTMerge/anonymous-fields', 
'/ASTMerge/injected-class-name-decl'):
 exclude_unsupported_files_for_aix(config.test_source_root + directory)
 
+# Some tests perform deep recursion, which requires a larger pthread stack size
+# than the relatively low default of 192 KiB for 64-bit processes on AIX. The
+# `AIXTHREAD_STK` environment variable provides a non-intrusive way to request
+# a larger pthread stack size for the tests. Various applications and runtime
+# libraries on AIX use a default pthread stack size of 4 MiB, so we will use
+# that as a default value here.
+if 'AIXTHREAD_STK' in os.environ:
+config.environment['AIXTHREAD_STK'] = os.environ['AIXTHREAD_STK']
+elif platform.system() == 'AIX':
+config.environment['AIXTHREAD_STK'] = '4194304'
Index: clang/test/Index/lit.local.cfg
===
--- clang/test/Index/lit.local.cfg
+++ /dev/null
@@ -1,12 +0,0 @@
-import platform
-
-# Some tests perform deep recursion, which requires a larger pthread stack size
-# than the relatively low default of 192 KiB for 64-bit processes on AIX. The
-# `AIXTHREAD_STK` environment variable provides a non-intrusive way to request
-# a larger pthread stack size for the tests. Various applications and runtime
-# libraries on AIX use a default pthread stack size of 4 MiB, so we will use
-# that as a default value here.
-if 'AIXTHREAD_STK' in os.environ:
-config.environment['AIXTHREAD_STK'] = os.environ['AIXTHREAD_STK']
-elif platform.system() == 'AIX':
-config.environment['AIXTHREAD_STK'] = '4194304'
Index: clang/test/Driver/arm-float-abi-lto.c
===
--- clang/test/Driver/arm-float-abi-lto.c
+++ clang/test/Driver/arm-float-abi-lto.c
@@ -1,5 +1,3 @@
-// FIXME: Produces a segmentation fault on AIX after the introduction of 
opaque pointers (D125847). 
-// UNSUPPORTED: system-aix
 // REQUIRES: arm-registered-target
 
 // RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s 
-S -o - -emit-llvm -DCALL_LIB -DDEFINE_LIB | FileCheck %s


Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -264,3 +264,13 @@
   '/ASTMerge/anonymous-fields', '/ASTMerge/injected-class-name-decl'):
 exclude_unsupported_files_for_aix(config.test_source_root + directory)
 
+# Some tests perform deep recursion, which requires a larger pthread stack size
+# than the relatively low default of 192 KiB for 64-bit processes on AIX. The
+# `AIXTHREAD_STK` environment variable provides a non-intrusive way to request
+# a larger pthread stack size for the tests. Various applications and runtime
+# libraries on AIX use a default pthread stack size of 4 MiB, so we will use
+# that as a default value here.
+if 'AIXTHREAD_STK' in os.environ:
+config.environment['AIXTHREAD_STK'] = os.environ['AIXTHREAD_STK']
+elif platform.system() == 'AIX':
+config.environment['AIXTHREAD_STK'] = '4194304'
Index: clang/test/Index/lit.local.cfg
===
--- clang/test/Index/lit.local.cfg
+++ /dev/null
@@ -1,12 +0,0 @@
-import platform
-
-# Some tests perform deep 

[clang] 9b1cf2e - Fix running orc-rt tests with LLVM_BUILD_EXTERNAL_COMPILER_RT (again).

2022-07-05 Thread Lang Hames via cfe-commits

Author: Lang Hames
Date: 2022-07-05T15:20:08-07:00
New Revision: 9b1cf2e2b2a8ca2bc10894d569a653429b989dd0

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

LOG: Fix running orc-rt tests with LLVM_BUILD_EXTERNAL_COMPILER_RT (again).

Add missing dependency on lli when building compiler-rt with
LLVM_BUILD_EXTERNAL_COMPILER_RT. Previously we would non-deterministically fail
the tests due to the missing binary.

This is essentially identical to 0e5ea403e8d, which added an earlier dependence
on llvm-jitlink.

rdar://96467892

Added: 


Modified: 
clang/runtime/CMakeLists.txt

Removed: 




diff  --git a/clang/runtime/CMakeLists.txt b/clang/runtime/CMakeLists.txt
index 02ea3811e3922..9f4633bc85b12 100644
--- a/clang/runtime/CMakeLists.txt
+++ b/clang/runtime/CMakeLists.txt
@@ -132,7 +132,7 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND EXISTS 
${COMPILER_RT_SRC_ROOT}/)
   if(LLVM_INCLUDE_TESTS)
 # Add binaries that compiler-rt tests depend on.
 set(COMPILER_RT_TEST_DEPENDENCIES
-  FileCheck count not llvm-nm llvm-objdump llvm-symbolizer llvm-jitlink)
+  FileCheck count not llvm-nm llvm-objdump llvm-symbolizer llvm-jitlink 
lli)
 
 # Add top-level targets for various compiler-rt test suites.
 set(COMPILER_RT_TEST_SUITES check-fuzzer check-asan check-hwasan 
check-asan-dynamic check-dfsan



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


[PATCH] D129065: [RISCV][Driver] Add libm linking to `RISCVToolchain` for C++

2022-07-05 Thread Anton Afanasyev 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 rGf553287b5889: [RISCV][Driver] Add libm linking to 
`RISCVToolchain` for C++ (authored by anton-afanasyev).

Changed prior to commit:
  https://reviews.llvm.org/D129065?vs=442069=442402#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129065

Files:
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  clang/test/Driver/riscv32-toolchain.c
  clang/test/Driver/riscv64-toolchain.c


Index: clang/test/Driver/riscv64-toolchain.c
===
--- clang/test/Driver/riscv64-toolchain.c
+++ clang/test/Driver/riscv64-toolchain.c
@@ -58,7 +58,7 @@
 // CXX-RV64-BAREMETAL-LP64: 
"{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1{{/|}}crtbegin.o"
 // CXX-RV64-BAREMETAL-LP64: 
"-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1"
 // CXX-RV64-BAREMETAL-LP64: 
"-L{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib"
-// CXX-RV64-BAREMETAL-LP64: "-lstdc++" "--start-group" "-lc" "-lgloss" 
"--end-group" "-lgcc"
+// CXX-RV64-BAREMETAL-LP64: "-lstdc++" "-lm" "--start-group" "-lc" "-lgloss" 
"--end-group" "-lgcc"
 // CXX-RV64-BAREMETAL-LP64: 
"{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1{{/|}}crtend.o"
 
 // RUN: env "PATH=" %clangxx -### %s -fuse-ld= \
@@ -73,7 +73,7 @@
 // CXX-RV64-BAREMETAL-NOSYSROOT-LP64: 
"{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1{{/|}}crtbegin.o"
 // CXX-RV64-BAREMETAL-NOSYSROOT-LP64: 
"-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1"
 // CXX-RV64-BAREMETAL-NOSYSROOT-LP64: 
"-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1/../../..{{/|}}..{{/|}}riscv64-unknown-linux-gnu/lib"
-// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "-lstdc++" "--start-group" "-lc" 
"-lgloss" "--end-group" "-lgcc"
+// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "-lstdc++" "-lm" "--start-group" "-lc" 
"-lgloss" "--end-group" "-lgcc"
 // CXX-RV64-BAREMETAL-NOSYSROOT-LP64: 
"{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1{{/|}}crtend.o"
 
 // RUN: env "PATH=" %clang -### %s -fuse-ld= -no-pie \
Index: clang/test/Driver/riscv32-toolchain.c
===
--- clang/test/Driver/riscv32-toolchain.c
+++ clang/test/Driver/riscv32-toolchain.c
@@ -58,7 +58,7 @@
 // CXX-RV32-BAREMETAL-ILP32: 
"{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1{{/|}}crtbegin.o"
 // CXX-RV32-BAREMETAL-ILP32: 
"-L{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1"
 // CXX-RV32-BAREMETAL-ILP32: 
"-L{{.*}}/Inputs/basic_riscv32_tree/riscv32-unknown-elf/lib"
-// CXX-RV32-BAREMETAL-ILP32: "-lstdc++" "--start-group" "-lc" "-lgloss" 
"--end-group" "-lgcc"
+// CXX-RV32-BAREMETAL-ILP32: "-lstdc++" "-lm" "--start-group" "-lc" "-lgloss" 
"--end-group" "-lgcc"
 // CXX-RV32-BAREMETAL-ILP32: 
"{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1{{/|}}crtend.o"
 
 // RUN: %clangxx -### %s -fuse-ld= \
@@ -73,7 +73,7 @@
 // CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: 
"{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1{{/|}}crtbegin.o"
 // CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: 
"-L{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1"
 // CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: 
"-L{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1/../../..{{/|}}..{{/|}}riscv32-unknown-linux-gnu/lib"
-// CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: "-lstdc++" "--start-group" "-lc" 
"-lgloss" "--end-group" "-lgcc"
+// CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: "-lstdc++" "-lm" "--start-group" "-lc" 
"-lgloss" "--end-group" "-lgcc"
 // CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: 
"{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1{{/|}}crtend.o"
 
 // RUN: env "PATH=" %clang -### %s -fuse-ld=ld -no-pie \
Index: clang/lib/Driver/ToolChains/RISCVToolchain.cpp
===
--- clang/lib/Driver/ToolChains/RISCVToolchain.cpp
+++ clang/lib/Driver/ToolChains/RISCVToolchain.cpp
@@ -201,8 +201,11 @@
 
   if (!Args.hasArg(options::OPT_nostdlib) &&
   !Args.hasArg(options::OPT_nodefaultlibs)) {
-if (ToolChain.ShouldLinkCXXStdlib(Args))
-  ToolChain.AddCXXStdlibLibArgs(Args, CmdArgs);
+if (D.CCCIsCXX()) {
+  if (ToolChain.ShouldLinkCXXStdlib(Args))
+ToolChain.AddCXXStdlibLibArgs(Args, CmdArgs);
+  CmdArgs.push_back("-lm");
+}
 CmdArgs.push_back("--start-group");
 CmdArgs.push_back("-lc");
 CmdArgs.push_back("-lgloss");


Index: clang/test/Driver/riscv64-toolchain.c
===
--- 

[clang] f553287 - [RISCV][Driver] Add libm linking to `RISCVToolchain` for C++

2022-07-05 Thread Anton Afanasyev via cfe-commits

Author: Anton Afanasyev
Date: 2022-07-06T00:52:26+03:00
New Revision: f553287b588916de09c66e3e32bf75e5060f967f

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

LOG: [RISCV][Driver] Add libm linking to `RISCVToolchain` for C++

GCC automatically links math library by adding `-lm` to linker command
line, since C++ runtime `libstdc++` requires libm, so add it to
`RISCVToochain` as well.

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/RISCVToolchain.cpp
clang/test/Driver/riscv32-toolchain.c
clang/test/Driver/riscv64-toolchain.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/RISCVToolchain.cpp 
b/clang/lib/Driver/ToolChains/RISCVToolchain.cpp
index a048765bc6d3b..3491de22d3719 100644
--- a/clang/lib/Driver/ToolChains/RISCVToolchain.cpp
+++ b/clang/lib/Driver/ToolChains/RISCVToolchain.cpp
@@ -201,8 +201,11 @@ void RISCV::Linker::ConstructJob(Compilation , const 
JobAction ,
 
   if (!Args.hasArg(options::OPT_nostdlib) &&
   !Args.hasArg(options::OPT_nodefaultlibs)) {
-if (ToolChain.ShouldLinkCXXStdlib(Args))
-  ToolChain.AddCXXStdlibLibArgs(Args, CmdArgs);
+if (D.CCCIsCXX()) {
+  if (ToolChain.ShouldLinkCXXStdlib(Args))
+ToolChain.AddCXXStdlibLibArgs(Args, CmdArgs);
+  CmdArgs.push_back("-lm");
+}
 CmdArgs.push_back("--start-group");
 CmdArgs.push_back("-lc");
 CmdArgs.push_back("-lgloss");

diff  --git a/clang/test/Driver/riscv32-toolchain.c 
b/clang/test/Driver/riscv32-toolchain.c
index 4b3cc997ee1cb..15f6d232d6136 100644
--- a/clang/test/Driver/riscv32-toolchain.c
+++ b/clang/test/Driver/riscv32-toolchain.c
@@ -58,7 +58,7 @@
 // CXX-RV32-BAREMETAL-ILP32: 
"{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1{{/|}}crtbegin.o"
 // CXX-RV32-BAREMETAL-ILP32: 
"-L{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1"
 // CXX-RV32-BAREMETAL-ILP32: 
"-L{{.*}}/Inputs/basic_riscv32_tree/riscv32-unknown-elf/lib"
-// CXX-RV32-BAREMETAL-ILP32: "-lstdc++" "--start-group" "-lc" "-lgloss" 
"--end-group" "-lgcc"
+// CXX-RV32-BAREMETAL-ILP32: "-lstdc++" "-lm" "--start-group" "-lc" "-lgloss" 
"--end-group" "-lgcc"
 // CXX-RV32-BAREMETAL-ILP32: 
"{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1{{/|}}crtend.o"
 
 // RUN: %clangxx -### %s -fuse-ld= \
@@ -73,7 +73,7 @@
 // CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: 
"{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1{{/|}}crtbegin.o"
 // CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: 
"-L{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1"
 // CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: 
"-L{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1/../../..{{/|}}..{{/|}}riscv32-unknown-linux-gnu/lib"
-// CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: "-lstdc++" "--start-group" "-lc" 
"-lgloss" "--end-group" "-lgcc"
+// CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: "-lstdc++" "-lm" "--start-group" "-lc" 
"-lgloss" "--end-group" "-lgcc"
 // CXX-RV32-BAREMETAL-NOSYSROOT-ILP32: 
"{{.*}}/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1{{/|}}crtend.o"
 
 // RUN: env "PATH=" %clang -### %s -fuse-ld=ld -no-pie \

diff  --git a/clang/test/Driver/riscv64-toolchain.c 
b/clang/test/Driver/riscv64-toolchain.c
index 7d66554660110..28e8142bb76fe 100644
--- a/clang/test/Driver/riscv64-toolchain.c
+++ b/clang/test/Driver/riscv64-toolchain.c
@@ -58,7 +58,7 @@
 // CXX-RV64-BAREMETAL-LP64: 
"{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1{{/|}}crtbegin.o"
 // CXX-RV64-BAREMETAL-LP64: 
"-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1"
 // CXX-RV64-BAREMETAL-LP64: 
"-L{{.*}}/Inputs/basic_riscv64_tree/riscv64-unknown-elf/lib"
-// CXX-RV64-BAREMETAL-LP64: "-lstdc++" "--start-group" "-lc" "-lgloss" 
"--end-group" "-lgcc"
+// CXX-RV64-BAREMETAL-LP64: "-lstdc++" "-lm" "--start-group" "-lc" "-lgloss" 
"--end-group" "-lgcc"
 // CXX-RV64-BAREMETAL-LP64: 
"{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1{{/|}}crtend.o"
 
 // RUN: env "PATH=" %clangxx -### %s -fuse-ld= \
@@ -73,7 +73,7 @@
 // CXX-RV64-BAREMETAL-NOSYSROOT-LP64: 
"{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1{{/|}}crtbegin.o"
 // CXX-RV64-BAREMETAL-NOSYSROOT-LP64: 
"-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1"
 // CXX-RV64-BAREMETAL-NOSYSROOT-LP64: 
"-L{{.*}}/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1/../../..{{/|}}..{{/|}}riscv64-unknown-linux-gnu/lib"
-// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "-lstdc++" "--start-group" "-lc" 
"-lgloss" "--end-group" "-lgcc"
+// CXX-RV64-BAREMETAL-NOSYSROOT-LP64: "-lstdc++" 

[PATCH] D129065: [RISCV][Driver] Add libm linking to `RISCVToolchain` for C++

2022-07-05 Thread Anton Afanasyev via Phabricator via cfe-commits
anton-afanasyev added a comment.

In D129065#3631052 , @jrtc27 wrote:

> Commit subject/body should say C++ in it

Sure, updated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129065

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


[PATCH] D128927: [libc++] Always build c++experimental.a

2022-07-05 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In D128927#3622793 , @ldionne wrote:

> @mstorsjo I might need some assistance figuring out what to do with the 
> Windows parts of this change.

I can try to have a look in a couple days or so - I'm vacationing and have been 
travelling, but I'm slowly trying to catch up on things here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128927

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


[PATCH] D128012: [HLSL] Add ExternalSemaSource & vector alias

2022-07-05 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added a comment.

Posted an update in rGa6e63e35ede4 
, which 
removes the not-fully-implemented RTTI bits, and adds an extra test case to 
cover instantiation errors.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128012

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


[PATCH] D108469: Improve handling of static assert messages.

2022-07-05 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann added a comment.
Herald added a reviewer: NoQ.

I missed my opportunity to review while being on vacation last week. I reviewed 
to keep myself informed; spotted a typo.




Comment at: llvm/lib/Support/Unicode.cpp:272
+/// Unicode code points of the Cf category are considered
+/// fornatting characters.
+bool isFormatting(int UCS) {




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108469

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


[clang] a6e63e3 - [NFC][HLSL] Add tests for vector alias. Remove dead code.

2022-07-05 Thread Chris Bieneman via cfe-commits

Author: Chris Bieneman
Date: 2022-07-05T16:32:59-05:00
New Revision: a6e63e35ede4b9f23b58437263eaac9a2926c9bf

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

LOG: [NFC][HLSL] Add tests for vector alias. Remove dead code.

Based on feedback from @Aaron.Ballman.

Remove the unused static ID char (can re-add it later if needed).

Add test to cover some invalid HLSL vector instantations ensuring
that the appropriate error messages are generated.

Added: 
clang/test/SemaHLSL/BuiltIns/vector-errors.hlsl

Modified: 
clang/include/clang/Sema/HLSLExternalSemaSource.h
clang/lib/Sema/HLSLExternalSemaSource.cpp

Removed: 




diff  --git a/clang/include/clang/Sema/HLSLExternalSemaSource.h 
b/clang/include/clang/Sema/HLSLExternalSemaSource.h
index 92154427a3e72..439fc3d10f333 100644
--- a/clang/include/clang/Sema/HLSLExternalSemaSource.h
+++ b/clang/include/clang/Sema/HLSLExternalSemaSource.h
@@ -19,8 +19,6 @@ class NamespaceDecl;
 class Sema;
 
 class HLSLExternalSemaSource : public ExternalSemaSource {
-  static char ID;
-
   Sema *SemaPtr = nullptr;
   NamespaceDecl *HLSLNamespace;
 

diff  --git a/clang/lib/Sema/HLSLExternalSemaSource.cpp 
b/clang/lib/Sema/HLSLExternalSemaSource.cpp
index 2de90378baf90..56c2dd40bd9a8 100644
--- a/clang/lib/Sema/HLSLExternalSemaSource.cpp
+++ b/clang/lib/Sema/HLSLExternalSemaSource.cpp
@@ -17,8 +17,6 @@
 
 using namespace clang;
 
-char HLSLExternalSemaSource::ID;
-
 HLSLExternalSemaSource::~HLSLExternalSemaSource() {}
 
 void HLSLExternalSemaSource::InitializeSema(Sema ) {

diff  --git a/clang/test/SemaHLSL/BuiltIns/vector-errors.hlsl 
b/clang/test/SemaHLSL/BuiltIns/vector-errors.hlsl
new file mode 100644
index 0..d2598a57400b0
--- /dev/null
+++ b/clang/test/SemaHLSL/BuiltIns/vector-errors.hlsl
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl 
-fsyntax-only -verify %s
+
+// Some bad declarations
+hlsl::vector ShouldWorkSomeday; // expected-error{{use of alias template 
'hlsl::vector' requires template arguments}}
+
+hlsl::vector<1> BadVec; // expected-error{{template argument for template type 
parameter must be a type}}
+// expected-note@*:* {{template is declared here}}
+// expected-note@*:* {{template parameter is declared here}}
+
+
+hlsl::vector AnotherBadVec; // expected-error{{template argument 
for non-type template parameter must be an expression}}
+// expected-note@*:* {{template parameter is declared here}}
+
+hlsl::vector YABV; // expected-error{{too many template arguments 
for alias template 'vector'}}
+// expected-note@*:* {{template is declared here}}
+
+// This code is rejected by clang because clang puts the HLSL built-in types
+// into the HLSL namespace.
+namespace hlsl {
+  struct vector {}; // expected-error {{redefinition of 'vector'}}
+}
+
+// This code is rejected by dxc because dxc puts the HLSL built-in types
+// into the global space, but clang will allow it even though it will shadow 
the
+// vector template.
+struct vector {}; // expected-note {{candidate found by name lookup is 
'vector'}}
+
+vector VecInt2; // expected-error {{reference to 'vector' is ambiguous}}
+
+// expected-note@*:* {{candidate found by name lookup is 'hlsl::vector'}}



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


[PATCH] D112579: Allow non-variadic functions to be attributed with `__attribute__((format))`

2022-07-05 Thread Félix Cloutier via Phabricator via cfe-commits
fcloutier updated this revision to Diff 442396.
fcloutier added a comment.

There was a merge conflict on the release notes, updating the differential to 
get a CI build.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112579

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/FormatString.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/attr-format.c
  clang/test/Sema/format-strings.c
  clang/test/SemaCXX/attr-format.cpp

Index: clang/test/SemaCXX/attr-format.cpp
===
--- clang/test/SemaCXX/attr-format.cpp
+++ clang/test/SemaCXX/attr-format.cpp
@@ -1,7 +1,11 @@
 // RUN: %clang_cc1 -fsyntax-only -Wformat-nonliteral -verify %s
+#include 
+
+int printf(const char *fmt, ...) __attribute__((format(printf, 1, 2)));
+
 struct S {
-  static void f(const char*, ...) __attribute__((format(printf, 1, 2)));
-  static const char* f2(const char*) __attribute__((format_arg(1)));
+  static void f(const char *, ...) __attribute__((format(printf, 1, 2)));
+  static const char *f2(const char *) __attribute__((format_arg(1)));
 
   // GCC has a hidden 'this' argument in member functions which is why
   // the format argument is argument 2 here.
@@ -38,6 +42,47 @@
 
 // Make sure we interpret member operator calls as having an implicit
 // this argument.
-void test_operator_call(S s, const char* str) {
+void test_operator_call(S s, const char *str) {
   s("%s", str);
 }
+
+template 
+void format(const char *fmt, Args &&...args) // expected-warning{{GCC requires a function with the 'format' attribute to be variadic}}
+__attribute__((format(printf, 1, 2)));
+
+template 
+Arg (Arg ) { return a; }
+
+struct foo {
+  int big[10];
+  foo();
+  ~foo();
+
+  template 
+  void format(const char *const fmt, Args &&...args) // expected-warning{{GCC requires a function with the 'format' attribute to be variadic}}
+  __attribute__((format(printf, 2, 3))) {
+printf(fmt, expand(args)...);
+  }
+};
+
+void format_invalid_nonpod(const char *fmt, struct foo f) // expected-warning{{GCC requires a function with the 'format' attribute to be variadic}}
+__attribute__((format(printf, 1, 2)));
+
+void do_format() {
+  int x = 123;
+  int  = x;
+  const char *s = "world";
+  format("bare string");
+  format("%s", 123); // expected-warning{{format specifies type 'char *' but the argument has type 'int'}}
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, do_format);
+  format("bad format %s"); // expected-warning{{more '%' conversions than data arguments}}
+
+  struct foo f;
+  format_invalid_nonpod("hello %i", f); // expected-warning{{format specifies type 'int' but the argument has type 'struct foo'}}
+
+  f.format("%s", 123); // expected-warning{{format specifies type 'char *' but the argument has type 'int'}}
+  f.format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);
+  f.format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, do_format);
+  f.format("bad format %s"); // expected-warning{{more '%' conversions than data arguments}}
+}
Index: clang/test/Sema/format-strings.c
===
--- clang/test/Sema/format-strings.c
+++ clang/test/Sema/format-strings.c
@@ -816,6 +816,7 @@
   __attribute__((__format__(__printf__, 2, 3))) {
 va_list ap;
 va_start(ap, fmt);
+vprintf(fmt, ap);
 vprintf(not_fmt, ap); // expected-warning{{format string is not a string literal}}
 va_end(ap);
   };
Index: clang/test/Sema/attr-format.c
===
--- clang/test/Sema/attr-format.c
+++ clang/test/Sema/attr-format.c
@@ -2,18 +2,18 @@
 
 #include 
 
-void a(const char *a, ...) __attribute__((format(printf, 1,2))); // no-error
-void b(const char *a, ...) __attribute__((format(printf, 1,1))); // expected-error {{'format' attribute parameter 3 is out of bounds}}
-void c(const char *a, ...) __attribute__((format(printf, 0,2))); // expected-error {{'format' attribute parameter 2 is out of bounds}}
-void d(const char *a, int c) __attribute__((format(printf, 1,2))); // expected-error {{format attribute requires variadic function}}
-void e(char *str, int c, ...) __attribute__((format(printf, 2,3))); // expected-error {{format argument not a string type}}
+void a(const char *a, ...) __attribute__((format(printf, 1, 2)));// no-error
+void b(const char *a, ...) __attribute__((format(printf, 1, 1)));// expected-error {{'format' attribute parameter 3 is out of bounds}}
+void c(const char *a, ...) __attribute__((format(printf, 0, 2)));// expected-error {{'format' attribute parameter 2 is out of bounds}}
+void d(const char *a, int c) 

[PATCH] D129064: [clang-format] Avoid crash in LevelIndentTracker.

2022-07-05 Thread Owen Pan via Phabricator via cfe-commits
owenpan added inline comments.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:62-70
 while (IndentForLevel.size() <= Line.Level)
   IndentForLevel.push_back(-1);
 if (Line.InPPDirective) {
   unsigned IndentWidth =
   (Style.PPIndentWidth >= 0) ? Style.PPIndentWidth : Style.IndentWidth;
   Indent = Line.Level * IndentWidth + AdditionalIndent;
 } else {

HazardyKnusperkeks wrote:
> So how about that?
Good idea, but it's an unrelated change. Let's take care of it in D129105, 
which I will update to use `resize()` instead of `insert()`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129064

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


[PATCH] D109621: [clang][Driver] Default to loading clang.cfg if config file not specified

2022-07-05 Thread Tom Stellard via Phabricator via cfe-commits
tstellar added a comment.

I similar RFC for this was proposed here: 
https://discourse.llvm.org/t/rfc-adding-a-default-file-location-to-config-file-support/63606


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

https://reviews.llvm.org/D109621

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


[PATCH] D129158: [pseudo] Define recovery strategy as grammar extension.

2022-07-05 Thread Haojian Wu via Phabricator via cfe-commits
hokein accepted this revision.
hokein added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/pseudo/lib/cxx/CXX.cpp:46
+  assert(Begin > 0);
+  const Token  = Tokens.tokens()[Begin - 1];
+  if (const Token *Right = Left.pair())

nit: assert Left is a left bracket?



Comment at: clang-tools-extra/pseudo/lib/cxx/CXX.cpp:54
+  return {
+  {(ExtensionID)Extension::Brackets, recoverBrackets},
+  };

btw, it is annoying to write an explicit ExtensionID<=>Extension conversion. To 
avoid that, what do you think of making the Symbol as an `enum` 
rather than `enum class`, and we still keep the qualified name usage 
`Extension::Brackets`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129158

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


[clang-tools-extra] 40af95d - [clang-tools-extra] Fix a link in ReleaseNotes.rst

2022-07-05 Thread Dmitri Gribenko via cfe-commits

Author: Dmitri Gribenko
Date: 2022-07-05T23:09:55+02:00
New Revision: 40af95d80bcb526ec7b025eb677f64bfdd083e96

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

LOG: [clang-tools-extra] Fix a link in ReleaseNotes.rst

Added: 


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

Removed: 




diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index ff444a0934f6f..1d6fd05605db7 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -133,7 +133,7 @@ New checks
   Detects confusable Unicode identifiers.
 
 - New :doc:`bugprone-assignment-in-if-condition
-  ` check.
+  ` check.
 
   Warns when there is an assignment within an if statement condition 
expression.
 



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


[PATCH] D124159: [SimplifyCFG] Thread branches on same condition in more cases (PR54980)

2022-07-05 Thread Nathan Chancellor via Phabricator via cfe-commits
nathanchance added a comment.

Should dc969061c68e62328607d68215ed8b9ef4a1e4b1 
 be 
reverted as well? I just bisected an assertion failure while building the Linux 
kernel for arm64 to that change:

  clang: 
/home/nathan/cbl/src/llvm-project/llvm/lib/Transforms/Utils/BasicBlockUtils.cpp:1136:
 llvm::BasicBlock *SplitBlockPredecessorsImpl(llvm::BasicBlock *, 
ArrayRef, const char *, llvm::DomTreeUpdater *, 
llvm::DominatorTree *, llvm::LoopInfo *, llvm::MemorySSAUpdater *, bool): 
Assertion `!isa(Preds[i]->getTerminator()) && "Cannot split an edge 
from a CallBrInst"' failed.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.  Program arguments: 
/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang -mlittle-endian 
-Qunused-arguments -fmacro-prefix-map=/home/nathan/cbl/src/linux/= -Wall 
-Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing 
-fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration 
-Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 
--target=aarch64-linux-gnu -fintegrated-as -Werror=unknown-warning-option 
-Werror=ignored-optimization-argument -mgeneral-regs-only -Wno-psabi 
-fno-asynchronous-unwind-tables -fno-unwind-tables 
-mbranch-protection=pac-ret+leaf+bti -fno-delete-null-pointer-checks 
-Wno-frame-address -Wno-address-of-packed-member -O2 -Wframe-larger-than=2048 
-fstack-protector-strong -Wimplicit-fallthrough -Wno-gnu 
-Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer 
-fno-optimize-sibling-calls -ftrivial-auto-var-init=zero 
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang 
-fno-stack-clash-protection -Wdeclaration-after-statement -Wvla 
-Wno-pointer-sign -Wcast-function-type -fno-strict-overflow -fno-stack-check 
-Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides 
-Wno-format -Wno-sign-compare -Wno-format-zero-length -Wno-pointer-to-enum-cast 
-Wno-tautological-constant-out-of-range-compare -Wno-unaligned-access 
-mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 
-mstack-protector-guard-offset=1184 -Wa,-march=armv8.5-a -nostdinc 
-I/home/nathan/cbl/src/linux/arch/arm64/include 
-I./arch/arm64/include/generated -I/home/nathan/cbl/src/linux/include 
-I./include -I/home/nathan/cbl/src/linux/arch/arm64/include/uapi 
-I./arch/arm64/include/generated/uapi -I/home/nathan/cbl/src/linux/include/uapi 
-I./include/generated/uapi -include 
/home/nathan/cbl/src/linux/include/linux/compiler-version.h -include 
/home/nathan/cbl/src/linux/include/linux/kconfig.h -include 
/home/nathan/cbl/src/linux/include/linux/compiler_types.h -D__KERNEL__ 
-DKASAN_SHADOW_SCALE_SHIFT= -DCONFIG_CC_HAS_K_CONSTRAINT=1 
-DARM64_ASM_ARCH=\"armv8.5-a\" -DKASAN_SHADOW_SCALE_SHIFT= -I 
/home/nathan/cbl/src/linux/arch/arm64/crypto -I ./arch/arm64/crypto 
-DKBUILD_MODFILE=\"arch/arm64/crypto/aes-ce-cipher\" 
-DKBUILD_BASENAME=\"aes_ce_glue\" -DKBUILD_MODNAME=\"aes_ce_cipher\" 
-D__KBUILD_MODNAME=kmod_aes_ce_cipher -c 
-Wp,-MMD,arch/arm64/crypto/.aes-ce-glue.o.d -fcolor-diagnostics -o 
arch/arm64/crypto/aes-ce-glue.o 
/home/nathan/cbl/src/linux/arch/arm64/crypto/aes-ce-glue.c
  1.   parser at end of file
  2.  Optimizer
   #0 0x55aae2db8b83 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang+0x3e2fb83)
   #1 0x55aae2db6b1e llvm::sys::RunSignalHandlers() 
(/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang+0x3e2db1e)
   #2 0x55aae2d40c13 (anonymous 
namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) 
CrashRecoveryContext.cpp:0:0
   #3 0x55aae2d40d8e CrashRecoverySignalHandler(int) 
CrashRecoveryContext.cpp:0:0
   #4 0x7fdd27ea18e0 (/usr/lib/libc.so.6+0x3e8e0)
   #5 0x7fdd27ef136c (/usr/lib/libc.so.6+0x8e36c)
   #6 0x7fdd27ea1838 gsignal (/usr/lib/libc.so.6+0x3e838)
   #7 0x7fdd27e8b535 abort (/usr/lib/libc.so.6+0x28535)
   #8 0x7fdd27e8b45c (/usr/lib/libc.so.6+0x2845c)
   #9 0x7fdd27e9a366 (/usr/lib/libc.so.6+0x37366)
  #10 0x55aae2dcb9b6 SplitBlockPredecessorsImpl(llvm::BasicBlock*, 
llvm::ArrayRef, char const*, llvm::DomTreeUpdater*, 
llvm::DominatorTree*, llvm::LoopInfo*, llvm::MemorySSAUpdater*, bool) 
BasicBlockUtils.cpp:0:0
  #11 0x55aae2dcba4c llvm::SplitBlockPredecessors(llvm::BasicBlock*, 
llvm::ArrayRef, char const*, llvm::DomTreeUpdater*, 
llvm::LoopInfo*, llvm::MemorySSAUpdater*, bool) 
(/home/nathan/tmp/build/llvm-bisect/stage1/bin/clang+0x3e42a4c)
  #12 0x55aae2ef5b01 (anonymous 
namespace)::SimplifyCFGOpt::simplifyCondBranch(llvm::BranchInst*, 
llvm::IRBuilder&) 
SimplifyCFG.cpp:0:0
  #13 0x55aae2ee2e29 (anonymous 
namespace)::SimplifyCFGOpt::run(llvm::BasicBlock*) SimplifyCFG.cpp:0:0
  #14 0x55aae2edfe84 

[PATCH] D127114: new clang-tidy checker for assignments within condition clause of if statement

2022-07-05 Thread Dmitri Gribenko via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG05130a6ba7d9: new clang-tidy checker for assignments within 
condition clause of if statement (authored by gribozavr).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127114

Files:
  clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.h
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp
@@ -0,0 +1,103 @@
+// RUN: %check_clang_tidy %s bugprone-assignment-in-if-condition %t
+
+void f(int arg) {
+  int f = 3;
+  if ((f = arg) || (f == (arg + 1)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f1(int arg) {
+  int f = 3;
+  if ((f == arg) || (f = (arg + 1)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f2(int arg) {
+  int f = 3;
+  if (f = arg)
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+volatile int v = 32;
+
+void f3(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && (f = v)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:40: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f4(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && ((f = v) || (f < 8
+  // CHECK-MESSAGES: :[[@LINE-1]]:41: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  } else if ((arg + 8 < f) && ((f = v) || (f < 8)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 6;
+  }
+}
+
+class BrokenOperator {
+public:
+  int d = 0;
+  int operator=(const int ) {
+d = val + 1;
+return d;
+  }
+};
+
+void f5(int arg) {
+  BrokenOperator bo;
+  int f = 3;
+  bo = f;
+  if (bo.d == 3) {
+f = 6;
+  }
+  if (bo = 3)
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 7;
+  }
+  if ((arg == 3) || (bo = 6))
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 8;
+  }
+  v = f;
+}
+
+// Tests that shouldn't trigger warnings.
+void awesome_f2(int arg) {
+  int f = 3;
+  if ((f == arg) || (f == (arg + 1))) {
+f = 5;
+  }
+}
+
+void awesome_f3(int arg) {
+  int f = 3;
+  if (f == arg) {
+f = 5;
+  }
+}
+
+void awesome_f4(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && ((f == v) || (f < 8 {
+f = 5;
+  }
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -78,6 +78,7 @@
`boost-use-to-string `_, "Yes"
`bugprone-argument-comment `_, "Yes"
`bugprone-assert-side-effect `_,
+   `bugprone-assignment-in-if-condition `_,
`bugprone-bad-signal-to-kill-thread `_,
`bugprone-bool-pointer-implicit-conversion `_, "Yes"
`bugprone-branch-clone `_,
Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
@@ -0,0 +1,23 @@
+.. title:: clang-tidy - bugprone-assignment-in-if-condition
+
+bugprone-assignment-in-if-condition
+===
+
+Finds assignments within conditions of `if` statements.
+Such assignments are bug-prone because they may have been intended as equality tests.
+
+This check finds all assignments within `if` conditions, including ones that are not flagged
+by `-Wparentheses` due to an extra set of parentheses, and including assignments that call
+an overloaded `operator=()`. The identified assignments violate 
+`BARR group "Rule 

[clang-tools-extra] 05130a6 - new clang-tidy checker for assignments within condition clause of if statement

2022-07-05 Thread Dmitri Gribenko via cfe-commits

Author: Dmitri Gribenko
Date: 2022-07-05T23:04:12+02:00
New Revision: 05130a6ba7d9974136388c1fbe63125596325d2e

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

LOG: new clang-tidy checker for assignments within condition clause of if 
statement

new clang-tidy checker for assignments within the condition clause of an 'if' 
statement.

Reviewed By: gribozavr2

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

Added: 
clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.cpp
clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.h

clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst

clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp

Modified: 
clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/list.rst

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.cpp
new file mode 100644
index 0..e4f52191e0b00
--- /dev/null
+++ b/clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.cpp
@@ -0,0 +1,49 @@
+//===--- AssignmentInIfConditionCheck.cpp - clang-tidy 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "AssignmentInIfConditionCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace bugprone {
+
+void AssignmentInIfConditionCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(ifStmt(hasCondition(forEachDescendant(
+ binaryOperator(isAssignmentOperator())
+ .bind("assignment_in_if_statement",
+ this);
+  Finder->addMatcher(ifStmt(hasCondition(forEachDescendant(
+ cxxOperatorCallExpr(isAssignmentOperator())
+ .bind("assignment_in_if_statement",
+ this);
+}
+
+void AssignmentInIfConditionCheck::check(
+const MatchFinder::MatchResult ) {
+  const auto *MatchedDecl =
+  Result.Nodes.getNodeAs("assignment_in_if_statement");
+  if (!MatchedDecl) {
+return;
+  }
+  diag(MatchedDecl->getBeginLoc(),
+   "an assignment within an 'if' condition is bug-prone");
+  diag(MatchedDecl->getBeginLoc(),
+   "if it should be an assignment, move it out of the 'if' condition",
+   DiagnosticIDs::Note);
+  diag(MatchedDecl->getBeginLoc(),
+   "if it is meant to be an equality check, change '=' to '=='",
+   DiagnosticIDs::Note);
+}
+
+} // namespace bugprone
+} // namespace tidy
+} // namespace clang

diff  --git 
a/clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.h 
b/clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.h
new file mode 100644
index 0..8e57f1a7ca80d
--- /dev/null
+++ b/clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.h
@@ -0,0 +1,34 @@
+//===--- AssignmentInIfConditionCheck.h - clang-tidy *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef 
LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_BUGPRONE_ASSIGNMENTINIFCONDITIONCHECK_H
+#define 
LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_BUGPRONE_ASSIGNMENTINIFCONDITIONCHECK_H
+
+#include "../ClangTidyCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace bugprone {
+
+/// Catches assignments within the condition clause of an if statement.
+///
+/// For the user-facing documentation see:
+/// 
http://clang.llvm.org/extra/clang-tidy/checks/bugprone-assignment-in-if-condition.html
+class AssignmentInIfConditionCheck : public ClangTidyCheck {
+public:
+  AssignmentInIfConditionCheck(StringRef Name, ClangTidyContext *Context)
+  : ClangTidyCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+};
+
+} // namespace bugprone
+} // namespace tidy
+} // namespace clang
+
+#endif // 

[PATCH] D125693: [DebugInfo] Support types, imports and static locals declared in a lexical block (3/5)

2022-07-05 Thread Ellis Hoag via Phabricator via cfe-commits
ellis added inline comments.



Comment at: llvm/test/Instrumentation/InstrProfiling/debug-info-correlate.ll:23
   call void @llvm.instrprof.increment(i8* getelementptr inbounds ([3 x i8], [3 
x i8]* @__profn_foo, i32 0, i32 0), i64 12345678, i32 2, i32 0)
-  ret void
+  ret void, !dbg !17
 }

I asked the same question in D113741, but why is this test changed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125693

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


[PATCH] D129160: libclang.so: Make SONAME the same as LLVM version

2022-07-05 Thread Tom Stellard via Phabricator via cfe-commits
tstellar created this revision.
tstellar added reviewers: MaskRay, h-vetinari.
Herald added subscribers: StephenFan, fedor.sergeev, mgorny.
Herald added a project: All.
tstellar requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This partially reverts c7b3a91017d26266d7556b1ac7c49b06f0109b91 
.  Having
libclang.so with a different SONAME than the other LLVM libraries was
causing a lot of confusion for users.  Also, this change did not really
acheive it's purpose of allowing apps to use newer versions of
libclang.so without rebuilding, because a new version of libclang.so
requires a new version of libLLVM.so, which does not have a stable ABI.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129160

Files:
  clang/tools/libclang/CMakeLists.txt
  clang/tools/libclang/libclang.exports
  clang/tools/libclang/libclang.map
  clang/tools/libclang/linker-script-to-export-list.py

Index: clang/tools/libclang/linker-script-to-export-list.py
===
--- clang/tools/libclang/linker-script-to-export-list.py
+++ /dev/null
@@ -1,11 +0,0 @@
-import re
-import os
-import sys
-
-input_file = open(sys.argv[1])
-output_file = open(sys.argv[2], 'w')
-
-for line in input_file:
-m = re.search('^\s+(clang_[^;]+)', line)
-if m:
-output_file.write(m.group(1) + "\n")
Index: clang/tools/libclang/libclang.map
===
--- clang/tools/libclang/libclang.map
+++ /dev/null
@@ -1,413 +0,0 @@
-# If you add a symbol to this file, make sure to add it with the correct
-# version.  For example, if the LLVM main branch is LLVM 14.0.0, add new
-# symbols with the version LLVM_14.
-# On platforms where versions scripts are not used, this file will be used to
-# generate a list of exports for libclang.so
-
-LLVM_13 {
-  global:
-clang_BlockCommandComment_getArgText;
-clang_BlockCommandComment_getCommandName;
-clang_BlockCommandComment_getNumArgs;
-clang_BlockCommandComment_getParagraph;
-clang_CXCursorSet_contains;
-clang_CXCursorSet_insert;
-clang_CXIndex_getGlobalOptions;
-clang_CXIndex_setGlobalOptions;
-clang_CXIndex_setInvocationEmissionPathOption;
-clang_CXRewriter_create;
-clang_CXRewriter_dispose;
-clang_CXRewriter_insertTextBefore;
-clang_CXRewriter_overwriteChangedFiles;
-clang_CXRewriter_removeText;
-clang_CXRewriter_replaceText;
-clang_CXRewriter_writeMainFileToStdOut;
-clang_CXXConstructor_isConvertingConstructor;
-clang_CXXConstructor_isCopyConstructor;
-clang_CXXConstructor_isDefaultConstructor;
-clang_CXXConstructor_isMoveConstructor;
-clang_CXXField_isMutable;
-clang_CXXMethod_isConst;
-clang_CXXMethod_isDefaulted;
-clang_CXXMethod_isPureVirtual;
-clang_CXXMethod_isStatic;
-clang_CXXMethod_isVirtual;
-clang_CXXRecord_isAbstract;
-clang_Comment_getChild;
-clang_Comment_getKind;
-clang_Comment_getNumChildren;
-clang_Comment_isWhitespace;
-clang_CompilationDatabase_dispose;
-clang_CompilationDatabase_fromDirectory;
-clang_CompilationDatabase_getAllCompileCommands;
-clang_CompilationDatabase_getCompileCommands;
-clang_CompileCommand_getArg;
-clang_CompileCommand_getDirectory;
-clang_CompileCommand_getFilename;
-clang_CompileCommand_getMappedSourceContent;
-clang_CompileCommand_getMappedSourcePath;
-clang_CompileCommand_getNumArgs;
-clang_CompileCommand_getNumMappedSources;
-clang_CompileCommands_dispose;
-clang_CompileCommands_getCommand;
-clang_CompileCommands_getSize;
-clang_Cursor_Evaluate;
-clang_Cursor_getArgument;
-clang_Cursor_getBriefCommentText;
-clang_Cursor_getCXXManglings;
-clang_Cursor_getCommentRange;
-clang_Cursor_getMangling;
-clang_Cursor_getModule;
-clang_Cursor_getNumArguments;
-clang_Cursor_getNumTemplateArguments;
-clang_Cursor_getObjCDeclQualifiers;
-clang_Cursor_getObjCManglings;
-clang_Cursor_getObjCPropertyAttributes;
-clang_Cursor_getObjCPropertyGetterName;
-clang_Cursor_getObjCPropertySetterName;
-clang_Cursor_getObjCSelectorIndex;
-clang_Cursor_getOffsetOfField;
-clang_Cursor_getParsedComment;
-clang_Cursor_getRawCommentText;
-clang_Cursor_getReceiverType;
-clang_Cursor_getSpellingNameRange;
-clang_Cursor_getStorageClass;
-clang_Cursor_getTemplateArgumentKind;
-clang_Cursor_getTemplateArgumentType;
-clang_Cursor_getTemplateArgumentUnsignedValue;
-clang_Cursor_getTemplateArgumentValue;
-clang_Cursor_getTranslationUnit;
-clang_Cursor_getVarDeclInitializer;
-clang_Cursor_hasAttrs;
-clang_Cursor_hasVarDeclExternalStorage;
-clang_Cursor_hasVarDeclGlobalStorage;
-clang_Cursor_isAnonymous;
-clang_Cursor_isAnonymousRecordDecl;
-

[PATCH] D129152: [Clang][unittests] Silence trucation warning with MSVC

2022-07-05 Thread Tobias Hieta via Phabricator via cfe-commits
thieta accepted this revision.
thieta added a comment.

Thanks for switching to pragma!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129152

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


[PATCH] D128762: [Clang] Rename StringLiteral::isAscii() => isOrdinary() [NFC]

2022-07-05 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann added a comment.

Just stopping by to say, thank you @cor3ntin!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128762

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


[PATCH] D129149: [OMPIRBuilder] Add support for simdlen clause

2022-07-05 Thread Prabhdeep Soni via Phabricator via cfe-commits
psoni2628 marked an inline comment as not done.
psoni2628 added inline comments.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:2596
   // Check for unsupported clauses
-  if (!S.clauses().empty()) {
-// Currently no clause is supported
-return false;
+  for (OMPClause *C : S.clauses()) {
+// Currently only simdlen clause is supported

psoni2628 wrote:
> arnamoy10 wrote:
> > I am just wondering whether we should have a check to make sure that we are 
> > processing the clauses of only `simd` directive here. Because the function 
> > takes a general `OMPExecutableDirective` as argument 
> That's a fair point. I guess `isSupportedByOpenMPIRBuilder` could be used for 
> other directive types other than simd, even though it's not right now.
Would it make more sense to only guard the checking of clauses with a check for 
`OMPSimdDirective`, or the whole thing? I believe even the code below, which 
checks for an ordered directive, is also specifically for `simd`?


Example of guarding the whole thing:

```
  if(dyn_cast(S)) {
// Check for unsupported clauses
for (OMPClause *C : S.clauses()) {
  // Currently only simdlen clause is supported
  if (dyn_cast(C))
continue;
  else
return false;
}

// Check if we have a statement with the ordered directive.
// Visit the statement hierarchy to find a compound statement
// with a ordered directive in it.
if (const auto *CanonLoop = dyn_cast(S.getRawStmt())) {
  if (const Stmt *SyntacticalLoop = CanonLoop->getLoopStmt()) {
for (const Stmt *SubStmt : SyntacticalLoop->children()) {
  if (!SubStmt)
continue;
  if (const CompoundStmt *CS = dyn_cast(SubStmt)) {
for (const Stmt *CSSubStmt : CS->children()) {
  if (!CSSubStmt)
continue;
  if (isa(CSSubStmt)) {
return false;
  }
}
  }
}
  }
}
  }
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129149

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


[PATCH] D129158: [pseudo] Define recovery strategy as grammar extension.

2022-07-05 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: hokein.
Herald added a project: All.
sammccall requested review of this revision.
Herald added subscribers: cfe-commits, alextsao1999.
Herald added a project: clang-tools-extra.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129158

Files:
  clang-tools-extra/pseudo/include/clang-pseudo/Language.h
  clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h
  clang-tools-extra/pseudo/include/clang-pseudo/grammar/LRGraph.h
  clang-tools-extra/pseudo/include/clang-pseudo/grammar/LRTable.h
  clang-tools-extra/pseudo/lib/GLR.cpp
  clang-tools-extra/pseudo/lib/cli/CLI.cpp
  clang-tools-extra/pseudo/lib/cxx/CXX.cpp
  clang-tools-extra/pseudo/lib/cxx/cxx.bnf
  clang-tools-extra/pseudo/lib/grammar/Grammar.cpp
  clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp
  clang-tools-extra/pseudo/lib/grammar/LRGraph.cpp
  clang-tools-extra/pseudo/test/cxx/empty-member-spec.cpp
  clang-tools-extra/pseudo/test/cxx/recovery-init-list.cpp
  clang-tools-extra/pseudo/unittests/GLRTest.cpp

Index: clang-tools-extra/pseudo/unittests/GLRTest.cpp
===
--- clang-tools-extra/pseudo/unittests/GLRTest.cpp
+++ clang-tools-extra/pseudo/unittests/GLRTest.cpp
@@ -48,6 +48,17 @@
testing::UnorderedElementsAreArray(Parents));
 }
 
+Token::Index recoverBraces(Token::Index Begin, const TokenStream ) {
+  EXPECT_GT(Begin, 0u);
+  const Token  = Code.tokens()[Begin - 1];
+  EXPECT_EQ(Left.Kind, tok::l_brace);
+  if (const auto* Right = Left.pair()) {
+EXPECT_EQ(Right->Kind, tok::r_brace);
+return Code.index(*Right);
+  }
+  return Token::Invalid;
+}
+
 class GLRTest : public ::testing::Test {
 public:
   void build(llvm::StringRef GrammarBNF) {
@@ -375,11 +386,12 @@
   //0--1({)--2(?)
   //  After recovering a `word` at state 1:
   //0--3(word)  // 3 is goto(1, word)
-  buildGrammar({"word"}, {});
+  buildGrammar({"word", "top"}, {"top := { word [recover=Braces] }"});
   LRTable::Builder B(TestLang.G);
   B.Transition[{StateID{1}, id("word")}] = StateID{3};
-  B.Recoveries.push_back({StateID{1}, {RecoveryStrategy::Braces, id("word")}});
+  B.Recoveries.push_back({StateID{1}, {extensionID("Braces"), id("word")}});
   TestLang.Table = std::move(B).build();
+  TestLang.RecoveryStrategies.try_emplace(extensionID("Braces"), recoverBraces);
 
   auto *LBrace = (tok::l_brace, 0);
   auto *Question1 = (tok::question, 1);
@@ -418,11 +430,12 @@
   //0--1({)--1({)--1({)
   //  After recovering a `block` at inside the second braces:
   //0--1({)--2(body)  // 2 is goto(1, body)
-  buildGrammar({"body"}, {});
+  buildGrammar({"body", "top"}, {"top := { body [recover=Braces] }"});
   LRTable::Builder B(TestLang.G);
   B.Transition[{StateID{1}, id("body")}] = StateID{2};
-  B.Recoveries.push_back({StateID{1}, {RecoveryStrategy::Braces, id("body")}});
+  B.Recoveries.push_back({StateID{1}, {extensionID("Braces"), id("body")}});
   TestLang.Table = std::move(B).build();
+  TestLang.RecoveryStrategies.try_emplace(extensionID("Braces"), recoverBraces);
 
   clang::LangOptions LOptions;
   // Innermost brace is unmatched, to test fallback to next brace.
@@ -455,13 +468,17 @@
   //  After recovering either `word` or `number` inside the braces:
   //0--1({)--2(word)   // 2 is goto(1, word)
   //  └--3(number) // 3 is goto(1, number)
-  buildGrammar({"number", "word"}, {});
+  buildGrammar({"number", "word", "top"},
+   {
+   "top := { number [recover=Braces] }",
+   "top := { word [recover=Braces] }",
+   });
   LRTable::Builder B(TestLang.G);
   B.Transition[{StateID{1}, id("number")}] = StateID{2};
   B.Transition[{StateID{1}, id("word")}] = StateID{3};
-  B.Recoveries.push_back(
-  {StateID{1}, {RecoveryStrategy::Braces, id("number")}});
-  B.Recoveries.push_back({StateID{1}, {RecoveryStrategy::Braces, id("word")}});
+  B.Recoveries.push_back({StateID{1}, {extensionID("Braces"), id("number")}});
+  B.Recoveries.push_back({StateID{1}, {extensionID("Braces"), id("word")}});
+  TestLang.RecoveryStrategies.try_emplace(extensionID("Braces"), recoverBraces);
   TestLang.Table = std::move(B).build();
   auto *LBrace = (tok::l_brace, 0);
   const auto *Root = GSStack.addNode(0, nullptr, {});
@@ -560,11 +577,12 @@
   build(R"bnf(
 _ := block
 
-block := { block }
-block := { numbers }
+block := { block [recover=Braces] }
+block := { numbers [recover=Braces] }
 numbers := NUMERIC_CONSTANT NUMERIC_CONSTANT
   )bnf");
   TestLang.Table = LRTable::buildSLR(TestLang.G);
+  TestLang.RecoveryStrategies.try_emplace(extensionID("Braces"), recoverBraces);
   clang::LangOptions LOptions;
   TokenStream Tokens = cook(lex("{ { 42 ? } }", LOptions), LOptions);
   pairBrackets(Tokens);
@@ -572,14 +590,14 @@
   const ForestNode  =
   glrParse({Tokens, Arena, GSStack}, id("block"), TestLang);
  

[PATCH] D129149: [OMPIRBuilder] Add support for simdlen clause

2022-07-05 Thread Prabhdeep Soni via Phabricator via cfe-commits
psoni2628 added inline comments.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:2596
   // Check for unsupported clauses
-  if (!S.clauses().empty()) {
-// Currently no clause is supported
-return false;
+  for (OMPClause *C : S.clauses()) {
+// Currently only simdlen clause is supported

arnamoy10 wrote:
> I am just wondering whether we should have a check to make sure that we are 
> processing the clauses of only `simd` directive here. Because the function 
> takes a general `OMPExecutableDirective` as argument 
That's a fair point. I guess `isSupportedByOpenMPIRBuilder` could be used for 
other directive types other than simd, even though it's not right now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129149

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


[PATCH] D112579: Allow non-variadic functions to be attributed with `__attribute__((format))`

2022-07-05 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!




Comment at: clang/test/SemaCXX/attr-format.cpp:76
+  format("bare string");
+  format("%s", 123); // expected-warning{{format specifies type 'char *' but 
the argument has type 'int'}}
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);

fcloutier wrote:
> aaron.ballman wrote:
> > This pointed out an interesting test case. What should the behavior be for:
> > ```
> > format("%p", 0);
> > ```
> > Because that sure feels like a more reasonable thing for someone to write 
> > expecting it to be treated as a null pointer constant.
> I think that the current behavior is the right one:
> 
> ```
> test.c:4:17: warning: format specifies type 'void *' but the argument has 
> type 'int' [-Wformat]
> printf("%p\n", 0);
> ~~ ^
> %d
> ```
> 
> The warning goes away if you use `(void *)0`, as expected. 
> `__attribute__((format))` has no semantic meaning, so we can't (and 
> shouldn't) infer that 0 is a pointer based on the usage of %p.
Ah, you know what, I've convinced myself I was wrong and you're right. C2x 
7.22.6.1p9 gives the latest conversion rules here, and I think passing `0`, 
despite being the null pointer constant, is UB when the format specifier is 
`%p`. On targets where `int` and `void *` are the same width, this diagnostic 
feels rather pedantic. But on systems where those differ, it seems more 
important to issue the warning... so I think you're correct that we should 
leave this behavior alone.

Thanks for thinking it through with me. :-)



Comment at: clang/test/SemaCXX/attr-format.cpp:77-78
+  format("%s", 123); // expected-warning{{format specifies type 'char *' but 
the argument has type 'int'}}
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, do_format);
+  format("bad format %s"); // expected-warning{{more '%' conversions than data 
arguments}}

fcloutier wrote:
> aaron.ballman wrote:
> > This likely isn't specific to your changes, but the `%p` in these examples 
> > should be warning the user (a function or function pointer is not a pointer 
> > to void or a pointer to a character type, so that call is UB).
> This is already a -Wformat-pedantic warning, which IMO is the right warning 
> group for it:
> 
> ```
> test.c:4:17: warning: format specifies type 'void *' but the argument has 
> type 'int (*)()' [-Wformat-pedantic]
> printf("%p\n", main);
> ~~ ^~~~
> 1 warning generated.
> ```
> 
> The relevant bit is clang/lib/AST/FormatString.cpp:
> 
> ```
> case CPointerTy:
>   if (argTy->isVoidPointerType()) {
> return Match;
>   } if (argTy->isPointerType() || argTy->isObjCObjectPointerType() ||
> argTy->isBlockPointerType() || argTy->isNullPtrType()) {
> return NoMatchPedantic;
>   } else {
> return NoMatch;
>   }
> ```
Ah, good that we have it in a pedantic diagnostic. I agree, it is a pedantic 
one, I thought we were missing it entirely.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112579

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


[PATCH] D128927: [libc++] Always build c++experimental.a

2022-07-05 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added inline comments.



Comment at: libcxx/docs/ReleaseNotes.rst:226
+  experimental features provided by it. Note that vendors are encouraged to 
ship the
+  experimental library now that the compiler provides an ergonomic way to use 
it.

Mordante wrote:
> I agree this is a build system change, but I wonder how many users read this 
> part and find the hidden gem.
> Should we add a note at new features too? Maybe there we can mention format 
> and ranges are available with this new switch.
> (technically that actually belongs in the next patch, but I wouldn't mind to 
> do it in this patch.)
I added a note to do this in the next patch, since I think it belongs there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128927

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


[PATCH] D128927: [libc++] Always build c++experimental.a

2022-07-05 Thread Louis Dionne via Phabricator via cfe-commits
ldionne updated this revision to Diff 442378.
ldionne marked 2 inline comments as done.
ldionne added a comment.

Address review comments and try to fix some CI issues


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128927

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/cmake/caches/Fuchsia.cmake
  compiler-rt/cmake/Modules/AddCompilerRT.cmake
  libcxx/CMakeLists.txt
  libcxx/appveyor.yml
  libcxx/cmake/caches/AIX.cmake
  libcxx/cmake/caches/Apple.cmake
  libcxx/cmake/caches/Generic-no-experimental.cmake
  libcxx/cmake/caches/MinGW.cmake
  libcxx/docs/BuildingLibcxx.rst
  libcxx/docs/ReleaseNotes.rst
  libcxx/docs/UsingLibcxx.rst
  libcxx/src/CMakeLists.txt
  libcxx/test/CMakeLists.txt
  
libcxx/test/libcxx/experimental/memory/memory.resource.global/global_memory_resource_lifetime.pass.cpp
  
libcxx/test/libcxx/experimental/memory/memory.resource.global/new_delete_resource_lifetime.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.ctor/default.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.eq/equal.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.eq/not_equal.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/allocate.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/construct_pair.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/construct_pair_const_lvalue_pair.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/construct_pair_rvalue.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/construct_pair_values.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/construct_piecewise_pair.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/construct_piecewise_pair_evil.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/construct_types.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/deallocate.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/destroy.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/resource.pass.cpp
  
libcxx/test/std/experimental/memory/memory.polymorphic.allocator.class/memory.polymorphic.allocator.mem/select_on_container_copy_construction.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.aliases/header_deque_synop.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.aliases/header_forward_list_synop.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.aliases/header_list_synop.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.aliases/header_map_synop.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.aliases/header_regex_synop.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.aliases/header_set_synop.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.aliases/header_string_synop.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.aliases/header_unordered_map_synop.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.aliases/header_unordered_set_synop.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.aliases/header_vector_synop.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.global/default_resource.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.global/new_delete_resource.pass.cpp
  
libcxx/test/std/experimental/memory/memory.resource.global/null_memory_resource.pass.cpp
  libcxx/utils/ci/run-buildbot
  libcxx/utils/libcxx/test/params.py

Index: libcxx/utils/libcxx/test/params.py
===
--- libcxx/utils/libcxx/test/params.py
+++ libcxx/utils/libcxx/test/params.py
@@ -62,6 +62,13 @@
 return '-std='+fallbacks[std]
   return None
 
+# TODO: Remove this once all the compilers we support understand `-funstable`
+def getUnstableFlag(cfg):
+  if hasCompileFlag(cfg, '-funstable'):
+return '-funstable -lc++experimental' # TODO: Remove this once Clang's -funstable flag implies -lc++experimental
+  else:
+return '-D_LIBCPP_ENABLE_EXPERIMENTAL -lc++experimental'
+
 DEFAULT_PARAMETERS = [
   Parameter(name='target_triple', type=str,
 help="The target triple to compile the test 

[PATCH] D128012: [HLSL] Add ExternalSemaSource & vector alias

2022-07-05 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Giving the posthumous review my LGTM so it's clear. :-)




Comment at: clang/lib/Sema/HLSLExternalSemaSource.cpp:41-44
+  auto *UsingDecl = UsingDirectiveDecl::Create(
+  AST, AST.getTranslationUnitDecl(), SourceLocation(), SourceLocation(),
+  NestedNameSpecifierLoc(), SourceLocation(), HLSLNamespace,
+  AST.getTranslationUnitDecl());

beanz wrote:
> aaron.ballman wrote:
> > beanz wrote:
> > > aaron.ballman wrote:
> > > > And users won't find this behavior surprising? I would be worried that 
> > > > the user has their own globally declared type that this hidden using 
> > > > directive will then cause to be ambiguous: 
> > > > https://godbolt.org/z/jMsW54vWe -- when users hit this themselves, the 
> > > > location of the conflict is going to point into nowhere-land, which is 
> > > > also rather unfortunate.
> > > > 
> > > > Actually, the more I think about this, the less comfortable I am with 
> > > > it. This also means you have to be *very* careful about conflicts with 
> > > > STL names, and it means that any new declarations added to the `hlsl` 
> > > > namespace automatically risk breaking code.
> > > > 
> > > > Aside: any particular reason the namespace declaration is implicit but 
> > > > the using directive declaration is not?
> > > As HLSL is implanted today in DXC the built-in types and functions are 
> > > all globally defined (not in any namespace). My goal here was to start 
> > > nesting them in an `hlsl` namespace, and to eventually do that for DXC as 
> > > well in a new language version. HLSL just got support for `using 
> > > namespace` like 3 months ago, so we can't do that in a header for 
> > > compatibility, so my intent was to throw it in the directive here. 
> > > 
> > > My hope is the next version of HLSL will move the builtins into the 
> > > `hlsl` namespace so I can make this only enabled for older language 
> > > versions in the near future.
> > > 
> > > In terms of conflicts with STL, I don't think the STL sources will 
> > > compile for HLSL anytime soon. Maybe in a future version of HLSL, but 
> > > we've got a long way to go to get there. For existing HLSL code, 
> > > namespaces are very sparingly used, and while we may find conflicts in 
> > > user code I think moving HLSL's builtins into a namespace will be worth 
> > > the pain... but I might be wrong about how much pain that will be.
> > So basically this trades redefinition errors for ambiguous lookup errors in 
> > terms of conflicts with user-declared code?
> > 
> > > In terms of conflicts with STL, I don't think the STL sources will 
> > > compile for HLSL anytime soon. Maybe in a future version of HLSL, but 
> > > we've got a long way to go to get there. For existing HLSL code, 
> > > namespaces are very sparingly used, and while we may find conflicts in 
> > > user code I think moving HLSL's builtins into a namespace will be worth 
> > > the pain... but I might be wrong about how much pain that will be.
> > 
> > I think moving them into a namespace is a lovely idea in theory, but it's 
> > still discomforting to add the `using` directive automatically for the 
> > user. The user is going to have the pain of dealing with the names moving 
> > to a new namespace at some point, so why not start from a cleaner design? 
> > It seems not entirely unreasonable to expect users to type `using namespace 
> > hlsl;` themselves if you're moving the types into a namespace, and users 
> > who need to handle older compilers can use the preprocessor to 
> > conditionally compile that line out. Or is that not really a viable option?
> Yea, basically in DXC declaring a top-level vector class would be a 
> redefinition error, where as with this implementation it would be a lookup 
> error.
> 
> The test case I just wrote is:
> ```
> // RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl 
> -fsyntax-only -verify %s
> 
> // This code is rejected by clang because clang puts the HLSL built-in types
> // into the HLSL namespace.
> namespace hlsl {
>   struct vector {}; // expected-error {{redefinition of 'vector'}}
> }
> 
> // This code is rejected by dxc because dxc puts the HLSL built-in types
> // into the global space, but clang will allow it even though it will shadow 
> the
> // vector template.
> struct vector {}; // expected-note {{candidate found by name lookup is 
> 'vector'}}
> 
> vector VecInt2; // expected-error {{reference to 'vector' is 
> ambiguous}}
> 
> // expected-note@*:* {{candidate found by name lookup is 'hlsl::vector'}}
> ```
> 
> My concern here is really about compatibility with existing code and things 
> get a bit funky because we don't always have the ability to modify the code. 
> The Windows and Xbox OSs ship HLSL compilers as part of the OS, and some 
> degree of explicit source compatibility for older language versions is needed.
> 
> I'm really hoping moving things into the `hlsl` namespace will land in our 
> 

[PATCH] D129105: [clang-format][NFC] Clean up IndentForLevel in LevelIndentTracker

2022-07-05 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added inline comments.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:82-83
+if (Size <= Line.Level)
+  IndentForLevel.insert(IndentForLevel.end(), Line.Level - Size + 1,
+UnknownIndent ? -1 : Indent);
   }

Could we do this with with `resize` similar to my proposal in D129064?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129105

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


[PATCH] D129064: [clang-format] Avoid crash in LevelIndentTracker.

2022-07-05 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added inline comments.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:62-70
 while (IndentForLevel.size() <= Line.Level)
   IndentForLevel.push_back(-1);
 if (Line.InPPDirective) {
   unsigned IndentWidth =
   (Style.PPIndentWidth >= 0) ? Style.PPIndentWidth : Style.IndentWidth;
   Indent = Line.Level * IndentWidth + AdditionalIndent;
 } else {

So how about that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129064

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


[PATCH] D112579: Allow non-variadic functions to be attributed with `__attribute__((format))`

2022-07-05 Thread Félix Cloutier via Phabricator via cfe-commits
fcloutier added inline comments.



Comment at: clang/test/SemaCXX/attr-format.cpp:76
+  format("bare string");
+  format("%s", 123); // expected-warning{{format specifies type 'char *' but 
the argument has type 'int'}}
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);

aaron.ballman wrote:
> This pointed out an interesting test case. What should the behavior be for:
> ```
> format("%p", 0);
> ```
> Because that sure feels like a more reasonable thing for someone to write 
> expecting it to be treated as a null pointer constant.
I think that the current behavior is the right one:

```
test.c:4:17: warning: format specifies type 'void *' but the argument has type 
'int' [-Wformat]
printf("%p\n", 0);
~~ ^
%d
```

The warning goes away if you use `(void *)0`, as expected. 
`__attribute__((format))` has no semantic meaning, so we can't (and shouldn't) 
infer that 0 is a pointer based on the usage of %p.



Comment at: clang/test/SemaCXX/attr-format.cpp:77-78
+  format("%s", 123); // expected-warning{{format specifies type 'char *' but 
the argument has type 'int'}}
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, do_format);
+  format("bad format %s"); // expected-warning{{more '%' conversions than data 
arguments}}

aaron.ballman wrote:
> This likely isn't specific to your changes, but the `%p` in these examples 
> should be warning the user (a function or function pointer is not a pointer 
> to void or a pointer to a character type, so that call is UB).
This is already a -Wformat-pedantic warning, which IMO is the right warning 
group for it:

```
test.c:4:17: warning: format specifies type 'void *' but the argument has type 
'int (*)()' [-Wformat-pedantic]
printf("%p\n", main);
~~ ^~~~
1 warning generated.
```

The relevant bit is clang/lib/AST/FormatString.cpp:

```
case CPointerTy:
  if (argTy->isVoidPointerType()) {
return Match;
  } if (argTy->isPointerType() || argTy->isObjCObjectPointerType() ||
argTy->isBlockPointerType() || argTy->isNullPtrType()) {
return NoMatchPedantic;
  } else {
return NoMatch;
  }
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112579

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


[PATCH] D112579: Allow non-variadic functions to be attributed with `__attribute__((format))`

2022-07-05 Thread Félix Cloutier via Phabricator via cfe-commits
fcloutier updated this revision to Diff 442373.
fcloutier marked 2 inline comments as done.
fcloutier added a comment.

Address documentation comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112579

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/FormatString.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/attr-format.c
  clang/test/Sema/format-strings.c
  clang/test/SemaCXX/attr-format.cpp

Index: clang/test/SemaCXX/attr-format.cpp
===
--- clang/test/SemaCXX/attr-format.cpp
+++ clang/test/SemaCXX/attr-format.cpp
@@ -1,7 +1,11 @@
 // RUN: %clang_cc1 -fsyntax-only -Wformat-nonliteral -verify %s
+#include 
+
+int printf(const char *fmt, ...) __attribute__((format(printf, 1, 2)));
+
 struct S {
-  static void f(const char*, ...) __attribute__((format(printf, 1, 2)));
-  static const char* f2(const char*) __attribute__((format_arg(1)));
+  static void f(const char *, ...) __attribute__((format(printf, 1, 2)));
+  static const char *f2(const char *) __attribute__((format_arg(1)));
 
   // GCC has a hidden 'this' argument in member functions which is why
   // the format argument is argument 2 here.
@@ -38,6 +42,47 @@
 
 // Make sure we interpret member operator calls as having an implicit
 // this argument.
-void test_operator_call(S s, const char* str) {
+void test_operator_call(S s, const char *str) {
   s("%s", str);
 }
+
+template 
+void format(const char *fmt, Args &&...args) // expected-warning{{GCC requires a function with the 'format' attribute to be variadic}}
+__attribute__((format(printf, 1, 2)));
+
+template 
+Arg (Arg ) { return a; }
+
+struct foo {
+  int big[10];
+  foo();
+  ~foo();
+
+  template 
+  void format(const char *const fmt, Args &&...args) // expected-warning{{GCC requires a function with the 'format' attribute to be variadic}}
+  __attribute__((format(printf, 2, 3))) {
+printf(fmt, expand(args)...);
+  }
+};
+
+void format_invalid_nonpod(const char *fmt, struct foo f) // expected-warning{{GCC requires a function with the 'format' attribute to be variadic}}
+__attribute__((format(printf, 1, 2)));
+
+void do_format() {
+  int x = 123;
+  int  = x;
+  const char *s = "world";
+  format("bare string");
+  format("%s", 123); // expected-warning{{format specifies type 'char *' but the argument has type 'int'}}
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, do_format);
+  format("bad format %s"); // expected-warning{{more '%' conversions than data arguments}}
+
+  struct foo f;
+  format_invalid_nonpod("hello %i", f); // expected-warning{{format specifies type 'int' but the argument has type 'struct foo'}}
+
+  f.format("%s", 123); // expected-warning{{format specifies type 'char *' but the argument has type 'int'}}
+  f.format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);
+  f.format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, do_format);
+  f.format("bad format %s"); // expected-warning{{more '%' conversions than data arguments}}
+}
Index: clang/test/Sema/format-strings.c
===
--- clang/test/Sema/format-strings.c
+++ clang/test/Sema/format-strings.c
@@ -816,6 +816,7 @@
   __attribute__((__format__(__printf__, 2, 3))) {
 va_list ap;
 va_start(ap, fmt);
+vprintf(fmt, ap);
 vprintf(not_fmt, ap); // expected-warning{{format string is not a string literal}}
 va_end(ap);
   };
Index: clang/test/Sema/attr-format.c
===
--- clang/test/Sema/attr-format.c
+++ clang/test/Sema/attr-format.c
@@ -2,18 +2,18 @@
 
 #include 
 
-void a(const char *a, ...) __attribute__((format(printf, 1,2))); // no-error
-void b(const char *a, ...) __attribute__((format(printf, 1,1))); // expected-error {{'format' attribute parameter 3 is out of bounds}}
-void c(const char *a, ...) __attribute__((format(printf, 0,2))); // expected-error {{'format' attribute parameter 2 is out of bounds}}
-void d(const char *a, int c) __attribute__((format(printf, 1,2))); // expected-error {{format attribute requires variadic function}}
-void e(char *str, int c, ...) __attribute__((format(printf, 2,3))); // expected-error {{format argument not a string type}}
+void a(const char *a, ...) __attribute__((format(printf, 1, 2)));// no-error
+void b(const char *a, ...) __attribute__((format(printf, 1, 1)));// expected-error {{'format' attribute parameter 3 is out of bounds}}
+void c(const char *a, ...) __attribute__((format(printf, 0, 2)));// expected-error {{'format' attribute parameter 2 is out of bounds}}
+void d(const char *a, int c) 

[PATCH] D129149: [OMPIRBuilder] Add support for simdlen clause

2022-07-05 Thread Arnamoy B via Phabricator via cfe-commits
arnamoy10 added inline comments.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:2596
   // Check for unsupported clauses
-  if (!S.clauses().empty()) {
-// Currently no clause is supported
-return false;
+  for (OMPClause *C : S.clauses()) {
+// Currently only simdlen clause is supported

I am just wondering whether we should have a check to make sure that we are 
processing the clauses of only `simd` directive here. Because the function 
takes a general `OMPExecutableDirective` as argument 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129149

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


[PATCH] D129065: [RISCV][Driver] Add libm linking to `RISCVToolchain`

2022-07-05 Thread Jessica Clarke via Phabricator via cfe-commits
jrtc27 added a comment.

Commit subject/body should say C++ in it


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129065

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


[PATCH] D129016: [PowerPC] implemented @llvm.ppc.kill.canary to corrupt stack guard

2022-07-05 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

Please run clang-format, rebase and re-upload. It doesn't apply cleanly to ToT.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129016

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


[PATCH] D129016: [PowerPC] implemented @llvm.ppc.kill.canary to corrupt stack guard

2022-07-05 Thread Kai Nacke via Phabricator via cfe-commits
Kai added a comment.

Some more nits, otherwise LGTM.




Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11150
+
+const uint64_t XORWord = 0x; // XORing with 0b111...111 
will never
+ // result in the original word

Line too long.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11157
+  : M->getNamedValue("__stack_chk_guard");
+ */
+if (useLoadStackGuardNode()) { // linux uses LOAD_STACK_GUARD node instead 
of having a

Please remove dead code.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11158
+ */
+if (useLoadStackGuardNode()) { // linux uses LOAD_STACK_GUARD node instead 
of having a
+   // canary word global value

Line too long.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11185
+  
+} else if (Value *GV = getSDagStackGuard(*M)) { // on aix, load from 
global value
+  VT = DAG.getTargetLoweringInfo().getValueType(DAG.getDataLayout(),

Line too long.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11188
+GV->getType(), true);
+  SDValue CanaryLoc = DAG.getGlobalAddress(dyn_cast(GV), DL, 
VT);
+

Line too long.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129016

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


[PATCH] D128182: [NFC] Switch FloatModeKind enum class to use bitmask enums

2022-07-05 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann added a comment.

@jolanta.jensen, I was on vacation last week and missed my opportunity to 
comment on this. I know the change has already landed, but I added a few 
comments anyway.




Comment at: clang/include/clang/Basic/TargetInfo.h:226-227
+  unsigned RealTypeUsesObjCFPRetMask
+  : llvm::BitmaskEnumDetail::bitWidth(
+(int)FloatModeKind::LLVM_BITMASK_LARGEST_ENUMERATOR);
   unsigned ComplexLongDoubleUsesFP2Ret : 1;

I believe this can be simplified to:
  : llvm::BitWidth;

(It should never be necessary to reach directly into a "detail" namespace from 
user code)



Comment at: clang/include/clang/Basic/TargetInfo.h:896
   bool useObjCFPRetForRealType(FloatModeKind T) const {
-assert(T <= FloatModeKind::Last &&
-   "T value is larger than RealTypeUsesObjCFPRetMask can handle");
-return RealTypeUsesObjCFPRetMask & (1 << (int)T);
+return RealTypeUsesObjCFPRetMask & llvm::BitmaskEnumDetail::Underlying(T);
   }

This again directly uses the "detail" namespace. I think this would be better 
written as:
  return (FloatModeKind)RealTypeUsesObjCFPRetMask & T;



Comment at: clang/lib/Basic/Targets/X86.h:423-424
 RealTypeUsesObjCFPRetMask =
-((1 << (int)FloatModeKind::Float) | (1 << (int)FloatModeKind::Double) |
- (1 << (int)FloatModeKind::LongDouble));
+(int)(FloatModeKind::Float | FloatModeKind::Double |
+  FloatModeKind::LongDouble);
 

Since `RealTypeUsesObjCFPRetMask` is declared as `unsigned`, it would be best 
to cast to `unsigned` instead of `int` here.



Comment at: clang/lib/Basic/Targets/X86.h:703
 // Use fpret only for long double.
-RealTypeUsesObjCFPRetMask = (1 << (int)FloatModeKind::LongDouble);
+RealTypeUsesObjCFPRetMask = (int)FloatModeKind::LongDouble;
 

Likewise, cast to `unsigned` here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128182

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


[PATCH] D128486: [pseudo] Add error-recovery framework & brace-based recovery

2022-07-05 Thread Sam McCall via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
sammccall marked an inline comment as done.
Closed by commit rG312116748890: [pseudo] Add error-recovery framework  
brace-based recovery (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D128486?vs=441154=442369#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128486

Files:
  clang-tools-extra/pseudo/include/clang-pseudo/GLR.h
  clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h
  clang-tools-extra/pseudo/include/clang-pseudo/grammar/LRGraph.h
  clang-tools-extra/pseudo/include/clang-pseudo/grammar/LRTable.h
  clang-tools-extra/pseudo/lib/GLR.cpp
  clang-tools-extra/pseudo/lib/grammar/Grammar.cpp
  clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp
  clang-tools-extra/pseudo/lib/grammar/LRGraph.cpp
  clang-tools-extra/pseudo/lib/grammar/LRTableBuild.cpp
  clang-tools-extra/pseudo/test/cxx/empty-member-spec.cpp
  clang-tools-extra/pseudo/test/cxx/recovery-init-list.cpp
  clang-tools-extra/pseudo/unittests/GLRTest.cpp

Index: clang-tools-extra/pseudo/unittests/GLRTest.cpp
===
--- clang-tools-extra/pseudo/unittests/GLRTest.cpp
+++ clang-tools-extra/pseudo/unittests/GLRTest.cpp
@@ -7,8 +7,9 @@
 //===--===//
 
 #include "clang-pseudo/GLR.h"
-#include "clang-pseudo/Token.h"
+#include "clang-pseudo/Bracket.h"
 #include "clang-pseudo/Language.h"
+#include "clang-pseudo/Token.h"
 #include "clang-pseudo/grammar/Grammar.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/TokenKinds.h"
@@ -33,11 +34,13 @@
 using StateID = LRTable::StateID;
 using testing::AllOf;
 using testing::ElementsAre;
+using testing::IsEmpty;
 using testing::UnorderedElementsAre;
 
 MATCHER_P(state, StateID, "") { return arg->State == StateID; }
 MATCHER_P(parsedSymbol, FNode, "") { return arg->Payload == FNode; }
 MATCHER_P(parsedSymbolID, SID, "") { return arg->Payload->symbol() == SID; }
+MATCHER_P(start, Start, "") { return arg->Payload->startTokenIndex() == Start; }
 
 testing::Matcher
 parents(llvm::ArrayRef Parents) {
@@ -247,9 +250,9 @@
   /*State=*/1, /*ForestNode=*/CVQualifierNode, /*Parents=*/{GSSNode0});
   const auto *GSSNode2 = GSStack.addNode(
   /*State=*/2, /*ForestNode=*/CVQualifierNode, /*Parents=*/{GSSNode0});
-  const auto *GSSNode3 =
-  GSStack.addNode(/*State=*/3, /*ForestNode=*/ClassNameNode,
-  /*Parents=*/{GSSNode1});
+  const auto *GSSNode3 = GSStack.addNode(
+  /*State=*/3, /*ForestNode=*/ClassNameNode,
+  /*Parents=*/{GSSNode1});
   const auto *GSSNode4 =
   GSStack.addNode(/*State=*/4, /*ForestNode=*/EnumNameNode,
   /*Parents=*/{GSSNode2});
@@ -366,6 +369,120 @@
   EXPECT_THAT(Heads, ElementsAre(GSSNode1));
 }
 
+TEST_F(GLRTest, Recover) {
+  // Recovery while parsing "word" inside braces.
+  //  Before:
+  //0--1({)--2(?)
+  //  After recovering a `word` at state 1:
+  //0--3(word)  // 3 is goto(1, word)
+  buildGrammar({"word"}, {});
+  LRTable::Builder B(TestLang.G);
+  B.Transition[{StateID{1}, id("word")}] = StateID{3};
+  B.Recoveries.push_back({StateID{1}, {RecoveryStrategy::Braces, id("word")}});
+  TestLang.Table = std::move(B).build();
+
+  auto *LBrace = (tok::l_brace, 0);
+  auto *Question1 = (tok::question, 1);
+  const auto *Root = GSStack.addNode(0, nullptr, {});
+  const auto *OpenedBraces = GSStack.addNode(1, LBrace, {Root});
+  const auto *AfterQuestion1 = GSStack.addNode(2, Question1, {OpenedBraces});
+
+  // Need a token stream with paired braces so the strategy works.
+  clang::LangOptions LOptions;
+  TokenStream Tokens = cook(lex("{ ? ? ? }", LOptions), LOptions);
+  pairBrackets(Tokens);
+  std::vector NewHeads;
+
+  unsigned TokenIndex = 2;
+  glrRecover({AfterQuestion1}, TokenIndex, {Tokens, Arena, GSStack}, TestLang,
+ NewHeads);
+  EXPECT_EQ(TokenIndex, 4u) << "should skip ahead to matching brace";
+  EXPECT_THAT(NewHeads, ElementsAre(AllOf(state(3), parsedSymbolID(id("word")),
+  parents({OpenedBraces}), start(1u;
+  EXPECT_EQ(NewHeads.front()->Payload->kind(), ForestNode::Opaque);
+
+  // Test recovery failure: omit closing brace so strategy fails
+  TokenStream NoRBrace = cook(lex("{ ? ? ? ?", LOptions), LOptions);
+  pairBrackets(NoRBrace);
+  NewHeads.clear();
+  TokenIndex = 2;
+  glrRecover({AfterQuestion1}, TokenIndex, {NoRBrace, Arena, GSStack}, TestLang,
+ NewHeads);
+  EXPECT_EQ(TokenIndex, 2u) << "should not advance on failure";
+  EXPECT_THAT(NewHeads, IsEmpty());
+}
+
+TEST_F(GLRTest, RecoverRightmost) {
+  // In a nested block structure, we recover at the innermost possible block.
+  //  Before:
+  //0--1({)--1({)--1({)
+  //  After 

[clang-tools-extra] 3121167 - [pseudo] Add error-recovery framework & brace-based recovery

2022-07-05 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2022-07-05T20:49:41+02:00
New Revision: 31211674889095299eb817d7be034fde23f7b00a

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

LOG: [pseudo] Add error-recovery framework & brace-based recovery

The idea is:

- a parse failure is detected when all heads die when trying to shift the next 
token
- we can recover by choosing a nonterminal we're partway through parsing, and
  determining where it ends through nonlocal means (e.g. matching brackets)
- we can find candidates by walking up the stack from the (ex-)heads
- the token range is defined using heuristics attached to grammar rules
- the unparsed region is represented in the forest by an Opaque node

This patch has the core GLR functionality.
It does not allow recovery heuristics to be attached as extensions to
the grammar, but rather infers a brace-based heuristic.

Expected followups:

- make recovery heuristics grammar extensions (depends on D127448)
- add recovery to our grammar for bracketed constructs and sequence nodes
- change the structure of our augmented `_ := start` rules to eliminate some
  special-cases in glrParse.
- (if I can work out how): avoid some spurious recovery cases described in 
comments

(Previously mistakenly committed as a0f4c10ae227a62c2a63611e64eba83f0ff0f577)

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

Added: 
clang-tools-extra/pseudo/test/cxx/recovery-init-list.cpp

Modified: 
clang-tools-extra/pseudo/include/clang-pseudo/GLR.h
clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h
clang-tools-extra/pseudo/include/clang-pseudo/grammar/LRGraph.h
clang-tools-extra/pseudo/include/clang-pseudo/grammar/LRTable.h
clang-tools-extra/pseudo/lib/GLR.cpp
clang-tools-extra/pseudo/lib/grammar/Grammar.cpp
clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp
clang-tools-extra/pseudo/lib/grammar/LRGraph.cpp
clang-tools-extra/pseudo/lib/grammar/LRTableBuild.cpp
clang-tools-extra/pseudo/test/cxx/empty-member-spec.cpp
clang-tools-extra/pseudo/unittests/GLRTest.cpp

Removed: 




diff  --git a/clang-tools-extra/pseudo/include/clang-pseudo/GLR.h 
b/clang-tools-extra/pseudo/include/clang-pseudo/GLR.h
index ebf54685b01b..7b0a80920da9 100644
--- a/clang-tools-extra/pseudo/include/clang-pseudo/GLR.h
+++ b/clang-tools-extra/pseudo/include/clang-pseudo/GLR.h
@@ -143,6 +143,25 @@ void glrShift(llvm::ArrayRef OldHeads,
 void glrReduce(std::vector , SymbolID Lookahead,
const ParseParams , const Language );
 
+// Heuristically recover from a state where no further parsing is possible.
+//
+// OldHeads is the parse state at TokenIndex.
+// This function consumes zero or more tokens by advancing TokenIndex,
+// and places any recovery states created in NewHeads.
+//
+// On failure, NewHeads is empty and TokenIndex is unchanged.
+//
+// WARNING: glrRecover acts as a "fallback shift". If it consumes no tokens,
+// there is a risk of the parser falling into an infinite loop, creating an
+// endless sequence of recovery nodes.
+// Generally it is safe for recovery to match 0 tokens against sequence symbols
+// like `statement-seq`, as the grammar won't permit another statement-seq
+// immediately afterwards. However recovery strategies for `statement` should
+// consume at least one token, as statements may be adjacent in the input.
+void glrRecover(llvm::ArrayRef OldHeads,
+unsigned , const ParseParams ,
+const Language , std::vector 
);
+
 } // namespace pseudo
 } // namespace clang
 

diff  --git a/clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h 
b/clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h
index f60bf487eeaf..e2957cc2ec71 100644
--- a/clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h
+++ b/clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h
@@ -82,9 +82,12 @@ inline tok::TokenKind symbolToToken(SymbolID SID) {
   assert(SID < NumTerminals);
   return static_cast(SID);
 }
-inline SymbolID tokenSymbol(tok::TokenKind TK) {
+inline constexpr SymbolID tokenSymbol(tok::TokenKind TK) {
   return TokenFlag | static_cast(TK);
 }
+// Error recovery strategies.
+// FIXME: these should be provided as extensions instead.
+enum class RecoveryStrategy : uint8_t { None, Braces };
 
 // An extension is a piece of native code specific to a grammar that modifies
 // the behavior of annotated rules. One ExtensionID is assigned for each unique
@@ -108,7 +111,7 @@ struct Rule {
   // length to 9 (this is the longest sequence in cxx grammar).
   static constexpr unsigned SizeBits = 4;
   static constexpr unsigned MaxElements = 9;
-  static_assert(MaxElements <= (1 << SizeBits), "Exceeds the maximum limit");
+  static_assert(MaxElements < (1 << 

[PATCH] D128012: [HLSL] Add ExternalSemaSource & vector alias

2022-07-05 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added inline comments.



Comment at: clang/lib/Sema/HLSLExternalSemaSource.cpp:41-44
+  auto *UsingDecl = UsingDirectiveDecl::Create(
+  AST, AST.getTranslationUnitDecl(), SourceLocation(), SourceLocation(),
+  NestedNameSpecifierLoc(), SourceLocation(), HLSLNamespace,
+  AST.getTranslationUnitDecl());

aaron.ballman wrote:
> beanz wrote:
> > aaron.ballman wrote:
> > > And users won't find this behavior surprising? I would be worried that 
> > > the user has their own globally declared type that this hidden using 
> > > directive will then cause to be ambiguous: 
> > > https://godbolt.org/z/jMsW54vWe -- when users hit this themselves, the 
> > > location of the conflict is going to point into nowhere-land, which is 
> > > also rather unfortunate.
> > > 
> > > Actually, the more I think about this, the less comfortable I am with it. 
> > > This also means you have to be *very* careful about conflicts with STL 
> > > names, and it means that any new declarations added to the `hlsl` 
> > > namespace automatically risk breaking code.
> > > 
> > > Aside: any particular reason the namespace declaration is implicit but 
> > > the using directive declaration is not?
> > As HLSL is implanted today in DXC the built-in types and functions are all 
> > globally defined (not in any namespace). My goal here was to start nesting 
> > them in an `hlsl` namespace, and to eventually do that for DXC as well in a 
> > new language version. HLSL just got support for `using namespace` like 3 
> > months ago, so we can't do that in a header for compatibility, so my intent 
> > was to throw it in the directive here. 
> > 
> > My hope is the next version of HLSL will move the builtins into the `hlsl` 
> > namespace so I can make this only enabled for older language versions in 
> > the near future.
> > 
> > In terms of conflicts with STL, I don't think the STL sources will compile 
> > for HLSL anytime soon. Maybe in a future version of HLSL, but we've got a 
> > long way to go to get there. For existing HLSL code, namespaces are very 
> > sparingly used, and while we may find conflicts in user code I think moving 
> > HLSL's builtins into a namespace will be worth the pain... but I might be 
> > wrong about how much pain that will be.
> So basically this trades redefinition errors for ambiguous lookup errors in 
> terms of conflicts with user-declared code?
> 
> > In terms of conflicts with STL, I don't think the STL sources will compile 
> > for HLSL anytime soon. Maybe in a future version of HLSL, but we've got a 
> > long way to go to get there. For existing HLSL code, namespaces are very 
> > sparingly used, and while we may find conflicts in user code I think moving 
> > HLSL's builtins into a namespace will be worth the pain... but I might be 
> > wrong about how much pain that will be.
> 
> I think moving them into a namespace is a lovely idea in theory, but it's 
> still discomforting to add the `using` directive automatically for the user. 
> The user is going to have the pain of dealing with the names moving to a new 
> namespace at some point, so why not start from a cleaner design? It seems not 
> entirely unreasonable to expect users to type `using namespace hlsl;` 
> themselves if you're moving the types into a namespace, and users who need to 
> handle older compilers can use the preprocessor to conditionally compile that 
> line out. Or is that not really a viable option?
Yea, basically in DXC declaring a top-level vector class would be a 
redefinition error, where as with this implementation it would be a lookup 
error.

The test case I just wrote is:
```
// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -fsyntax-only 
-verify %s

// This code is rejected by clang because clang puts the HLSL built-in types
// into the HLSL namespace.
namespace hlsl {
  struct vector {}; // expected-error {{redefinition of 'vector'}}
}

// This code is rejected by dxc because dxc puts the HLSL built-in types
// into the global space, but clang will allow it even though it will shadow the
// vector template.
struct vector {}; // expected-note {{candidate found by name lookup is 
'vector'}}

vector VecInt2; // expected-error {{reference to 'vector' is ambiguous}}

// expected-note@*:* {{candidate found by name lookup is 'hlsl::vector'}}
```

My concern here is really about compatibility with existing code and things get 
a bit funky because we don't always have the ability to modify the code. The 
Windows and Xbox OSs ship HLSL compilers as part of the OS, and some degree of 
explicit source compatibility for older language versions is needed.

I'm really hoping moving things into the `hlsl` namespace will land in our next 
language version (HLSL 202x), but since 2021 still isn't fully out the door... 
I don't really know when that will be. I could preemptively gate the using 
declaration here on the version being < hlsl202x, which would put clang one 
step ahead of 

[PATCH] D128486: [pseudo] Add error-recovery framework & brace-based recovery

2022-07-05 Thread Sam McCall via Phabricator via cfe-commits
sammccall marked 5 inline comments as done.
sammccall added a comment.

Thanks in particular for flagging the issue with duplicate forest nodes, you've 
found a hole in the model.
That said, I've left a big FIXME and I think we should patch it later.




Comment at: clang-tools-extra/pseudo/include/clang-pseudo/grammar/LRGraph.h:148
+RecoveryStrategy Strategy; // Heuristic choosing the tokens to match.
+SymbolID Result;   // The symbol that is produced.
+  };

hokein wrote:
> nit: mention the `Result` must be a nonterminal.
Hmm, I don't think it has to be?

(To deduce a brace recovery rule we require it, but that doesn't mean it needs 
to be true in general)



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:178
+const ForestNode  =
+Params.Forest.createOpaque(Option->Symbol, Option->Position);
+const GSS::Node *NewHead = Params.GSStack.addNode(

hokein wrote:
> should we worry about the case where we create a duplicated forest node? e.g. 
> we have two best options and both recover to the same nonterminal.
Oh no, you're right... we also have all the options for the GSS node being 
either the same/different in that case.

And it gets worse, what if we have one recovery -> X, and another recovery -> 
Y, and a rule `X := Y`. The following `glrReduce` will produce a duplicate `X`, 
instead of an `AmbiguousX{ OpaqueX, SequenceX{ OpaqueY } }`.

As much as I hate this, I think we should slap a FIXME on it and move on. I 
don't think multiple tied recoveries is common, and the solution here is just 
as likely to break the tie as it is to fix this with fancy algorithms.
However I don't think we have enough data to make a decision on exactly what to 
do yet.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:44
+
+void glrRecover(llvm::ArrayRef OldHeads,
+unsigned , const TokenStream ,

hokein wrote:
> sammccall wrote:
> > hokein wrote:
> > > The `GLR.cpp` file is growing significantly, I think the recovery part is 
> > > large enough to be lived in a separate file `GLRRecovery.cpp`, but the 
> > > declaration can still be in the `GLR.h`.
> > This is interesting, recover/shift/reduce/parse are (vertically) 
> > self-contained enough that it didn't seem like a big problem yet...
> > 
> > If the concern is file length, maybe we'd thather start with `reduce`; if 
> > it's relatedness, `GSS`?
> > 
> > My line count is:
> >  - recover: 156
> >  - shift: 47
> >  - reduce: 319
> >  - parse: 87
> >  - GSS: 66
> Yeah, indeed these pieces can be split, my main concern is not file length -- 
> I would prefer keeping shift/reduce/parse into a single file, as they form a 
> complete GLR algorithm (splitting them would make it harder to read and 
> follow).
> 
> Recovery seems like a different thing, I would image this part of code will 
> grow more in the future
> - the GLR algorithm has the core recovery mechanism framework with some 
> fallback recovery strategies (eof, brackets)
> - we have different recovery strategies implemented (some of them might be 
> cxx-specific, probably be part of pseudoCXX library);
> 
> 
It's hard to tell yet, but I guess I don't really see why it's going to be 
easier to reason about shift/recover in isolation vs shift/reduce. Let's see 
how this goes past the initial patch (in particular once we move stuff into 
extensions)



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:130
+
+  assert(NewHeads.empty()); // We may repeatedly populate and clear it.
+  llvm::Optional RecoveryRange;

hokein wrote:
> sammccall wrote:
> > hokein wrote:
> > > nit: might be clearer to move the assertion to the beginning of the 
> > > function.
> > The purpose of the assertion is to make it obvious that NewHeads.clear() 
> > only discards items added during the loop below.
> > An assertion at the top of the function would be less useful for this, both 
> > because it's not on the screen when reading NewHeads.clear() and because 
> > it's much less locally obvious that nothing has been pushed onto NewHeads 
> > at some prior point in the function.
> Yeah, but I'd treat it as a contract of the API (the `NewHeads` argument 
> passed to `glrRecover` must be empty).
> 
> btw, the empty assertion is missing in the latest version.
Yes, I think this is obsolete - the latest version of glrRecover no longer 
requires NewHeads to be empty at all, as it doesn't use it as scratch space.



Comment at: clang-tools-extra/pseudo/unittests/GLRTest.cpp:558
 
+TEST_F(GLRTest, RecoveryEndToEnd) {
+  // Simple example of brace-based recovery showing:

hokein wrote:
> nit: not sure the intention having the `RecoveryEndToEnd` separated from the 
> above recover-related tests, why not grouping them together?
this tests glrParse, and it's grouped with the other glrParse tests consistent 
with this file (e.g. GLRReduceOrder is with 

[PATCH] D129152: [Clang][unittests] Silence trucation warning with MSVC

2022-07-05 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov accepted this revision.
ASDenysPetrov added a comment.
This revision is now accepted and ready to land.

@aganea Thank you for fixing this.
`TestValues` structure impies to hold a set of values which can do some kind of 
convertions including truncations. This is what tests are about. That's true, 
it may happen that some test cases don't need some values. You can carry them 
out to some `TestValues2` structure and use them instead. That also would work. 
So it's up to you. I'm OK with both solutions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129152

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


[PATCH] D129016: [PowerPC] implemented @llvm.ppc.kill.canary to corrupt stack guard

2022-07-05 Thread Paul Scoropan via Phabricator via cfe-commits
pscoro updated this revision to Diff 442368.
pscoro added a comment.

removed commented code


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129016

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/CodeGen/PowerPC/builtins-ppc-stackprotect.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll

Index: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll
@@ -0,0 +1,77 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   --ppc-asm-full-reg-names < %s | FileCheck %s -check-prefix=AIX
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux \
+; RUN:   --ppc-asm-full-reg-names < %s | FileCheck %s -check-prefix=LINUX
+
+declare void @llvm.ppc.kill.canary()
+define dso_local void @test_kill_canary() {
+; AIX-LABEL: test_kill_canary:
+; AIX:   # %bb.0: # %entry
+; AIX-NEXT:blr
+;
+; LINUX-LABEL: test_kill_canary:
+; LINUX:   # %bb.0: # %entry
+; LINUX-NEXT:blr
+entry:
+  call void @llvm.ppc.kill.canary()
+  ret void
+}
+
+attributes #0 = { sspreq }
+; Function Attrs: sspreq
+define dso_local void @test_kill_canary_ssp() #0 {
+; AIX-LABEL: test_kill_canary_ssp:
+; AIX:   # %bb.0: # %entry
+; AIX-NEXT:mflr r0
+; AIX-NEXT:std r0, 16(r1)
+; AIX-NEXT:stdu r1, -128(r1)
+; AIX-NEXT:ld r3, L..C0(r2) # @__ssp_canary_word
+; AIX-NEXT:ld r4, 0(r3)
+; AIX-NEXT:std r4, 120(r1)
+; AIX-NEXT:ld r4, 0(r3)
+; AIX-NEXT:xori r4, r4, 65535
+; AIX-NEXT:xoris r4, r4, 65535
+; AIX-NEXT:std r4, 0(r3)
+; AIX-NEXT:ld r3, 0(r3)
+; AIX-NEXT:ld r4, 120(r1)
+; AIX-NEXT:cmpld r3, r4
+; AIX-NEXT:bne cr0, L..BB1_2
+; AIX-NEXT:  # %bb.1: # %entry
+; AIX-NEXT:addi r1, r1, 128
+; AIX-NEXT:ld r0, 16(r1)
+; AIX-NEXT:mtlr r0
+; AIX-NEXT:blr
+; AIX-NEXT:  L..BB1_2: # %entry
+; AIX-NEXT:bl .__stack_chk_fail[PR]
+; AIX-NEXT:nop
+;
+; LINUX-LABEL: test_kill_canary_ssp:
+; LINUX:   # %bb.0: # %entry
+; LINUX-NEXT:mflr r0
+; LINUX-NEXT:std r0, 16(r1)
+; LINUX-NEXT:stdu r1, -128(r1)
+; LINUX-NEXT:.cfi_def_cfa_offset 128
+; LINUX-NEXT:.cfi_offset lr, 16
+; LINUX-NEXT:ld r3, -28688(r13)
+; LINUX-NEXT:std r3, 120(r1)
+; LINUX-NEXT:ld r3, -28688(r13)
+; LINUX-NEXT:xori r3, r3, 65535
+; LINUX-NEXT:xoris r3, r3, 65535
+; LINUX-NEXT:std r3, 120(r1)
+; LINUX-NEXT:ld r3, 120(r1)
+; LINUX-NEXT:ld r4, -28688(r13)
+; LINUX-NEXT:cmpld r4, r3
+; LINUX-NEXT:bne cr0, .LBB1_2
+; LINUX-NEXT:  # %bb.1: # %entry
+; LINUX-NEXT:addi r1, r1, 128
+; LINUX-NEXT:ld r0, 16(r1)
+; LINUX-NEXT:mtlr r0
+; LINUX-NEXT:blr
+; LINUX-NEXT:  .LBB1_2: # %entry
+; LINUX-NEXT:bl __stack_chk_fail
+; LINUX-NEXT:nop
+entry:
+  call void @llvm.ppc.kill.canary()
+  ret void
+}
Index: llvm/lib/Target/PowerPC/PPCISelLowering.cpp
===
--- llvm/lib/Target/PowerPC/PPCISelLowering.cpp
+++ llvm/lib/Target/PowerPC/PPCISelLowering.cpp
@@ -11127,6 +11127,76 @@
 }
 break;
   }
+  case Intrinsic::ppc_kill_canary: {
+MachineFunction  = DAG.getMachineFunction();
+const Module *M = MF.getMMI().getModule();
+
+/* If SafeStack or !StackProtector, kill_canary not supported */
+if (MF.getFunction().hasFnAttribute(Attribute::SafeStack) ||
+!MF.getFunction().hasStackProtectorFnAttr()) {
+  DAG.ReplaceAllUsesOfValueWith(
+  SDValue(Op.getNode(), 0),
+  Op->getOperand(0)); // prepare node for deletion
+  break;
+}
+
+EVT VT = DAG.getTargetLoweringInfo().getPointerTy(DAG.getDataLayout());
+EVT MemVT =
+DAG.getTargetLoweringInfo().getPointerMemTy(DAG.getDataLayout());
+
+SDValue Load;
+SDValue Store;
+
+const uint64_t XORWord = 0x; // XORing with 0b111...111 will never
+ // result in the original word
+
+if (useLoadStackGuardNode()) { // linux uses LOAD_STACK_GUARD node instead of having a
+   // canary word global value
+MachineSDNode *LSG = DAG.getMachineNode(PPC::LOAD_STACK_GUARD, DL, VT,
+Op->getOperand(0));
+if (VT != MemVT) {
+  Load = DAG.getPtrExtOrTrunc(SDValue(LSG, 0), DL, MemVT);
+} else {
+  Load = SDValue(LSG, 0);
+}
+
+/* frame index used to determine stack guard location if
+ * LOAD_STACK_GUARD is used */
+MachineFrameInfo  = MF.getFrameInfo();
+int SPI = MFI.getStackProtectorIndex(); // should 

[PATCH] D128401: [clang-tidy] Fixing a bug raising false alarms on static local variables in the Infinite Loop Checker

2022-07-05 Thread Ziqing Luo via Phabricator via cfe-commits
ziqingluo-90 added a comment.

Hi @LegalizeAdulthood, @NoQ, @gribozavr2, @Eugene.Zelenko,

Is there any further issue I should address for this patch?


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

https://reviews.llvm.org/D128401

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


[PATCH] D129152: [Clang][unittests] Silence trucation warning with MSVC

2022-07-05 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea updated this revision to Diff 442366.
aganea added a comment.

Use `#pragma`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129152

Files:
  clang/unittests/StaticAnalyzer/RangeSetTest.cpp


Index: clang/unittests/StaticAnalyzer/RangeSetTest.cpp
===
--- clang/unittests/StaticAnalyzer/RangeSetTest.cpp
+++ clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -88,6 +88,12 @@
   template 
   static constexpr T X555TruncZeroOf = TruncZeroOf; // 0x'5600
 
+// Silence 'warning C4309: 'initializing': truncation of constant value'
+//   in RangeSetCastToPromotionConversionTest.
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(push)
+#pragma warning(disable : 4309)
+#endif
   // Numbers for ranges with the same bits in the lowest byte.
   // 0x'AA2A
   static constexpr T FromA = ClearLowBytes + 42;
@@ -95,6 +101,10 @@
   // 0x'552A
   static constexpr T FromB = ClearLowBytes + 42;
   static constexpr T ToB = FromB + 2; // 0x'552C
+
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(pop)
+#endif
 };
 
 template 


Index: clang/unittests/StaticAnalyzer/RangeSetTest.cpp
===
--- clang/unittests/StaticAnalyzer/RangeSetTest.cpp
+++ clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -88,6 +88,12 @@
   template 
   static constexpr T X555TruncZeroOf = TruncZeroOf; // 0x'5600
 
+// Silence 'warning C4309: 'initializing': truncation of constant value'
+//   in RangeSetCastToPromotionConversionTest.
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(push)
+#pragma warning(disable : 4309)
+#endif
   // Numbers for ranges with the same bits in the lowest byte.
   // 0x'AA2A
   static constexpr T FromA = ClearLowBytes + 42;
@@ -95,6 +101,10 @@
   // 0x'552A
   static constexpr T FromB = ClearLowBytes + 42;
   static constexpr T ToB = FromB + 2; // 0x'552C
+
+#if defined(_MSC_VER) && !defined(__clang__)
+#pragma warning(pop)
+#endif
 };
 
 template 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D112579: Allow non-variadic functions to be attributed with `__attribute__((format))`

2022-07-05 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D112579#3630647 , @fcloutier wrote:

> I'm afraid that's also not possible: `D` is a `Decl`, so it doesn't have 
> `getType()`. `Decl` is the tightest-fitting superclass of `BlockDecl`, 
> `FunctionDecl` and `ObjCMethodDecl` (because `BlockDecl` is a direct subclass 
> of it).
>
> One option could be to cast the `Decl` to a `FunctionDecl` and then use 
> `FDecl->isVariadic()`, similarly to how it goes for `BlockDecl` and 
> `ObjCMethodDecl`. I'm not sure that it's equivalent, but if you believe it is 
> and like it better, I can do that.

Ahh, I had forgotten about `BlockDecl` not being a `ValueDecl`. In that 
case, I think the code is fine as-is, sorry for the noise!

I think this generally LG; I found a few minor nits in the documentation and 
some questions on the tests. The test stuff can be handled in a follow-up if 
you think it's worthwhile.




Comment at: clang/include/clang/Basic/AttrDocs.td:3147
+
+As an extension to GCC's behavior, Clang accepts the format attribute on
+non-variadic functions. Clang checks non-variadic format functions for the same





Comment at: clang/include/clang/Basic/AttrDocs.td:3165
+
+Using the format attribute on a non-variadic function emits a GCC compatibility
+diagnostic.





Comment at: clang/test/SemaCXX/attr-format.cpp:76
+  format("bare string");
+  format("%s", 123); // expected-warning{{format specifies type 'char *' but 
the argument has type 'int'}}
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);

This pointed out an interesting test case. What should the behavior be for:
```
format("%p", 0);
```
Because that sure feels like a more reasonable thing for someone to write 
expecting it to be treated as a null pointer constant.



Comment at: clang/test/SemaCXX/attr-format.cpp:77-78
+  format("%s", 123); // expected-warning{{format specifies type 'char *' but 
the argument has type 'int'}}
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, _format);
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, do_format);
+  format("bad format %s"); // expected-warning{{more '%' conversions than data 
arguments}}

This likely isn't specific to your changes, but the `%p` in these examples 
should be warning the user (a function or function pointer is not a pointer to 
void or a pointer to a character type, so that call is UB).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112579

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


[PATCH] D127114: new clang-tidy checker for assignments within condition clause of if statement

2022-07-05 Thread dodohand via Phabricator via cfe-commits
dodohand updated this revision to Diff 442358.
dodohand added a comment.

somehow, clang-format needed to be re-run.


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

https://reviews.llvm.org/D127114

Files:
  clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.h
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp
@@ -0,0 +1,103 @@
+// RUN: %check_clang_tidy %s bugprone-assignment-in-if-condition %t
+
+void f(int arg) {
+  int f = 3;
+  if ((f = arg) || (f == (arg + 1)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f1(int arg) {
+  int f = 3;
+  if ((f == arg) || (f = (arg + 1)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f2(int arg) {
+  int f = 3;
+  if (f = arg)
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+volatile int v = 32;
+
+void f3(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && (f = v)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:40: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f4(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && ((f = v) || (f < 8
+  // CHECK-MESSAGES: :[[@LINE-1]]:41: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  } else if ((arg + 8 < f) && ((f = v) || (f < 8)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 6;
+  }
+}
+
+class BrokenOperator {
+public:
+  int d = 0;
+  int operator=(const int ) {
+d = val + 1;
+return d;
+  }
+};
+
+void f5(int arg) {
+  BrokenOperator bo;
+  int f = 3;
+  bo = f;
+  if (bo.d == 3) {
+f = 6;
+  }
+  if (bo = 3)
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 7;
+  }
+  if ((arg == 3) || (bo = 6))
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 8;
+  }
+  v = f;
+}
+
+// Tests that shouldn't trigger warnings.
+void awesome_f2(int arg) {
+  int f = 3;
+  if ((f == arg) || (f == (arg + 1))) {
+f = 5;
+  }
+}
+
+void awesome_f3(int arg) {
+  int f = 3;
+  if (f == arg) {
+f = 5;
+  }
+}
+
+void awesome_f4(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && ((f == v) || (f < 8 {
+f = 5;
+  }
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -78,6 +78,7 @@
`boost-use-to-string `_, "Yes"
`bugprone-argument-comment `_, "Yes"
`bugprone-assert-side-effect `_,
+   `bugprone-assignment-in-if-condition `_,
`bugprone-bad-signal-to-kill-thread `_,
`bugprone-bool-pointer-implicit-conversion `_, "Yes"
`bugprone-branch-clone `_,
Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
@@ -0,0 +1,23 @@
+.. title:: clang-tidy - bugprone-assignment-in-if-condition
+
+bugprone-assignment-in-if-condition
+===
+
+Finds assignments within conditions of `if` statements.
+Such assignments are bug-prone because they may have been intended as equality tests.
+
+This check finds all assignments within `if` conditions, including ones that are not flagged
+by `-Wparentheses` due to an extra set of parentheses, and including assignments that call
+an overloaded `operator=()`. The identified assignments violate 
+`BARR group "Rule 8.2.c" `_.
+
+.. 

Re: [PATCH] D128059: [Clang] Add a warning on invalid UTF-8 in comments.

2022-07-05 Thread Corentin via cfe-commits
My plan is to do that for all papers once past plenary to
keep consistency with cxx_status.

On Tue, Jul 5, 2022 at 6:13 PM Aaron Ballman via Phabricator <
revi...@reviews.llvm.org> wrote:

> aaron.ballman added reviewers: tahonermann, clang-language-wg.
> aaron.ballman added inline comments.
>
>
> 
> Comment at: clang/docs/ReleaseNotes.rst:271
> +- Added ``-Winvalid-utf8`` which diagnoses invalid UTF-8 code unit
> sequences in
> +  comments.
>
> 
> Should we mention `P2295R5` now that it's at least core approved?
> Something like:
> %%%
> ...unit sequences in comments; in support of `P2295R5 <
> http://wg21.link/P2295R5>`_.
> %%%
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D128059/new/
>
> https://reviews.llvm.org/D128059
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D128012: [HLSL] Add ExternalSemaSource & vector alias

2022-07-05 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D128012#3630680 , @beanz wrote:

> @aaron.ballman, I just had a total brain-asleep moment, and pushed this 
> without realizing that I had feedback from you. Are you okay with me 
> addressing that most-commit or would you prefer a revert? Huge apologies...

No worries, it happens! Post-commit is fine by me; no need to have significant 
churn.




Comment at: clang/lib/Headers/hlsl/hlsl_basic_types.h:30
 #ifdef __HLSL_ENABLE_16_BIT
-typedef int16_t int16_t2 __attribute__((ext_vector_type(2)));
-typedef int16_t int16_t3 __attribute__((ext_vector_type(3)));
-typedef int16_t int16_t4 __attribute__((ext_vector_type(4)));
-typedef uint16_t uint16_t2 __attribute__((ext_vector_type(2)));
-typedef uint16_t uint16_t3 __attribute__((ext_vector_type(3)));
-typedef uint16_t uint16_t4 __attribute__((ext_vector_type(4)));
+typedef vector int16_t2;
+typedef vector int16_t3;

beanz wrote:
> aaron.ballman wrote:
> > Can you explain these changes in light of:
> > 
> > > The problem is that templates aren't supported before HLSL 2021, and type 
> > > aliases still aren't supported in HLSL.
> > 
> > This still looks like it's using template and type aliases.
> This is an extreme total hack of insanity, but it is how HLSL works.
> 
> Basically, user-defined templates aren't supported, but built-in templates 
> have been around for years. In DXC, the `vector` template is a class 
> containing an ext_vector but there are horrible hacks in member expr handling 
> to make the `.` operator return ext_vector swizzles... Using an alias allows 
> me to get source compatibility here without having to do any of the member 
> expr hacking.
Interesting and horrifying in equal measures. :-)



Comment at: clang/lib/Sema/HLSLExternalSemaSource.cpp:41-44
+  auto *UsingDecl = UsingDirectiveDecl::Create(
+  AST, AST.getTranslationUnitDecl(), SourceLocation(), SourceLocation(),
+  NestedNameSpecifierLoc(), SourceLocation(), HLSLNamespace,
+  AST.getTranslationUnitDecl());

beanz wrote:
> aaron.ballman wrote:
> > And users won't find this behavior surprising? I would be worried that the 
> > user has their own globally declared type that this hidden using directive 
> > will then cause to be ambiguous: https://godbolt.org/z/jMsW54vWe -- when 
> > users hit this themselves, the location of the conflict is going to point 
> > into nowhere-land, which is also rather unfortunate.
> > 
> > Actually, the more I think about this, the less comfortable I am with it. 
> > This also means you have to be *very* careful about conflicts with STL 
> > names, and it means that any new declarations added to the `hlsl` namespace 
> > automatically risk breaking code.
> > 
> > Aside: any particular reason the namespace declaration is implicit but the 
> > using directive declaration is not?
> As HLSL is implanted today in DXC the built-in types and functions are all 
> globally defined (not in any namespace). My goal here was to start nesting 
> them in an `hlsl` namespace, and to eventually do that for DXC as well in a 
> new language version. HLSL just got support for `using namespace` like 3 
> months ago, so we can't do that in a header for compatibility, so my intent 
> was to throw it in the directive here. 
> 
> My hope is the next version of HLSL will move the builtins into the `hlsl` 
> namespace so I can make this only enabled for older language versions in the 
> near future.
> 
> In terms of conflicts with STL, I don't think the STL sources will compile 
> for HLSL anytime soon. Maybe in a future version of HLSL, but we've got a 
> long way to go to get there. For existing HLSL code, namespaces are very 
> sparingly used, and while we may find conflicts in user code I think moving 
> HLSL's builtins into a namespace will be worth the pain... but I might be 
> wrong about how much pain that will be.
So basically this trades redefinition errors for ambiguous lookup errors in 
terms of conflicts with user-declared code?

> In terms of conflicts with STL, I don't think the STL sources will compile 
> for HLSL anytime soon. Maybe in a future version of HLSL, but we've got a 
> long way to go to get there. For existing HLSL code, namespaces are very 
> sparingly used, and while we may find conflicts in user code I think moving 
> HLSL's builtins into a namespace will be worth the pain... but I might be 
> wrong about how much pain that will be.

I think moving them into a namespace is a lovely idea in theory, but it's still 
discomforting to add the `using` directive automatically for the user. The user 
is going to have the pain of dealing with the names moving to a new namespace 
at some point, so why not start from a cleaner design? It seems not entirely 
unreasonable to expect users to type `using namespace hlsl;` themselves if 
you're moving the types into a namespace, and users who need to handle 

[PATCH] D128914: [HIP] Add support for handling HIP in the linker wrapper

2022-07-05 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 442356.
jhuber6 added a comment.

Addressing some comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128914

Files:
  clang/test/Driver/linker-wrapper-image.c
  clang/test/Driver/linker-wrapper.c
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
  clang/tools/clang-linker-wrapper/OffloadWrapper.cpp
  clang/tools/clang-linker-wrapper/OffloadWrapper.h

Index: clang/tools/clang-linker-wrapper/OffloadWrapper.h
===
--- clang/tools/clang-linker-wrapper/OffloadWrapper.h
+++ clang/tools/clang-linker-wrapper/OffloadWrapper.h
@@ -21,4 +21,8 @@
 /// registers the images with the CUDA runtime.
 llvm::Error wrapCudaBinary(llvm::Module , llvm::ArrayRef Images);
 
+/// Wraps the input bundled image into the module \p M as global symbols and
+/// registers the images with the HIP runtime.
+llvm::Error wrapHIPBinary(llvm::Module , llvm::ArrayRef Images);
+
 #endif
Index: clang/tools/clang-linker-wrapper/OffloadWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/OffloadWrapper.cpp
+++ clang/tools/clang-linker-wrapper/OffloadWrapper.cpp
@@ -22,6 +22,7 @@
 namespace {
 /// Magic number that begins the section containing the CUDA fatbinary.
 constexpr unsigned CudaFatMagic = 0x466243b1;
+constexpr unsigned HIPFatMagic = 0x48495046;
 
 /// Copied from clang/CGCudaRuntime.h.
 enum OffloadEntryKindFlag : uint32_t {
@@ -288,14 +289,15 @@
 
 /// Embed the image \p Image into the module \p M so it can be found by the
 /// runtime.
-GlobalVariable *createFatbinDesc(Module , ArrayRef Image) {
+GlobalVariable *createFatbinDesc(Module , ArrayRef Image, bool IsHIP) {
   LLVMContext  = M.getContext();
   llvm::Type *Int8PtrTy = Type::getInt8PtrTy(C);
   llvm::Triple Triple = llvm::Triple(M.getTargetTriple());
 
   // Create the global string containing the fatbinary.
   StringRef FatbinConstantSection =
-  Triple.isMacOSX() ? "__NV_CUDA,__nv_fatbin" : ".nv_fatbin";
+  IsHIP ? ".hip_fatbin"
+: (Triple.isMacOSX() ? "__NV_CUDA,__nv_fatbin" : ".nv_fatbin");
   auto *Data = ConstantDataArray::get(C, Image);
   auto *Fatbin = new GlobalVariable(M, Data->getType(), /*isConstant*/ true,
 GlobalVariable::InternalLinkage, Data,
@@ -303,10 +305,11 @@
   Fatbin->setSection(FatbinConstantSection);
 
   // Create the fatbinary wrapper
-  StringRef FatbinWrapperSection =
-  Triple.isMacOSX() ? "__NV_CUDA,__fatbin" : ".nvFatBinSegment";
+  StringRef FatbinWrapperSection = IsHIP   ? ".hipFatBinSegment"
+   : Triple.isMacOSX() ? "__NV_CUDA,__fatbin"
+   : ".nvFatBinSegment";
   Constant *FatbinWrapper[] = {
-  ConstantInt::get(Type::getInt32Ty(C), CudaFatMagic),
+  ConstantInt::get(Type::getInt32Ty(C), IsHIP ? HIPFatMagic : CudaFatMagic),
   ConstantInt::get(Type::getInt32Ty(C), 1),
   ConstantExpr::getPointerBitCastOrAddrSpaceCast(Fatbin, Int8PtrTy),
   ConstantPointerNull::get(Type::getInt8PtrTy(C))};
@@ -328,9 +331,10 @@
   ConstantAggregateZero::get(ArrayType::get(getEntryTy(M), 0u));
   auto *DummyEntry = new GlobalVariable(
   M, DummyInit->getType(), true, GlobalVariable::ExternalLinkage, DummyInit,
-  "__dummy.cuda_offloading.entry");
-  DummyEntry->setSection("cuda_offloading_entries");
+  IsHIP ? "__dummy.hip_offloading.entry" : "__dummy.cuda_offloading.entry");
   DummyEntry->setVisibility(GlobalValue::HiddenVisibility);
+  DummyEntry->setSection(IsHIP ? "hip_offloading_entries"
+   : "cuda_offloading_entries");
 
   return FatbinDesc;
 }
@@ -358,7 +362,7 @@
 /// 0, entry->size, 0, 0);
 ///   }
 /// }
-Function *createRegisterGlobalsFunction(Module ) {
+Function *createRegisterGlobalsFunction(Module , bool IsHIP) {
   LLVMContext  = M.getContext();
   // Get the __cudaRegisterFunction function declaration.
   auto *RegFuncTy = FunctionType::get(
@@ -368,8 +372,8 @@
Type::getInt8PtrTy(C), Type::getInt8PtrTy(C), Type::getInt8PtrTy(C),
Type::getInt8PtrTy(C), Type::getInt32PtrTy(C)},
   /*isVarArg*/ false);
-  FunctionCallee RegFunc =
-  M.getOrInsertFunction("__cudaRegisterFunction", RegFuncTy);
+  FunctionCallee RegFunc = M.getOrInsertFunction(
+  IsHIP ? "__hipRegisterFunction" : "__cudaRegisterFunction", RegFuncTy);
 
   // Get the __cudaRegisterVar function declaration.
   auto *RegVarTy = FunctionType::get(
@@ -378,25 +382,31 @@
Type::getInt8PtrTy(C), Type::getInt8PtrTy(C), Type::getInt32Ty(C),
getSizeTTy(M), Type::getInt32Ty(C), Type::getInt32Ty(C)},
   /*isVarArg*/ false);
-  FunctionCallee RegVar = M.getOrInsertFunction("__cudaRegisterVar", RegVarTy);
+  FunctionCallee RegVar = 

[PATCH] D129152: [Clang][unittests] Silence trucation warning with MSVC

2022-07-05 Thread Tobias Hieta via Phabricator via cfe-commits
thieta added a comment.

Isn't it better to silence this warning with a pragma instead of disabling it 
for the whole file?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129152

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


[PATCH] D128923: [LinkerWrapper] Add AMDGPU specific options to the LLD invocation

2022-07-05 Thread Joseph Huber via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0bb1bf1b1761: [LinkerWrapper] Add AMDGPU specific options to 
the LLD invocation (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128923

Files:
  clang/test/Driver/linker-wrapper.c
  clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp


Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -8,9 +8,9 @@
 //
 // This tool works as a wrapper over a linking job. This tool is used to create
 // linked device images for offloading. It scans the linker's input for 
embedded
-// device offloading data stored in sections `.llvm.offloading..`
-// and extracts it as a temporary file. The extracted device files will then be
-// passed to a device linking job to create a final device image.
+// device offloading data stored in sections `.llvm.offloading` and extracts it
+// as a temporary file. The extracted device files will then be passed to a
+// device linking job to create a final device image.
 //
 //===-===//
 
@@ -573,6 +573,7 @@
"out");
   if (!TempFileOrErr)
 return TempFileOrErr.takeError();
+  std::string ArchArg = ("-plugin-opt=mcpu=" + Arch).str();
 
   SmallVector CmdArgs;
   CmdArgs.push_back(*LLDPath);
@@ -580,6 +581,8 @@
   CmdArgs.push_back("gnu");
   CmdArgs.push_back("--no-undefined");
   CmdArgs.push_back("-shared");
+  CmdArgs.push_back("-plugin-opt=-amdgpu-internalize-symbols");
+  CmdArgs.push_back(ArchArg);
   CmdArgs.push_back("-o");
   CmdArgs.push_back(*TempFileOrErr);
 
Index: clang/test/Driver/linker-wrapper.c
===
--- clang/test/Driver/linker-wrapper.c
+++ clang/test/Driver/linker-wrapper.c
@@ -18,7 +18,7 @@
 // RUN: clang-linker-wrapper --host-triple x86_64-unknown-linux-gnu --dry-run 
-linker-path \
 // RUN:   /usr/bin/ld -- %t.o -o a.out 2>&1 | FileCheck %s 
--check-prefix=AMDGPU_LINK
 
-// AMDGPU_LINK: lld{{.*}}-flavor gnu --no-undefined -shared -o {{.*}}.out 
{{.*}}.o {{.*}}.o
+// AMDGPU_LINK: lld{{.*}}-flavor gnu --no-undefined -shared 
-plugin-opt=-amdgpu-internalize-symbols -plugin-opt=mcpu=gfx908 -o {{.*}}.out 
{{.*}}.o {{.*}}.o
 
 // RUN: clang-offload-packager -o %t.out \
 // RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=openmp,triple=x86_64-unknown-linux-gnu \
@@ -90,7 +90,7 @@
 // RUN:   /usr/bin/ld --device-linker=a --device-linker=nvptx64-nvidia-cuda=b 
-- \
 // RUN:   %t.o -o a.out 2>&1 | FileCheck %s --check-prefix=LINKER_ARGS
 
-// LINKER_ARGS: lld{{.*}}-flavor gnu --no-undefined -shared -o {{.*}}.out 
{{.*}}.o a
+// LINKER_ARGS: lld{{.*}}-flavor gnu --no-undefined -shared 
-plugin-opt=-amdgpu-internalize-symbols -plugin-opt=mcpu=gfx908 -o {{.*}}.out 
{{.*}}.o a
 // LINKER_ARGS: nvlink{{.*}}-m64 -o {{.*}}.out -arch sm_70 {{.*}}.o a b
 
 // RUN: clang-offload-packager -o %t-lib.out \


Index: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
===
--- clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -8,9 +8,9 @@
 //
 // This tool works as a wrapper over a linking job. This tool is used to create
 // linked device images for offloading. It scans the linker's input for embedded
-// device offloading data stored in sections `.llvm.offloading..`
-// and extracts it as a temporary file. The extracted device files will then be
-// passed to a device linking job to create a final device image.
+// device offloading data stored in sections `.llvm.offloading` and extracts it
+// as a temporary file. The extracted device files will then be passed to a
+// device linking job to create a final device image.
 //
 //===-===//
 
@@ -573,6 +573,7 @@
"out");
   if (!TempFileOrErr)
 return TempFileOrErr.takeError();
+  std::string ArchArg = ("-plugin-opt=mcpu=" + Arch).str();
 
   SmallVector CmdArgs;
   CmdArgs.push_back(*LLDPath);
@@ -580,6 +581,8 @@
   CmdArgs.push_back("gnu");
   CmdArgs.push_back("--no-undefined");
   CmdArgs.push_back("-shared");
+  CmdArgs.push_back("-plugin-opt=-amdgpu-internalize-symbols");
+  CmdArgs.push_back(ArchArg);
   CmdArgs.push_back("-o");
   CmdArgs.push_back(*TempFileOrErr);
 
Index: clang/test/Driver/linker-wrapper.c
===
--- clang/test/Driver/linker-wrapper.c
+++ clang/test/Driver/linker-wrapper.c
@@ -18,7 +18,7 @@
 // RUN: clang-linker-wrapper --host-triple x86_64-unknown-linux-gnu --dry-run 

[clang] 0bb1bf1 - [LinkerWrapper] Add AMDGPU specific options to the LLD invocation

2022-07-05 Thread Joseph Huber via cfe-commits

Author: Joseph Huber
Date: 2022-07-05T13:43:51-04:00
New Revision: 0bb1bf1b1761a9070540df0ae0e51bc1bfb80ccd

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

LOG: [LinkerWrapper] Add AMDGPU specific options to the LLD invocation

We use LLD to perform AMDGPU linking. This linker accepts some arguments
through the `-plugin-opt` facilities. These options match what `Clang`
will output when given the same input.

Reviewed By: yaxunl

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

Added: 


Modified: 
clang/test/Driver/linker-wrapper.c
clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp

Removed: 




diff  --git a/clang/test/Driver/linker-wrapper.c 
b/clang/test/Driver/linker-wrapper.c
index ecd196313f5e8..c9855ec38abb9 100644
--- a/clang/test/Driver/linker-wrapper.c
+++ b/clang/test/Driver/linker-wrapper.c
@@ -18,7 +18,7 @@
 // RUN: clang-linker-wrapper --host-triple x86_64-unknown-linux-gnu --dry-run 
-linker-path \
 // RUN:   /usr/bin/ld -- %t.o -o a.out 2>&1 | FileCheck %s 
--check-prefix=AMDGPU_LINK
 
-// AMDGPU_LINK: lld{{.*}}-flavor gnu --no-undefined -shared -o {{.*}}.out 
{{.*}}.o {{.*}}.o
+// AMDGPU_LINK: lld{{.*}}-flavor gnu --no-undefined -shared 
-plugin-opt=-amdgpu-internalize-symbols -plugin-opt=mcpu=gfx908 -o {{.*}}.out 
{{.*}}.o {{.*}}.o
 
 // RUN: clang-offload-packager -o %t.out \
 // RUN:   
--image=file=%S/Inputs/dummy-elf.o,kind=openmp,triple=x86_64-unknown-linux-gnu \
@@ -90,7 +90,7 @@
 // RUN:   /usr/bin/ld --device-linker=a --device-linker=nvptx64-nvidia-cuda=b 
-- \
 // RUN:   %t.o -o a.out 2>&1 | FileCheck %s --check-prefix=LINKER_ARGS
 
-// LINKER_ARGS: lld{{.*}}-flavor gnu --no-undefined -shared -o {{.*}}.out 
{{.*}}.o a
+// LINKER_ARGS: lld{{.*}}-flavor gnu --no-undefined -shared 
-plugin-opt=-amdgpu-internalize-symbols -plugin-opt=mcpu=gfx908 -o {{.*}}.out 
{{.*}}.o a
 // LINKER_ARGS: nvlink{{.*}}-m64 -o {{.*}}.out -arch sm_70 {{.*}}.o a b
 
 // RUN: clang-offload-packager -o %t-lib.out \

diff  --git a/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp 
b/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
index ffd17b6cc2dd1..3e935bcbd30a8 100644
--- a/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
+++ b/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp
@@ -8,9 +8,9 @@
 //
 // This tool works as a wrapper over a linking job. This tool is used to create
 // linked device images for offloading. It scans the linker's input for 
embedded
-// device offloading data stored in sections `.llvm.offloading..`
-// and extracts it as a temporary file. The extracted device files will then be
-// passed to a device linking job to create a final device image.
+// device offloading data stored in sections `.llvm.offloading` and extracts it
+// as a temporary file. The extracted device files will then be passed to a
+// device linking job to create a final device image.
 //
 //===-===//
 
@@ -573,6 +573,7 @@ Expected link(ArrayRef InputFiles, 
Triple TheTriple,
"out");
   if (!TempFileOrErr)
 return TempFileOrErr.takeError();
+  std::string ArchArg = ("-plugin-opt=mcpu=" + Arch).str();
 
   SmallVector CmdArgs;
   CmdArgs.push_back(*LLDPath);
@@ -580,6 +581,8 @@ Expected link(ArrayRef InputFiles, 
Triple TheTriple,
   CmdArgs.push_back("gnu");
   CmdArgs.push_back("--no-undefined");
   CmdArgs.push_back("-shared");
+  CmdArgs.push_back("-plugin-opt=-amdgpu-internalize-symbols");
+  CmdArgs.push_back(ArchArg);
   CmdArgs.push_back("-o");
   CmdArgs.push_back(*TempFileOrErr);
 



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


[PATCH] D128158: [AMDGPU] Add amdgcn_sched_group_barrier builtin

2022-07-05 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added inline comments.



Comment at: clang/test/SemaOpenCL/builtins-amdgcn-error.cl:70
+{
+  __builtin_amdgcn_sched_group_barrier(x, 0, 1); // expected-error {{argument 
to '__builtin_amdgcn_sched_group_barrier' must be a constant integer}}
+}

Test error for each argument?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128158

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


[PATCH] D129152: [Clang][unittests] Silence trucation warning with MSVC

2022-07-05 Thread Alexandre Ganea via Phabricator via cfe-commits
aganea created this revision.
aganea added reviewers: ASDenysPetrov, thieta, hans.
Herald added subscribers: steakhal, mgorny.
Herald added a project: All.
aganea requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

I'm seeing the following with MSVC 2022:

  C:\git\llvm-project\clang\unittests\StaticAnalyzer\RangeSetTest.cpp(97): 
warning C4309: 'initializing': truncation of constant value
  C:\git\llvm-project\clang\unittests\StaticAnalyzer\RangeSetTest.cpp(948): 
note: see reference to class template instantiation 
'`anonymous-namespace'::TestValues' being compiled
  C:\git\llvm-project\clang\unittests\StaticAnalyzer\RangeSetTest.cpp(942): 
note: while compiling class template member function 'void 
`anonymous-namespace'::RangeSetCastToPromotionConversionTest_Test_Test::TestBody(void)'

The issue here is that `RangeSetCastToPromotionConversionTest` tries to 
instantiate the template at L947, `using TV = TestValues;` which ends up 
trying to assign at L94, `static constexpr T ToA = FromA + 2;` which overflows 
with `T=char`. Ideally, we wouldn't need `FromA/ToA/FromB/ToB` for this test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129152

Files:
  clang/unittests/StaticAnalyzer/CMakeLists.txt


Index: clang/unittests/StaticAnalyzer/CMakeLists.txt
===
--- clang/unittests/StaticAnalyzer/CMakeLists.txt
+++ clang/unittests/StaticAnalyzer/CMakeLists.txt
@@ -20,6 +20,11 @@
   TestReturnValueUnderConstruction.cpp
   )
 
+if(MSVC)
+  # warning C4309: 'initializing': truncation of constant value
+  set_source_files_properties(RangeSetTest.cpp PROPERTIES COMPILE_FLAGS 
-wd4309)
+endif()
+
 clang_target_link_libraries(StaticAnalysisTests
   PRIVATE
   clangBasic


Index: clang/unittests/StaticAnalyzer/CMakeLists.txt
===
--- clang/unittests/StaticAnalyzer/CMakeLists.txt
+++ clang/unittests/StaticAnalyzer/CMakeLists.txt
@@ -20,6 +20,11 @@
   TestReturnValueUnderConstruction.cpp
   )
 
+if(MSVC)
+  # warning C4309: 'initializing': truncation of constant value
+  set_source_files_properties(RangeSetTest.cpp PROPERTIES COMPILE_FLAGS -wd4309)
+endif()
+
 clang_target_link_libraries(StaticAnalysisTests
   PRIVATE
   clangBasic
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D128923: [LinkerWrapper] Add AMDGPU specific options to the LLD invocation

2022-07-05 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl accepted this revision.
yaxunl added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128923

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


[PATCH] D128850: [HIP] Generate offloading entries for HIP with the new driver.

2022-07-05 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl accepted this revision.
yaxunl added a comment.

LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128850

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


[PATCH] D122573: [TBAA] Emit distinct TBAA tags for pointers with different depths,types.

2022-07-05 Thread Rui Zhang via Phabricator via cfe-commits
rui.zhang added a comment.

I like the direction where this change is leading to and hope there is some way 
to land it incrementally. Since BuiltinType has the above mentioned concern on 
`void *`, how about we focus on `RecordType` pointers as a first step instead? 
Are there any pitfalls if we distinguish `RecordType` pointers by depth?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122573

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


[PATCH] D105584: [MLIR][OpenMP] Distribute Construct Operation

2022-07-05 Thread Abid via Phabricator via cfe-commits
abidmalikwaterloo updated this revision to Diff 442343.
abidmalikwaterloo added a comment.

Removed unrelated changes in CMakefile.txt


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105584

Files:
  mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
  mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
  mlir/test/Dialect/OpenMP/ops.mlir

Index: mlir/test/Dialect/OpenMP/ops.mlir
===
--- mlir/test/Dialect/OpenMP/ops.mlir
+++ mlir/test/Dialect/OpenMP/ops.mlir
@@ -121,6 +121,19 @@
   return
 }
 
+// CHECK-LABEL: omp_DistributeOp
+func.func @omp_DistributeOp(%lb : index, %ub : index, %step : index, %data_var : memref, %chunk_var : i32) -> () {
+  // CHECK: omp.distribute collapse(2)
+  // CHECK-SAME: for (%{{.*}}) : index = (%{{.*}}) to (%{{.*}}) step (%{{.*}})
+  "omp.distribute" (%lb, %ub, %step) ({
+^bb0(%iv: index):
+ omp.yield 
+  }) {operand_segment_sizes = dense<[1,1,1,0,0,0]> : vector<6xi32>, collapse_val = 2} :
+(index, index, index) -> ()
+ 
+ return
+ }
+
 // CHECK-LABEL: omp_wsloop
 func.func @omp_wsloop(%lb : index, %ub : index, %step : index, %data_var : memref, %linear_var : i32, %chunk_var : i32) -> () {
 
Index: mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
===
--- mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
+++ mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
@@ -207,6 +207,20 @@
   return success();
 }
 
+//===-===//
+// Verifier for Dristribute Op
+//===-===//
+
+LogicalResult DistributeOp::verify(){
+  if (this->lowerBound().empty()) 
+return emitOpError() << "empty lowerbound for distribute loop operation";
+  
+  if (this->upperBound().empty()) 
+return emitOpError() << "empty upperbound for distribute loop operation";
+  
+  return success();	
+}
+
 /// schedule ::= `schedule` `(` sched-list `)`
 /// sched-list ::= sched-val | sched-val sched-list |
 ///sched-val `,` sched-modifier
@@ -510,14 +524,14 @@
 }
 
 //===--===//
-// WsLoopOp
+// LoopControl
 //===--===//
 
 /// loop-control ::= `(` ssa-id-list `)` `:` type `=`  loop-bounds
 /// loop-bounds := `(` ssa-id-list `)` to `(` ssa-id-list `)` inclusive? steps
 /// steps := `step` `(`ssa-id-list`)`
 ParseResult
-parseWsLoopControl(OpAsmParser , Region ,
+parseLoopControl(OpAsmParser , Region ,
SmallVectorImpl ,
SmallVectorImpl ,
SmallVectorImpl ,
@@ -560,7 +574,7 @@
   return success();
 }
 
-void printWsLoopControl(OpAsmPrinter , Operation *op, Region ,
+void printLoopControl(OpAsmPrinter , Operation *op, Region ,
 ValueRange lowerBound, ValueRange upperBound,
 ValueRange steps, TypeRange loopVarTypes,
 UnitAttr inclusive) {
Index: mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
===
--- mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
+++ mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
@@ -394,7 +394,7 @@
   custom(
 $reduction_vars, type($reduction_vars), $reductions
   ) `)`
-) `for` custom($region, $lowerBound, $upperBound, $step,
+) `for` custom($region, $lowerBound, $upperBound, $step,
   type($step), $inclusive) attr-dict
   }];
   let hasVerifier = 1;
@@ -446,7 +446,7 @@
 def YieldOp : OpenMP_Op<"yield",
 [NoSideEffect, ReturnLike, Terminator,
  ParentOneOf<["WsLoopOp", "ReductionDeclareOp", 
- "AtomicUpdateOp", "SimdLoopOp"]>]> {
+ "AtomicUpdateOp", "SimdLoopOp","DistributeOp"]>]> {
   let summary = "loop yield and termination operation";
   let description = [{
 "omp.yield" yields SSA values from the OpenMP dialect op region and
@@ -463,6 +463,68 @@
   let assemblyFormat = [{ ( `(` $results^ `:` type($results) `)` )? attr-dict}];
 }
 
+//===--===//
+// 2.9.4.1 distribute Construct
+//===--===//
+
+def DistributeOp : OpenMP_Op<"distribute", [AttrSizedOperandSegments,
+AllTypesMatch<["lowerBound", "upperBound", "step"]>]> {
+  let summary = "distribute loop construct";
+  let description = [{ 
+The distribute construct specifies that the iterations of one or more loop
+will be executed by the initial teams in the context of their implicit 
+tasks. The iterations are distributed across the initial threads of all 
+initial teams that execute the teams region to which the 

[PATCH] D126779: [analyzer] Fix assertion in simplifySymbolCast

2022-07-05 Thread Gabor Marton via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
martong marked 2 inline comments as done.
Closed by commit rG2df120784af4: [analyzer] Fix assertion in simplifySymbolCast 
(authored by martong).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126779

Files:
  clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
  clang/test/Analysis/produce-symbolcast_x86.cpp


Index: clang/test/Analysis/produce-symbolcast_x86.cpp
===
--- clang/test/Analysis/produce-symbolcast_x86.cpp
+++ clang/test/Analysis/produce-symbolcast_x86.cpp
@@ -11,6 +11,15 @@
 template 
 void clang_analyzer_dump(T);
 
+void test_double(int n) {
+  double D = n / 30;
+  clang_analyzer_dump(D); // expected-warning{{(double) ((reg_$0) / 
30)}}
+  char C = D;
+  clang_analyzer_dump(C); // expected-warning{{(char) ((double) ((reg_$0) / 30))}}
+  int I = C; // assertion should not fail here!
+  clang_analyzer_dump(I); // expected-warning{{(int) ((char) ((double) 
((reg_$0) / 30)))}}
+}
+
 void test_schar(schar x) {
   clang_analyzer_dump(x); // expected-warning{{reg_$0}}
 
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -1103,6 +1103,10 @@
   SymbolRef RootSym = cast(SE)->getOperand();
   QualType RT = RootSym->getType().getCanonicalType();
 
+  // FIXME support simplification from non-integers.
+  if (!RT->isIntegralOrEnumerationType())
+return makeNonLoc(SE, T, CastTy);
+
   BasicValueFactory  = getBasicValueFactory();
   APSIntType CTy = BVF.getAPSIntType(CastTy);
   APSIntType TTy = BVF.getAPSIntType(T);


Index: clang/test/Analysis/produce-symbolcast_x86.cpp
===
--- clang/test/Analysis/produce-symbolcast_x86.cpp
+++ clang/test/Analysis/produce-symbolcast_x86.cpp
@@ -11,6 +11,15 @@
 template 
 void clang_analyzer_dump(T);
 
+void test_double(int n) {
+  double D = n / 30;
+  clang_analyzer_dump(D); // expected-warning{{(double) ((reg_$0) / 30)}}
+  char C = D;
+  clang_analyzer_dump(C); // expected-warning{{(char) ((double) ((reg_$0) / 30))}}
+  int I = C; // assertion should not fail here!
+  clang_analyzer_dump(I); // expected-warning{{(int) ((char) ((double) ((reg_$0) / 30)))}}
+}
+
 void test_schar(schar x) {
   clang_analyzer_dump(x); // expected-warning{{reg_$0}}
 
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -1103,6 +1103,10 @@
   SymbolRef RootSym = cast(SE)->getOperand();
   QualType RT = RootSym->getType().getCanonicalType();
 
+  // FIXME support simplification from non-integers.
+  if (!RT->isIntegralOrEnumerationType())
+return makeNonLoc(SE, T, CastTy);
+
   BasicValueFactory  = getBasicValueFactory();
   APSIntType CTy = BVF.getAPSIntType(CastTy);
   APSIntType TTy = BVF.getAPSIntType(T);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 2df1207 - [analyzer] Fix assertion in simplifySymbolCast

2022-07-05 Thread Gabor Marton via cfe-commits

Author: Gabor Marton
Date: 2022-07-05T19:00:23+02:00
New Revision: 2df120784af40c9cfebaf2a505a5ebe74c51b44a

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

LOG: [analyzer] Fix assertion in simplifySymbolCast

Depends on D128068.
Added a new test code that fails an assertion in the baseline.
That is because `getAPSIntType` works only with integral types.

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
clang/test/Analysis/produce-symbolcast_x86.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp 
b/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
index 7b08acdb569b..cf3d13ffb7ba 100644
--- a/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ b/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -1103,6 +1103,10 @@ nonloc::SymbolVal 
SValBuilder::simplifySymbolCast(nonloc::SymbolVal V,
   SymbolRef RootSym = cast(SE)->getOperand();
   QualType RT = RootSym->getType().getCanonicalType();
 
+  // FIXME support simplification from non-integers.
+  if (!RT->isIntegralOrEnumerationType())
+return makeNonLoc(SE, T, CastTy);
+
   BasicValueFactory  = getBasicValueFactory();
   APSIntType CTy = BVF.getAPSIntType(CastTy);
   APSIntType TTy = BVF.getAPSIntType(T);

diff  --git a/clang/test/Analysis/produce-symbolcast_x86.cpp 
b/clang/test/Analysis/produce-symbolcast_x86.cpp
index 0db10072a6eb..e4968f7063c0 100644
--- a/clang/test/Analysis/produce-symbolcast_x86.cpp
+++ b/clang/test/Analysis/produce-symbolcast_x86.cpp
@@ -11,6 +11,15 @@ using ullong = unsigned long long;
 template 
 void clang_analyzer_dump(T);
 
+void test_double(int n) {
+  double D = n / 30;
+  clang_analyzer_dump(D); // expected-warning{{(double) ((reg_$0) / 
30)}}
+  char C = D;
+  clang_analyzer_dump(C); // expected-warning{{(char) ((double) ((reg_$0) / 30))}}
+  int I = C; // assertion should not fail here!
+  clang_analyzer_dump(I); // expected-warning{{(int) ((char) ((double) 
((reg_$0) / 30)))}}
+}
+
 void test_schar(schar x) {
   clang_analyzer_dump(x); // expected-warning{{reg_$0}}
 



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


[PATCH] D128068: [analyzer] Do not emit redundant SymbolCasts

2022-07-05 Thread Gabor Marton 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 rG5d7fa481cf4d: [analyzer] Do not emit redundant SymbolCasts 
(authored by martong).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128068

Files:
  clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
  clang/test/Analysis/symbolcast-floatingpoint.cpp


Index: clang/test/Analysis/symbolcast-floatingpoint.cpp
===
--- /dev/null
+++ clang/test/Analysis/symbolcast-floatingpoint.cpp
@@ -0,0 +1,24 @@
+// RUN: %clang_analyze_cc1 -x c++ -analyzer-checker=debug.ExprInspection \
+// RUN:-analyzer-config support-symbolic-integer-casts=false \
+// RUN:-verify %s
+
+// RUN: %clang_analyze_cc1 -x c++ -analyzer-checker=debug.ExprInspection \
+// RUN:-analyzer-config support-symbolic-integer-casts=true \
+// RUN:-verify %s
+
+template 
+void clang_analyzer_dump(T);
+
+void test_no_redundant_floating_point_cast(int n) {
+
+  double D = n / 30;
+  clang_analyzer_dump(D); // expected-warning{{(double) ((reg_$0) / 
30)}}
+
+  // There are two cast operations evaluated above:
+  // 1. (n / 30) is cast to a double during the store of `D`.
+  // 2. Then in the next line, in RegionStore::getBinding during the load of 
`D`.
+  //
+  // We should not see in the dump of the SVal any redundant casts like
+  // (double) ((double) $n / 30)
+
+}
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -113,6 +113,8 @@
   QualType fromTy, QualType toTy) {
   assert(operand);
   assert(!Loc::isLocType(toTy));
+  if (fromTy == toTy)
+return operand;
   return nonloc::SymbolVal(SymMgr.getCastSymbol(operand, fromTy, toTy));
 }
 


Index: clang/test/Analysis/symbolcast-floatingpoint.cpp
===
--- /dev/null
+++ clang/test/Analysis/symbolcast-floatingpoint.cpp
@@ -0,0 +1,24 @@
+// RUN: %clang_analyze_cc1 -x c++ -analyzer-checker=debug.ExprInspection \
+// RUN:-analyzer-config support-symbolic-integer-casts=false \
+// RUN:-verify %s
+
+// RUN: %clang_analyze_cc1 -x c++ -analyzer-checker=debug.ExprInspection \
+// RUN:-analyzer-config support-symbolic-integer-casts=true \
+// RUN:-verify %s
+
+template 
+void clang_analyzer_dump(T);
+
+void test_no_redundant_floating_point_cast(int n) {
+
+  double D = n / 30;
+  clang_analyzer_dump(D); // expected-warning{{(double) ((reg_$0) / 30)}}
+
+  // There are two cast operations evaluated above:
+  // 1. (n / 30) is cast to a double during the store of `D`.
+  // 2. Then in the next line, in RegionStore::getBinding during the load of `D`.
+  //
+  // We should not see in the dump of the SVal any redundant casts like
+  // (double) ((double) $n / 30)
+
+}
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -113,6 +113,8 @@
   QualType fromTy, QualType toTy) {
   assert(operand);
   assert(!Loc::isLocType(toTy));
+  if (fromTy == toTy)
+return operand;
   return nonloc::SymbolVal(SymMgr.getCastSymbol(operand, fromTy, toTy));
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 5d7fa48 - [analyzer] Do not emit redundant SymbolCasts

2022-07-05 Thread Gabor Marton via cfe-commits

Author: Gabor Marton
Date: 2022-07-05T18:42:34+02:00
New Revision: 5d7fa481cf4d36e14345b1c3ebc951edda0b40b1

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

LOG: [analyzer] Do not emit redundant SymbolCasts

In `RegionStore::getBinding` we call `evalCast` unconditionally to align
the stored value's type to the one that is being queried. However, the
stored type might be the same, so we may end up having redundant
`SymbolCasts` emitted.

The solution is to check whether the `to` and `from` type are the same
in `makeNonLoc`.

Note, we can't just do type equivalence check at the beginning of `evalCast`
because when `evalCast` is called from `getBinding` then the original type
(`OriginalTy`) is not set, so one operand is missing for the comparison. In
`evalCastSubKind(nonloc::SymbolVal)` when the original type is not set,
we get the `from` type via `SymbolVal::getType()`.

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

Added: 
clang/test/Analysis/symbolcast-floatingpoint.cpp

Modified: 
clang/lib/StaticAnalyzer/Core/SValBuilder.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp 
b/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
index 13fac37899cd2..7b08acdb569b0 100644
--- a/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ b/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -113,6 +113,8 @@ nonloc::SymbolVal SValBuilder::makeNonLoc(const SymExpr 
*operand,
   QualType fromTy, QualType toTy) {
   assert(operand);
   assert(!Loc::isLocType(toTy));
+  if (fromTy == toTy)
+return operand;
   return nonloc::SymbolVal(SymMgr.getCastSymbol(operand, fromTy, toTy));
 }
 

diff  --git a/clang/test/Analysis/symbolcast-floatingpoint.cpp 
b/clang/test/Analysis/symbolcast-floatingpoint.cpp
new file mode 100644
index 0..8ea4c9b6c24c1
--- /dev/null
+++ b/clang/test/Analysis/symbolcast-floatingpoint.cpp
@@ -0,0 +1,24 @@
+// RUN: %clang_analyze_cc1 -x c++ -analyzer-checker=debug.ExprInspection \
+// RUN:-analyzer-config support-symbolic-integer-casts=false \
+// RUN:-verify %s
+
+// RUN: %clang_analyze_cc1 -x c++ -analyzer-checker=debug.ExprInspection \
+// RUN:-analyzer-config support-symbolic-integer-casts=true \
+// RUN:-verify %s
+
+template 
+void clang_analyzer_dump(T);
+
+void test_no_redundant_floating_point_cast(int n) {
+
+  double D = n / 30;
+  clang_analyzer_dump(D); // expected-warning{{(double) ((reg_$0) / 
30)}}
+
+  // There are two cast operations evaluated above:
+  // 1. (n / 30) is cast to a double during the store of `D`.
+  // 2. Then in the next line, in RegionStore::getBinding during the load of 
`D`.
+  //
+  // We should not see in the dump of the SVal any redundant casts like
+  // (double) ((double) $n / 30)
+
+}



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


[PATCH] D127114: new clang-tidy checker for assignments within condition clause of if statement

2022-07-05 Thread dodohand via Phabricator via cfe-commits
dodohand updated this revision to Diff 442340.
dodohand added a comment.

Updated to merge successfully into latest version of main branch


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

https://reviews.llvm.org/D127114

Files:
  clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.h
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp
@@ -0,0 +1,103 @@
+// RUN: %check_clang_tidy %s bugprone-assignment-in-if-condition %t
+
+void f(int arg) {
+  int f = 3;
+  if ((f = arg) || (f == (arg + 1)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f1(int arg) {
+  int f = 3;
+  if ((f == arg) || (f = (arg + 1)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f2(int arg) {
+  int f = 3;
+  if (f = arg)
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+volatile int v = 32;
+
+void f3(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && (f = v)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:40: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f4(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && ((f = v) || (f < 8
+  // CHECK-MESSAGES: :[[@LINE-1]]:41: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  } else if ((arg + 8 < f) && ((f = v) || (f < 8)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 6;
+  }
+}
+
+class BrokenOperator {
+public:
+  int d = 0;
+  int operator=(const int ) {
+d = val + 1;
+return d;
+  }
+};
+
+void f5(int arg) {
+  BrokenOperator bo;
+  int f = 3;
+  bo = f;
+  if (bo.d == 3) {
+f = 6;
+  }
+  if (bo = 3)
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 7;
+  }
+  if ((arg == 3) || (bo = 6))
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 8;
+  }
+  v = f;
+}
+
+// Tests that shouldn't trigger warnings.
+void awesome_f2(int arg) {
+  int f = 3;
+  if ((f == arg) || (f == (arg + 1))) {
+f = 5;
+  }
+}
+
+void awesome_f3(int arg) {
+  int f = 3;
+  if (f == arg) {
+f = 5;
+  }
+}
+
+void awesome_f4(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && ((f == v) || (f < 8 {
+f = 5;
+  }
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -78,6 +78,7 @@
`boost-use-to-string `_, "Yes"
`bugprone-argument-comment `_, "Yes"
`bugprone-assert-side-effect `_,
+   `bugprone-assignment-in-if-condition `_,
`bugprone-bad-signal-to-kill-thread `_,
`bugprone-bool-pointer-implicit-conversion `_, "Yes"
`bugprone-branch-clone `_,
Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/assignment-in-if-condition.rst
@@ -0,0 +1,23 @@
+.. title:: clang-tidy - bugprone-assignment-in-if-condition
+
+bugprone-assignment-in-if-condition
+===
+
+Finds assignments within conditions of `if` statements.
+Such assignments are bug-prone because they may have been intended as equality tests.
+
+This check finds all assignments within `if` conditions, including ones that are not flagged
+by `-Wparentheses` due to an extra set of parentheses, and including assignments that call
+an overloaded `operator=()`. The identified assignments violate 
+`BARR group "Rule 8.2.c" 

[PATCH] D127114: new clang-tidy checker for assignments within condition clause of if statement

2022-07-05 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added a comment.

Thanks! I'll commit this for you once you upload a refreshed patch (that 
applies to the main branch cleanly).


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

https://reviews.llvm.org/D127114

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


[PATCH] D128012: [HLSL] Add ExternalSemaSource & vector alias

2022-07-05 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added inline comments.



Comment at: clang/lib/Headers/hlsl/hlsl_basic_types.h:30
 #ifdef __HLSL_ENABLE_16_BIT
-typedef int16_t int16_t2 __attribute__((ext_vector_type(2)));
-typedef int16_t int16_t3 __attribute__((ext_vector_type(3)));
-typedef int16_t int16_t4 __attribute__((ext_vector_type(4)));
-typedef uint16_t uint16_t2 __attribute__((ext_vector_type(2)));
-typedef uint16_t uint16_t3 __attribute__((ext_vector_type(3)));
-typedef uint16_t uint16_t4 __attribute__((ext_vector_type(4)));
+typedef vector int16_t2;
+typedef vector int16_t3;

aaron.ballman wrote:
> Can you explain these changes in light of:
> 
> > The problem is that templates aren't supported before HLSL 2021, and type 
> > aliases still aren't supported in HLSL.
> 
> This still looks like it's using template and type aliases.
This is an extreme total hack of insanity, but it is how HLSL works.

Basically, user-defined templates aren't supported, but built-in templates have 
been around for years. In DXC, the `vector` template is a class containing an 
ext_vector but there are horrible hacks in member expr handling to make the `.` 
operator return ext_vector swizzles... Using an alias allows me to get source 
compatibility here without having to do any of the member expr hacking.



Comment at: clang/lib/Sema/HLSLExternalSemaSource.cpp:41-44
+  auto *UsingDecl = UsingDirectiveDecl::Create(
+  AST, AST.getTranslationUnitDecl(), SourceLocation(), SourceLocation(),
+  NestedNameSpecifierLoc(), SourceLocation(), HLSLNamespace,
+  AST.getTranslationUnitDecl());

aaron.ballman wrote:
> And users won't find this behavior surprising? I would be worried that the 
> user has their own globally declared type that this hidden using directive 
> will then cause to be ambiguous: https://godbolt.org/z/jMsW54vWe -- when 
> users hit this themselves, the location of the conflict is going to point 
> into nowhere-land, which is also rather unfortunate.
> 
> Actually, the more I think about this, the less comfortable I am with it. 
> This also means you have to be *very* careful about conflicts with STL names, 
> and it means that any new declarations added to the `hlsl` namespace 
> automatically risk breaking code.
> 
> Aside: any particular reason the namespace declaration is implicit but the 
> using directive declaration is not?
As HLSL is implanted today in DXC the built-in types and functions are all 
globally defined (not in any namespace). My goal here was to start nesting them 
in an `hlsl` namespace, and to eventually do that for DXC as well in a new 
language version. HLSL just got support for `using namespace` like 3 months 
ago, so we can't do that in a header for compatibility, so my intent was to 
throw it in the directive here. 

My hope is the next version of HLSL will move the builtins into the `hlsl` 
namespace so I can make this only enabled for older language versions in the 
near future.

In terms of conflicts with STL, I don't think the STL sources will compile for 
HLSL anytime soon. Maybe in a future version of HLSL, but we've got a long way 
to go to get there. For existing HLSL code, namespaces are very sparingly used, 
and while we may find conflicts in user code I think moving HLSL's builtins 
into a namespace will be worth the pain... but I might be wrong about how much 
pain that will be.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128012

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


[PATCH] D127114: new clang-tidy checker for assignments within condition clause of if statement

2022-07-05 Thread dodohand via Phabricator via cfe-commits
dodohand added a comment.

Hi @gribozavr2, I don't have commit access... I'll address the merge issue ASAP 
though.


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

https://reviews.llvm.org/D127114

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


[PATCH] D127114: new clang-tidy checker for assignments within condition clause of if statement

2022-07-05 Thread dodohand via Phabricator via cfe-commits
dodohand marked 4 inline comments as done.
dodohand added a comment.

Addressed comments from gribozavr2


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

https://reviews.llvm.org/D127114

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


[PATCH] D127114: new clang-tidy checker for assignments within condition clause of if statement

2022-07-05 Thread dodohand via Phabricator via cfe-commits
dodohand updated this revision to Diff 442338.
dodohand added a comment.

Addressing comments from @gribozavr2 identifying comments needing 
update/removal/improvement.


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

https://reviews.llvm.org/D127114

Files:
  clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.h
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-assignment-in-if-condition.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp
@@ -0,0 +1,103 @@
+// RUN: %check_clang_tidy %s bugprone-assignment-in-if-condition %t
+
+void f(int arg) {
+  int f = 3;
+  if ((f = arg) || (f == (arg + 1)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f1(int arg) {
+  int f = 3;
+  if ((f == arg) || (f = (arg + 1)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f2(int arg) {
+  int f = 3;
+  if (f = arg)
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+volatile int v = 32;
+
+void f3(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && (f = v)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:40: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  }
+}
+
+void f4(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && ((f = v) || (f < 8
+  // CHECK-MESSAGES: :[[@LINE-1]]:41: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 5;
+  } else if ((arg + 8 < f) && ((f = v) || (f < 8)))
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 6;
+  }
+}
+
+class BrokenOperator {
+public:
+  int d = 0;
+  int operator=(const int ) {
+d = val + 1;
+return d;
+  }
+};
+
+void f5(int arg) {
+  BrokenOperator bo;
+  int f = 3;
+  bo = f;
+  if (bo.d == 3) {
+f = 6;
+  }
+  if (bo = 3)
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 7;
+  }
+  if ((arg == 3) || (bo = 6))
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: an assignment within an 'if' condition is bug-prone [bugprone-assignment-in-if-condition]
+  {
+f = 8;
+  }
+  v = f;
+}
+
+// Tests that shouldn't trigger warnings.
+void awesome_f2(int arg) {
+  int f = 3;
+  if ((f == arg) || (f == (arg + 1))) {
+f = 5;
+  }
+}
+
+void awesome_f3(int arg) {
+  int f = 3;
+  if (f == arg) {
+f = 5;
+  }
+}
+
+void awesome_f4(int arg) {
+  int f = 3;
+  if ((f == arg) || ((arg + 6 < f) && ((f == v) || (f < 8 {
+f = 5;
+  }
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -54,6 +54,7 @@
`boost-use-to-string `_, "Yes"
`bugprone-argument-comment `_, "Yes"
`bugprone-assert-side-effect `_,
+   `bugprone-assignment-in-if-condition `_,
`bugprone-bad-signal-to-kill-thread `_,
`bugprone-bool-pointer-implicit-conversion `_, "Yes"
`bugprone-branch-clone `_,
Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-assignment-in-if-condition.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone-assignment-in-if-condition.rst
@@ -0,0 +1,23 @@
+.. title:: clang-tidy - bugprone-assignment-in-if-condition
+
+bugprone-assignment-in-if-condition
+===
+
+Finds assignments within conditions of `if` statements.
+Such assignments are bug-prone because they may have been intended as equality tests.
+
+This check finds all assignments within `if` conditions, including ones that are not flagged
+by `-Wparentheses` due to an extra set of parentheses, and including assignments that call
+an overloaded `operator=()`. The identified assignments violate 
+`BARR group "Rule 8.2.c" 

[PATCH] D128012: [HLSL] Add ExternalSemaSource & vector alias

2022-07-05 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added a comment.

@aaron.ballman, I just had a total brain-asleep moment, and pushed this without 
realizing that I had feedback from you. Are you okay with me addressing that 
most-commit or would you prefer a revert? Huge apologies...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128012

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


[PATCH] D128068: [analyzer] Do not emit redundant SymbolCasts

2022-07-05 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

In D128068#3594171 , @steakhal wrote:

>> We can't just do that check in `evalCast` because there are many additonal 
>> logic before we'd end up in `makeNonLoc`.
>
> I'm not exactly up to date. Could you please extend the summary with an 
> example to underpin this statement prior to committing?

Yeah, okay, I've updated the summary and will do so with the commit message as 
well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128068

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


[PATCH] D112579: Allow non-variadic functions to be attributed with `__attribute__((format))`

2022-07-05 Thread Félix Cloutier via Phabricator via cfe-commits
fcloutier added a comment.

I'm afraid that's also not possible: `D` is a `Decl`, so it doesn't have 
`getType()`. `Decl` is the tightest-fitting superclass of `BlockDecl`, 
`FunctionDecl` and `ObjCMethodDecl` (because `BlockDecl` is a direct subclass 
of it).

One option could be to cast the `Decl` to a `FunctionDecl` and then use 
`FDecl->isVariadic()`, similarly to how it goes for `BlockDecl` and 
`ObjCMethodDecl`. I'm not sure that it's equivalent, but if you believe it is 
and like it better, I can do that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112579

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


[PATCH] D127114: new clang-tidy checker for assignments within condition clause of if statement

2022-07-05 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp:84
+
+// Add something that doesn't trigger the check here.
+void awesome_f2(int arg) {




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

https://reviews.llvm.org/D127114

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


[PATCH] D128012: [HLSL] Add ExternalSemaSource & vector alias

2022-07-05 Thread Chris Bieneman 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 rGb8dbc6ffea93: [HLSL] Add ExternalSemaSource  vector 
alias (authored by beanz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128012

Files:
  clang/include/clang/Sema/HLSLExternalSemaSource.h
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Headers/hlsl/hlsl_basic_types.h
  clang/lib/Sema/CMakeLists.txt
  clang/lib/Sema/HLSLExternalSemaSource.cpp
  clang/test/AST/HLSL/vector-alias.hlsl

Index: clang/test/AST/HLSL/vector-alias.hlsl
===
--- /dev/null
+++ clang/test/AST/HLSL/vector-alias.hlsl
@@ -0,0 +1,53 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -x hlsl -ast-dump -o - %s | FileCheck %s 
+
+// CHECK: NamespaceDecl 0x{{[0-9a-fA-F]+}} <>  implicit hlsl
+// CHECK-NEXT: TypeAliasTemplateDecl 0x{{[0-9a-fA-F]+}} <>  implicit vector
+// CHECK-NEXT: TemplateTypeParmDecl 0x{{[0-9a-fA-F]+}} <>  class depth 0 index 0 element
+// CHECK-NEXT: TemplateArgument type 'float'
+// CHECK-NEXT: BuiltinType 0x{{[0-9a-fA-F]+}} 'float'
+// CHECK-NEXT: NonTypeTemplateParmDecl 0x{{[0-9a-fA-F]+}} <>  'int' depth 0 index 1 element_count
+// CHECK-NEXT: TemplateArgument expr
+// CHECK-NEXT: IntegerLiteral 0x{{[0-9a-fA-F]+}} <> 'int' 4
+// CHECK-NEXT: TypeAliasDecl 0x{{[0-9a-fA-F]+}} <>  implicit vector 'element __attribute__((ext_vector_type(element_count)))'
+// CHECK-NEXT: DependentSizedExtVectorType 0x{{[0-9a-fA-F]+}} 'element __attribute__((ext_vector_type(element_count)))' dependent 
+// CHECK-NEXT: TemplateTypeParmType 0x{{[0-9a-fA-F]+}} 'element' dependent depth 0 index 0
+// CHECK-NEXT: TemplateTypeParm 0x{{[0-9a-fA-F]+}} 'element'
+// CHECK-NEXT: DeclRefExpr 0x{{[0-9a-fA-F]+}} <> 'int' lvalue
+// NonTypeTemplateParm 0x{{[0-9a-fA-F]+}} 'element_count' 'int'
+
+// Make sure we got a using directive at the end.
+// CHECK: UsingDirectiveDecl 0x{{[0-9a-fA-F]+}} <>  Namespace 0x{{[0-9a-fA-F]+}} 'hlsl'
+
+[numthreads(1,1,1)]
+int entry() {
+  // Verify that the alias is generated inside the hlsl namespace.
+  hlsl::vector Vec2 = {1.0, 2.0};
+
+  // CHECK: DeclStmt 0x{{[0-9a-fA-F]+}} 
+  // CHECK-NEXT: VarDecl 0x{{[0-9a-fA-F]+}}  col:26 Vec2 'hlsl::vector':'float __attribute__((ext_vector_type(2)))' cinit
+
+  // Verify that you don't need to specify the namespace.
+  vector Vec2a = {1, 2};
+
+  // CHECK: DeclStmt 0x{{[0-9a-fA-F]+}} 
+  // CHECK-NEXT: VarDecl 0x{{[0-9a-fA-F]+}}  col:18 Vec2a 'vector':'int __attribute__((ext_vector_type(2)))' cinit
+
+  // Build a bigger vector.
+  vector Vec4 = {1.0, 2.0, 3.0, 4.0};
+
+  // CHECK: DeclStmt 0x{{[0-9a-fA-F]+}} 
+  // CHECK-NEXT: VarDecl 0x{{[0-9a-fA-F]+}}  col:21 used Vec4 'vector':'double __attribute__((ext_vector_type(4)))' cinit
+
+  // Verify that swizzles still work.
+  vector Vec3 = Vec4.xyz;
+
+  // CHECK: DeclStmt 0x{{[0-9a-fA-F]+}} 
+  // CHECK-NEXT: VarDecl 0x{{[0-9a-fA-F]+}}  col:21 Vec3 'vector':'double __attribute__((ext_vector_type(3)))' cinit
+
+  // Verify that the implicit arguments generate the correct type.
+  vector<> ImpVec4 = {1.0, 2.0, 3.0, 4.0};
+
+  // CHECK: DeclStmt 0x{{[0-9a-fA-F]+}} 
+  // CHECK-NEXT: VarDecl 0x{{[0-9a-fA-F]+}}  col:12 ImpVec4 'vector<>':'float __attribute__((ext_vector_type(4)))' cinit
+  return 1;
+}
Index: clang/lib/Sema/HLSLExternalSemaSource.cpp
===
--- /dev/null
+++ clang/lib/Sema/HLSLExternalSemaSource.cpp
@@ -0,0 +1,98 @@
+//===--- HLSLExternalSemaSource.cpp - HLSL Sema Source ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//
+//===--===//
+
+#include "clang/Sema/HLSLExternalSemaSource.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/Basic/AttrKinds.h"
+#include "clang/Sema/Sema.h"
+
+using namespace clang;
+
+char HLSLExternalSemaSource::ID;
+
+HLSLExternalSemaSource::~HLSLExternalSemaSource() {}
+
+void HLSLExternalSemaSource::InitializeSema(Sema ) {
+  SemaPtr = 
+  ASTContext  = SemaPtr->getASTContext();
+  IdentifierInfo  = AST.Idents.get("hlsl", tok::TokenKind::identifier);
+  HLSLNamespace =
+  NamespaceDecl::Create(AST, AST.getTranslationUnitDecl(), false,
+SourceLocation(), SourceLocation(), , nullptr);
+  HLSLNamespace->setImplicit(true);
+  AST.getTranslationUnitDecl()->addDecl(HLSLNamespace);
+  defineHLSLVectorAlias();
+
+  // This adds a `using namespace hlsl` directive. In DXC, we don't put HLSL's
+  // built in types inside a 

[clang] b8dbc6f - [HLSL] Add ExternalSemaSource & vector alias

2022-07-05 Thread Chris Bieneman via cfe-commits

Author: Chris Bieneman
Date: 2022-07-05T11:30:29-05:00
New Revision: b8dbc6ffea93976dc0d8569c9d23e9c21e33e317

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

LOG: [HLSL] Add ExternalSemaSource & vector alias

HLSL vector types are ext_vector types, but they are also exposed via a
template syntax `vector`. This is morally equavalent to the code:

```c++
template 
using vector = T __attribute__((ext_vector_type(Size)))
```

The problem is that templates aren't supported before HLSL 2021, and
type aliases still aren't supported in HLSL.

To resolve this (and other issues where HLSL can't represent its own
types), we rely on an external AST & Sema source being registered for
HLSL code.

This patch adds the HLSLExternalSemaSource and registers the vector
type alias.

Depends on D127802

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

Added: 
clang/include/clang/Sema/HLSLExternalSemaSource.h
clang/lib/Sema/HLSLExternalSemaSource.cpp
clang/test/AST/HLSL/vector-alias.hlsl

Modified: 
clang/lib/Frontend/FrontendAction.cpp
clang/lib/Headers/hlsl/hlsl_basic_types.h
clang/lib/Sema/CMakeLists.txt

Removed: 




diff  --git a/clang/include/clang/Sema/HLSLExternalSemaSource.h 
b/clang/include/clang/Sema/HLSLExternalSemaSource.h
new file mode 100644
index 0..92154427a3e72
--- /dev/null
+++ b/clang/include/clang/Sema/HLSLExternalSemaSource.h
@@ -0,0 +1,43 @@
+//===--- HLSLExternalSemaSource.h - HLSL Sema Source *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file defines the HLSLExternalSemaSource interface.
+//
+//===--===//
+#ifndef CLANG_SEMA_HLSLEXTERNALSEMASOURCE_H
+#define CLANG_SEMA_HLSLEXTERNALSEMASOURCE_H
+
+#include "clang/Sema/ExternalSemaSource.h"
+
+namespace clang {
+class NamespaceDecl;
+class Sema;
+
+class HLSLExternalSemaSource : public ExternalSemaSource {
+  static char ID;
+
+  Sema *SemaPtr = nullptr;
+  NamespaceDecl *HLSLNamespace;
+
+  void defineHLSLVectorAlias();
+
+public:
+  ~HLSLExternalSemaSource() override;
+
+  /// Initialize the semantic source with the Sema instance
+  /// being used to perform semantic analysis on the abstract syntax
+  /// tree.
+  void InitializeSema(Sema ) override;
+
+  /// Inform the semantic consumer that Sema is no longer available.
+  void ForgetSema() override { SemaPtr = nullptr; }
+};
+
+} // namespace clang
+
+#endif // CLANG_SEMA_HLSLEXTERNALSEMASOURCE_H

diff  --git a/clang/lib/Frontend/FrontendAction.cpp 
b/clang/lib/Frontend/FrontendAction.cpp
index 65160dd7e0b18..81915e6330b03 100644
--- a/clang/lib/Frontend/FrontendAction.cpp
+++ b/clang/lib/Frontend/FrontendAction.cpp
@@ -24,6 +24,7 @@
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Lex/PreprocessorOptions.h"
 #include "clang/Parse/ParseAST.h"
+#include "clang/Sema/HLSLExternalSemaSource.h"
 #include "clang/Serialization/ASTDeserializationListener.h"
 #include "clang/Serialization/ASTReader.h"
 #include "clang/Serialization/GlobalModuleIndex.h"
@@ -1014,6 +1015,13 @@ bool FrontendAction::BeginSourceFile(CompilerInstance 
,
 CI.getASTContext().setExternalSource(Override);
   }
 
+  // Setup HLSL External Sema Source
+  if (CI.getLangOpts().HLSL && CI.hasASTContext()) {
+IntrusiveRefCntPtr HLSLSema(
+new HLSLExternalSemaSource());
+CI.getASTContext().setExternalSource(HLSLSema);
+  }
+
   FailureCleanup.release();
   return true;
 }

diff  --git a/clang/lib/Headers/hlsl/hlsl_basic_types.h 
b/clang/lib/Headers/hlsl/hlsl_basic_types.h
index 2069990f5c06c..e68715f1a6a45 100644
--- a/clang/lib/Headers/hlsl/hlsl_basic_types.h
+++ b/clang/lib/Headers/hlsl/hlsl_basic_types.h
@@ -27,38 +27,38 @@ typedef long int64_t;
 // built-in vector data types:
 
 #ifdef __HLSL_ENABLE_16_BIT
-typedef int16_t int16_t2 __attribute__((ext_vector_type(2)));
-typedef int16_t int16_t3 __attribute__((ext_vector_type(3)));
-typedef int16_t int16_t4 __attribute__((ext_vector_type(4)));
-typedef uint16_t uint16_t2 __attribute__((ext_vector_type(2)));
-typedef uint16_t uint16_t3 __attribute__((ext_vector_type(3)));
-typedef uint16_t uint16_t4 __attribute__((ext_vector_type(4)));
+typedef vector int16_t2;
+typedef vector int16_t3;
+typedef vector int16_t4;
+typedef vector uint16_t2;
+typedef vector uint16_t3;
+typedef vector uint16_t4;
 #endif
 
-typedef int int2 __attribute__((ext_vector_type(2)));
-typedef int int3 __attribute__((ext_vector_type(3)));
-typedef int int4 

[PATCH] D127114: new clang-tidy checker for assignments within condition clause of if statement

2022-07-05 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 accepted this revision.
gribozavr2 added a comment.
This revision is now accepted and ready to land.

LGTM with a few minor edits.

Do you have commit access?




Comment at: 
clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.cpp:19-21
+void AssignmentInIfConditionCheck::registerMatchers(MatchFinder *Finder) {
+  // Scott Added this one
+  Finder->addMatcher(ifStmt(hasCondition(forEachDescendant(





Comment at: 
clang-tools-extra/clang-tidy/bugprone/AssignmentInIfConditionCheck.cpp:32-34
+const MatchFinder::MatchResult ) {
+  // Add callback implementation.
+  const auto *MatchedDecl =

No need to repeat the code in comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-assignment-in-if-condition.cpp:1-4
+// RUN: %check_clang_tidy %s bugprone-assignment-in-if-condition %t
+
+// Add something that triggers the check here.
+void f(int arg) {




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

https://reviews.llvm.org/D127114

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


[PATCH] D127114: new clang-tidy checker for assignments within condition clause of if statement

2022-07-05 Thread dodohand via Phabricator via cfe-commits
dodohand added a comment.

Hi @alexfh , @aaron.ballman, Could one of you have a look at this? I'd like to 
get it moving toward resolution and don't know who else ought to do a review...


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

https://reviews.llvm.org/D127114

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


[PATCH] D129048: Rewording the "static_assert" to static assertion

2022-07-05 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D129048#3630584 , @Codesbyusman 
wrote:

> Yes I am looking into the DiagnosticParseKinds.td

Excellent, thank you!

In D129048#3630589 , @Codesbyusman 
wrote:

> Yes I am looking into the DiagnosticParseKinds.td. Kindly also look another 
> error encountered in testing while updating the test. Although not having in 
> my system but this  is giving .
> Look here 
> 

I noticed that one earlier -- I think it's unrelated to your changes. (I've 
seen that test spuriously fail before and there's nothing in the test files 
that uses a static assertion, so it seems highly unlikely that changes to the 
diagnostic message caused that issue; I expect it will go away on its own when 
you push up another patch in the future.) I think it's safe for you to ignore.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129048

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


  1   2   3   >